在日常的 Android 应用安全分析中，经常会遇到一些对抗，比如目标应用加壳、混淆、加固，需要进行脱壳还原；又或者会有针对常用注入工具的检测，比如 frida、Xposed 等，这时候也会想知道这些工具的核心原理以及是否自己可以实现。

其实这些问题的答案就在 Android 的 Java 虚拟机实现中。可以是早期的 Dalvik 虚拟机，也可以是最新的 ART 虚拟机。从时代潮流来看，本文主要专注于 ART。不过，为了铭记历史，也会对 Dalvik 虚拟机做一个简单的介绍。最后会从 ART 的实现出发j对一些实际的应用场景进行讨论。

注: 本文分析基于 AOSP android-12.0.0_r11

我们知道，Java 是一门跨平台的语言，系统实际运行的是 Java 字节码，由 Java 虚拟机去解释执行。如果读者之前看过 如何破解一个Python虚拟机壳并拿走12300元ETH 一文或者对 Python 虚拟机有所了解的话就会知道，解释执行的过程可以看做是一个循环，对每条指令进行解析，并针对指令的名称通过巨大的 switch-case 分发到不同的分支中处理。其实 Java 虚拟机也是类似的，但 JVM 对于性能做了很多优化，比如 JIT 运行时将字节码优化成对应平台的二进制代码，提高后续运行速度等。

Android 代码既然是用 Java 代码编写的，那么运行时应该也会有一个解析字节码的虚拟机。和标准的 JVM 不同，Android 中实际会将 Java 代码编译为 Dalvik 字节码，运行时解析的也是用自研的虚拟机实现。之所以使用自研实现，也许一方面有商业版权的考虑，另一方面也确实是适应了移动端的的运行场景。Dalvik 指令基于寄存器，占 1-2 字节，Java 虚拟机指令基于栈，每条指令只占 1 字节；因此 Dalvik 虚拟机用空间换时间从而获得比 Oracle JVM 更快的执行速度。

其实 Java 代码执行并不慢，但其启动时间却是一大瓶颈。如果每个 APP 运行都要启动并初始化 Java 虚拟机，那延时将是无法接受的。在 Android 12 应用启动流程分析 一文中我们说到，APP 应用进程实际上是通过 zygote 进程 fork 出来的。这样的好处是子进程继承了父进程的进程空间，对于只读部分可以直接使用，而数据段也可以通过 COW(Copy On Write) 进行延时映射。查看 zygote 与其子进程的 /proc/self/maps 可以发现大部分系统库的映射都是相同的，这就是 fork 所带来的好处。

在 Android 用户态启动流程分析 中我们分析了 init、zygote 和 system_server 的启动流程，其中在介绍 zygote 的启动流程时说到这是个 native 程序，在其中 main 函数的结尾有这么一段代码:

上述代码在 frameworks/base/cmds/app_process/app_main.cpp 中，runtime.start 的作用就是启动 Java 虚拟机并将执行流转交给对应的 Java 函数。

详细介绍可以会看 Android 用户态启动流程分析 一文，这里我们只需要知道 Java 虚拟机是在 Zygote 进程创建的，并由子进程继承，因此 APP 从 zygote 进程中 fork 启动后就无需再次启动 Java 虚拟机，而是复用原有的虚拟机执行轻量的初始化即可。

Android Java 虚拟机包括早期的 Dalvik 虚拟机和当前的 ART 虚拟机，我们将其统称为 Java 虚拟机，因为对于应用程序而言应该是透明的，也就是说二者应该提供了统一的对外接口。

这个接口可以分为两部分，一部分是提供给 Java 应用的接口，即我们常见的 JavaVM、JNIEnv 结构体提供的诸如 FindClass、GetMethodID、CallVoidMethod 等接口；另一部分则是提供给系统开发者的接口，系统通过这些接口去初始化并创建虚拟机，从而使自身具备执行 Java 代码的功能。

JniInvocation.Init 方法中即进行了第二部分接口的初始化操作，其中主要逻辑是根据系统属性 (persist.sys.dalvik.vm.lib.2) 判断待加载的虚拟机动态库，Dalvik 虚拟机对应的是 libdvm.so，ART 虚拟机对应的是 libart.so；然后通过 dlopen 进行加载，并通过 dlsym 获取其中三个函数符号，作为抽象 Java 虚拟机的接口:

例如，在上述 zygote 的 AndroidRuntime::startVm 方法实现中，就是通过指定参数最终调用 JNI_CreateJavaVM 来完成 Java 虚拟机的创建工作。

通过这三个接口实现了对于不同 Java 虚拟机细节的隐藏，既可以用 ART 无缝替换 Dalvik 虚拟机，也可以在未来用某个新的虚拟机无缝替换掉 ART 虚拟机。

总的来说，Java 虚拟机只在 Zygote 进程中创建一次，子进程通过 fork 获得虚拟机的一个副本，因此 zygote 才被称为所有 Java 进程的父进程；同时，也因为每个子进程拥有独立的虚拟机副本，所以某个进程的虚拟机崩溃后不影响其他进程，从而实现安全的运行时隔离。

Dalvik 是早期 Android 的 Java 虚拟机，伴随着 Android 5.0 的更新，正式宣告其历史使命的结束:

虽然现在 Dalvik 已经被 ART 虚拟机所取代，但其简洁的实现有助于我们理解 Java 代码的运行流程，因此还是先对其进行简单的介绍。

上节中我们知道 zygote 进程创建并初始化 Java 虚拟机后执行的第一个 Java 函数是 com.android.internal.os.ZygoteInit 的 main 方法，这是个静态方法，因此在 Native 层调用的是 JNI 接口函数 CallStaticVoidMethod。其调用流程可以简化如下所示:

Dalvik 虚拟机支持三种执行模式，分别是:

以上述调用流程中的 portable 模式为例，对应 dvmInterpretStd 实现的核心代码如下所示:

可以看到其核心在于一个巨大的 switch/case，以 PC 为起点不断读取字节码(4字节对齐)，并根据 op_code 去分发解释执行不同的指令直到 Java 方法运行结束返回或者抛出异常。之所以称为可移植模式(portable)正是因为该代码纯粹是解释执行，既没有提前优化也没有运行时的 JIT 优化，也因此具有平台无关性，只要 C 编译器支持对应平台即可运行。

虽然 Dalvik 已经被 ART 取代，但其中的 Dalvik 字节码格式还是被保留了下来。即便在最新版本的 Android 中，编译 Java 生成的依旧是 DEX 文件，其格式可以参考 Dalvik Executable format，Dalvik 字节码的介绍可以参考官方文档 Dalvik bytecode。

ART 全称为 Android Runtime，是继 Dalvik 之后推出的高性能 Android Java 虚拟机。在本文中我们重点关注 ART 虚拟机执行 Java 代码的流程。在介绍 ART 的代码执行流程之前，我们需要先了解在 ART 中针对 DEX 的一系列提前优化方案，以及由此产生的各类中间文件。

在我们使用 Android-Studio 编译应用时，实际上是通过 Java 编译器先将 .java 代码编译为对应的 Java 字节码，即 .class 类文件；然后用 dx(在新版本中是d8) 将 Java 字节码转换为 Dalvik 字节码，并将所有生成的类打包到统一的 DEX 文件中，最终和资源文件一起 zip 压缩为 .apk 文件。

在安装用户的 APK 时，Android 系统主要通过 PacketManager 对应用进行解包和安装。其中在处理 DEX 文件时候，会通过 installd 进程调用对应的二进制程序对字节码进行优化，这对于 Dalvik 虚拟机而言使用的是 dexopt 程序，而 ART 中使用的是 dex2oat 程序。

dexopt 将 dex 文件优化为 odex 文件，即 optimized-dex 的缩写，其中包含的是优化后的 Dalvik 字节码，称为 quickend dex；dex2oat 基于 LLVM，优化后生成的是对应平台的二进制代码，以 oat 格式保存，oat 的全称为 Ahead-Of-Time。oat 文件实际上是以 ELF 格式进行存储的，并在其中 oatdata 段(section) 包含了原始的 DEX 内容。

在 Android 8 之后，将 OAT 文件一分为二，原 oat 仍然是 ELF 格式，但原始 DEX 文件内容被保存到了 VDEX 中，VDEX 有其独立的文件格式。整体流程如下图所示:

值得一提的是，在 Andorid 系统中 dex2oat 会将优化后的代码保存在 /data/app 对应的应用路径下，系统应用会保存在 /data/dalvik-cache/ 下，对于后者，产生的实际有三个文件，比如:

system_ext@priv-app@Settings@Settings.apk@classes.dex 实际上是 ELF 格式的 OAT 文件，所以我们不能以貌(后缀)取人；.art 也是一个特殊的文件格式，如前文所言，Android 实现了自己的 Java 虚拟机，这个虚拟机本身是用 C/C++ 实现的，其中的一些 Java 原语有对应的 C++ 类，比如:

当创建一个 Java 对象时，内存中会创建对应的 C++ 对象并调用其构造函数，JVM 管理者这些 C++ 对象的引用。为了加速启动过程，避免对这些常见类的初始化，Android 使用了 .art 格式来保存这些 C++ 对象的实例，简单来说，art 文件可以看做是一系列常用 C++ 对象的内存 dump。

不论是 oat、vdex 还是 art，都是 Android 定义的内部文件格式，官方并不保证其兼容性，事实上在 Android 各个版本中这些文件格式都有不同程度的变化，这些变化是不反映在文档中的，只能通过代码去一窥究竟。因此对于这些文件格式我们现在只需要知道其大致作用，无需关心其实现细节。

在前一篇文章 (Android 12 应用启动流程分析) 中我们知道 APP 最终在 ActivityThread 中完成 Application 的创建和初始化，最终调用 Activity.onCreate 进入视图组件的生命周期。但这里其实忽略了一个问题: APP 的代码(DEX/OAT 文件) 是如何加载到进程中的？

在 Java 中负责加载指定类的对象是 ClassLoader，Android 中也是类似，BaseDexClassLoader 继承自 ClassLoader 类，实现了许多 DEX 相关的加载操作，其子类包括:

以常见的 PathClassLoader 为例，其构造函数会调用父类的构造函数，整体调用链路简化如下表:

在 OpenDexFilesFromOat 中执行了真正的代码加载工作，伪代码如下:

通过 OpenDexFilesFromOat_Impl 加载获取 DexFile 结构体数组，值得注意的是加载完 DEX 之后会将内存中的 dex_file 设置为不可写，当然目前还没有强制，但可见这是未来的趋势。

继续看实现部分是如何加载 Dex 文件的:

加载过程首先将 vdex 映射到内存中，然后将已经映射到内存中的 dex 或者在磁盘中的 dex 转换为 DexFile 结构体，最后再将 vdex 和 oat 文件关联起来。

vdex 是 Android 8.0 加入的新文件格式，主要用于保存优化代码的原始 DEX 信息，而 OAT 中则主要保存 dex2oat 编译后的 Native 代码。

VdexFile 的结构大致如下所示，其中 D 代表 VDEX 中包含的 DEX 文件个数:

VdexFile 结构详见: art/runtime/vdex_file.h

dex_file_loader.Open 的调用路径如下:

实际根据起始 4 字节判断是标准 DEX 还是紧凑型 DEX (cdex, compat dex)，并使用对应的结构体进行初始化。cdex 是当前 ART 内部使用的 DEX 文件格式，主要是为了减少磁盘和内存的使用。但不论是 StandardDexFile 还是 CompactDexFile 都继承于 DexFile，二者的构造函数最终还是会调用 DexFile 的构造函数。

DexFile 结构详见 art/libdexfile/dex/dex_file.h

在完成所有 DexFile 的初始化之后，会继续使用 OatFile::OpenFromVdex 创建 oat_file 并进行注册。该函数的调用链路如下:

与早期使用 odex 的区别是现在在创建完 OatFile 之后，会调用 oat_file->SetVdex 获取 vdex 对象的所有权，用以实现 OAT 的部分接口，比如获取内存中对应 DEX 文件的起始地址:

详见: art/runtime/oat_file.h

本来按照时间线来看的话，这里应该先介绍 ART 运行时类和方法的加载过程，但我从实践出发，先看 Java 方法的调用过程，并针对其中涉及到的概念在下一节继续介绍。

在 Web 安全中，Java 服务端通常带有一个称为 RASP (Runtime Application Self-Protection) 的动态防护方案，比如监控某些执行命令的敏感函数调用并进行告警，其实际 hook 点是在 JVM 中，不论是方法直接调用还是反射调用都可以检测到。因此我们有理由猜测在 Android 中也有类似的调用链路，为了方便观察，这里先看反射调用的场景，一般反射调用的示例如下:

因此一个方法的调用会进入到 Method.invoke 方法，这是一个 native 方法，实际实现在 art/runtime/native/java_lang_reflect_Method.cc:

InvokeMethod 定义在 art/runtime/reflection.cc，其实现的核心代码如下:

上面省略了许多细节，主要是做了一些调用前的检查和预处理工作，流程可以概况为:

值得注意的是，jobject 类型的 javaMethod 可以转换为 ArtMethod 指针，该结构体是 ART 虚拟机中对于具体方法的描述。之后经过一系列调用:

最终进入 ArtMethod::Invoke 函数，还是只看核心代码:

ART 对于 Java 方法实现了两种执行模式，一种是像 Dalvik 虚拟机一样解释执行字节码，姑且称为解释模式；另一种是快速模式，即直接调用通过 OAT 编译后的本地代码。

在 ART 早期指定本地代码还细分为 Portable 和 Quick 两种模式，但由于对极致速度的追求以及随着 Quick 模式的不断优化，Portable 也逐渐退出了历史舞台。

阅读上述代码可以得知，当 ART 运行时尚未启动或者指定强制使用解释执行时，虚拟机执行函数使用的是解释模式，ART 可以在启动时指定 -Xint 参数强制使用解释执行，但即便指定了使用解释执行模式，还是有一些情况无法使用解释执行，比如:

解释执行的入口是 art::interpreter::EnterInterpreterFromInvoke，该函数定义在 art/runtime/interpreter/interpreter.cc，关键代码如下:

其中的 CodeItem 就是 DEX 文件中对应方法的字节码，还是老样子，直接看简化的调用链路:

ExecuteSwitchImplAsm 为了速度直接使用汇编实现，在 ARM64 平台中的定义如下:

本质上是调用保存在 x1 寄存器的第二个参数，调用处的代码片段如下:

即调用了 ExecuteSwitchImplCpp，在该函数中，可以看见典型的解释执行代码:

在当前版本中 (Android 12)，实际上是通过宏展开去定义了所有 op_code 的处理分支，不同版本实现都略有不同，但解释执行的核心思路从 Android 2.x 版本到现在都是一致的，因为字节码的定义并没有太多改变。

再回到 ArtMethod 真正调用之前，如果不使用解释模式执行，则通过 art_quick_invoke_stub 去调用。stub 是一小段中间代码，用于跳转到实际的 native 执行，该符号使用汇编实现，在 ARM64 中的定义在 art/runtime/arch/arm64/quick_entrypoints_arm64.S，核心代码如下:

中间省略了一些保存上下文以及调用后恢复寄存器的代码，其核心是调用了 ArtMethod 结构体偏移 ART_METHOD_QUICK_CODE_OFFSET_64 处的指针，该值对应的代码为:

即 entry_point_from_quick_compiled_code_ 属性所指向的地址。

可以认为这就是所有快速模式执行代码的入口，至于该指针指向什么地方，又是什么时候初始化的，可以参考下一节代码加载部分。实际在方法调用时，快速模式执行的方法可能在其中执行到了需要以解释模式执行的方法，同样以解释模式执行的方法也可能在其中调用到 JNI 方法或者其他以快速模式执行的方法，所以在单个函数执行的过程中运行状态并不是一成不变的，但由于每次切换调用前后都保存和恢复了当前上下文，使得不同调用之间可以保持透明，这也是模块化设计的一大优势所在。

在上节我们知道在 ART 虚拟机中，Java 方法的调用主要通过 ArtMethod::Invoke 去实现，那么 ArtMethod 结构是什么时候创建的呢？为什么 jmethod/jobject 可以转换为 ArtMethod 指针呢？

在 Java 这门语言中，方法是需要依赖类而存在的，因此要分析方法的初始化需要先分析类的初始化。虽然我们前面知道如何从 OAT/VDEX/DEX 文件中构造对应的 ClassLoader 来进行类查找，但那个时候类并没有初始化，可以编写一个简单的类进行验证:

如果 Demo 类在代码中没有使用，那么上述两个打印都不会触发；如果使用 Class.forName("Demo") 进行反射引用，则 static block 中的代码会被调用。跟踪 Class.forName 调用:

最终调用到名为 classForName 的 native 方法，其定义在 art/runtime/native/java_lang_Class.cc:

首先将 Java 格式的类表示转换为 smali 格式，然后通过指定的 class_loader 去查找类，查找过程主要通过 class_linker 实现。由于 forName 函数中指定了 initialize 为 true，因此在找到对应类后还会额外执行一步 EnsureInitialized，在后文会进行详细介绍。

FindClass 实现了根据类名查找类的过程，定义在 art/runtime/class_linker.cc 中，关键流程如下:

首先会通过 LookupClass 在已经加载的类中查找，已经加载的类会保存在 ClassTable 中，以 hash 表的方式存储，该表的键就是类对应的 hash，通过 descriptor 计算得出。如果之前已经加载过，那么这时候就可以直接返回，如果没有就需要执行真正的加载了。从这里我们也可以看出，类的加载过程属于懒加载 (lazy loading)，如果一个类不曾被使用，那么是不会有任何加载开销的。

然后会判断指定的类加载器是否为空，为空表示要查找的类实际上是一个系统类。系统类不存在于 APP 的 DEX 文件中，而是 Android 系统的一部分。由于每个 Android (Java) 应用都会用到系统类，为了提高启动速度，实际通过 zygote 去加载，并由所有子进程一起共享。上述 boot_class_path_ 数组在 Runtime::Init 中通过 ART 启动的参数进行初始化，感兴趣的可以自行研究细节。

我们关心的应用类查找过程可以分为两步，首先在父类的 ClassLoader 进行查找，如果没找到才会通过指定的 classLoader 进行查找，这也是很多类似 Java 文章中提到的 “双亲委派” 机制。保证关键类的查找过程优先通过系统类加载器，可以防止关键类实现被应用篡改。

FindClassInBaseDexClassLoader 的实现使用伪代码描述如下所示:

根据不同的 class_loader 类型使用不同的搜索顺序，如果涉及到父 ClassLoader 的搜索，则使用递归查找，递归的停止条件是当前 class_loader 为java.lang.BootClassLoader。

FindClassInBootClassLoaderClassPath 的关键代码如下:

如果在 BaseClassLoader 中没有找到对应的类，那么最终会通过传入的 classLoader 查找，即调用指定类加载器的 loadClass 方法。在这个场景中(Class.forName)，实际指定的是 caller 的 classLoader，编写一个 APK 进行动态分析，打印出当前的 classLoader 如下:

所以这是一个 PathClassLoader 对象，该类没有定义 loadClass，因此是调用了父类的 loadClass 方法，整体调用路径如下所示:

最终调用了 DexFile 的 native 方法 defineClassNative，实现在 art/runtime/native/dalvik_system_DexFile.cc，关键代码如下:

也就是说，不论是通过 FindClassInBaseDexClassLoader 查找还是通过指定 classLoader 的 loadClass 加载，最终执行的流程都是类似的，即在对应的 DexFile(OatDexFile) 中根据类名搜索对应类的 ClassDef 字段，了解 Dex 文件结构的对这个字段应该不会陌生，后面可能会单独写一篇 DexFile 文件格式的介绍，这里限于篇幅先不展开，只需要知道这个字段包含类的定义即可。

在找到类在对应 Dex 文件中的 ClassDef 内容后，会通过 ClassLinker 完成该类的后续注册流程，包括:

其中 DefineClass 是我们比较关心的，因此下面单独进行介绍。

先看代码:

这里只列出一些关键代码，init_done_ 用于表示当前 ClassLinker 的初始化状态，初始化过程用于从 Image 空间或者手动创建内部类，手动创建的内部类包括:

它们都直接定义在了 art::runtime::mirror 命名空间中，比如 Object 定义为 mirror::Object，所属文件为 art/runtime/mirror/object.h ；

ClassLinker::LoadClass 用于从指定 DEX 文件中加载目标类的属性和方法等内容，注意这里其实是在对应类添加到 ClassTable 之后才加载的，这是出于 ART 的内部优化考虑，另外一个原因是类的属性根只能通过 ClassTable 访问，因此需要在访问前先在 ClassTable 中占好位置。其实现如下:

上面用到了 C++11 的 lambda 函数来通过迭代器访问类中的关联元素，分别是:

对于属性的加载通过 LoadField 实现，主要作用是初始化 ArtField 并与目标类关联起来；LoadMethod 的实现亦是类似，主要是使用 dex 文件中对应方法的 CodeItem 对 ArtMethod 进行初始化，并与 klass 关联。但是对于方法而言，还好进行额外的一步，即 LinkCode。

LinkCode 顾名思义是对代码进行链接，关键代码如下:

其中 quick_code 指针指向的是 OatMethod 中的 code_offset_ 偏移处的值，该值指向的是 OAT 优化后的本地代码位置。InitializeMethodsCode 是 Instrumentation 类的方法，实现在 art/runtime/instrumentation.cc，如果看过之前分析应用启动流程的文章应该对这个类不会陌生，尽管不是同一个类，但它们的功能却是类似的，即作为某些关键调用的收口，并在其中实现可插拔的追踪行为。其内部实现如下:

第一部分正是用于追踪的判断，如果当前已经安装了追踪监控，那么会根据当前方法的类别分别设置对应的入口点；否则就以常规方式设置方法的调用入口:

设置 ArtMethod 入口地址的方法是 UpdateEntryPoints，其内部实现非常简单:

内部实质上是调用了 ArtMethod::SetEntryPointFromQuickCompiledCode:

回顾我们前面分析方法调用的章节，对于快速执行的场景，ArtMethod::Invoke 最终是跳转到 entry_point_from_quick_compiled_code 进行执行，而这个字段就是在这里进行设置的。

至此，我们完成了 ART 方法调用流程分析的最后一块拼图。

此时我们已经完成了类的加载，包括类中的所有方法、属性的初始化。在前文 classForName 的实现中，完成类加载后还调用了一次 EnsureInitialized，在其中调用了 ClassLinker::InitializeClass 对类进行初始化，主要包括静态属性的初始化以及调用类中的 <clinit> 代码，这也是为什么本节开头 Demo 类的 static block 中代码会被调用的原因。

初始化流程严格按照 Java 语言标准实现，详见 Java Language Specification 12.4.2 "Detailed Initialization Procedure"

通过上面的分析，我们大致了解了 ART 虚拟机的文件、代码加载流程，以及对应 Java 方法和指令的运行过程。正所谓无利不起早，之所以花费这么多时间精力去学习 ART，是因为其在 Android 运行过程中起着举足轻重的作用，下面就列举一些常见的应用场景。

所谓热修复，就是在不修改原有代码的基础上修改应用功能，比如替换某些类方法的实现，达到热更新的目的。犹记得在几年前，热修复的概念在 Android 生态中甚嚣尘上，随着 ART 替换 Dalvik，以及碎片化引入的一系列问题导致这种方案逐渐销声匿迹。但是热修复的使用场景并没有完全消失，比如在 Android 应用安全研究中 Hook 的概念也是热修复的一种延续。

那么根据前面总结的知识可以考虑一个问题，如何在运行时劫持某个 Java 方法的执行流程？最好是可以在指定方法调用前以及返回前分别触发我们自己定义的回调，从而实现调用参数和返回值的观察和修改。

根据前文对方法调用和代码加载的分析，Android 中的 Java 方法在 ART 中执行都会通过 ArtMethod::Invoke 进行调用，在其内部要么通过解释器直接解释执行(配合 JIT)；要么通过 GetEntryPointFromQuickCompiledCode 获取本地代码进行执行，当然后者在某些场景下依然会回退到解释器，但入口都是固定的，即
entry_point_from_quick_compiled_code 所指向的 quick 代码。因此，要想实现 Java 方法调用的劫持，可以有几种思路:

当然，前途是光明的，道路是曲折的，这些方法看起来都很直观，但实现起来有很多工程化的难点。比如需要仔细处理调用前后的堆栈令其保持平衡，这涉及到 inline-hook 框架本身的鲁棒性；有比如在新版本中对于系统类方法的调用，ART 会直接优化成汇编跳转而绕过 ArtMethod 方法的查找过程，因此方法 1、2 无法覆盖到这些场景，……不一而足。

以大家常用的 frida 为例，其对 Java 方法 Hook 的实现在 frida-java-bridge，关键代码在 lib/android.js 文件中:

其中 Nterp 是 ART 中一个改良过的解释器，用于替代早期 Dalvik 的 mterp 解释器，这里先不展开实现的细节，只需关注实际执行劫持的地方，即 interceptor.activate(vm)。interceptor 在实例化时指定的 quickCode 即为对应 ArtMethod 的快速执行入口，activate 代码如下:

可以看到 frida 实际上是使用了我们上述的第 3 种 Hook 思路，即修改 stub code 为我们的劫持代码，这种方式一般称之为 dynamic callee-side rewriting，优点是即便对于 OAT 极致优化的系统类方法也同样有效。当然，我们这里只是管中规豹，实际的实现上还有很多细节值得学习，感兴趣的可以自行阅读代码。

了解过 Android 逆向工程的人应该都知道，基于 Java 编译出来的 Dalvik 字节码其实很好理解，加上一些开源或者商业的反编译工具，甚至可以将字节码还原为和源代码非常接近的 Java 代码表示。这对于很多想在代码中隐藏秘密的公司而言是很不愿意看到的。

因此，安全工程师们就想出了一些保护代码防止静态逆向分析的方案，业内常称为 加壳，国外叫做 Packer，即在原始字节码上套上一层保护壳，并在运行时进行执行解密还原。

回顾我们学习的知识可以脑暴出几种安全加固方案(其实是业内已有方案):

这些加固方案根据解密粒度不同也常称为整体壳、抽取壳。对于整体加密的方案不必多说，在 PC 时代也有很多类似的混淆方法；而对于抽取壳，实现就百花齐放了，比如有的加固方案是在类初始化期间进行还原，有的是在方法执行前进行还原。

回顾上面介绍热修复的内容，壳代码其实也可以看做是一个热修复框架，只不过是对于每个函数都进行了劫持，在目标函数运行前对实际的字节码进行还原；

有些类级别的加固则是基于上文中代码加载流程，在类的初始化函数(<clinit>)中执行解密操作，因为 Java 标准保证了这是一个类最先执行的代码。

由于抽取壳本身对字节码进行了加密，因此在应用安装期间 dex2oat 就无法优化这些代码，以至于在运行时只能通过解释执行，虽然有一部分 JIT 的加持，但还是让 ART 的大部分优化心血付诸东流；另外，加壳本身会使用到 ART 中的一些内部符号和偏移，因此需要针对不同版本进行适配，一个不小心就是用户端的持续崩溃。

也因为这些原因，很多头部厂商的 Android 应用其实是不加壳的，对于真正需要保护的代码，可以选择 JNI 用 C/C++ 实现，并配上 LLVM 成熟的混淆方案进行加固。

由于很多安全公司把加固做成了商业服务，因此除了正常应用，大部分恶意软件和非法应用也都用上了商业的加固方案，这对于正义的安全研究员而言是一个确实的阻碍，因此脱壳也就成了常见需求。

一开始我们在遇到加固的应用时候会先尝试进行手动进行分析、调试、还原，但是后来大家发现其实基于 ART 的运行模式有更通用的解决方式。

这里以目前相对较新的抽取壳为例，回顾上文代码方法调用和代码加载的章节，不论加固的抽取和还原方法如何，最终还是要回到解释执行的(至少在 JIT 之前)，因为加密的代码在安装时并没有被 AOT 优化。而且为了保证原始代码逻辑不变，对应加密方法在实际运行之前肯定需要被正确解密还原。

基于这点事实，我们可以在 ArtMethod 调用前进行断点，然后通过 method->GetDexFile() 获得对应 dex 文件在内存中的地址并进行转储保存。如果当前内存中的 dex 部分偏移被恶意修改，那么还可以通过 method->GetCodeItem() 获取对应方法解密后的字节码地址进行手动转储恢复。

如果要恢复完整的 dex 文件，则需要令目标程序在运行时调用所有类的所有方法，这显然不太现实；不过网上已经有了一些开源的方案基于主动调用的思路去批量伪造方法调用，触发壳的解密逻辑从而实现全量还原，比如 DexHunter 和 FART，都是通过修改 Android 源码实现的脱壳方案。

正如上节所说，安全加固方案五花八门，很难有一种绝对通用的方法去还原所有加固，往往还需要针对不同的壳做一些微小的适配工作。但总的来说，脱壳一方比写壳一方还是占优势的，前者只需要针对一种环境实现，不用考虑性能成本；后者则需要对 ART 有更深的理解来保证加固程序的稳定性，同时还要针对不同环境都进行覆盖，这也是攻防不对等的一个典型案例吧。

对于上述 Android 应用加壳的方案，在数次攻防角斗下已经被证明了只能作为辅助防护，因此移动安全厂商又提出了一些新的加固方案，比如直接对字节码本身下手，套用 LLVM 控制流和数据流混淆的那一套方案，将字节码的执行顺序打乱，插入各种无效指令来阻碍逆向工程；又或者将字节码的实现抽批量自动取到 JNI 层，并辅以二进制级别的安全加固，这种方案通常称为 Java2C，即将 Java 代码转译成 C 代码编译来防止逆向分析。……

这时，传统的脱壳方法就不见得有效了，因为即便还原出字节码或者 Java 代码，其流程也是混乱的，对于 Java2C 则更不用说，只能在二进制中想办法将 JNI 调用还原。

不过我们可以思考一下，逆向工程的目的是什么？如果是为了分析还原程序的执行流程，对其行为进行画像和取证，那么完全可以通过动态跟踪的方式实现。上文中已经介绍了如果对某个指定方法进行热修复或者说 hook，那么这里的思路就是对应用中的所有 Java 方法都进行 hook，从而实现我们的运行时方法跟踪行为。

例如针对每个 Java 方法在进入和退出前都插入我们的 hook 代码，作用就是发送函数进出事件及其相关信息，如进程、线程 ID、方法名、参数等，接收端处理数据后实现一个树状的调用流图。

一个简单的调用流图示例如下所示:

前端通过处理和过滤这些数据，可以在很大程度上还原程序行为。那么要如何实现所有 Java 方法的追踪呢？entry_point_from_quick_compiled_code_ 是一个重点关注的点，但如果我们想要像 frida 一样劫持，就需要对每个方法做许多额外的工作，比如修改函数的 access_flag，修改解释器执行流程等。因此关键点还是在于如何同时处理解释执行和快速执行的代码，并将潜在的 JIT 运行时优化考虑进去，自己造一个轮子无可厚非，但其实 ART 中已经提供了这么一个“后门”，那就是在上文 LinkCode 代码中的那句:

在 Instrumentation::InitializeMethodsCode 的实现中，会先判断当前是否已经注册了追踪的 stub，如果有的话会直接替换对应方法的入口点:

对于已经初始化过的 ArtMethod，还可以用 Instrumentation::InstallStubsForMethod 去为指定方法安装跟踪代码。关于 Instrumentation 网上还没有太多公开资料，需要通过源码去进一步研究。

当然还是那句老话，想法是简单的，实现是复杂的，这其中目前可预计到的问题就有:

因此再展开就说来话长了，目前也只是在探索阶段，后续有机会再单独分享这部分内容吧。

本文主要目的是分析 Android 12 中 ART 的实现，包括 Java 方法初始化和执行的过程。基于对 ART 的深入理解，我们也列举了几种实践中经常遇到的场景，比如热修复、动态注入、安全加固、脱壳等。也许在工作中信奉拿来主义，只需要工具能用就行，但了解工具背后的原理，才能更好适应当前不断激化的攻防对抗环境，从而更好地迎接未来的挑战。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！