APK加固技术的演变，APK加固技术和不足之处

主流加固厂商

1. 腾讯乐固
2. 360加固
3. 阿里聚安全
4. 百度加固
5. 顶像加固
6. 网易云加固
7. 邦邦加固
8. 爱加密
9. 娜迦加固
10. 通付盾加固
11. 。。。

第一代壳：动态加载

开发过程

程序分成加载（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 会导致体积呈线性增大，性能有所下降；