封面圖1014.png

根據國家互聯網金融風險分析技術平臺監測數據顯示：截至 2020 年 5 月底，共發現 2801 個互聯網金融仿冒 App ，仿冒 App 下載量高達 3343.7 萬次。

“李逵”和“李鬼”

互聯網環境下，盜用和剽竊能有多簡單？

先看一波新聞標題感受下：

《北斗衛星導航系統全球免費，卻因山寨app收費20元連中國人都誤會》
《500萬人用山寨12123查違章？高仿APP不只是坑錢》
《關注：小米金融被騙子盯上遭假冒，真假難辨山寨APP要警惕！》
……

根據國家互聯網金融風險分析技術平臺監測數據顯示：截至 2020 年 5 月底，共發現 2801 個互聯網金融仿冒 App ，仿冒 App 下載量高達 3343.7 萬次。

伴隨著移動應用數量的井噴式增長，對於一個 App 來說，被山寨和盜版無疑成為了每一個應用開發者最頭疼與煩惱的問題之一。

移動端黑產日益壯大，伴隨而來的逆向攻擊手段也越來越高明，基於 java 開發的 Android 應用因其語言的特性和系統的開源屬性，大量 Android 應用程序面臨著應用程序遭逆襲破解、知識產權被侵犯、被二次打包簽名等安全問題。

為解決上述問題，在 APK 上傳至應用市場之前，需要先對 APK 進行加固並對加固後的 APK 進行兼容性測試，可最大限度保障應用不被破解。

加固技術的演進與優化

傳統加固

第一代加固技術採用的是Dex加密存儲，解密時落地；落地之後通過自定義的DexClassLoader將解密出的Dex加載到內存中，然後程序運行該文件（Dex是APK的Java代碼經過編譯後生成的文件，可以簡單理解為Java的邏輯）。

其脫殼方式很簡單：因為Dex加密是整體進行的，解密時還會落地。可以通過HOOK文件操作（Read、Write、Delete）將Dex文件脫殼出來，通過反編譯工具分析，從而得到APP的核心邏輯。

之後對第一代版本進行了升級，與未升級版相比：Dex加密存儲方式相同，但解密時不落地；解密之後在內存中通過自定義DexClassLoader進行加載。升級版本的脫殼方法也比較簡單，主要採用內存Dump方法，將文件寫到磁盤中，通過HOOK dvmDexFilePartial的方式達到脫殼目的。

第二代加固方式採用的是Dex Method方法抽離，Dex在內存中加載時不連續。其原理是：Method方法通過一些加固方法抽離，APK在運行時，整個Dex會一併修復，然後在內存中運行，也就說在內存中有著完整的Dex代碼。第三代方式與第二代相比同樣是採用Dex Method方法抽離，但Dex執行中動態解密。兩者的差異在於：後者在APK運行時，Dex文件是不進行修復的，而是等到Class被執行時才進行解密。

對第二代和第三代進行脫殼前，需要先了解Dex結構。Dex結構從dex_header開始，在頭部存在Dex的標誌位；然後逐步按結構指向Method結構體，Method結構中的code_off字段最終指向可執行代碼。因此在第二代和第三代的脫殼過程中，需要HOOK DVM虛擬機中很底層的函數，從而拿到需要執行的APK的類，進而得知Class object全部方法；然後在內存中對DEX進行重建，重建之後再將其Dump到本地，得到脫殼之後的Dex文件，便於後續採用工具分析。

除了上述的脫殼方式之外，通用的脫殼機（開源的Zjdroid、DexHunter）也可以輕鬆脫掉大部分殼；並且，由於傳統的加固方式容易被脫殼，導致目前脫殼類教程非常之多。因此，傳統的加固方式面臨著很大的挑戰。

全量混淆

針對層出不窮的脫殼方式。阿里內部經過多次討論後，認為傳統的加固方式已過時，需要轉變思路：混淆。

ProGuard混淆

在APP發佈前，通常會對應用進行ProGuard混淆，類似上圖的配置。圖中的proguard-android.txt/proguard-rules.pro是ProGuard的混淆規則。在Java中，某些特性如反射調用以及可序列化類等是需要保留的，因此需要人工配置一些複雜的規則。當規則全部配置成功後，對APK進行反編譯，從上圖可以看到某些邏輯被混淆成了a、b、c等，進而大大增加了黑客逆向分析的難度。

通過混淆可以增加逆向分析的難度，但並不代表著不能分析。上圖是對金山隱私保險箱逆向分析的案例，通過反編譯工具分析，得知金山隱私保險箱對其核心代碼進行了混淆，例如它的類名是a、b、c等形式。由於ProGuard混淆時需要配置很多規則，很多開發人員為了保障兼容性會保持很多類，導致APK內的邏輯並不全部混淆，進而導致安全性的降低，通常ProGuard混淆率在10%-30%。

為了解決ProGuard混淆需要配置很多規則導致混淆效率低下的問題，阿里內部研發了全量混淆技術。上圖左側是手淘在未混淆之前的反編譯情況，其中的類、函數名都是一目瞭然的；經過全量混淆之後的效果圖如右側所示：類名全部變成了a、b、c的類型，並且全量混淆幾乎是不用任何配置的，大大降低了使用成本。目前，全量混淆已在線上對外發布。

優化瘦身

隨著APK功能的增加，其體積也在不斷地增大，例如手淘、支付寶等應用達到五十幾兆、遊戲類的APK達到幾百甚至上千兆，進而引發了手機資源存儲、用戶下載流量浪費等問題。因此APK優化瘦身勢在必行。

APK優化瘦身的實現邏輯主要包括：首先，清除Dex文件Debug信息，減少編譯器自動產生函數，優化性能，減少體積；其次，通過Java層攔截技術，對SO進行重新打包壓縮，減少體積；同時，修改Android應用資源名稱，通常資源名稱是帶有實際意義的，通過將帶有實際意義的長文件名修改成上文所示的a、b、c等形式既減少應用體積，又提高了資源保護強度；此外，通過自行開發的7z工具，對簽名後的APK包重新壓縮，達到進一步減少體積的目的。