Android 反編譯的威脅
逆向分析: 漏洞挖掘、協議分析
二次打包: 盜版、破解、廣告
保護方案
代碼混淆:Java代碼、C\C++帶馬甲、JS\HTML代碼
應用加固:DEX文件、SO文件、資源文件
APP構建過程中用到的工具
編譯流程
- java源碼編譯:通過javac將源碼編譯爲.class文件
- 多dex分包:腳本將類根據一定規則劃分到主dex和從dex中，生成配置文件
- proguard優化/混淆:對.class文件進行壓縮、優化、混淆處理
- 轉化爲dex文件:dx\d8將.class文件轉換爲dex文件
DEX加固方案的演進
- 動態加載:從服務器動態加載業務的DEX
- DEX內存加載:模擬App啓動的時候，將我們的殼、將業務DEX文件加載到內存中，然後通過一些處理方式，讓DEX文件把Application啓動起來，讓應用認爲和普通的啓動方式是一樣的 (缺點:DEX會暴露在內存中)
- DEX指令抽取:把DEX文件中的一些方法的指令抽取出來，然後在內存中開闢一段區域，然後將我們內存加載的DEX解析到相應的方法指令偏移的地方，方法指令的偏移指向我們開闢的一段內存裏面。(缺點:不徹底)
- 虛擬機加固:我們通過自己實現一套虛擬機，將DEX方法的指令抽取出來，在運行的時候，我們的虛擬機裏面就運行被抽取的一段指令。這樣攻擊者想要破解，首先必須要找到我們虛擬機的入口，將虛擬機整個邏輯還原出來，這樣攻擊成本相對比較高 (缺點:本身Android應用就運行在虛擬機裏面，不論是Dalvik還是ART，增加個虛擬機，就會增加一層對應用運行時代碼的解釋執行操作，那麼解釋執行的效率會大大下降)
- JAVA2C:提升應用運行時的效率，我們的方法會轉換爲一層在Native(JNI)上實現的邏輯，最終通過JNI編譯成so，這樣的話在本地執行，而不是在虛擬機執行，執行效率會大大提升。
DEX內存加載實現原理
框架原理
Android加殼框架原理爲Proxy/Delegate Application，即使用自定義的代理Application類作爲程序入口(修改AndroidManifest.xml)，在代理Application中完成殼的解密操作，最後啓動原來的Application
ProxyApplication:框架會提供一個ProxyApplication抽象基類(abstract class)，使用者需要繼承這個類，並重載initProxyApplication()方法，在其中改變surrounding，如替換ClassLoader等
DelegateApplication:即應用原有的Application，應用從getApplicationContext()等方法中取到的都是DelegateApplication
修改入口
將Manifest中application改爲ProxyApplication
代理Application
在ProxyApplication中實現如下內容
- 內存加載DEX:加載原Application
- ClassLoader設置
- Application引用替換
殼啓動流程
- 內存加載DEX文件:通過Dalvik、ART虛擬機JNI接口內存加載被加密隱藏的DEX文件
- 設置ClassLoader:將DEX文件內存加載產生的mCookie放入ClassLoader中(MutiDex)
- 加載原Application:基於替換後的ClassLoader查找原始Application類並生成實例
- Application還原:將API層的所有Application引用替換爲原始Application