当前位置：首页 > news >正文

Unidbg模拟JNI调用时参数传递的继承链陷阱

news 2026/6/23 17:15:24

1. 揭开Unidbg模拟JNI调用时的继承链陷阱

第一次用Unidbg模拟调用JNI函数时，我遇到了一个诡异的问题：明明按照文档写了调用逻辑，却总是莫名其妙崩溃。最让人抓狂的是，错误日志里连个有用的线索都没有。后来才发现，这其实是个典型的"类继承链断裂"问题。

想象一下这样的场景：你在Java层调用native方法，这个方法内部通过FindClass获取了某个类A，然后调用类A的方法。在Unidbg模拟时，如果你传入的对象没有正确继承类A，就会导致调用链断裂。这就好比你要用钥匙开锁，钥匙确实是钥匙，但和你家的锁根本不匹配。

举个例子，假设有个JNI函数内部调用了ContextWrapper类的getFilesDir方法。如果你在Unidbg中直接创建一个MainActivity对象传入，而没有建立正确的继承关系，就会触发这个陷阱。因为MainActivity必须继承ContextWrapper才能调用其方法，这个继承关系在真实Android环境中是自动建立的，但在Unidbg模拟时需要手动处理。

2. 为什么参数传递会出问题？

2.1 JNI调用的底层机制

JNI调用本质上是在不同环境间传递数据。当Java调用native方法时，虚拟机会把Java对象转换成JNI能识别的形式。关键点在于，这个转换过程会保留对象的类继承关系信息。

在Unidbg中模拟这个过程时，很多人（包括最初的我）会犯一个错误：只创建了目标类的实例，却忽略了它的继承链。比如直接创建MainActivity对象，而没设置它的父类是ContextWrapper。这就导致后续调用getFilesDir时，虚拟机会发现"这个对象根本不是ContextWrapper"，于是抛出错误。

2.2 两种典型的错误场景

第一种是直接传0作为jobject参数。这在某些简单场景可能侥幸通过，但一旦遇到需要检查对象类型的情况就会崩溃。就像下面的代码：

// 错误示范：直接传0 list.add(0); // 第二个参数传0

第二种是创建了对象但没设置正确的继承关系：

// 错误示范：没有继承链 DvmObject<?> obj = vm.resolveClass("com/example/MainActivity").newObject(null);

这两种做法都会导致后续的GetMethodID和Call*Method调用失败，而且错误信息往往很不直观，让人摸不着头脑。

3. 如何正确打通调用链？

3.1 建立完整的类继承关系

正确的做法是在创建对象时显式指定父类。Unidbg的DvmClass提供了这个功能：

// 正确做法：指定父类 DvmClass ContextWrapper = vm.resolveClass("android/content/ContextWrapper"); DvmClass MainActivity = vm.resolveClass("com/example/MainActivity", ContextWrapper); DvmObject<?> obj = MainActivity.newObject(null);

这样创建的对象就具有完整的继承链，能够通过JNI的类型检查。对于上面的例子，因为MainActivity继承了ContextWrapper，所以可以安全调用getFilesDir方法。

3.2 处理接口实现的情况

当方法参数是接口类型时（比如Map），情况又有些不同。这时需要确保传入的对象实现了该接口：

// 处理接口实现 DvmClass Map = vm.resolveClass("java/util/Map"); DvmClass TreeMap = vm.resolveClass("java/util/TreeMap", Map); DvmObject<?> mapObj = TreeMap.newObject(new TreeMap<>());

这里的关键是TreeMap要声明实现了Map接口，否则调用Map接口的方法时会失败。这和Java中的"implements"关键字是同样的概念。

4. 实战案例解析

4.1 文件路径获取的正确姿势

让我们看一个完整的正确示例。假设要模拟调用一个获取文件路径的native方法，内部使用了ContextWrapper的getFilesDir：

public void getFilePath() { // 1. 准备参数列表 List<Object> list = new ArrayList<>(); list.add(vm.getJNIEnv()); // JNIEnv* // 2. 创建正确继承关系的对象 DvmClass ContextWrapper = vm.resolveClass("android/content/ContextWrapper"); DvmClass MainActivity = vm.resolveClass("com/example/MainActivity", ContextWrapper); DvmObject<?> activityObj = MainActivity.newObject(null); list.add(activityObj.hashCode()); // 正确的jobject // 3. 调用native方法 Number result = module.callFunction(emulator, 0x1234, list.toArray())[0]; // 处理结果... }

这段代码的关键点在于MainActivity正确地继承了ContextWrapper，因此后续JNI调用getFilesDir时不会出现类转换错误。

4.2 处理Map类型参数的陷阱

另一个常见场景是处理Map类型的参数。错误的做法是直接创建TreeMap对象而不声明它实现Map接口：

// 错误做法：没有声明实现Map接口 DvmObject<?> mapObj = vm.resolveClass("java/util/TreeMap").newObject(new TreeMap<>());

正确的做法应该是：

// 正确做法：声明实现Map接口 DvmClass Map = vm.resolveClass("java/util/Map"); DvmClass TreeMap = vm.resolveClass("java/util/TreeMap", Map); DvmObject<?> mapObj = TreeMap.newObject(new TreeMap<>());

这样才能确保后续调用Map接口的方法（如isEmpty）时不会出错。