[原创]APP整体加固原理-Android安全-看雪安全社区｜专业技术交流与安全研究论坛

# 0x00 前言

在前两篇文章中，我们完成了一个简单的整体加固 Demo 以及自动化加壳工具，也通过 Android 源码分析了 **`mClassLoader`**
  的重要性。但回过头来看，这两个话题之间其实存在一段逻辑上的跳跃：我们知道了**要这么做**，也知道了**必须这么做**，却还没有系统地理解**为什么这么做能生效**。

仔细想想其实跳过了几个基础但是比较重要的问题：

- **mClassLoader 到底是什么？** 它是 `PathClassLoader` 还是 `DexClassLoader`？它的内部结构长什么样？
  - **为什么系统要通过它来找类？** 它的查找规则是什么？为什么我们自己 new 一个 `DexClassLoader` 加载 `dex`，系统却不认？
  - **除了替换 `mClassLoader`，还有没有别的方案？** 网上说的"热修复"跟加固本质上是不是一回事？

这些问题导致我对整个加固逻辑只是一知半解，偶然间发现了一些资源课程帮我解决了这一部分的问题，遂写下这篇文章记录下来，希望会有所帮助。

由于笔者水平有限，文中难免存在疏漏或理解不到位的地方，如有错误恳请各位大佬不吝指正，感激不尽。

# 0x01 类加载器

## 什么是类加载器

**类加载器(`ClassLoader`)**是`Java/Android`虚拟机中负责加载类的组件。这里以Android为例，`dex`文件本身只是存放类字节码的文件。把一个dex文件复制到App私有目录之后，系统并不会自动识别里面有哪些类，也不会自动将这些类变成可以直接使用的`Java`对象。

`ClassLoader`的作用就是告诉虚拟机：应该到哪些`dex / apk / jar`文件里去找类。

当使用`DexClassLoader`加载一个外部dex的时候，本质上就是给虚拟机新增了一条类的搜索路径。在加载类的时候，`ClassLoader`会沿着查找规则，在这些`dex`路径当中找到对应类的字节码，并且把它定义成运行时的`Class`对象。

## 几个重要的成员结构

在`Android`类加载器当中有几个比较重要的成员，对于**动态加载及整体加固**非常重要，分别有下面几个：

+ **`DexFile`**：是`Dex`文件在运行时的封装，**对于类加载器来说**，类加载器最终会通过它从`dex`中查找并加载目标类；**对于开发者来说**，可以通过这个结构获取到类名列表，`dex`文件路径，native层的`dex`句柄
+ **`dexElements`**：是`Element`类的数组，其中`Element`这个类包含了`DexFile`，这个数组决定了类加载器要到哪里找类，以及查找类的顺序

+ **`PathList`**：`PathList`是Android类加载器内部用来**保存搜索路径**的成员，其中又包含了`dexElements`这个成员，是`BaseDexClassLoader`这个类的成员。

这几个成员的包含关系如下：

```bash
BaseDexClassLoader
	-> PathList : DexPathList
		-> dexElements : Element[]
			-> dexFile : DexFile
```

## 验证：通过反射获取`Dex`类名列表

了解成员结构之后，我们可以写一段代码来验证一下——将某个类加载器当前搜索路径下所有的类打印出来。这样能更直观地看到 ClassLoader 内部到底"管着"哪些类。首先看一下 Android 源码中是怎么获取类名列表的：

![](upload/attach/202606/999665_ZJUMQTUHYTF9ZQ7.webp)

在Android源码当中使用的是一个`getClassNameList`的方法来获取**类名列表**，那么我们也可以通过反射来调用这个方法来获取类名列表。在得知几个成员关系的情况下，这个大致的方案如下：

> 1. 首先需要通过反射来获取某个**类加载器**的`pathList`
> 2. 使用反射获取`pathList`中的`dexElements`
> 3. 遍历`dexElements`数组，获取每个项中的`dexFile` ，然后通过反射调用`dexFile`中的`getClassNameList`方法来获取类名列表

**代码实现如下：**

```java
public static void printClassLoaderClasses(ClassLoader classLoader){
    myLogD("classLoader -> " + classLoader);
    try{
        // 获取pathlist
        Class basedexclassLoader = classLoader.loadClass("dalvik.system.BaseDexClassLoader");
        Field pathlistfield = basedexclassLoader.getDeclaredField("pathList");
        pathlistfield.setAccessible(true);
        Object pathlistobj = pathlistfield.get(classLoader);

// 获取dexElements
        Class dexpathlistClass = classLoader.loadClass("dalvik.system.DexPathList");
        Field dexElementsfield = dexpathlistClass.getDeclaredField("dexElements");
        dexElementsfield.setAccessible(true);
        Object[] dexElementsobj = (Object[]) dexElementsfield.get(pathlistobj);

// 获取dexFile
        Class elementClass = classLoader.loadClass("dalvik.system.DexPathList$Element");
        Field dexfileField = elementClass.getDeclaredField("dexFile");
        dexfileField.setAccessible(true);

// mCookie field
        Class dexfileClass = classLoader.loadClass("dalvik.system.DexFile");
        Field mCookiefield = dexfileClass.getDeclaredField("mCookie");
        mCookiefield.setAccessible(true);

// 获取method
        Method[] methods = dexfileClass.getDeclaredMethods();
        Method getClassNameListmethod = null;

for(Method method : methods){
            if(method.getName().equals("getClassNameList")){
                getClassNameListmethod = method;
                getClassNameListmethod.setAccessible(true);
                break;
            }
        }

for(Object element : dexElementsobj){
            Object dexfileobj = dexfileField.get(element);
            Object mCookieobj = mCookiefield.get(dexfileobj);
            String[] classlist = (String[]) getClassNameListmethod.invoke(dexfileobj, mCookieobj);

for(String className : classlist){
                myLogI("classname : " + className);
            }
        }

} catch (NoSuchFieldException e) {
        throw new RuntimeException(e);
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    } catch (InvocationTargetException e) {
        throw new RuntimeException(e);
    }
}
```

**效果演示：**

![](upload/attach/202606/999665_NK6B64EUKNMN9JM.webp)

通过这种方法就能够将类加载器搜索路径中所有的`dex/apk/jar`文件包含的类打印出来。也就是说通过这个方式能够找到某个`ClassLoader`当前能够搜索到的类。

## 类加载器的类型

JVM 中类加载器分为 `Bootstrap` → `Extension` → `Application` 三层，Android 在此基础上做了简化和适配，形成了自己的一套类加载器体系：

# Android 类加载器

![](upload/attach/202606/999665_KYVCRQ6VP3RXPV7.webp)

+ `ClassLoader`：是一个抽象类，定义了`ClassLoader`的主要功能
+ `BootClassLoader`：继承自`ClassLoader`,用于Android系统启动时预加载常用类.
+ `SecureClassLoader`：继承了`ClassLoader`，但并不是实现类，而是拓展并加入了权限管理功能，增强安全性
+ `URLClassLoader`：通过`URL`路径从`jar`文件和文件夹中加载类和资源
+ `BaseDexClassLoader`：继承自`ClassLoader`,是抽象类`ClassLoader`的具体实现类.
+ `InMemoryDexClassLoader`：Android8.0新增，继承自`BaseDexClassLoader`,用于加载内存中的dex文件。
+ `PathClassLoader`：继承自`BaseDexClassLoader`,用于加载已安装的apk的dex文件.
+ `DexClassLoader`：继承自`BaseDexClassLoader`,用于加载已安装的`apk`的`dex`文件,以及从SD卡中加载未安装的`apk`的`dex`文件.

搞清楚了类加载器是什么、内部长什么样，下一个问题就是：**当系统要找某个类的时候，到底按照什么规则在多个 ClassLoader 之间查找？** 这就涉及到**双亲委派机制**了。

# 0x02 双亲委派机制

## 什么是双亲委派

双亲委派是类加载器（`classLoader`）加载类时的一种**查找规则**。这里使用`JVM`当中的双亲委派图进行解析，这个查找规则大致如下：

![](upload/attach/202606/999665_CEB2JANNUK35DV8.webp)

1. 先判断这个`Class`是否已经被加载，如果没有则先委派给父类加载器查找，并依次递归到顶层的类加载器
2. 如果顶层类加载器找到了，则返回该`Class`，否则依次往下查找
3. 如果所有父加载器都没找到Class则自己进行查找，如果仍查找失败则抛出`classNotFound`异常

这里配合Android源码来阅读能更快理解这个过程，这里找到`loadClass`的源码：

```java
protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException {

// 1. 先检查当前 ClassLoader 是否已经加载过这个类
    Class<?> c = findLoadedClass(name);

if (c == null) {

// 2. 如果没有加载过，先交给父类加载器加载
        try {
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                // 3. 如果没有父加载器，就交给 BootstrapClassLoader
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
            // 父加载器找不到时，不直接抛出
            // 而是继续让当前 ClassLoader 自己找
        }

// 4. 父加载器也找不到，当前 ClassLoader 才调用 findClass 自己查找
        if (c == null) {
            c = findClass(name);
        }
    }

// 5. 返回最终找到的 Class 对象
    return c;
}
```

**双亲委派机制的优点：**

1. 避免重复加载，如果已经加载过一次`Class`，可以直接读取已经加载的`Class`
2. 提高安全性，无法使用自定义类来替换系统类，可以防止核心API库被随意篡改。

## 通过代码打印`ClassLoader`委派链

java当中也提供了API来获取`ClassLoader`委派的父`ClassLoader`，这里可以通过代码来打印一下委派的关系链：

```java
public static void printClassLoaderHierarchy(ClassLoader currentClassloader){
    int level = 0;
    StringBuffer sb = new StringBuffer();

while(currentClassloader != null){
        for(int i = 0;i < level; i++){
            sb.append("    ");
        }

sb.append("[")
                .append(level)
                .append("] ")
                .append(currentClassloader.getClass().getName())
                .append(" -> ")
                .append(currentClassloader)
                .append("\n");

currentClassloader = currentClassloader.getParent();
        level++;
    }
    myLogD(sb.toString());
}
```

效果展示：

![](upload/attach/202606/999665_VHRH5Y886J4HNS9.webp)

通过这个方法能够很清楚的看到委派链是：`PathClassLoader->BootClassLoader`。

这个位于委派链最前端的 **`PathClassLoader`，其实就是前两篇文章中反复出现的 `mClassLoader`**——App 进程中默认的类加载器。系统所有 "找类" 的操作都从它开始，然后沿着委派链逐级向上委托。理解了这一点，就能明白为什么加固必须对它下手：**我们自己创建的 `DexClassLoader` 不在这个委派链上，系统根本不会去问它。** 接下来我们通过实战来验证这个问题。

# 0x03 动态加载`Dex`

## mClassLoader 在源码中的位置

简单回顾一下：`mClassLoader` 这个默认类加载器存储在 `LoadedApk` 中，而 `LoadedApk` 又存放在 `ActivityThread` 的 `mPackages` 这个 `ArrayMap` 成员里：

![](upload/attach/202606/999665_Z45KWCGKYRZA6PA.webp)
`mPackages` 以**包名**为键，对应的值是一个 `WeakReference`，引用的就是 `LoadedApk`——它包含了 `mClassLoader` 这个默认类加载器。

![](upload/attach/202606/999665_F5QEUY95KHFJR5Q.webp)

也就是说，要修改 `mClassLoader`，需要先通过反射拿到 `ActivityThread`，再获取 `LoadedApk`，最后修改其中的 `mClassLoader` 字段。`ActivityThread` 可以通过反射调用其静态方法 `currentActivityThread` 直接获取。

## 测试环境准备

这里重新创建一个新的项目，包括普通类，以及一个继承activity的组件类：

+ **`TestClass`：**

```java
  public class TestClass {
      public static void testfunc(){
          Log.i("[testLoaded]","[com.example.test01.TestClass] testfunc is calling...");
      }
  }
  ```

+ **`TestActivity`：**

```java
  public class TestActivity extends Activity {
      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          Log.i("[testLoaded]","[com.example.test01.TestActivity] onCreate is calling...");
      }
  }
  ```

由于高版本的Android无法读`sdcard`的内容，这里为了方便加载期间，`build`之后将相关的`dex`文件丢到测试项目的`assets`目录当中：

![](upload/attach/202606/999665_HWFZW9PF72QYUMJ.webp)

并且还需要封装一个从assets目录当中，使用`dexClassLoader`加载`dex`的方法：

```java
private static ClassLoader loadDexFromAssest(Context context, String dexName, ClassLoader parentClassLoader){
    File dexFile = new File(context.getFilesDir(),dexName);
    if(!dexFile.exists()){
        try(InputStream is = context.getAssets().open(dexName); FileOutputStream fos = new FileOutputStream(dexFile)){
            byte[] buffer = new byte[4096];
            int len;
            while((len = is.read(buffer)) != -1){
                fos.write(buffer, 0, len);
            }
        } catch (FileNotFoundException e) {
            throw new RuntimeException(e);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

File optimizedDir = context.getCodeCacheDir();
    return new DexClassLoader(dexFile.getAbsolutePath(),
            optimizedDir.getAbsolutePath(),
            null,
            parentClassLoader);
}
```

此外为了让当前项目能够启动这个`TestActivity`，还需要在`Manifest`清单文件当中的`<activity>`标签当中加上这个：

```xml
<activity android:name="com.example.test01.TestActivity"></activity>
```

## 动态加载普通类

首先动态加载一下`TestClass`这个普通的类，然后通过反射调用一下这个类当中的`testfunc`函数，代码如下：

```java
public static void loadedNomalClass(Context context){
    ClassLoader pathClassloader = MainActivity.class.getClassLoader();
    dexclassloader = loadDexFromAssest(context, "test.dex", pathClassloader);

try{
        Class testClass = dexclassloader.loadClass("com.example.test01.TestClass");
        Method testfunc = testClass.getDeclaredMethod("testfunc");
        testfunc.setAccessible(true);
        testfunc.invoke(null);
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    } catch (InvocationTargetException e) {
        throw new RuntimeException(e);
    } catch (NoSuchMethodException e) {
        throw new RuntimeException(e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    }
}
```

![](upload/attach/202606/999665_P78Z44E2V7X5TND.webp)

可以看到这里成功执行了这个`testfunc`，没有任何异常。

## 动态加载组件

### 动态加载组件类的问题

了解了动态加载`dex`，并且使用反射调用内部方法的手法后。接着来看看如果**仅仅**使用上面的步骤来动态加载组件，并启动组件的话会出现什么问题。

```java
public static void startActivityFirstMethod(Context context){
    ClassLoader pathClassloader = MainActivity.class.getClassLoader();
    dexclassloader = loadDexFromAssest(context, "test.dex", pathClassloader);

try{
        Class TestActivity = dexclassloader.loadClass("com.example.test01.TestActivity");
        myLogD("Class : " + TestActivity);
        context.startActivity(new Intent(context, TestActivity));
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    }
}
```

这里需要使用`context.startActivity`来启动`Activity`，而不是反射。

![](upload/attach/202606/999665_P4CH8EJBV6BCGM5.webp)

![](upload/attach/202606/999665_RVN2R2TBYNDP75B.webp)

通过`logcat`可以看到这个`dexclassloader`是能够成功`loadClass`，但是这里使用`startActivity`来启动`Activity`却抛出了`ClassNotFound`的异常。说明当前的类加载器无法找到这个`com.example.test01.TestActivity`。

这是为什么呢？这里用`printClassLoaderHierarchy`来看看委派链，传入的参数是`dexclassloader`：

![](upload/attach/202606/999665_QT8YA6DZEGDH9PD.webp)

发现只有在`dexClassLoader`这个类加载器当中才有`test.dex`这个访问路径。

通过观察委派链输出的`ClassLoader`和报错信息的`ClassLoader`，可以发现这两个类加载器是一样的，那么说明这个app默认用来查找类的`classloader`是`pathClassloader`。

通过这个大概能够知道出现这个问题的其实是：动态加载的`dex`文件的类加载器是`DexClassLoader`，其委派的加载器是`pathClassLoader`。而默认类加载器是`pathClassLoader`，通过**双亲委派查找类**的时候，只能查找`pathClassLoader ~ BootClassLoader`这个范围，而无法通过`dexClassLoader`查找，所以会出现`ClassNotFound`这个异常。大概如下图所示：

![](upload/attach/202606/999665_4Y4NE592YJ5YQVQ.webp)

# 解决方法

那么现在已经知道了是大概是因为这个双亲委派机制无法通过`dexClassLoader`找到这个类。那么我们只需要将`dexClassLoader`添加到这个双亲委派能够查找到的范围就可以了，这里提供三个方法，它们的本质都是**让系统能从默认的查找路径上找到外部 dex 中的类**：

1. **替换默认类加载器** — 将 `mClassLoader` 直接设置为 `DexClassLoader`（这正是第一篇文章中壳代码的做法）
2. **插入委派链** — 将 `DexClassLoader` 插入到 `PathClassLoader` 与 `BootClassLoader` 之间
3. **合并 dexElements** — 将 `DexClassLoader` 的 `dexElements` 合并到 `PathClassLoader` 的 `dexElements` 中（也就是常说的"热修复"方案）

# 方法一

获取到`LoadedApk`，然后使用反射修改`mClassLoader`，改成`DexClassLoader`即可，大致过程可以参考下图：

![](upload/attach/202606/999665_R67XUMXY77CBMSC.webp)

+ 代码示例：

try{
        // 通过currentActivityThread获取 ActivityThreaObj
        Class activityThreadclass = pathClassloader.loadClass("android.app.ActivityThread");
        Method currentActivityThreadmethod = activityThreadclass.getDeclaredMethod("currentActivityThread");
        currentActivityThreadmethod.setAccessible(true);
        Object currentactivityThreadobj = currentActivityThreadmethod.invoke(null);

// 获取mPackages
        Field mPackagesfield = activityThreadclass.getDeclaredField("mPackages");
        mPackagesfield.setAccessible(true);
        ArrayMap mPackagesobj = (ArrayMap) mPackagesfield.get(currentactivityThreadobj);

if(appcontext != null){
            String packagename = appcontext.getPackageName();
            WeakReference wr = (WeakReference) mPackagesobj.get(packagename);
            Object loadedapkObj = (Object) wr.get();

Class loadedApkClass = pathClassloader.loadClass("android.app.LoadedApk");
            Field mClassLoaderField = loadedApkClass.getDeclaredField("mClassLoader");
            mClassLoaderField.setAccessible(true);

// 打印mClassLoader变化
            ClassLoader prevClassloader = (ClassLoader) mClassLoaderField.get(loadedapkObj);
            myLogD("prev classloader -> " + prevClassloader);
            mClassLoaderField.set(loadedapkObj,dexclassloader);
            myLogD("curr classloader -> " + dexclassloader);
        }
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    } catch (InvocationTargetException e) {
        throw new RuntimeException(e);
    } catch (NoSuchMethodException e) {
        throw new RuntimeException(e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    } catch (NoSuchFieldException e) {
        throw new RuntimeException(e);
    }

try{
        Class TestActivity = dexclassloader.loadClass("com.example.test01.TestActivity");
        myLogD("Class : " + TestActivity);

//            printClassLoaderHierarchy(dexclassloader);
        context.startActivity(new Intent(context, TestActivity));
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    }
}
```

可以看到成功执行了`onCreate`了。

![](upload/attach/202606/999665_N2H53YKBHKVBKRF.webp)

这就是第一篇文章中壳代码的核心逻辑——在 `attachBaseContext` 中替换 `mClassLoader`，让系统后续找类时沿着新的 ClassLoader 去加载我们解密出来的 dex。

# 方法二

将dexClassLoader插入到pathClassLoader和bootClassLoader当中

![](upload/attach/202606/999665_V8EZT9JMXKJ67Y8.webp)

```java
public static void startActivitySecondMethod(Context context){
    ClassLoader pathClassloader = MainActivity.class.getClassLoader();
    ClassLoader bootClassloader = pathClassloader.getParent();
    dexclassloader = loadDexFromAssest(context, "test.dex", bootClassloader);

try{
        Field parentfield = ClassLoader.class.getDeclaredField("parent");
        parentfield.setAccessible(true);
        parentfield.set(pathClassloader, dexclassloader);
    } catch (NoSuchFieldException e) {
        throw new RuntimeException(e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    }

// 打印委派链
    printClassLoaderHierarchy(pathClassloader);

try{
        Class TestActivityClass = dexclassloader.loadClass("com.example.test01.TestActivity");
        myLogE(TestActivityClass.toString());
        context.startActivity(new Intent(context, TestActivityClass));
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    }
}
```

![](upload/attach/202606/999665_W8KF2Y6EYMW2CAG.webp)

可以看到此时的委派链是`pathClassLoader -> DexClassLoader -> BootClassLoader`，而且能够正常启动Activity，并执行`onCreate`函数。

相比方法一直接替换 `mClassLoader`，这种方法保留了原来的 `PathClassLoader` 在委派链顶端，改动更小、更隐蔽，是另一种可行的加固思路。

# 方法三：合并 dexElements（热修复方案）

上面两种方法都是从修改委派链路出发，那么还有没有别的方法呢？回想一下 0x01 中介绍的 `dexElements`——这个数组决定了类加载器要到哪里找类以及查找顺序。如果我们将 `DexClassLoader` 的 `dexElements` 合并到 `PathClassLoader` 的 `dexElements` 中，`PathClassLoader` 就能直接搜到我们外部加载的 dex 了。

而这正是常说的**热修复**原理：将补丁 dex 加载后插入到 `dexElements` 头部，加载类时就会优先命中补丁中的类。

这里通过源码看看为什么会优先加载补丁`dex`：

![](upload/attach/202606/999665_5AVEUXU5STVA3UK.webp)

可以看到这里是通过遍历`dexElements`当中的每一项来`findClass`的，只要找到了就直接返回`class`。这就是为什么能够优先加载补丁后的`dex`。

# 代码示例

那么知道了原理就来写一下代码

首先要来封装几个工具方法：

+ 从`ClassLoader`中获取`dexElements`：

```java
public static Object getDexElementsInClassLoader(ClassLoader classLoader){
    try{
        Class BaseDexClassLoaderClass = classLoader.loadClass("dalvik.system.BaseDexClassLoader");
        Field pathListField = BaseDexClassLoaderClass.getDeclaredField("pathList");
        pathListField.setAccessible(true);
        Object pathListObj = pathListField.get(classLoader);

Class DexPathListClass = classLoader.loadClass("dalvik.system.DexPathList");
        Field dexElementsField = DexPathListClass.getDeclaredField("dexElements");
        dexElementsField.setAccessible(true);
        Object dexElementsObj = dexElementsField.get(pathListObj);
        return dexElementsObj;
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    } catch (NoSuchFieldException e) {
        throw new RuntimeException(e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    }
}
```

+ 为`ClassLoader`设置`dexElements`：

```java
public static void setDexElementsInCloassLoader(ClassLoader classLoader, Object dexElements){
    try{
        Class BaseDexClassLoaderClass = classLoader.loadClass("dalvik.system.BaseDexClassLoader");
        Field pathListField = BaseDexClassLoaderClass.getDeclaredField("pathList");
        pathListField.setAccessible(true);
        Object pathlistObj = pathListField.get(classLoader);

Class DexPathListClass = classLoader.loadClass("dalvik.system.DexPathList");
        Field dexElementsField = DexPathListClass.getDeclaredField("dexElements");
        dexElementsField.setAccessible(true);
        dexElementsField.set(pathlistObj, dexElements);
    } catch (NoSuchFieldException e) {
        throw new RuntimeException(e);
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    }
}
```

+ 合并`dexElements`：

```java
public static Object combineDexElements(Object element1, Object element2){
    Object result = null;
    int len1 = Array.getLength(element1);
    int len2 = Array.getLength(element2);
    int newlen = len1+len2;
    result = Array.newInstance(element1.getClass().getComponentType(), newlen);

for(int i = 0; i < newlen; i++){
        if(i < len2){
            Array.set(result,i,Array.get(element2, i));
        }else{
            Array.set(result, i, Array.get(element1, i - len2));
        }
    }
    myLogD("newDexElements's len : "+newlen);
    return result;
}
```

+ **启动函数：**

```java
public static void startActivityThirdMethod(Context context){
    ClassLoader pathClassLoader = MainActivity.class.getClassLoader();
    dexclassloader = loadDexFromAssest(context, "test.dex", pathClassLoader);
    Object dexElements1 = getDexElementsInClassLoader(pathClassLoader);
    Object dexElements2 = getDexElementsInClassLoader(dexclassloader);
    Object newdexElements = combineDexElements(dexElements1, dexElements2);

setDexElementsInCloassLoader(pathClassLoader, newdexElements);
	
    printClassLoaderHierarchy(pathClassLoader);
    try{
        Class TestActivityClass = pathClassLoader.loadClass("com.example.test01.TestActivity");
        myLogE(TestActivityClass.toString());
        context.startActivity(new Intent(context, TestActivityClass));
    } catch (ClassNotFoundException e) {
        throw new RuntimeException(e);
    }
}
```

合并之后可以看到`pathClassLoader`当中有`test.dex`，并且`onCreate`也可以正常执行了。

![](upload/attach/202606/999665_7CEWR6PE459G9YR.webp)

这种方法不需要修改委派链，只需要操作 `dexElements` 数组。它既是热修复的底层原理，也可以作为加固的一种实现方式——将被保护的 dex 合并进 `mClassLoader` 的搜索路径中，系统自然就能找到它了。

# 0x04 总结

## 回看前言的三个问题

到了这里，前言中抛出的三个问题已经有了明确的答案：

**1. mClassLoader 到底是什么？**

它是 `PathClassLoader`，存储在 `LoadedApk` 中，是 App 进程的默认类加载器。它的内部结构是 `PathList → dexElements[] → DexFile`，`dexElements` 数组决定了它能搜索哪些 dex 文件。

**2. 为什么系统要通过它来找类？**

因为双亲委派机制。系统找类时从 `mClassLoader`（即 `PathClassLoader`）出发，沿着 `PathClassLoader → BootClassLoader` 这条委派链逐级向上查找。我们自己 `new` 的 `DexClassLoader` 不在这个链上，所以 `startActivity` 时系统压根不会去问它——这就是 `ClassNotFound` 的根因。

**3. 除了替换 mClassLoader，还有没有别的方案？**

有。本文展示了三种方案，它们的共同目标是——**让系统能从默认的查找路径上找到外部 dex 中的类**：

| 方案              | 操作                                                  | 思路                                             |
| ----------------- | ----------------------------------------------------- | ------------------------------------------------ |
| 替换 mClassLoader | 反射修改 `LoadedApk.mClassLoader`                     | 直接"换人"，让系统以为 DexClassLoader 就是默认的 |
| 插入委派链        | `PathClassLoader.parent = DexClassLoader`             | "加塞"，让 DexClassLoader 出现在委派链上         |
| 合并 dexElements  | 将 DexClassLoader 的 dexElements 拼入 PathClassLoader | "借用"，不改变委派链，只扩充搜索数组             |

## 整体加固的原理

整体加固的原理，说到底就是**类加载器的接管**。壳代码在 `attachBaseContext` 这个最早的执行时机，解密原始 dex，然后通过操纵类加载器（替换、插入或合并），让系统在后续启动 `Application`、`Activity` 等组件时，能够找到隐藏在外部 dex 中的真正代码。三种方案路径不同，但终点一致——**把解密后的 dex "挂"到系统能看见的地方。**

回复或点赞可查看完整内容

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

最后于 2026-6-3 19:15 被x0rrrrr编辑，原因：

#逆向分析 #基础理论 #混淆加固

上传的附件：

testLoaded.7z （5.20MB，23次下载）
test01.7z （4.98MB，23次下载）

最新回复 (62) 1 2 3 ▶
XCicada 雪币： 3103 活跃值： (2705) 能力值： ( LV6，RANK：80 ) 在线值：发帖 3 回帖 324 粉丝 101 关注私信	XCicada 2 2 楼 1 2026-6-3 14:11 0
xingbing 雪币： 158 活跃值： (5791) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 3 楼学习。 2026-6-3 16:11 0
eviliori 雪币： 192 活跃值： (268) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 39 粉丝 2 关注私信	eviliori 4 楼 1 2026-6-3 18:24 0
byhk 雪币： 2734 活跃值： (8968) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 206 粉丝 1 关注私信	byhk 5 楼谢谢分享 2026-6-3 18:46 0
嘎嘎真的很棒雪币： 716 活跃值： (3812) 能力值： ( LV3，RANK：30 ) 在线值：发帖 8 回帖 161 粉丝 7 关注私信	嘎嘎真的很棒 6 楼 1 2026-6-3 19:08 0
fengvmu 雪币： 5948 活跃值： (3826) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 70 粉丝 0 关注私信	fengvmu 7 楼谢谢分享 2026-6-3 19:18 0
SomeMx 雪币： 4211 活跃值： (5614) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 8 楼过来瞧瞧 2026-6-3 21:21 0
jyotidwi 雪币： 1349 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 121 粉丝 3 关注私信	jyotidwi 9 楼 Tql 2026-6-3 22:16 0
wx_北极星_493 雪币： 159 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 59 粉丝 0 关注私信	wx_北极星_493 10 楼看看 2026-6-3 23:41 0
叶晓枫A 雪币： 139 活跃值： (985) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	叶晓枫A 11 楼看看原理 2026-6-4 03:49 0
mb_wqvhhpxn 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 10 粉丝 0 关注私信	mb_wqvhhpxn 12 楼看看 2026-6-4 10:16 0
LQ6H 雪币： 530 活跃值： (2627) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 80 粉丝 1 关注私信	LQ6H 13 楼 666 2026-6-4 14:21 0
斗转南see雪雪币： 202 活跃值： (548) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 26 粉丝 1 关注私信	斗转南see雪 14 楼 1 2026-6-4 16:22 0
4Chan 雪币： 375 活跃值： (4087) 能力值： ( LV3，RANK：30 ) 在线值：发帖 9 回帖 202 粉丝 12 关注私信	4Chan 15 楼学习一下 2026-6-4 19:30 0
huangjw 雪币： 6747 活跃值： (11957) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 514 粉丝 2 关注私信	huangjw 16 楼可以复习 2026-6-4 20:27 0
GEKEZYX 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 157 粉丝 0 关注私信	GEKEZYX 17 楼 666 2026-6-5 00:20 0
明尊雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 1 粉丝 0 关注私信	明尊 18 楼 666 2026-6-8 11:23 0
baichisi 雪币： 39 活跃值： (2693) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 115 粉丝 0 关注私信	baichisi 19 楼 666 2026-6-8 13:51 0
mb_ezmrnfsu 雪币： 222 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 24 粉丝 0 关注私信	mb_ezmrnfsu 20 楼 666 2026-6-13 19:08 0
mb_eizetlni 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 47 粉丝 1 关注私信	mb_eizetlni 21 楼 666 2026-6-13 20:22 0
随风而行aa 雪币： 7773 活跃值： (25229) 能力值： ( LV12，RANK：550 ) 在线值：发帖 39 回帖 432 粉丝 1587 关注私信	随风而行aa 10 22 楼看看 2026-6-13 22:28 0
ClPrada 雪币： 3 活跃值： (200) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 51 粉丝 0 关注私信	ClPrada 23 楼 2026-6-16 13:44 0
Freax 雪币： 5152 活跃值： (2545) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 73 粉丝 1 关注私信	Freax 24 楼 66 2026-6-16 15:19 0
wx_小白_266 雪币： 159 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 39 粉丝 0 关注私信	wx_小白_266 25 楼看看 2026-6-17 10:33 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复