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

要须心地收汗马，孔孟行世目杲杲。这篇文章主要讲述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这两个文件的解析，下面继续看：

文章图片

【Android逆向之旅---反编译利器Apktool和Jadx源码分析以及错误纠正】这里会解析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源码，都不是问题。