代次 |
第一代 |
第二代 |
第三代 |
第四代 |
第五代 |
技术路线 |
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 |