移动端测试之安卓App加固与逆向

lsekfe

题记
　　由于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中，在内存中实现解密。

Miss_love

学习学习