Android DEX加固方案与原理
生活随笔
收集整理的這篇文章主要介紹了
Android DEX加固方案与原理
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
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
總結
以上是生活随笔為你收集整理的Android DEX加固方案与原理的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: runtime error progra
- 下一篇: CentOS8 手工编译安装 Realt