- 腾讯乐固
- 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和系统交互
第五代加壳：VMP虚拟机源码保护 核心逻辑1、攻击者可以将指令转换/VMP加固方案当做黑盒、通过自定义的JNI接口对象对黑盒内部进行探测、记录和分析；
2、四代VMP一般和第三代加固技术配合使用、三代存在的问题、该方案依旧存在
不足之处1、基于第四代的方案：Java或kotlin => C++ 即使用java2cpp 方案
2、基于LLVM工具链实现so的VMP；
3、通过对IR进行指令转换，生成自定义的指令集IR => VM , app内部隔离出独立的执行环境，核心代码在此环境下面运行；
1、无法摆脱JNI的依赖
2、由于java2cpp 会导致体积呈线性增大，性能有所下降；
