题记
由于Android系统的开源属性，再加上安卓App的开发除部分采用C/C++外，其余主要都采用Java进行开发。
Java源码最终编译成smali字符码，以classes.dex的形式保存在App的apk文件中。而Java的基本类库（JDK）是开源的，这就使得安卓App被逆向破解的门槛降低。
业界有很多对apk进行逆向的工具，如Apktool、AndroidKiller、JEB、JADX等等。
为了应对大量安卓应用被逆向、篡改二次打包、调试、Hook等所衍生的安全问题，各安全厂商也是推出并不断优化移动端的加固方案。安卓App的加固技术经历了从代码混淆技术到虚拟机保护技术的发展。当然，加固与逆向，攻防相长，从未停止。
现在市场上的加固主要有两种：一种是对apk整体的加固，一种是对so文件的加固。
本文主要针对apk整体加固进行讲解。主要讲三个方面的内容：加固和逆向的基本原理、使用工具进行脱壳的实例。
一、加固的基本原理
1、Dex文件
先通过下图来了解一下保护对象dex文件的格式：
在分析这个文件的时候，最重要的还是文件头信息，因为它是一个文件的开始部分，也是索引部分。它的定义如下：
而对于文件头我们重点关注这三个部分：
1) checksum
文件校验码 ，使用alder32 算法校验文件除去 maigc ，checksum 外余下的所有文件区域 ，用于检查文件错误。
2) signature
使用 SHA-1 算法 hash 除去 magic，checksum 和 signature 外余下的所有文件区域 ，用于唯一识别本文件。
3) file_size
dex文件的大小 。
为什么要关注这三个字段呢？原因是在加固过程中涉及对dex的重新拼接。dex拼接后要修改这三个字段，字段修改正确后才能保证dex的正确加载。待会我们讲到加固的基本原理就清楚了。
2、Dex文件加固原理
dex文件进行整体加固的原理如下：
在加固的过程中需要三个对象：
1）需要加密的源apk
2）壳程序apk(负责解密apk的工作)
3)加密工程(将源apk进行加密，然后和壳dex合并成新的dex)
对App dex进行加固的基本步骤如下：
第一步：从需要加密的源apk文件里获取到原始dex文件。
第二步：使用加密工程对原始dex文件进行加密。
第三步：从壳程序apk中获取到壳dex，将壳dex和第二步加密的源dex文件进行合并，用合并后的dex替换源dex。
第四步： 因为源apk文件已经被修改，所以需要删除源apk的签名信息，即删除META-INF目录下的.RSA、.SF 和MANIFEST.MF文件。
第五步：生成加固后的apk文件。
第六步：对加固后的apk文件进行签名，apk加固完成。
通过上述步骤，我们将一个文件(加密之后的源apk)写入到壳dex中，那么我们肯定需要修改文件校验码(checksum)，因为它检查文件是否有错误，signature也是一样，是唯一识别文件的算法，另外dex的大小也发生了改变。
所以我们需要修改dex的三个文件头，将源apk的大小追加到壳dex的末尾。
我们修改之后得到新的dex文件样式如下：
3、安卓加固技术历程
第一代加固技术-动态加载壳：对dex、so、资源文件等进行混淆及加密，运行时再解密，最后通过自定义ClassLoader动态加载源apk。
第一代加固技术的缺陷是依赖Java的动态加载机制，而这个机制要求关键逻辑部分必须解压，并且释放到文件系统，这就给了攻击机会去获取对应的文件。
第二代加固技术-不落地加载：是在第一代加固技术的基础上改进，主要解决第一代技术中关键逻辑必须释放到文件系统（俗称落地）的缺陷。通过内存动态加载dex，也就是不落地加载，可以将Dex加密放在apk中，在内存中实现解密。
版权声明：本文出自《51测试天地》第六十一期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任
