前段時間，我整出了一個 無需Root也能使用Xposed 的方法，簡單來說，就是通過 雙開技術（VirtualApp）結合本進程內的Java Method Hook（epic）實現加載Xposed模塊，從而任意修改內部App的方法。項目剛 開源 不久，有大量用戶指責 VirtualXposed 是惡意軟件，有病毒！比如說：

• VirusTotal says you have malware · Issue #10 · android-hacker/VirtualXposed
• McAfee報毒 · Issue #21 · android-hacker/VirtualXposed
• Galaxy Note8設備維護中提示對設備有害 · Issue #8 · android-hacker/VirtualXposed

以及 VirusTotal的檢測結果：

(檢測報告地址：VirusTotal )

我當時不以為然，所以沒放在心上；畢竟沒有什么病毒能這么明目張膽公開把自己的代碼放出來給別人用吧？

直到后來，面對部分XDA用戶的質疑，以及一些國外媒體的報道，我意識到，在部分用戶眼中，「病毒」這個詞對他們非常敏感，16家殺毒引擎說你有病毒，就算你覺得清者自清，別人也是敬而遠之。于是我就開始了“洗脫罪名”之旅。

剛開始的時候我也是無從下手，去網上搜索這些病毒的名字，什么 `Android:Agent-QBQ [PUP]`, `Tool.SilentInstaller.6.origin` 基本沒有什么有意義的結果；整個代碼那么多，怎么判斷是哪一部分有問題，我到底應該從哪里查起？

然后我就找了幾個做過病毒分析的工程師聊了聊，他們告訴我，目前一般對Android APK的靜態分析方法是采用特征分析，就是提取你APK安裝包里面的特征，然后拿起和病毒庫做比對，如果有匹配，那么就認為你可能是有害程序。

于是我就想，如果我是病毒分析工程師，我應該提取哪些特征呢？動態加載代碼，運行可執行文件，敏感包名？順著這個想法，我做了幾件事：

VirtualApp中有大量的 `odex`, `dex` 等字符串，針對這些串用硬編碼的base64加密串替代，運行時解密然后使用。

把所有硬編碼的類名，如微信，QQ里面的類（對這些App做過特殊處理）也用base64串代替。

修改manifest中注冊的組件名，避免被匹配為VirtualApp。

這么做之后，依然有14家反病毒引擎認為是病毒（少了2家）；當時我有點懵，心里一萬只草泥馬奔騰而過。。。

這么光靠猜實在不是辦法，需要有一種科學的方法去分析和解決這個問題。既然我們知道殺毒引擎會匹配特征，正向去猜測它提取的特征行不通，那么我們可以反過來，看看什么“東西”會命中它的哪些特征。具體來說，APK文件分為幾個部分：Manifest，資源，dex文件（Java代碼），so文件（native 代碼）以及其他文件；我們可以把APK中的一部分文件剔除，然后把這個缺失某部分的APK文件拿去給反病毒引擎檢測，如果前后檢測結果有不同，那么說明被剔除的那部分可能就是命中了某些病毒的特征，從而被誤判。當然，這種方法不一定正確，這取決于殺毒引擎如何提取特征；但是可以一試。

嘗試之后發現，只有java code才會導致殺毒引擎被判為病毒；其他之前猜想的manifest組件，so文件實際上都沒有問題。那么，到底是哪部分Java代碼被判為有問題呢？起初我打算從依賴庫的角度去做代碼剔除，不過立馬就被否定了——雖然我依賴了十幾個三方庫，但是很顯然，很有可能查到最后會發現 VirtualXposed 本身的代碼才是被判為病毒的根源。最后，我使用的方法是這樣的：

?

取出所有的Java類，根據全限定名排序。

按順序刪掉一半的類，然后打包成APK給反病毒引擎檢測；如果有變化，那么說明被刪的那部分類有問題；于是用被刪的那部分類再做二分（再刪除一半）繼續檢測，直到被鎖定為一個或幾個特定的類。如果沒有變化，那用同樣的辦法對保留的那部分類做二分。

鎖定到某些特定的類還不夠，最好能鎖定到具體的行。于是，我們可以繼續以方法為粒度進行二分測試，直到定位到所有的方法。

但是，光有思路是不行的。具體如何實施這個方案呢？你要刪除一半的類，怎么刪？很顯然，如果直接刪Java源碼，是無法編譯成功拿到最終的apk文件的。我們應該對編譯產物做處理。在D8編譯器出來之前，APK的打包流程是這樣的：

?

觀察Java 源碼以及第三方庫被打包為dex的過程，我們可以知道，刪除被編譯過后的class文件是可以達到目的的；而如果要控制這個過程，gradle的Transform API是個極佳的選擇。

另外，其實還有一條路：Android虛擬機有一套自己的虛擬機指令smali，我們也可以反編譯APK得到smali文件，刪掉部分smali文件然后重打包；這樣也可以達到目的，不過由于 gradle Transform API的存在，刪class文件的過程實現起來簡單很多，并且可操作性也強很多；再結合字節碼操作工具，我們可以對apk做各種修改來試探反病毒引擎。

最終使用的代碼在這：fuck_anti_virus.gradle。這是一個gradle插件，在項目里面直接引用即可。

?

經過數天對16個反病毒引擎的探測，我解決了所有被誤報的問題；最終的檢測結果長這樣：

?

不過這里面被誤判為病毒的代碼，實在是讓人啼笑皆非。不妨來看一下：

?

1. 敏感API調用, `openDexFileNative`, `openDexFile`，用base64編碼解決

2. 敏感API調用，`System.setProperty`，通過用反射調用繞過

3. 打印日志以及異常堆棧被誤判（這個我沒弄清楚原因，有點莫名其妙）

4. 替換Mainifest組件名

5. 修改類名，修改輸入日志的姿勢

如果第一個和第二個還能扯得上點關系，后面那幾個以及我其他的修改，我想說，不是我針對誰，這些反病毒引擎簡直都是智障。。。

?

然后分享一個最近無意中發現的代碼：

?

這是某雙開軟件，動態加載的插件逆向之后的代碼。剛開始看到的時候，我驚呆了。這尼瑪是在直接查被雙開的微信內部的數據庫啊！我記得之前說過，雙開軟件是非常不安全的，雙開軟件本身對內部的APP有著完全的控制權，而且雙開內部的APP對其他被雙開APP的數據有著完全的訪問權（比如說你在里面裝了一個惡意軟件，這個軟件可以訪問微信，支付寶的所有數據；所以把雙開軟件成為沙盒是不恰當的，這里面并不安全）。但是我沒想到，竟然真的有人這么做，而且還是雙開軟件自己干的。但如果你把這個軟件丟到殺毒軟件里面檢測呢，沒錯，很安全。就連 `Android:Agent-QBQ [PUP]`(Potentially Unwanted Program) 都沒有。

?

最后我還是想說，現在的反病毒引擎真的是弱雞。當然也可能是因為 VirusTotal是免費的，各大殺毒引擎給出的API都是比較弱雞的版本，非常歡迎各路安全工程師前來打臉 ^_^ 還有，使用雙開軟件以及Xposed等功能的時候，一定要注意安全哦～

?

https://zhuanlan.zhihu.com/p/36459486

總結

以上是生活随笔為你收集整理的一种绕开反病毒引擎的方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。