App为什么会被破-jie入侵

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

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

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

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

之前曾有媒体报道，有网络黑产专门从各种渠道找到App的apk，然后将apk文件逆向破-jie，再植入广告、病毒代码，最后重新打包投入公开市场，当不明真相的网友将带病毒广告的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文件脱壳流程：