0x00 需求

应客户需求，针对Android应用进行安全加固，本方案目前实现了防止应用被静态分析，防止二次打包功能。

0x01 背景

关于Android加壳的技术分析早几年都已在网上讨论开了，我也是多方参考看学论坛、CSDN等网站，进行了实践测试得出的方案。 APK应用加固如果仅从应用程序包本身去做安全，是不可能做到天衣无缝（毕竟你终究得让系统认得你，能够加载你，最后可以运行你），所以这种方式仅仅是防小白不能轻易的静态分析APK，比如使用apktool，backsmail，jdgui等工具反编译应用。所以市面上的不管是邦邦加固、腾讯加固、爱加密等等，针对APK应用加固也都是为了提高被反编译的难度，不能绝对的保护应用。单从加密机制方面分析，他们做的很多工作都是躲躲藏藏的，当然这在应用加固肯定能够增加一定的混淆性，但不能最终的保护应用免遭破解。 上面也说了，即使你保护的非常好，但是最终运行起来后，仍需要加载到内存中，需要虚拟机识别，这时候数据也就暴露出来了，如果该应用是运行在一台ROOT的手机上，那恭喜你，你的应用已无生还。通过一些工具dump内存就可以找到你的DEX文件，我在看雪论坛中也看到一个帖子叫脱壳神器，也是依赖于定制的Android系统对应用进行脱壳，最终得到DEX文件。

0x02 思路

APK应用加固不仅仅是从应用自身去做安全加固，更应结合应用所运行的系统一块去做安全加固。 目前所采用的方案中就是结合咱公司的安全芯片去做APK应用安全加固，通过安全芯片的硬算法去分散密钥加密DEX文件来保证应用的安全性，只有安全芯片的手机才能运行安全加固的应用。 关于APK加壳的技术，相信很多人都非常感兴趣，我也是参考别人文章，然后再分析Android源码最终优化得出来的一种方案。我大致讲一下原理，有不懂的地方请参考相关资料，应用在启动时（即四大组件调用）都会首先启动Application，所以加壳就在这里做，结合APK动态加载技术（这个可以参考谷歌官方代码android-support-multidex.jar）就完成了。

0x03 PC端加壳实现流程

开发语言使用JAVA，加上shell脚本进行APK的安全加固。 1、输入文件：已签名的APK应用包 2、使用apktool工具对该APK包进行decode，记住这里不反编译classes.dex，只解析资源文件（如果某些应用无法使用apktool工具解析，则无法进行安全加固，请注意） 3、对AndroidManifest.xml中的Application节点做修改，把android:name修改为解壳使用的XdjaApplication全称，如果应用存在android:name则把该类名称保存为meta-data，供解壳程序使用。 4、把安全加固相关的so文件根据不同平台，拷贝至相应libs目录下； 5、提取出APK中的签名证书，加密后保存至assets目录中； 6、提取目录下的源dex文件，加密后保存至assets目录中； 7、拷贝解壳classes.dex至解压目录下； 8、最后再使用apktool对该目录进行重新打包，得到加固后的APK文件； 9、加固后的APK不带签名，且签名必须使用原签名证书对应的私钥进行签名； 上述操作后，APK已经完成加固功能，可以分别使用公司ACE手机和其它手机做对比测试。

0x04 解壳实现流程

1、实现MappleApplication类继承Application，实现attachBaseContext和onCreate接口； 2、attachBaseContext接口中，首先检查应用的签名是否与原签名一致，如果不相同则直接抛出异常；然后参考android-support-multidex.jar源码中加载多dex的方法，把assets中加密的源dex进行解密并加载至当前的ClassLoader中； 3、onCreate接口中，读取AndroidManifest.xml文件，解析meta-data中是否存在应用自定义的Application（参加0x03中第3步），如果存在则实例化该类并调用其onCreate方法。 4、接下来应用就会正常运行起来了。

0x05 总结

上述已经简单描述了实现流程还有实现关键点，目前APK安全加固只实现了防二次打包、源DEX保护功能，仍有其它安全功能有待实现，如应用资源保护、应用so保护等。