论Android代码加固的意义和hook详解手机开发

加固的意义

从安卓2.x版本起，加固技术就逐渐火了起来。最初，只有一些创业型公司涉及加固领域；随着安卓应用的逐渐升温，诸如阿里、腾讯、百度等大型互联网公司逐渐涉及该领域。

那么为什么要对APP进行加固呢？主要原因有三点：首先安卓的APP应用通常采用Java语言编写的，开发门槛低，容易被反编译（解释性语言的弊端）；其次安卓市场比较混乱且可自签名，进而导致大量应用被二次打包，植入广告、木马；同时，手机Root后，黑客可利用Hook等技术手段可对应用进行动态攻击，获取应用的核心逻辑。综合这三点来看，安卓应用的安全系数是非常低的，因此APP加固就有了意义：应用加固之后可以有效减少反编译、二次打包、植入广告木马等操作。

传统加固

第一代加固技术采用的是Dex加密存储，解密时落地；落地之后通过自定义的DexClassLoader将解密出的Dex加载到内存中，然后程序运行该文件（Dex是APK的Java代码经过编译后生成的文件，可以简单理解为Java的逻辑）。

其脱壳方式很简单：因为Dex加密是整体进行的，解密时还会落地。可以通过HOOK文件操作（Read、Write、Delete）将Dex文件脱壳出来，通过反编译工具分析，从而得到APP的核心逻辑。

之后对第一代版本进行了升级，与未升级版相比：Dex加密存储方式相同，但解密时不落地；解密之后在内存中通过自定义DexClassLoader进行加载。升级版本的脱壳方法也比较简单，主要采用内存Dump方法，将文件写到磁盘中，通过HOOK dvmDexFilePartial的方式达到脱壳目的。

第二代加固方式采用的是Dex Method方法抽离，Dex在内存中加载时不连续。其原理是：Method方法通过一些加固方法抽离，APK在运行时，整个Dex会一并修复，然后在内存中运行，也就说在内存中有着完整的Dex代码。第三代方式与第二代相比同样是采用Dex Method方法抽离，但Dex执行中动态解密。两者的差异在于：后者在APK运行时，Dex文件是不进行修复的，而是等到Class被执行时才进行解密。

对第二代和第三代进行脱壳前，需要先了解Dex结构。Dex结构从dex_header开始，在头部存在Dex的标志位；然后逐步按结构指向Method结构体，Method结构中的code_off字段最终指向可执行代码。因此在第二代和第三代的脱壳过程中，需要HOOK DVM虚拟机中很底层的函数，从而拿到需要执行的APK的类，进而得知Class object全部方法；然后在内存中对DEX进行重建，重建之后再将其Dump到本地，得到脱壳之后的Dex文件，便于后续采用工具分析。

除了上述的脱壳方式之外，通用的脱壳机（开源的Zjdroid、DexHunter）也可以轻松脱掉大部分壳；并且，由于传统的加固方式容易被脱壳，导致目前脱壳类教程非常之多。因此，传统的加固方式面临着很大的挑战。

全量混淆

针对层出不穷的脱壳方式。阿里内部经过多次讨论后，认为传统的加固方式已过时，需要转变思路：混淆。

ProGuard混淆

在APP发布前，通常会对应用进行ProGuard混淆，类似上图的配置。图中的proguard-android.txt/proguard-rules.pro是ProGuard的混淆规则。在Java中，某些特性如反射调用以及可序列化类等是需要保留的，因此需要人工配置一些复杂的规则。当规则全部配置成功后，对APK进行反编译，从上图可以看到某些逻辑被混淆成了a、b、c等，进而大大增加了黑客逆向分析的难度。

通过混淆可以增加逆向分析的难度，但并不代表着不能分析。上图是对金山隐私保险箱逆向分析的案例，通过反编译工具分析，得知金山隐私保险箱对其核心代码进行了混淆，例如它的类名是a、b、c等形式。由于ProGuard混淆时需要配置很多规则，很多开发人员为了保障兼容性会保持很多类，导致APK内的逻辑并不全部混淆，进而导致安全性的降低，通常ProGuard混淆率在10%-30%。

为了解决ProGuard混淆需要配置很多规则导致混淆效率低下的问题，阿里内部研发了全量混淆技术。上图左侧是手淘在未混淆之前的反编译情况，其中的类、函数名都是一目了然的；经过全量混淆之后的效果图如右侧所示：类名全部变成了a、b、c的类型，并且全量混淆几乎是不用任何配置的，大大降低了使用成本。目前，全量混淆已在线上对外发布。

优化瘦身

随着APK功能的增加，其体积也在不断地增大，例如手淘、支付宝等应用达到五十几兆、游戏类的APK达到几百甚至上千兆，进而引发了手机资源存储、用户下载流量浪费等问题。因此APK优化瘦身势在必行。

APK优化瘦身的实现逻辑主要包括：首先，清除Dex文件Debug信息，减少编译器自动产生函数，优化性能，减少体积；其次，通过Java层拦截技术，对SO进行重新打包压缩，减少体积；同时，修改Android应用资源名称，通常资源名称是带有实际意义的，通过将带有实际意义的长文件名修改成上文所示的a、b、c等形式既减少应用体积，又提高了资源保护强度；此外，通过自行开发的7z工具，对签名后的APK包重新压缩，达到进一步减少体积的目的。

上图是阿里内部应用优化瘦身之后对比效果图，从图中可以看到手淘、支付宝、钉钉瘦身前后的对比，瘦身效果可以达到10%左右。

上图是市场上常见应用瘦身前后的对照表，微博、百度地图等应用优化后的减少百分比可达到百分之十几；华为账号等应用优化瘦身减少率甚至达到40+%。通常应用优化瘦身减少率在15%-20%，具体数值和APK的开发质量有关。

总结

全量混淆和优化瘦身等阿里内部使用的加固方案都是在实际业务强需求下开发的，经历了数以万计的APP和用户测试，其稳定性和可靠性绝对具有保障。