Android App加固原理与技术历程

App为何会被破解入侵

随着黑客技术的普及化平民化，App，这个承载咱们移动数字工做和生活的重要工具，不只是黑客眼中的肥肉，也得到更多网友的关注。百度一下“App破解”就有5290万条结果。

​

一旦App被破解，不只使用者的照片、身份证、手机号、联系住址、邮箱和支付密码等敏感信息会泄露，还可能感染手机的操做系统，进而致使手机被入侵篡改，乃至成为攻击者操控的“僵尸网络”中的一部分。

安卓App的开发除了部分功能采用C/C++编码外，其他主要都是采用Java进行编码开发功能。Java源码最终编译成smali字符码，以classes.dex保存在App的APK中。

Java是一种解释性语言，功能强大，易用性强。初学者能轻松地学习Java，并编写简单的应用程序。并且Java的基本类库（JDK）是开源的，这就使不少Java开发的应用被逆向破解的门槛很低。目前市面上有大量的逆向破解工具，例如：Dex2Jar、JEB、JD-GUI等等。只要懂代码编程，利用这些工具就能够破解市面上那些防护薄弱、存在大量安全漏洞的App。这就很好理解为何会有如此多人去搜索“App破解”了。

以前曾有媒体报道，有网络黑产专门从各类渠道找到App的apk，而后将apk文件逆向破解，再植入广告、病毒代码，最后从新打包投入公开市场，当不明真相的网友将带病毒广告的App下载后，会带来巨大经济损失。

加固技术发展历程

传统App加固技术，先后经历了四代技术变动，保护级别每一代都有所提高，但其固有的安全缺陷和兼容性问题始终未能获得解决。而下一代加固技术—虚机源码保护，适用代码类型更普遍，App保护级别更高，兼容性更强，堪称将来级别的保护方案。

​

第一代加固技术—动态加载

第一代Android加固技术用于保护应用的逻辑不被逆向与分析，最先广泛在恶意软件中使用，其主要基于Java虚拟机提供的动态加载技术。

保护流程

开发阶段

开发阶段中将程序切分红加载（Loader）与关键逻辑（Payload）两部分，并分别打包；

​

启动流程

运行时加载部分（Loader）会先运行，释放出关键逻辑（Payload），而后java的动态加载技术进行加载，并转交控制权。

​

核心代码：

​

备注（multidex组件的加固原理）：

Android的DEX文件在设计之初程序广泛较小，因此在DEX文件设计时，只容许包含65535个函数引用。而随着Android应用的发展，大量的应用的代码已经超过了65535的限制，为了解决这个问题，Android5.0以后原生支持加载多个dex，而为了对旧版本的兼容，Android提供了multidex组件。该组件的实现原理与上面介绍的是一致的。

缺陷与对抗

第一代加固技术的缺陷是依赖Java的动态加载机制，而这个机制要求关键逻辑（Payload）部分必须解压，而且释放到文件系统，这就给了攻击机会去获取对应的文件。虽然能够经过关键逻辑（Payload）被加载后，被从文件系统删除，用于防止被复制，可是攻击者能够拦截对应的删除函数，阻止删除。

而关键逻辑（Payload）会被加密后保存，可用于对抗静态分析，可是攻击者能够经过自定义虚拟机，拦截动态加载机制所使用的关键函数，在这个函数内部，复制文件系统中的关键逻辑（Payload）文件。

第二代加固技术—不落地加载

相对第一代加固技术，第二代加固技术在APK修改方面已经完善，能作到对开发的零干扰。开发过程当中不须要对应用作特殊处理，只须要在最终发布前进行保护便可。而为了实现这个零干扰的流程，Loader须要处理好Android的组件的生命周期。

保护流程

1）Loader被系统加载。

2）系统初始化Loader内的StubApplication。

3）StubApplication解密而且加载原始的DEX文件（Payload）。

4）StubApplication从原始的DEX文件（Payload）中找到原始的Application对象，建立并初始化。

5）将系统内全部对StubApplication对象的引用使用替换成原始Application，此步骤使用JAVA的反射机制实现。

6）由Android系统进行其余组件的正常生命周期管理。

对开发零干扰的加固后启动流程：

​

另外一方面，不落地加载技术是在第一代加固技术的基础上改进，主要解决第一代技术中Payload必须释放到文件系统（俗称落地）的缺陷，其主要的技术方案有两种：

A．拦截系统IO相关的函数（如read、write），在这些函数中提供透明加解密。具体的流程是：

1）关键逻辑（Payload）以加密的方式存储在APK中。

2）运行时加载部分（Loader）将关键逻辑释（Payload）放到文件系统，此时关键逻辑（Payload）还处于加密状态。

3）加载部分拦截对应的系统IO函数（read，write等）。

4）加载部分（Loader）正常调用Java动态加载机制。因为虚拟机的IO部分被拦截，因此虚拟机读取到已经解密的关键逻辑（Payload）。

透明加解密方案流程：

​

B．直接调用虚拟机提供的函数进行不落地的加载，具体流程是：

1）关键逻辑（Payload）以加密的方式存储在APK中。 

2）运行时加载部分（Loader）将关键逻辑释（Payload）放到内存。

3）加载部分调用虚拟机内部接口进行加载。

不落地加载流程：

​

关键的系统函数以下： 

​

兼容性

方案A透明加密方案因为其须要拦截系统的IO函数，这部分会使用inline hook或者got hook等技术，其会带来必定的兼容性问题

方案B的不落地加载方案因为其调须要调用系统内部的接口，而这个接口并不导出，各个厂商在实现时又有各自的自定义修改，致使该方案存在兼容性问题。

缺陷与对抗

第二代加固技术在应用启动时要处理大量的加解密加载操做，会形成应用长时间假死（黑屏），用户体验差。

在加固技术实现上没有本质区别，虽然能防止第一代加固技术文件必须落地被复制的缺陷，可是也能够从如下方面进行对抗：

例如内存中的DEX文件头会被清除，用于防止在dump文件中被找到；DEX文件结构被破坏，例如增长了一些错误的数据，提升恢复的成本。

可是Payload被加载以后，在内存中是连续的，利用gdb等调试工具dump内存后能够直接找到Payload，进行简单的处理以后能够恢复出100%的Payload文件。

和第一代加固技术的对抗方法同样，不落地加载也没法对抗自定义虚拟机。只需对上述的关键函数进行拦截而后将对应的内存段写出去，便可恢复Payload。注意，因为IO相关的函数被拦截，因此没法直接调用read/write等函数进行直接的读写，须要使用syscall函数进行绕过。

虽然厂商会本身实现可能上述函数，从而绕过上述函数的拦截。可是Android的类加载器必须能找到对于的结构体才能正常执行，攻击者能够以类加载器作为起点，找到对应的Payload在内存中的位置。

第三代加固技术—指令抽离

因为第二代加固技术仅仅对文件级别进行加密，其带来的问题是内存中的Payload是连续的，能够被攻击者轻易获取。第三代加固技术对这部分进行了改进，将保护级别降到了函数级别。

保护流程

发布阶段

发布阶段将原始DEX内的函数内容（Code Item）清除，单独移除到一个文件中。

​

运行阶段

运行阶段将函数内容从新恢复到对应的函数体。恢复的时间点有几个方式：

A.加载以后恢复函数内容到DEX壳所在的内存区域

​

B.加载以后将函数内容恢复到虚拟机内部的结构体上：虚拟机读取DEX文件后内部对每个函数有一个结构体，这个结构体上有一个指针指向函数内容（CodeItem），能够经过修改这个指针修改对应的函数内容。

​

C.拦截虚拟机内与查找执行代码相关的函数，返回函数内容。

兼容性

指令抽离技术使用了大量的虚拟内部结构与未被文档的特性，再加上Android复杂的厂商定制，带来大量的兼容性问题。

缺陷与对抗

指令抽离技术的某些方案与虚拟机的JIT性能优化冲突，没法达到最佳的运行性能。依旧使用了java虚拟机进行函数内容的执行。攻击者能够经过自定义Android虚拟机，在解释器的代码上作记录一个函数的内容（CodeItem）。接下来遍历触发全部函数，从而获取到所有的函数内容。最终从新组装成一个完整的DEX文件。目前已经有自动化工具能够指令抽离技术中脱壳。

第三代加固DEX文件脱壳流程：

​

第四代加固技术：指令转换/VMP

第三代加固技术在函数级别的保护，使用Android虚拟机内的解释器执行代码，带来可能被记录的缺陷，第四代加固技术使用本身的解释器来避免第三代的缺陷。而自定义的解释器没法对Android系统内的其余函数进行直接调用，必须使用JAVA的JNI接口进行调用。

保护流程

主要实现由两种：

A.DEX文件内的函数被标记为native，内容被抽离并转换成一个符合JNI要求的动态库。 动态库内经过JNI和Android系统进行交互。

​

B.DEX文件内的函数被标记为native，内容被抽离并转换成自定义的指令格式，该格式使用自定义接收器执行，和A同样须要使用JNI和Android系统进行调用。

​

兼容性

第四代VMP加固技术通常配合第三代加固技术使用，因此第三代的全部兼容性问题，指令转换/VMP加固也存在。

缺陷与对抗

不论使用指令转换/VMP加固的A方案或者B方案，其必须经过虚拟机提供的JNI接口与虚拟机进行交互，攻击者能够直接将指令转换/VMP加固方案看成黑盒，经过自定义的JNI接口对象，对黑盒内部进行探测、记录和分析，进而获得完整DEX程序。

第四代加固DEX文件恢复：

​

另外，第四代VMP加固技术只实现Java代码保护，没有作到使用VMP技术来保护C/C++等代码，安全保护能力有所欠缺。

下一代加固技术—虚机源码保护

跟第四代的VMP加固技术，虚机源码保护加固是用虚机技术保护全部的代码，包括Java，Kotlin，C/C++，Objective-C，Swift等多种代码，具有极高的兼容性；使App获得更高安全级别的保护，运行更加稳定。

保护流程

虚机源码保护为用户提供一套完整的工具链，首先把用户待保护的核心代码编译成中间的二进制文件，随后生成独特的虚机源码保护执行环境和只能在该环境下执行的运行程序。

虚机源码保护会在App内部隔离出独立的执行环境，该核心代码的运行程序在此独立的执行环境里运行。即使App自己被破解，这部分核心代码仍然不可见。

虚机源码保护加固流程：

​

对抗优点

生成的虚机源码保护拥有独特的可变指令集，极大的提升了指令跟踪、逆向分析的难度。同时，虚机源码保护还提供了反调试能力和监控能力。虚机源码保护能够经过自身的探针感知到环境的变化，实时探测到外界对本环境的调试、注入等非正常执行流程变化，将调试动做引入程序陷阱，并发出警报，进而进行实时更新，提升安全强度。

加固技术发展及其攻防对抗的更迭，伴随着互联网技术发展不断升级，咱们深信邪不能胜正，而虚机源码保护加固做为当前领先的加固技术，在将来很长一段时间，可以为App提供足够强度的保护，为企业和开发者的业务发展保驾护航。

————————————————

有加固需求的同窗看这里：

Android应用加固：https://www.dingxiang-inc.com/business/stee

iOS应用加固：https://www.dingxiang-inc.com/business/ios