Android逆向之旅---反编译利器Apktool和Jadx源码分析以及错误纠正

一、前言

在之前的破解过程中可以看到我们唯一离不开的一个神器那就是apktool了，这个工具多强大就不多说了，但是如果没有他我们没法涉及到后面的破解工作了，这个工具是开源的，也是使用Java语言开发的，代码相对简单，我们今天就来分析一下他的大体逻辑，注意是大体逻辑哦，因为如果要一行一行代码分析，首先觉得没必要，其次浪费时间，有了源码，谁看不懂呢。至于为什么要分析这个工具其实原因只有一个，就是我们在之前的反编译过程中会发现，总是有那么几个apk应用不让我们那么容易的反编译，他们就利用apktool的漏洞，对apk做了一定的混淆工作，所以我们需要通过分析源码来解决这些异常错误，从而能够对每个apk反编译都是如鱼得水。

二、破解的国际惯例

其实在之前的破解文章中，我们在拿到一个apk进行破解之前，都会干这两件事：
第一件事：用压缩软件解压apk，得到classes.dex，然后使用dex2jar+jd-gui工具查看代码逻辑
但是这里我们会发现如果想看资源文件比如AndroidManifest.xml和res下面的一下xml文件都是乱码的，因为他们是遵循Android中的arsc文件格式，关于这个格式不了解的同学可以网上搜一下，但是关于这个文件格式我在之前的几篇文章中做了格式解析：
Android中如何解析资源文件样式 其实不管是什么文件格式，都是有文件格式的说明文档的，只要按照这个说明文章去做解析即可
第二件事：使用apktool工具进行反编译apk，得到smali源码和资源文件
这里得到的是smali源码，破解了这么长时间，smali语法就不做太多的介绍了，他就是Android虚拟机识别执行的指令代码，他和dex文件可以互相转化的，使用baksmali.jar和smali.jar这两个工具即可，后面会详细说到，当然这里还可以得到所有的资源文件，即arsc格式解析之后的内容，而且这个工具可以实现回编译，这个功能也是很强大的，不过后面分析源码就知道了，回编译其实是借助aapt这个强大的系统命令来完成的。
所以这里我们可以看到最终如果我们想要完全的分析一个apk，apktool工具是不可或缺的，他是开启破解大门的钥匙，这个工具也是在逆向领域敲门砖，而且现在很多比较可视化的破解工具，比如：apk改之理，jeb，gda等，其实这些工具核心都是使用apktool+dex2jar+jd-gui这三个工作组成的，只是后期做了一定的界面优化而已。

三、Apktool工具反编译常见的问题

上面说了apktool工具的地位和作用，下面我们再来看一下apktool工具在反编译的过程中会遇到哪些问题呢？
这里我们只看BAT这三家公司的app，我们在反编译的过程中发现了QQ和支付宝分别报了这两个错误：
1、QQ报了这个错误：
Exception in thread "main" brut.androlib.AndrolibException: Multiple res specs: attr/name

这个主要是因为QQ利用了apktool的一个漏洞，做了属性id的混淆



2、支付宝报了这个错误：
Exception in thread "main" brut.androlib.AndrolibException: Could not decode arsc file

这个错误其实是在使用apktool工具的时候报的错误最多的，这个主要是利用apktool的漏洞，修改了resource.arsc的头部信息



其实网上很多解决方案都是说apktool这个工具的版本太旧了，用最新版本，但是这里可以看一下apktool.jar的版本：



这个版本是最新的了。
其实反编译失败很简单，就是这些公司他们知道了apktool这个工具反编译那么牛逼，那肯定想办法不让你反编译成功呀，所以他们也去看apktool的源码，分析得到漏洞，然后进行apk的一些混淆，防止反编译，所以说防护和破解真的是无休止的战争，但是幸好apktool的代码也是更新的比较快的，所以会解决这些漏洞，但是我们在破解的时候遇到这些问题，不能一味的等待apktool的更新，既然是开源的，那么就直接分析源码，发现报错的地方修复即可。

四、分析Apktool源码

上面说了为什么要分析apktool的源码，下面就真正的开始分析吧
当然第一步先得到apktool的源码吧，地址：https://code.google.com/p/android-apktool/
看到有google的域名是不是瞬间感觉整个人都不好了，的确国内程序猿一般打开都是始终loading的过程，直至error，所以我们只能去万能的github上search了，找到了这个地址：https://github.com/iBotPeaches/Apktool，可以看到这个有很多人关注，而且代码是有人维护和更新的，所以靠谱，clone到本地。
但是他是一个gradle项目，所以咋们就给Eclipse装一个gradle插件，然后导入项目即可，这里因为apktool是Java项目，所以还是使用Eclipse比较习惯吧。但是这里又遇到一个蛋疼的地方，还是国内网络的问题，gradle下载失败，因为这里引用了一些第三方的jar



好吧，那么我们只能无奈的手动去一个一个找这些jar包，不过在这个过程中还是比较蛋疼的，就是有些jar找的很蛋疼，不过最后还是都凑齐了，没有报错了，项目结构如下：



这里Apktools这个项目是入口的项目，也是主要功能项目类，Baksmali和Smali，SmaliUtil是操作smali的工具类，BrutCommon和BrutDir，BrutUtil是一些辅助的工具类，代码简单，不做太多的解释，这里除了Apktool之外，其他工程都是一个功能库，他们直接的引用关系如下：
Baksmali依赖于：SmaliUtil
BrutDir依赖于：BrutCommon,BrutUtil
BrutUtil依赖于：BrutCommon
Smali依赖于：SmaliUtil
Apktool依赖于：Baksmali,BrutCommon,BrutDir,BrutUtil,Smali

这里直接来看看主要功能Apktools项目

第一、分析Apktool的反编译源码
首先我们知道，Java项目的入口方法肯定是main方法，搜一下找到这个Main类：



这个方法中得到参数，然后进行参数的分析和组装。继续往下看，看执行代码：



这里看到了我们经常用的一些命令参数，他们的含义这里也都可以了解到了，有一个ApkDecoder类，是反编译的核心类：



最终也是调用他的decode方法：



这里看到使用了Androlib这个核心类来做了一些操作，首先会判断需不需要解析资源文件，即arsc格式的，这里又细分了解析resource.arsc和AndroidManifest.xml这两个文件的解析，下面继续看：



这里会解析dex文件，得到smali源码，而且区分了多个dex的情况。

其实到这里我们可以发现，apktool在反编译的整个过程中核心点就三个：
解析resource.arsc文件，AndroidManifest.xml文件，dex文件
那么关于这三个文件的格式解析，一定请看这篇文章：Android中解析所有文件格式
如果看了这篇文章之后，会发现Android中的这三个文件都有各自的格式，解析也是很简单的。所以这里就不在详细介绍了具体的解析步骤了，但是这三个文件分别对应的三个经典格式图必须展示一下：
AndroidManifest.xml文件格式图：



Resource.arsc文件格式图：



Dex文件个格式图：



这三张图可算是经典中的经典，而且一定要看懂，因为不看懂这三张图的话，自己在分析apktool解析源码的时候会非常的费劲。

下面继续分析，Androidlib这个核心解析类其实就那么几个方法，下面来一一讲解：
1、decodeRawFiles
这个方法主要解析原生的文件，就是Android在编译apk的过程中不参与编译的文件目录，一般是assets和libs



2、decodeManifestWithResources
这个方法主要是解析AndroidManifest.xml的



我们知道Android在安装一个apk的时候，肯定也是需要解析AndroidManifest.xml文件的，而且Android中解析xml文件采用的是Pull解析法，所以这里直接把Android中的一些方法copy过来了。



然后在弄一个xmlPull的解析jar包即可：



3、decodeResourcesFull
这个方法用来解析resource.arsc文件的，这个文件我们知道他主要包含了所有资源文件的一种格式，Android中资源文件都有相应的类型，以及唯一的一个整型id值，那么这个文件就包含这些内容



这个方法其实用到的解析类和AndroidManifest.xml的解析类是一样的，因为他们都属于arsc格式，而且资源文件也是xml格式的，这里值得注意的是，会产生一个反编译中最关键的一个文件：public.xml，这个文件是在反编译之后的res\values\public.xml



这里可以看到，一个id字段，都有对应的类型，名称，和id值的
而这里的id值是一个整型值，8个字节；由三部分组成的：
PackageId+TypeId+EntryId
PackageId：是包的Id值，Android中如果是第三方应用的话，这个值默认就是0x7F，系统应用的话就是0x01，具体我们可以后面看aapt源码得知，他占用两个字节。
TypeId：是资源的类型Id值，一般Android中有这几个类型：attr，drawable，layout，dimen，string，style等，而且这些类型的值是从1开始逐渐递增的，而且顺序不能改变，attr=0x01，drawable=0x02....他占用两个字节。
EntryId：是在具体的类型下资源实体的id值，从0开始，依次递增，他占用四个字节。

4、decodeSourcesSmali
这个方法主要是将dex文件解析成smali源码



这里使用了SmaliDecoder的decode方法：



这里需要借助一个工具包dexlib，他是用来处理dex文件的，处理完dex文件之后，在交给baksmali这个工具类生成smali文件即可。

到这里我们可以看到上面就大致分析完了apktool在反编译的时候做的主要三件事：
解析resource.arsc，解析AndroidManifest.xml，解析dex文件
源码分析完了，下面就开始测试运行一下，这里用使用了BAT三家的主要app做实验：



这里为了运行简单，我们在入口的main方法中，去手动构造一个参数：



这里用了BAT三家的几个app测试，发现，只有qq和支付宝有问题，所以这里就直接看着两个app反编译会出现什么错误，然后来分析解决这个问题：
1、分析QQ应用反编译的问题



这里报错了，错误和我们开始使用apktool工具的时候是一样的，看看崩溃代码：



这里可以发现，使用一个Map结构存放ResResSpec格式数据的，而且key是spec的name值，那么我们知道资源id的值是唯一的，这里不可能会出现相同的name值的，是腾讯做了混淆机制，这种混淆机制只对apktool工具有效，对Android系统解析apk运行是不影响的，那么问题就好办了，我们知道了崩溃的原因，修复也就简单了，直接加一个判断，判断这个key是否存在map中，存在的话就直接返回即可：



再次运行：



看到了，过滤了重复的资源值，反编译成功了，这里因为反编译过程中会用到系统的资源id，需要需要系统资源包framework.apk参与解析工作，这里因为QQ程序包比较大，反编译时间会长点。我们可以去看看反编译之后的目录：



我们可以看看他的AndroidManifest.xml内容：



解析成功，可以正常查看了。
这里我们就解决了QQ反编译的问题了，

2、分析支付宝应用反编译的错误问题



看到了，这个错误和我们开始看到的错误是一样的，下面我们看看崩溃的地方是什么原因导致的：



这里是读取一个字符串常量池Chunk头部信息报错的，关于Chunk的头部信息可以参考这篇文章：Android中解析resource.arsc文件
StringChunk的头部信息包括这些内容：
header：标准的Chunk头部信息结构
stringCount：字符串的个数
styleCount：字符串样式的个数
flags：字符串的属性,可取值包括0x000(UTF-16),0x001(字符串经过排序)、0X100(UTF-8)和他们的组合值
stringStart：字符串内容块相对于其头部的距离
stylesStart：字符串样式块相对于其头部的距离

其中header是一个标准的Chunk头部信息：
type：是当前这个chunk的类型(两个字节)
headerSize：是当前这个chunk的头部大小(两个字节)
size：是当前这个chunk的大小(四个字节)

就是八个字节。
我们继续分析错误代码：



这里会检查已给Chunk结构的完整性，出入的StringPool值是：



看到了，这里是字符串常量池Chunk的头部信息，而且值是固定的：0x001C0001
在进入看看代码：



这里如果发现格式不正确就抛出一个异常，也就是格式不是0x001C0001的话。
那么问题差不多清楚了，这里崩溃的原因很可能是支付宝应用的resource.arsc的StringPool的Chunk的头部信息被混淆了，导致这个错误的，我们通过上面的分析知道，StringPool这个Chunk的头部标准格式是：0x001C0001，我们来看看支付宝应用的resource.arsc文件的二进制数据：



发现了，有这个值，那么为何还报错呢？到这里我们或许不知道该怎么办了，其实很简单，我们再去弄一个能够反编译的apk的resource.arsc文件看看：



擦，发现果然不一样，支付宝头部信息多了8个字节，0x000001000，那么我们再看上面的检查Chunk头部类型数据的代码：



其实，这里可以看到，apktool其实已经做了一个头部信息的检查，但是这里只是检查0x001C0001这个正确信息之前的值只有四个字节，而且是0的情况，这里读取int整型值，四个字节，发现如果等于传递进来的possible的话即0，就继续执行这个方法，但是这里的possible值是-1了，也就是这里只会检查四个字节，但是我们分析了支付宝的resource.arsc文件，发现他是8个字节，而且还不全是0，是前四个字节是0，后四个字节是1：



所以这里检测也是失败的，抛出异常了。

好了，到这里我们就分析完了支付宝的资源文件混淆的机制了，下面我们修改就简单了，首先。我们把上面的8个字节全部改成0：



然后替换之前的resource.arsc文件，直接用压缩软件替换即可，
然后在修改上面的检测代码：



这里，修改代码，就是会做一直检测，直到遇到正确的值为止，我们修复完成之后，运行：



哈哈，不报错了，看看反编译之后的目录：



反编译也成功啦啦~~

我们通过上面的分析就知道了，现在使用apktool反编译的主要两个错误就是：
1、Exception in thread "main" brut.androlib.AndrolibException: Multiple res specs: attr/name
异常原因：通过分析源码知道，这个错误主要是因为apk做了混淆操作，导致在反编译的过程中存入了重复的id值，错误代码：
ResTypeSpec.java的addResSpec方法78行

修复：在这个方法存入map数据之前做一个判断操作即可
2、Exception in thread "main" brut.androlib.AndrolibException: Could not decode arsc file
异常原因：通过分析源码知道，这个错误主要是因为apk了做了resource.arsc头部信息的修改，导致在分析头部数据结构的时候出错，错误代码：ExtDataInput.java的skipCheckChunkTypeInt方法 73行
修复：修复resource.arsc头部数据，修改skipCheckChunkTypeInt检测方法逻辑

第二、Apktool的回编译源码分析
到这里我们就分析完了apktool的反编译功能源码，也解决了QQ和支付宝应用反编译的失败问题，下面再继续分析一下apktool的回编译功能，关于回编译功能的话，这里可以先看这篇文章：Android中编译Apk的步骤分析 这里我们可以知道aapt命令的功能：



使用aapt命令编译资源文件
aapt package -f -m -J gen -S res -I D:/android-sdk-windows/platforms/android-16/android.jar -M AndroidManifest.xml
这里的命令参数有点多就不全部介绍了，就说明几个：
-J 后面跟着是gen目录，也就是编译之后产生的R类，存放的资源Id
-S 后面跟着是res目录，也就是需要编译的资源目录
-l 后面跟着是系统的库，因为我们在项目资源中会用到系统的一些资源文件，所以这里需要链接一下
-M 后面跟着是工程的清单文件，需要从这个文件中得到应用的包名，然后产生对应的R文件和包名。

而且，这个命令不仅可以进行编译，可以反编译，就是上面我们提到的解析AndroidManifest.xml和resource.arsc的时候，使用它可以做到的，解析dex文件可以使用dumpdex这个命令的。这些命令都是在androidsdk目录的build-tools目录下。
知道了这个编译过程，其实回编译就是按照这个步骤来的，而这里重要的就是使用aapt命令：



这里我们把命令放到了项目的framework目录下：



然后开始构造命令参数，主要需要引用系统的jar包：android.jar



这里就差不多分析完了回编译的功能，我们修改一下入口代码，添加回编译运行参数：



运行程序：



回编译成功，得到apk文件：



不过这个文件是没有签名的，需要签名，这里不继续了，不是本文的讲解的知识点了。

到这里我们就分析完了apktool工具所有的源码了，其实他的功能很简单：
1、反编译的过程中主要是解析AndroidManifest.xml，resource.arsc，dex文件
2、回编译的时候借助aapt命令完成编译操作

五、分析Jadx源码

下面继续来看反编译的另外一个神器：Jadx
这个工具也是开源的，可以直接去github上去搜索：https://github.com/skylot/jadx
这个工具其实和apktool反编译的功能差不多，但是有一个特色，就是他的可视化功能，能够高效的分析apk的结构，下面来看一个例子：



看到了吧，这里感觉结构很清晰，而且是可视化的，分析起来会比较方便，感觉他是集成了apktool+jd-gui的功能，但是他和apktool相比的话，还是有点缺陷的，首先他反编译会比较耗时，这个后面说，其次是他不能修改代码，进行回编译的，这个是很蛋疼的，所以他和apktool相比较的话，还是差了点，但是他反编译还是很靠谱的，这里为什么分析它呢？其实是因为他是开源的，其次是借助了asm这个工具来生成class文件，实现Java代码的可视化。
下面就来说说asm这个工具类的用途：
这里写了一个demo来看看效果：



运行结果：



这里没有打印Hello world!的代码，但是结果却打印了，这个就是asm功能了：能够手动的构造一个class文件



这个功能，大家是否联想到了，动态代理模式，会产生一个动态代理类，而且还会生成一个Proxy.class文件，而且在JavaWeb中的Spring框架中的Cglib也是采用了这个功能来实现AOP编程的，他可以通过输入一个字符串来定义类，给这个类添加方法，字段等信息，然后生成类的字节码数组，可以保存成class文件，同时也可以使用ClassLoader来加载字节码数据，然后在反射调用指定的方法。
那么其实Jadx的可视化功能就是借助于这个功，同时著名的dex2jar工具也是的，可以去dex2jar工具的lib目录看看：



那么Jadx的反编译步骤是这样的：
解析dex文件=》smali源码=》解析smali指令=》借助asm生成class文件=》解析class文件得到Java源码

Apktool+Jadx源码下载：http://pan.baidu.com/s/1cHU30M

六、总结
好了，到这里我们就分析完了Apktool和jadx的源码了，我们这里主要还是分析了Apktool的源码，因为我们在反编译的过程中还是需要借助这个神器的，其实他内部没什么神秘的，就是解析三个文件，因为apktool是开源的，所以一些公司就会去找他的漏洞，然后通过这个漏洞来给自己的apk加固，增加反编译的困难，但是我们也是可以分析apktool源码的，知道了反编译的错误信息，也是可以去分析错误，然后修复错误，最终还是可以反编译成功的，所以这种资源加固来抵抗apktool的方案其实效率并没有那么高，因为只要有apktool源码，都不是问题。

更多内容：点击这里关注微信公众号，最新Android技术实时推送