AndroidManifest文件格式、Resource.arsc文件格式解析与混淆

   0x01 AndroidManifest文件格式解析

    1.1 文件格式解析

    我们就不重新造车轮子了，参考Android逆向之旅---解析编译之后的AndroidManifest文件格式。

    提示下，在看这篇文章时，大家最好下载了010editor，并且下载了解析AndroidManifest文件的模板AndroidManifestTemplate.bt，这样可以帮助我们更加清晰的理解文件结构。

    1.2 混淆AndroidManifest文件

    我们在axml(注意是axml不是AndroidManifest.xml)中添加一个属性，该属性的属性名是name，属性的值是some.class，属性的ID号为0。根据前文所述，android系统对于非法的res ID号是不会解析的。所以我们添加这个无用的属性后，并不影响该APK的正常工作(上图左下角所示)，但是对于apktool之类的逆向工具而言，他们却会对这个无用的属性进行解析(上图右下角所示)。所以，如果我们进行重打包的话，Apktool就会将该属性变更为一个ID号0x01010003的可以被系统解析的属性。这样造成的后果就是：由于我们的APK中并没有实现trap.class类，所以APK启动时会报错“there is no trap.class~~”。

    参考AndroidManifest Ambiguity方案原理及代码，这里已经实现，并且开源了。

   0x02 Resource.arsc文件格式解析

    2.1 文件格式解析

    我们同样不重复造车轮子了，参考Android逆向之旅---解析编译之后的Resource.arsc文件格式。

    同样也有模板，https://github.com/tomken/010_template_for_android/blob/master/ARSCTemplate.bt。

    2.2 混淆Resource.arsc文件

    这里没有混淆文件的源码，只有混淆后的样本和破解思路，参考Android逆向之旅---反编译利器Apktool和Jadx源码分析以及错误纠正中的分析支付宝应用反编译的错误问题。

    支付宝混淆了Resource.arsc，使Apktool反编译失败。于是我们找到了Apktool中对应的代码，理解了为什么会失败，然后修改Resource.arsc，使Apktool正常工作。关于Apktool导入与调试，请参考反编译利器Apktool和Dex2jar导入源码以及编译调试。

    0x03 混淆dex文件

    参考Android应用方法隐藏及反调试技术浅析，这个dex使DexCode结构的debugInfoOff字段设置为0xFEEEEEEE，使反编译失败，通过修改Apktool的源码，可以修复这个崩溃。

    ps：Apktool源码中均有解析AndroidManifest文件结构和Resource.arsc文件结构的源码。Apktool重打包(回编译)的时候也是借助aapt命令完成编译操作的。