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://download.csdn.net/detail/jiangwei0910410003/9655578


六、总结

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


《Android应用安全防护和逆向分析》

点击立即购买:京东  天猫

更多内容:点击这里

关注微信公众号,最新Android技术实时推送

阅读更多

扫码向博主提问

尼古拉斯_赵四

博客专家

非学,无以致疑;非问,无以广识
去开通我的Chat快问
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/jiangwei0910410003/article/details/51671019
个人分类: Android 逆向之旅
所属专栏: 移动安全与逆向
上一篇Apk脱壳圣战之---脱掉“爱加密”的壳
下一篇Apk脱壳圣战之---脱掉“360加固”的壳
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭