DexHunter的原理分析和使用说明（一）

本文博客地址：http://blog.csdn.net/qq1084283172/article/details/53710357

Android通用脱壳工具DexHunter是2015年下半年，大牛 zyqqyz最先在看雪论坛放出来的，见《Android
dex文件通用自动脱壳器》这篇文章的说明。作者 zyqqyz在放出DexHunter通用脱壳工具代码的同时还专门在乌云网站上写了一篇文章《从Android运行时出发，打造我们的脱壳神器》，更详细的对DexHunter通用脱壳工具的原理进行了详细的说明。当时看了几遍作者zyqqyz写的文章和silide.ppt但是还是比较蒙，不知道是咋回事，连这个工具的代码是怎么使用都没搞清楚。后面花了一段时间，将DexHunter脱壳工具的代码认真的分析一遍，比较清楚的明白了作者的脱壳的思路然后又将作者写的关于DexHunter的文章都看了几遍。现在知道怎么使用DexHunter脱壳工具的代码了，感觉作者大牛 zyqqyz对Android的dex文件的格式解析和存储以及Android运行时的类加载的详细过程非常的熟悉，在作者分享的有关DexHunter脱壳工具的文章后面，作者也将最近这一段时间里，国内一些常见加固的思路整理了一遍，特此写一篇学习的笔记，暂时只分析dvm情况下的脱壳思路。

一、作者zyqqyz总结的国内加固厂商的加固思路

DexHunter脱壳工具的处理思路和对抗思路很多也是基于加固厂商的加固思路来思考的，具体在DexHunter的代码里有体现。

1.360基本上是把原始的dex加密存在了一个so中，加载之前解密。

2.阿里把一些class_data_item和code_item拆出去了，打开dex时会修复之间的关系，同时一些annotation_off是无效的的来防止静态解析。

3.百度是把一些class_data_item拆走了，与阿里很像，同时它还会抹去dex文件的头部；它也会选择个别方法重新包装，达到调用前还原，调用后抹去的效果。我们可以通过对DoInvoke
(ART)和dvmMterp_invokeMethod (DVM)监控来获取到相关代码。

4.梆梆和爱加密与360的做法很像，梆梆把一堆read,write,mmap等libc函数hook了，防止读取相关dex的区域，爱加密的字符串会变，但是只是文件名变目录不变。

5.腾讯针对于被保护的类或方法造了一个假的class_data_item，不包含被保护的内容。真正的class_data_item会在运行的时候释放并连接上去，但是code_item却始终存在于dex文件里，它用无效数据填充annotation_off和debug_info_off来实现干扰反编译。

二、在dvm情况下，DexHunter脱壳工具的实现思路。

在dvm情况下，DexHunter脱壳工具主要的实现思路是修改Android源码文件/dalvik/vm/native/dalvik_system_DexFile.cpp里的Dalvik_dalvik_system_DexFile_defineClassNative函数的实现，具体操作是在Android系统代码调用函数dvmDefineClass进行类加载之前，主动地一次性加载并初始化Dex文件所有的类。

DexHunter脱壳工具在进行odex文件的内存dump的时候，分3部分进行内存dump：

[part
1]—–内存中从odex文件头到class_defs之前的文件数据内容（part1文件）

[part 2]—–class_defs段的文件数据内容（classdef文件和extra文件）

[part 3]—–class_defs后边到整个odex文件结束的部分的文件数据内容（data文件）

在进行odex文件的内存dump时，先dump [part
1]部分的文件数据内容到part1文件中，再dump [part 3]部分的文件数据内容到data文件中，最后先主动一次性加载并初始化dex文件的所有类，然后dump [part 2]部分文件的数据内容。但是呢，现在像前面提到的阿里、百度等的加固会在 [part 2]部分文件数据内容这里做了对抗处理，导致类的classDataOff或者类成员方法的codeOff指向的真实原始文件数据内容不在odex文件所在的内存范围内，被放在了另一份内存区域里。因此在进行dump [part 2]部分文件的数据内容时，需要进行相关的classDataOff或codeOff的相对文件偏移的修复和判断以及这部分真实原始文件数据内容的保存。DexHunter脱壳工具在dump [part 2]部分文件的数据内容时是有相关的判断，并会将这部分不在odex文件内存区域的数据保存到extra文件中，被修改过的class_defs段就保存在classdef文件。拿到odex文件的这几部分文件数据内容以后，按照odex文件的格式排布进行文件的重组，还原到whole.dex文件中。

加固处理后，超过odex文件所在内存区域的DexClassData或者DexCode这部分文件数据内容的文件相对偏移classDataOff或codeOff被设置在odex文件的末尾，并且存储在extra文件中的顺序为先存类成员方法的类字节码指令method->insns的数据再存DexClassData相关的类成员的结构信息：

DexHunter脱壳工具涉及到的知识点：

1>. dex文件的分布其实就是分区段存储不同的内容，在头部里有指向各个区段起始的偏移值。我们需要关注的就是class_defs和data这两个段了。

2>.
class_defs包含了所有的类，用class_def_item来描述，每个class_def_item指向一个class_data_item，每个class_data_item 包含了一个class的数据DexClassData，每个方法用encoded_method结构来描述，它又指向了一个code_item的DexCode，这个里面就保存着一个方法的所有指令。下图是对class_def_item展开的一个示意图：

3>.
修改的关键点，在DVM中是Dalvik_dalvik_system_DexFile_defineClassNative，主要的修改就发生在这里。简单地说就是主动地一次性加载并初始化所有的类。

DexHunter这样做隐含的几个前提条件：

当类被加载时，dex中对应的部分必须有效；
类初始化的时候，dex中的内容包括生成的Class对象是可以被修改的；
只有在执行一个方法时，才要求code_item是有效的。

DexHunter的工作流程（其中浅红色的部分就是内存dump产生的文件）：

4>. 作者 zyqqyz按脱壳思路整理的步骤：

5>.
下边就要进行一些判断–看需不需要修复:

6>.
作者 zyqq演讲的ppt的思考思路整理：

整理了这么多，大多数的知识和截图都是作者大牛 zyqqyz整理的，我只是搬运过来，代码是基本看懂了，但是真是写不明白，后面我会给出自己注释的DexHunter的代码以及DexHunter的使用的说明。本来打算一篇博文记录完毕的，看来不行，上面很多的截图是作者zyqqyz在HITCON
2015演讲ppt的内容，谢谢作者大牛。懒得打开看pdf文件了，直接把自己认为对我有帮助的直接截图在博客上，方便查阅了。