ClassLoader 和动态加载

前言

ClassLoader（类加载器）是 Java 虚拟机和 Android 运行时中负责加载字节码文件的核心组件。在 Android 逆向工程中，理解 ClassLoader 的工作机制是掌握加壳与脱壳技术的必要前提——几乎所有第一代、第二代壳的核心原理都围绕 ClassLoader 展开。

本文将从 Java ClassLoader 基础出发，逐步深入到 Android 体系中的 ClassLoader 实现，最终通过代码示例和 Frida Hook 实战，展示 ClassLoader 在动态加载和脱壳中的关键作用。

一、Java ClassLoader 体系回顾

1.1 什么是 ClassLoader

ClassLoader 是 Java 提供的一个抽象类，负责将 .class 字节码文件加载到 JVM 中，转换为 java.lang.Class 对象。每个 Class 对象都记录了自己是由哪个 ClassLoader 加载的。

// 获取当前类的 ClassLoader
ClassLoader loader = getClass().getClassLoader();
System.out.println(loader);                    // sun.misc.Launcher$AppClassLoader
System.out.println(loader.getParent());        // sun.misc.Launcher$ExtClassLoader
System.out.println(loader.getParent().getParent()); // null (Bootstrap)

1.2 三层 ClassLoader 架构

标准 Java 中存在三层 ClassLoader，构成双亲委派模型（Parents Delegation Model）：

ClassLoader	职责	加载路径
Bootstrap ClassLoader	加载核心类库（rt.jar 等）	`$JAVA_HOME/jre/lib`
Extension ClassLoader	加载扩展类库	`$JAVA_HOME/jre/lib/ext`
Application ClassLoader	加载用户类路径（classpath）	用户指定路径

1.3 双亲委派机制

双亲委派的核心思想是：当某个 ClassLoader 需要加载一个类时，它不会自己先去加载，而是把请求委派给父 ClassLoader，层层向上传递。只有当所有父加载器都无法加载时，当前加载器才会尝试加载。

// ClassLoader.loadClass() 简化流程
protected Class<?> loadClass(String name, boolean resolve) {
    // 1. 检查是否已加载
    Class<?> c = findLoadedClass(name);
    if (c == null) {
        try {
            // 2. 委派给父加载器
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
            // 父加载器无法加载，交给当前加载器
        }
        if (c == null) {
            // 3. 当前加载器自行加载
            c = findClass(name);
        }
    }
    return c;
}

双亲委派的意义：

安全性：防止核心类被篡改。即使用户自定义了一个 java.lang.String，也会被 Bootstrap ClassLoader 优先加载，用户的类永远不会被使用。
避免重复加载：同一个类只会被加载一次，保证类的唯一性。

二、Android ClassLoader 体系

Android 虽然基于 Java，但并不使用标准 JVM，而是使用 ART（或 Dalvik）虚拟机，字节码格式从 .class 变为了 .dex。因此 Android 的 ClassLoader 体系与 Java 有显著差异。

2.1 Android ClassLoader 家族

ClassLoader (抽象类)
├── BootClassLoader          // 对应 Java 的 Bootstrap ClassLoader
├── URLClassLoader           // Java 标准类，Android 中基本不用
├── BaseDexClassLoader       // Android 核心，继承自 ClassLoader
│   ├── PathClassLoader      // 加载已安装 APK 的类
│   ├── DexClassLoader       // 加载任意路径的 DEX/JAR/APK
│   └── InMemoryDexClassLoader // Android 8.0+，内存中加载 DEX
└── SecureClassLoader        // 安全相关

2.2 BootClassLoader

BootClassLoader 是 Android 中的顶层类加载器，由 C++ 实现而非 Java。它负责加载 Android 系统核心类，包括：

java.lang.*、java.util.* 等 Java 核心类
android.* 等 Android 框架类
位于 /system/framework/ 下的系统 JAR 包

BootClassLoader 的 getParent() 返回 null，与 Java 中的 Bootstrap ClassLoader 行为一致。

2.3 PathClassLoader

PathClassLoader 是 Android 应用启动时的默认类加载器：

// Android 内部创建 PathClassLoader 的方式
PathClassLoader pathLoader = new PathClassLoader(
    "/data/app/com.example.app/base.apk",   // APK 安装路径
    ClassLoader.getSystemClassLoader().getParent()  // 父加载器
);

特点：

只能加载已安装的 APK 文件中的 DEX
从 Android 8.0（Oreo）开始，也能加载经过优化的 OAT/VDEX 文件
应用启动时自动创建，通过 getClassLoader() 即可获取

// 在任意 Activity 中
ClassLoader loader = getClassLoader();
System.out.println(loader.getClass().getName());
// 输出: dalvik.system.PathClassLoader

2.4 DexClassLoader

DexClassLoader 是 Android 动态加载的核心工具，可以加载任意路径下的 DEX、JAR 或 APK 文件：

public class DexClassLoader extends BaseDexClassLoader {
    public DexClassLoader(String dexPath,          // DEX 文件路径（可多个，用 : 分隔）
                          String optimizedDirectory, // 优化后 DEX 存放路径（已废弃）
                          String librarySearchPath,  // native 库搜索路径
                          ClassLoader parent) {      // 父加载器
        super(dexPath, optimizedDirectory, librarySearchPath, parent);
    }
}

与 PathClassLoader 的关键区别：

特性	PathClassLoader	DexClassLoader
加载范围	已安装的 APK	任意路径的 DEX/JAR/APK
optimizedDirectory	不需要	Android 8.0+ 忽略此参数
典型用途	应用正常加载	插件化、热修复、加壳

注意：从 Android 8.0（API 26）开始，DexClassLoader 和 PathClassLoader 的实现已经完全一致，差异仅在于历史遗留的 optimizedDirectory 参数。但在低版本中，DexClassLoader 是加载外部 DEX 的唯一方式。

2.5 InMemoryDexClassLoader

Android 8.0 引入了 InMemoryDexClassLoader，支持直接从内存中的字节数组加载 DEX，无需写入文件系统：

// 从内存加载 DEX（Android 8.0+）
byte[] dexBytes = Files.readAllBytes(Paths.get("/sdcard/secret.dex"));
ByteBuffer dexBuffer = ByteBuffer.wrap(dexBytes);

InMemoryDexClassLoader loader = new InMemoryDexClassLoader(
    dexBuffer,    // DEX 字节缓冲区
    getClassLoader()  // 父加载器
);

Class<?> loadedClass = loader.loadClass("com.example.SecretClass");

这在加壳场景中非常有用——解密后的 DEX 可以直接在内存中加载，不落盘，增加了逆向分析难度。

三、双亲委派在 Android 中的实现

Android 中的双亲委派与 Java 类似，但有以下特点：

请求加载 com.example.MyClass
         │
         ▼
  BootClassLoader ──── 能加载（系统类）？───→ 返回
         │ 不能
         ▼
  PathClassLoader ──── 能加载（已安装 APK）？───→ 返回
         │ 不能
         ▼
  DexClassLoader ──── 能加载（外部 DEX）？───→ 返回
         │ 不能
         ▼
    抛出 ClassNotFoundException

关键点：Android 的 PathClassLoader 的父加载器是 BootClassLoader（而不是 Extension ClassLoader），因为 Android 中不存在 Extension ClassLoader 这个层级。

// 验证 Android 中的加载器层级
ClassLoader loader = getClassLoader();
// PathClassLoader → BootClassLoader → null

四、DexClassLoader 源码分析

4.1 BaseDexClassLoader 核心逻辑

DexClassLoader 和 PathClassLoader 都继承自 BaseDexClassLoader，核心逻辑集中在这个类中：

public class BaseDexClassLoader extends ClassLoader {
    private final DexPathList pathList;

    public BaseDexClassLoader(String dexPath, ...) {
        this.pathList = new DexPathList(dexPath, ...);
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 委托给 DexPathList 查找
        Class c = pathList.findClass(name, suppressedExceptions);
        return c;
    }
}

4.2 DexPathList 的结构

DexPathList 是实际的类查找引擎，内部维护了一个 dexElements 数组，每个元素代表一个 DEX 文件的描述信息：

final class DexPathList {
    private Element[] dexElements;  // 核心！所有 DEX 文件的描述数组

    public Class<?> findClass(String name) {
        for (Element element : dexElements) {
            // 遍历所有 Element，逐个查找目标类
            Class<?> clazz = element.findClass(name, definingContext);
            if (clazz != null) {
                return clazz;
            }
        }
        throw new ClassNotFoundException(name);
    }
}

Element 的内部结构：

static class Element {
    private final File path;              // DEX/JAR/APK 文件路径
    private final DexFile dexFile;        // 打开后的 DEX 文件对象

    Class<?> findClass(String name, ...) {
        return dexFile != null ? dexFile.loadClassBinaryName(name, ...) : null;
    }
}

核心流程总结：

DexClassLoader.loadClass("com.example.Foo")
    → 双亲委派（先交给 BootClassLoader）
    → 父加载器找不到
    → BaseDexClassLoader.findClass()
    → DexPathList.findClass()
    → 遍历 dexElements[] 数组
    → Element.dexFile.loadClassBinaryName()
    → 找到并返回 Class 对象

这个 dexElements 数组是热修复和加壳技术的核心操作对象。

五、动态加载技术在加壳中的应用

5.1 加壳的基本思路

加壳的核心流程可以简化为：

加壳阶段：将原始 APK（源 DEX）加密，与壳程序合并生成新的 APK
运行阶段：壳程序运行后，解密源 DEX，通过 ClassLoader 动态加载
关键操作：将解密后的 DEX 注入到 PathClassLoader 的 dexElements 中

┌─────────────────────────────────────┐
│         壳 APK（安装到手机）          │
│  ┌───────────┐  ┌────────────────┐  │
│  │ 壳 DEX    │  │ 加密的源 DEX    │  │
│  │ (明文)    │  │ (被保护代码)    │  │
│  └───────────┘  └────────────────┘  │
└─────────────────────────────────────┘
          │ 运行时
          ▼
┌─────────────────────────────────────┐
│  1. 壳代码执行                       │
│  2. 读取并解密源 DEX → 内存          │
│  3. 用 DexClassLoader 加载解密后的 DEX │
│  4. 反射替换 PathClassLoader          │
│     的 dexElements                   │
│  5. 跳转到源 Application 的入口       │
└─────────────────────────────────────┘

5.2 反射替换 dexElements

壳程序在运行时的核心操作，就是通过反射将解密后的 DEX 插入到 PathClassLoader 的 dexElements 数组中：

// 加壳框架中的典型实现（简化版）
private void loadDex(Context context, byte[] decryptedDex) {
    // 1. 获取当前 PathClassLoader
    PathClassLoader pathLoader = (PathClassLoader) getClassLoader();

    // 2. 反射获取 BaseDexClassLoader 的 pathList 字段
    Field pathListField = BaseDexClassLoader.class.getDeclaredField("pathList");
    pathListField.setAccessible(true);
    Object pathList = pathListField.get(pathLoader);

    // 3. 反射获取 DexPathList 的 dexElements 数组
    Field dexElementsField = pathList.getClass().getDeclaredField("dexElements");
    dexElementsField.setAccessible(true);
    Object[] oldElements = (Object[]) dexElementsField.get(pathList);

    // 4. 将解密后的 DEX 写入临时文件
    File dexFile = new File(context.getCacheDir(), "decrypted.dex");
    dexFile.createNewFile();
    FileOutputStream fos = new FileOutputStream(dexFile);
    fos.write(decryptedDex);
    fos.close();

    // 5. 用 DexClassLoader 加载解密后的 DEX，构造新的 Element
    DexClassLoader dexLoader = new DexClassLoader(
        dexFile.getAbsolutePath(),
        context.getCacheDir().getAbsolutePath(),
        null,
        pathLoader
    );
    Object newPathList = pathListField.get(dexLoader);
    Object[] newElements = (Object[]) dexElementsField.get(newPathList);

    // 6. 合并数组：新 DEX 放在前面（优先加载）
    Object[] combinedElements = new Object[oldElements.length + newElements.length];
    System.arraycopy(newElements, 0, combinedElements, 0, newElements.length);
    System.arraycopy(oldElements, 0, combinedElements, newElements.length, oldElements.length);

    // 7. 反射替换 dexElements
    dexElementsField.set(pathList, combinedElements);
}

为什么新 DEX 要放在数组前面？ 因为 DexPathList.findClass() 会按顺序遍历 dexElements，先找到的先返回。热修复和加壳都利用了这个特性来实现类的替换。

六、代码示例：手动实现 DEX 动态加载

下面通过一个完整的示例，演示如何手动使用 DexClassLoader 加载外部 DEX 文件中的类：

6.1 准备被加载的 DEX

首先创建一个简单的 Java 项目，编译为 DEX 文件：

// DynamicPlugin.java（将被编译为 DEX）
package com.example.plugin;

public class DynamicPlugin {
    public String getMessage() {
        return "Hello from dynamically loaded DEX!";
    }

    public int calculate(int a, int b) {
        return a * b + 42;
    }
}

编译并转换为 DEX：

javac DynamicPlugin.java
d8 --output . DynamicPlugin.class
# 生成 classes.dex

6.2 宿主 App 中动态加载

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        try {
            // 1. 将 DEX 文件复制到应用私有目录
            String dexPath = getFilesDir().getAbsolutePath() + "/classes.dex";
            copyAssetToFile("classes.dex", dexPath);

            // 2. 创建 DexClassLoader
            DexClassLoader dexLoader = new DexClassLoader(
                dexPath,                        // DEX 路径
                getCacheDir().getAbsolutePath(), // 优化目录
                null,                           // native 库路径
                getClassLoader()                // 父加载器
            );

            // 3. 加载目标类
            Class<?> pluginClass = dexLoader.loadClass("com.example.plugin.DynamicPlugin");

            // 4. 通过反射调用方法
            Object plugin = pluginClass.newInstance();
            Method getMessage = pluginClass.getMethod("getMessage");
            String result = (String) getMessage.invoke(plugin);

            Log.d("DynamicLoad", result);  // 输出: Hello from dynamically loaded DEX!

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

七、脱壳中如何利用 ClassLoader 机制

在逆向分析加壳应用时，ClassLoader 机制是脱壳的关键切入点。

7.1 核心思路

壳程序在运行时一定会执行以下操作之一：

创建 DexClassLoader 加载解密后的 DEX
反射修改 PathClassLoader 的 dexElements
调用 DexFile.open() 或 DexPathList 的相关方法

我们只需要 Hook 这些关键方法，就能在运行时捕获壳程序加载的真实 DEX。

7.2 Hook ClassLoader.loadClass

通过 Frida Hook ClassLoader.loadClass() 方法，可以监控到运行时所有类的加载行为：

// hook_classloader.js
Java.perform(function() {
    // Hook DexClassLoader 构造函数，捕获加载的 DEX 路径
    var DexClassLoader = Java.use("dalvik.system.DexClassLoader");

    DexClassLoader.$init.implementation = function(dexPath, optDir, libPath, parent) {
        console.log("\n[*] DexClassLoader 被调用!");
        console.log("[*] DEX 路径: " + dexPath);
        console.log("[*] 优化目录: " + optDir);
        console.log("[*] Native 库路径: " + libPath);
        return this.$init(dexPath, optDir, libPath, parent);
    };
});

7.3 实战案例：Frida Hook 找到真实 DEX 路径

以下是一个完整的 Frida 脚本，用于定位加壳应用运行时加载的真实 DEX 文件：

// dump_dex_path.js
Java.perform(function() {

    // 方法1: Hook DexClassLoader 构造函数
    var DexClassLoader = Java.use("dalvik.system.DexClassLoader");
    DexClassLoader.$init.implementation = function(dexPath, optDir, libPath, parent) {
        console.log("[DexClassLoader] 加载: " + dexPath);
        if (dexPath.indexOf("/data/app/") === -1) {
            console.log("[!] 发现非标准路径 DEX（可能是脱壳目标）: " + dexPath);
        }
        return this.$init(dexPath, optDir, libPath, parent);
    };

    // 方法2: Hook DexPathList 构造函数
    var DexPathList = Java.use("dalvik.system.DexPathList");
    DexPathList.$init.implementation = function(dexPath, ...) {
        console.log("[DexPathList] 初始化，DEX路径: " + dexPath);
        return this.$init(dexPath, ...);
    };

    // 方法3: Hook InMemoryDexClassLoader（针对内存壳）
    if (Java.available) {
        try {
            var InMemoryDexClassLoader = Java.use("dalvik.system.InMemoryDexClassLoader");
            InMemoryDexClassLoader.$init.implementation = function(dexBuffer, parent) {
                console.log("[InMemoryDexClassLoader] 内存 DEX 被加载!");
                console.log("[!] 建议配合 DexDump 进一步提取");
                return this.$init(dexBuffer, parent);
            };
        } catch(e) {
            console.log("[-] InMemoryDexClassLoader 不可用: " + e);
        }
    }

    // 方法4: 遍历当前所有 ClassLoader 的 DEX 列表
    function dumpLoadedDexes() {
        console.log("\n=== 当前已加载的 DEX 列表 ===");
        var BaseDexClassLoader = Java.use("dalvik.system.BaseDexClassLoader");
        var loader = Java.use("java.lang.ClassLoader")
            .getSystemClassLoader();

        // 获取 pathList
        var pathListField = BaseDexClassLoader.class.getDeclaredField("pathList");
        pathListField.setAccessible(true);
        var pathList = pathListField.get(loader);

        // 获取 dexElements
        var dexElementsField = pathList.class.getDeclaredField("dexElements");
        dexElementsField.setAccessible(true);
        var elements = dexElementsField.get(pathList);

        for (var i = 0; i < elements.length; i++) {
            var element = elements[i];
            var dexFileField = element.class.getDeclaredField("dexFile");
            dexFileField.setAccessible(true);
            var dexFile = dexFileField.get(element);

            console.log("  [" + i + "] " + dexFile.toString());
        }
    }

    // 延迟执行，等待壳完成解密和加载
    setTimeout(function() {
        dumpLoadedDexes();
    }, 5000);
});

使用方式：

frida -U -f com.target.app -l dump_dex_path.js

输出示例：

[DexClassLoader] 加载: /data/data/com.target.app/cache/decrypted.dex
[!] 发现非标准路径 DEX（可能是脱壳目标）: /data/data/com.target.app/cache/decrypted.dex

=== 当前已加载的 DEX 列表 ===
  [0] DexFile{zip:/data/app/com.target.app/base.apk}
  [1] DexFile{zip:/data/data/com.target.app/cache/decrypted.dex}

找到 decrypted.dex 的路径后，就可以直接用 adb pull 将其拉取出来，然后使用 baksmali 或 jadx 进行反编译分析。

八、总结

ClassLoader 是理解 Android 加壳与脱壳技术的基石。本文的核心知识点回顾：

Java 双亲委派模型：逐层向上委派加载，保证安全性和唯一性
Android ClassLoader 体系：BootClassLoader → PathClassLoader/DexClassLoader/InMemoryDexClassLoader
DexPathList 的 dexElements 数组：这是热修复和加壳共同操作的核心数据结构
加壳原理：加密源 DEX → 运行时解密 → 通过 DexClassLoader 加载 → 反射替换 dexElements
脱壳切入点：Hook DexClassLoader 构造函数、遍历 pathList.dexElements、关注 InMemoryDexClassLoader

掌握这些知识后，你就能理解为什么大多数脱壳工具（如 FART、DexDump）的核心逻辑都是在运行时寻找并 dump 真实的 DEX 文件。在后续文章中，我们将结合这些原理，深入学习具体的脱壳实战技术。

本文采用署名-非商业性使用-相同方式共享 4.0 国际许可协议，转载请注明出处。