0×00 前言


之前对Android的两个运行时的源码做了一些研究,又加上如火如荼的Android加固服务的兴起,便产生了打造一个用于脱壳的运行时,于是便有了DexHunter的诞生(源码:https://github.com/zyq8709/DexHunter/)。今天,我就通过这篇小文聊聊我的一些简单的思路,供大家参考和讨论。

0×02 相关机制


首先,先来看一看Android运行时的一些相关机制,看看我们来怎么搞。

首当其冲,要脱壳少不了研究一下Dex文件的格式,这一点Android的官方文档写的已经很清晰了,我这里就简单再提一下。整个结构便如图1所示:

图1 Dex文件结构

其实就是分区段存储不同的内容,在头部里有指向各个区段起始的偏移值。当然我们最关心的就是class_defs和data这两个段了。

class_defs包含了所有的类,用class_def_item来描述。图2是对class_def_item展开的一个示意图:

图2 class_def_item结构

每个class_def_item指向一个class_data_item,每个class_data_item 包含了一个class的数据,每个方法用encoded_method结构来描述,它又指向了一个code_item,这个里面就保存着一个方法的所有指令。

对于ART下,安装后的dex文件会被编译为oat文件,这个oat文件其实是一个ELF文件,图3是它的一个结构:

图3 OAT文件结构

其中可以看到oatdata指向的部分包含了原有的Dex文件,这个是我们的目标。当然oatexec指向了编译后的ARM指令,但是对于我们暂时来说没有什么卵用。

0×03 四个时机


为了脱壳,我们要建立一个概念,就是“时机”。对于非虚拟机壳,从内存中转储是一个最为有效和统用的技巧,那么就必须要找到一个时机,保证内存中的数据是完全正确的。

在Android中呢,便有这么四个时机:

  1. 打开Dex文件

    就是把APK中的dex文件提取并做cache,那么最终打开的其实是odex或oat文件;

  2. 加载Class

    运行时读取存储在Dex中的每个class,并用来填充一个生成的Class对象,其中包含了class的所有成员,这样一个class才能被使用;图4表示了ART和DVM下的Class对象的结构

    图4 Class的结构

  3. 初始化Class

    如果一个class有static块,那么这个部分就会编译为类的初始化器,具体看说就是方法,在class真正需要被使用的时候就会执行它,当然,壳就可以利用它来做许多事情;

  4. 调用具体的方法

    不用多说,就是根据生成的Class对象查找到具体的代码指令并执行了。

0×04 两种加载


好,那我们怎么做呢?很简单,我们就从类的加载开始。

总的来说,有两种可以加载类的方法,一个是显示加载,主要用于反射,就是通过调用Class.forName()或ClassLoader.loadClass()方法来主动加载一个类;另一个是隐式加载,主要是通过创建第一个class的实例或在类产生前访问静态成员时发生。这些操作的背后在运行时中是有相应的函数来真正完成的。

在ART中:

显式加载:

ClassLoader.loadClass 对应DexFile_defineClassNative

Class.forName 对应Class_classForName

隐式加载:

对应artAllocObjectFromCode

图5表述了这个关系:

图5 ART中的实现

在DVM中:

显式加载:

ClassLoader.loadClass对应Dalvik_dalvik_system_DexFile_defineClassNative

Class.forName对应Dalvik_java_lang_Class_classForName

隐式加载:

对应dvmResolveClass

图6是DVM中的实现表示:

图6 DVM中的实现

0×05 开始修改


很清晰看到,我们找到了关键点,在ART中是DefineClass,DVM中是Dalvik_dalvik_system_DexFile_defineClassNative,我们就从这里动手,主要的修改就发生在这里。简单地说就是主动地一次性加载并初始化所有的类。

这样做是隐含了几条原则的:

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

图7就是DexHunter的一个工作流程:

图7 DexHunter原理

下面就分这几个步骤来说:

(1) 定位内存

对于之前提到的入口函数,都有一个参数表示在操作的文件。

ART中,这个参数是DexFile对象,其中有一个location_成员,是一个字符串,可以简单的理解为此文件的路径。那么DVM中是DexOrJar,相对的字符串成员是fileName。这下我们就好整了,只要我们指定了目标字符串,我们就可以从可能使用的众多dex文件中找出我们想要的那个,而且方便的是,通过这两个对象,我们还能很容易找到操作的文件在内存中的起始地址和长度。

(2) 主动加载并初始化

这个就是遍历dex文件中class_defs区段里每一个class_def_item,并逐一加载和初始化,在ART里我们使用FindClass函数来加载类,EnsureInitialized进行初始化;在DVM中用dvmDefineClass加载,dvmIsClassInitialized 和dvmInitClass来初始化。

(3) 转储并自动修复

最后就是真正抓取dex了。把dex分为三部分:

  • Part 1: class_defs之前的内容
  • Part 2: class_defs段
  • Part 3: class_defs后边的部分

我们把Part 1存在part1文件里,Part 3存在data文件中,Part 2先不要急。

现在我们要解析class_defs的东东了。不整代码了,用文字简单来说,就是模仿Android的过程,我们把每个class_data_item解码为内存中的对象(有LEB128编码),便于我们的修复。

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

看class_def_item中的 class_data_off是不是在之前拿到的dex文件的内存范围内,如果跑出去了,就需要把这个类的class_data_item给放到dex尾部去,修改class_def_item并保存。

比较解析出来的accessflag、codeoff和运行时生成的方法对象的accessflag、codeoff,如果不一致,以运行时中的为准,并修改保存。

同样,检查code_item_off是否出界了,一旦出界,把code_item收回来,继续向尾部添加,并修改class_def_item的相关内容重新保存。

当然了,所谓放到尾部,只是先保证偏移值从尾部开始的,真正的内容先存在extra文件了。被修改过的class_defs段,就保存在classdef文件中了。

然后我们把四个文件重新拼起来,就得到原始的dex或odex了。

0×06 有趣的现象


最后聊一下我们看到的一些有趣的现象。

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

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

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

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

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

0×07 参考


https://source.android.com/devices/tech/dalvik/dex-format.html
/libcore/libart/src/main/java/java/lang/ClassLoader.java
/libcore/libdvm/src/main/java/java/lang/ClassLoader.java
/libcore/dalvik/src/main/java/dalvik/system/DexClassLoader.java
/libcore/dalvik/src/main/java/dalvik/system/PathClassLoader.java

https://github.com/anestisb/oatdump_plus#dalvik-opcode-changes-in-art