主流加固厂商
- 腾讯乐固
- 360加固
- 阿里聚安全
- 百度加固
- 顶像加固
- 网易云加固
- 邦邦加固
- 爱加密
- 娜迦加固
- 通付盾加固
- 。。。
第一代壳:动态加载
开发过程
程序分成加载(loader)与关键逻辑(payload)两部分,并分别打包
核心逻辑
启动时loader会先运行,释放出关键逻辑payload,然后使用java的动态加载技术进行加载,并转交控制权
不足之处
1、payload部分需要解压和释放在文件系统中,可以直接获取
2、可以通过hook虚拟机关键词函数,在加载payload时把dex在内存中dump出来
第二代壳:内存不落地加载
开发过程
加载loader,初始化StubApplication,解密后加载payload,转交控制权给原来的appcation的Oncreate方法,最好正常加载其他组件
核心逻辑
1、拦截系统IO相关函数,如read/write,在这些函数中提供透明加密
2、直接调用虚拟机提供的函数进行不落地加载,即内存加载。
不足之处
1、在启动时进行大量的解密操作,容易造成卡顿或者假死
2、payload被加载后,在内存中是连续的,拦截关键函数在内存dump还是可以直接获取的。
第三代壳:代指令抽取
开发过程
首先经保护级别降到函数级别,然后将原始的dex内的函数内容Code Item清场、单独移到加密文件、运行时再讲函数内容重新恢复到对应的函数体
核心逻辑
1、加载后恢复函数内存到dex 所在的内存区域
2、虚拟机读取dex文件后,内存对每一个函数有一个结构体,其中有一个只在指向函数的内容Codeitem,可以通过修改这个指针修改对应的函数内容
3、拦截虚拟机内与查找执行代码相关的函数,返回函数内容
不足之处
1、指令抽取方案跟虚拟机的jit优化冲突、达不到最佳的性能
2、依然使用java虚拟机进行函数内容执行,无法对抗自定义虚拟机如dexhunter
3、使用大量的虚拟机内部结构、存在兼容性问题
第四代壳:转换指令
核心逻辑
1、dex文件的函数被标记为native,内容被抽取并转化为JNI标准的动态库so文件、so文件通过JNI和Android系统交互
2、函数体内容被抽离并转换成自定义的指令格式、该格式使用自定义的接收器执行,然后然后使用JNI和系统交互
不足之处
1、攻击者可以将指令转换/VMP加固方案当做黑盒、通过自定义的JNI接口对象对黑盒内部进行探测、记录和分析;
2、四代VMP一般和第三代加固技术配合使用、三代存在的问题、该方案依旧存在
第五代加壳:VMP虚拟机源码保护
核心逻辑
1、基于第四代的方案:Java或kotlin => C++ 即使用java2cpp 方案
2、基于LLVM工具链实现so的VMP;
3、通过对IR进行指令转换,生成自定义的指令集IR => VM , app内部隔离出独立的执行环境,核心代码在此环境下面运行;
不足之处
1、无法摆脱JNI的依赖
2、由于java2cpp 会导致体积呈线性增大,性能有所下降;