| 代次 | 第一代 | 第二代 | 第三代 | 第四代 | 第五代 |
| 技术路线 | dex透明加解密技术 | 函数级代理技术 | so文件加壳技术 | 代码混淆和虚拟化技术 | 安全容器技术 |
| 设计思路 | 对每个或每组可执行文件加壳加密，增加复杂度，让破解者因为复杂无法破解，知难而退。 | 不让破解者拿到可执行文件及关键数据 | |||
| 技术原理 | 核心思想是把需要保护的dex文件加密后打包到APK中, 在需要使用时先解密dex再加载到内存, 然后删除解密后的明文文件, 或者直接在内存中动态解密, 不释放到文件系统。 | 针对第一代技术可以被dump内存的问题进行的改进, 原理是在内存中只加载一个函数代理模块, 当APP需要使用某些功能时由该代理模块去寻找真正实现功能的函数, 找到后调用该函数并且把执行结果返回给APP, 函数代理模块相对于一个中间人的角色。 | 由于java层的保护始终受到java虚拟机的限制, 无法防止自定义java虚拟机的***, 所以第三代技术将保护移动到了更底层的so文件上, 通过将核心代码封装到so文件中, 同时对so文件加壳保护, 并且吸取了第一代和第二代技术的优点, 对so文件进行加密和防内存dump处理。 | 第四代技术将保护主体移动到粒度更细的函数层, 通过自定义编译器在编译时对代码进行混淆和虚拟化保护, 隐藏真实的业务逻辑, 增加了逆向分析的难度。 | 第五代加固技术的核心理念是让***无法拿到实体文件，无法在系统中运行任何反编译工具，自然也就无法破解，从根本上解决APP被破解的问题; 其实现原理是使用加密容器技术，构建一个与操作系统紧密耦合的容器, 让APP运行在容器中，容器对外物理隔离，容器内白名单运行APP，外界无法直接访问容器中的APP和so以及配置等文件。 |
| 缺点 | 直接对dex文件进行加解密, 逻辑简单直接, 容易实现。 | 解决了内存被dump的问题。 | 将核心代码从java层移动到了so层, 提高了破解的难度。 | 可以针对单个函数进行保护, 配置更灵活。 | APP文件始终在加密容器中, ***无法拿到so文件, 自然无法破解, 并且同时兼容前四代技术, 可以配合使用。 |
| 缺点 | 由于dex文件最终需要被解密后加载到内存中, 所以可以通过dump内存获取明文数据。 | 技术实现复杂, 兼容性差。 由于该技术仍然使用了java虚拟机执行所有函数, ***者可以通过修改java虚拟机记录代理模块找到的所有真实函数, 从而获取明文代码。 | 随着脱壳技术的发展, 和自动化脱壳技术的出现, 这种防护措施的效果也越来越差。 | 由于代码混混淆和虚拟化保护增加了额外的业务逻辑, 导致APP性能下降和体积增大; 并且该技术不能防止程序关键校验逻辑被爆破。 | 需要在操作系统中安装容器运行环境, 需要操作系统控制权，必须出厂前部署、或己方技术人员安装部署。 |
| 加固的层次 | java层 | java层 | so层 | java层/so层 | so层 |
| 加固介入的时间点 | 开发过程中/开发完成后 | 开发过程中 | 开发过程中/开发完成后 | 开发过程中 | 开发完成后 |
| 是否改变IDE环境 | 不改变 | 不改变 | 不改变 | 需改变IDE环境, 使用第三方的编译器编译代码 | 不改变 |
| 是否影响调试 | 影响 | 影响 | 影响 | 影响 | 不影响 |
| ***是否可以接触到文件实体 | 是 | 是 | 是 | 是 | 由于所有文件都在容器中, ***无法拿到文件 |
| 是否需要安装OS中间件 | 不需要 | 不需要 | 不需要 | 不需要 | 需要安装OS中间件来运行容器 |
| 适用场景 | 适合独立APP发布时增加安全，无需操作系统及设备绝对控制权的场景。如手机的应用、游戏、或其他单个安装的软件。 | 适合拥有操作系统绝对控制权的场景，或者其他场景比较固定的场景。 | |||
| 安卓应用反编译 | 适合 | 适合 | 适合 | 适合 | 不适合 |
| java/C#应用反编译 | 适合 | 适合 | 适合 | 适合 | 适合、把java应用发布在容器内 |
| python代码加密 | 不适合 | 不适合 | 不适合 | 不适合 | 适合、把python文件发布在容器内 |
| 单个EXE/DLL加壳加密 | 适合 | 适合 | 适合 | 适合 | 适合、把exe文件发布在容器内 |
| 整机保护 | 不适合 | 不适合 | 不适合 | 不适合 | 适合 |
| 主要厂家 | 已淘汰 | 已淘汰 | 爱加密，几维、360加固宝、顶象、娜迦 | 爱加密，几维、360加固宝、顶象、娜迦 | 深信达CBS |
