移动应用逆向实战：从Frida动态Hook到unidbg静态模拟算法复现

1. 项目概述一次从动态到静态的逆向实战最近在分析一个移动应用时遇到了一个典型的“黑盒”参数zzz。这个参数出现在某个蜂窝网络服务的核心请求中每次请求都会变化显然是某种算法生成的签名或令牌。对于这类问题我们通常的思路是先通过动态分析如 Frida快速定位关键函数理解其逻辑然后再用静态分析或模拟执行如 unidbg来稳定复现算法。这次实战我就完整地走了一遍这个流程从 Frida 的快速 Hook 定位到 unidbg 的稳定算法复现最终成功生成了可用的zzz参数。整个过程充满了挑战也积累了不少经验今天就来详细拆解一下希望能给遇到类似问题的朋友一些启发。这个zzz参数有几个特点长度固定为 64 位十六进制字符串对相同的输入在不同时间或设备上输出可能不同它被附加在 HTTP 请求头中服务端会据此进行校验。我们的目标很明确逆向出生成这个 64 位字符串的完整算法并能在脱离原 App 环境的情况下用 Python 或其他语言稳定复现。这不仅是技术上的挑战更是对逆向工程中“动态定位”与“静态模拟”两种核心能力结合的经典考验。无论你是刚接触逆向的新手还是想深入了解 unidbg 如何接棒 Frida 完成自动化这篇记录都能提供一条清晰的路径。2. 逆向分析的整体思路与工具选型面对一个未知的加密参数盲目地静态阅读汇编或 Smali 代码效率极低。我的策略是“由动至静层层深入”。首先利用 Frida 进行动态插桩快速缩小关键代码的范围甚至直接观察到算法的输入输出和关键运算。然后将定位到的核心函数或库放入 unidbg 这个强大的“沙盒”中进行模拟执行从而脱离真机或模拟器环境实现算法的稳定复现和深入分析。2.1 为什么选择 Frida 作为突破口Frida 是一个动态代码插桩工具包它允许你将 JavaScript 代码片段注入到目标进程无论是桌面还是移动应用中。在 Android 逆向中它的价值无可替代。核心优势在于实时性与交互性。你不需要重新打包 APK就能在应用运行时Hook挂钩任意的 Java 函数或 NativeC/C函数。对于zzz这类参数我们通常的怀疑对象是 Java 层的某个getZZZ()方法或者 JNIJava Native Interface调用的某个 so 库函数。使用 Frida我们可以快速枚举和尝试 Hook 所有看起来可疑的函数名通过打印其参数和返回值立刻就能知道这个函数是否参与了zzz的生成。这种“即插即用、所见即所得”的能力在逆向初期信息匮乏时是最高效的侦查手段。具体到本次分析我首先怀疑zzz可能由 Java 层生成。于是写了一个 Frida 脚本Hook 了所有类名中包含 “sign”、“auth”、“token”、“encrypt” 等关键词的类方法。很快我就发现了一个名为com.xxx.bee.network.security.Encryptor的类其generateToken(byte[] data)方法的返回值长度和格式与zzz高度吻合。通过打印输入参数data我发现它就是请求体Body的 MD5 值加上当前时间戳。这让我们成功将搜索范围从整个应用缩小到了一个具体的类和方法。2.2 为什么需要 unidbg 接棒虽然 Frida 帮我们定位到了关键函数但直接基于 Frida Hook 的结果来编写算法复现代码存在几个明显问题环境依赖性算法可能依赖特定的 Android 系统环境、设备信息IMEI, Android ID或应用上下文。这些在 Frida 脚本中获取和模拟比较繁琐。稳定性与性能Frida Hook 毕竟是在真实应用进程中运行可能引发崩溃尤其 Hook 了不稳定的函数时。同时对于需要批量生成zzz的场景频繁启动 App 并注入脚本效率太低。深入分析受限如果关键逻辑在 Native 层且算法复杂如涉及大量的位运算、查表仅通过 Frida 打印输入输出和少量中间值很难完全理解其内部逻辑。这时unidbg就派上用场了。它是一个基于 Unicorn 引擎的逆向工具可以模拟执行 Android 的 so 库文件而无需依赖完整的 Android 系统或真机。你可以把它想象成一个专门为 so 库准备的“沙盒”或“虚拟机”。它的工作流程完美承接了 Frida 的成果我们用 Frida 找到了生成zzz的关键 so 库比如libencrypt.so和具体的 JNI 函数名比如Java_com_xxx_bee_network_security_Encryptor_generateToken。然后我们可以将这个 so 文件从 APK 中提取出来用 unidbg 写一个 Java 程序直接加载这个 so并调用那个 JNI 函数。unidbg 会模拟执行 so 里的所有指令最终给出计算结果。在这个过程中我们还可以利用 unidbg 提供的调试功能像使用 IDA Pro 一样单步跟踪代码、查看内存和寄存器从而彻底搞懂算法细节。简单来说分工如下Frida 是“侦察兵”负责在复杂的战场App上快速找到敌人关键函数的位置unidbg 是“实验室”把抓到的“敌人样本”so 库带回来在可控的环境下进行彻底解剖和研究并复制出它的武器算法。3. 使用 Frida 进行动态定位与初步分析定位到Encryptor.generateToken后我们的逆向工作才算真正开始。这个方法很可能只是一个外壳真正的加密逻辑在 Native 层。下面是我的具体操作步骤和心得。3.1 Frida 环境搭建与基础 Hook首先确保你的测试环境真机或模拟器已 root 并安装了 Frida Server。在电脑上安装 Frida-toolspip install frida-tools。编写一个基础的 Hook 脚本这里以 Hook 上述 Java 方法为例// hook_encryptor.js Java.perform(function () { var Encryptor Java.use(com.xxx.bee.network.security.Encryptor); Encryptor.generateToken.overload([B).implementation function (data) { console.log(\n[*] Encryptor.generateToken called!); // 打印输入参数byte数组 console.log([] Input data (hex): bytesToHex(data)); console.log([] Input data (length): data.length); // 调用原方法获取结果 var result this.generateToken(data); // 打印输出结果 console.log([] Output token: result); console.log([] Output length: result.length); // 打印调用栈有助于理解调用链 console.log([] Call stack:); console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Exception).$new())); return result; }; // 辅助函数将byte数组转为十六进制字符串 function bytesToHex(bytes) { var hex []; for (var i 0; i bytes.length; i) { hex.push((bytes[i] 4).toString(16)); hex.push((bytes[i] 0xF).toString(16)); } return hex.join(); } });使用命令frida -U -f com.xxx.bee -l hook_encryptor.js --no-pause启动应用并注入脚本。触发一次网络请求你会在控制台看到详细的输入输出信息。注意在实际操作中可能会遇到方法重载overload的情况。overload([B)表示 Hook 参数为一个 byte 数组的方法。如果方法有多个重载你需要用overload(java.lang.String)等来指定。使用Encryptor.generateToken.overloads可以查看所有重载这是一个非常实用的技巧。3.2 深入 Native 层Hook JNI 函数通过 Java 层的 Hook我们确认了输入是请求体 MD5 加时间戳。但generateToken方法内部很可能通过System.loadLibrary加载了 so并通过 JNI 调用 Native 函数。我们需要继续向下追踪。首先修改 Hook 脚本监控System.loadLibrary的调用看看加载了哪些 soJava.perform(function () { var System Java.use(java.lang.System); System.loadLibrary.overload(java.lang.String).implementation function (libname) { console.log([*] System.loadLibrary called: libname libname); var stack Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Exception).$new()); console.log(stack); // 打印调用栈看是谁加载的 return this.loadLibrary(libname); }; });运行后你可能会看到加载了libencrypt.so。接下来我们需要 Hook 这个 so 里的 JNI 函数。JNI 函数名有固定格式Java_包名_类名_方法名。这里可能就是Java_com_xxx_bee_network_security_Encryptor_generateToken。使用 Frida 的Interceptor.attach来 Hook Native 函数。你需要知道这个函数的地址或者通过模块名函数名来定位。更简单的方法是使用 Frida 的Module.findExportByName。Java.perform(function () { // 首先确保库已加载可以延迟执行或等待 setTimeout(function() { var nativeFuncPtr Module.findExportByName(libencrypt.so, Java_com_xxx_bee_network_security_Encryptor_generateToken); if (nativeFuncPtr ! null) { console.log([] Found native function at: nativeFuncPtr); Interceptor.attach(nativeFuncPtr, { onEnter: function (args) { // args[0] 是 JNIEnv* // args[1] 是 jclass/jobject // args[2] 是 jbyteArray即输入的 data console.log(\n[*] Native generateToken ENTER); // 将 jbyteArray 转换为 Frida 可读的字节数组 var env Java.vm.getEnv(); var jbyteArray args[2]; var jbytes env.getByteArrayElements(jbyteArray, null); var length env.getArrayLength(jbyteArray); var buffer Memory.readByteArray(jbytes, length); console.log([] Native input length: length); console.log([] Native input (hex): Array.from(new Uint8Array(buffer)).map(b b.toString(16).padStart(2, 0)).join()); }, onLeave: function (retval) { // retval 是 jstring即返回的 token console.log([*] Native generateToken LEAVE); var env Java.vm.getEnv(); var jstr retval; var nativeString env.getStringUtfChars(jstr, null); var token Memory.readCString(nativeString); console.log([] Native output token: token); env.releaseStringUtfChars(jstr, nativeString); } }); } else { console.log([-] Native function not found!); } }, 3000); // 延迟3秒等待so加载 });通过这个 Native Hook我们验证了加密确实发生在libencrypt.so中并且看到了最原始的输入输出。这为后续使用 unidbg 提供了最关键的目标我们需要模拟执行libencrypt.so里的Java_com_xxx_bee_network_security_Encryptor_generateToken函数。3.3 Frida 动态分析阶段的经验与避坑过反调试很多应用会检测 Frida。常见手段包括检查进程名、端口默认 27042、特定文件或线程。可以使用隐蔽性更强的 Frida 版本如frida-server改名或使用-D参数指定非默认端口也可以在脚本开头主动抹除一些特征。本次分析的 App 反调试较弱没有遇到太大阻碍。处理混淆类名、方法名可能被混淆成a.a,b.c等。此时不能靠关键词搜索需要结合调用栈分析、监控常见加密库如javax.crypto.Cipher的使用或者通过参数类型和返回值特征来定位。例如寻找参数是byte[]返回String的方法。数据转换在 Native Hook 时正确操作 JNI 数据类型jbyteArray,jstring是关键。上述示例中使用Java.vm.getEnv()获取JNIEnv指针来操作是标准做法。务必记得在onLeave中释放获取的字符串字符releaseStringUtfChars避免内存问题。脚本稳定性Frida 脚本注入可能导致应用崩溃尤其是 Hook 了不稳定的函数或处理不当。务必使用try-catch包裹关键逻辑并且先从小范围、简单的 Hook 开始测试。4. 使用 unidbg 模拟执行与算法复现拿到libencrypt.so和确切的 JNI 函数签名后我们就可以搭建 unidbg 环境了。unidbg 是一个 Java 项目我们需要编写一个 Java 程序来引导它。4.1 unidbg 环境搭建与项目初始化首先从 GitHub 克隆 unidbg 项目或者如果你使用 Maven可以直接添加依赖。这里以直接使用源码为例。准备环境确保已安装 JDK 8 或 11 和 Maven。获取 unidbggit clone https://github.com/zhkl0228/unidbg.git导入项目将 unidbg 文件夹作为一个 Maven 项目导入到你的 IDE如 IntelliJ IDEA中。创建测试类在unidbg-android/src/test/java下或其他你喜欢的源码目录创建一个新的 Java 类例如BeeEncryptTest.java。我们的目标是在这个测试类中编写代码加载libencrypt.so调用Java_com_xxx_bee_network_security_Encryptor_generateToken函数并传入正确的参数得到与 Frida 捕获的一致的zzz值。4.2 编写 unidbg 模拟执行代码以下是BeeEncryptTest.java的核心代码框架package com.test; import com.github.unidbg.AndroidEmulator; import com.github.unidbg.Module; import com.github.unidbg.linux.android.AndroidEmulatorBuilder; import com.github.unidbg.linux.android.AndroidResolver; import com.github.unidbg.linux.android.dvm.*; import com.github.unidbg.memory.Memory; import java.io.File; public class BeeEncryptTest { private final AndroidEmulator emulator; private final VM vm; private final Module module; public BeeEncryptTest() { // 1. 创建模拟器支持32位和64位 emulator AndroidEmulatorBuilder.for32Bit().build(); // 2. 获取内存接口 Memory memory emulator.getMemory(); // 设置库解析器用于自动解决系统so依赖如libc, libdl memory.setLibraryResolver(new AndroidResolver(23)); // API Level 23 // 3. 创建Android虚拟机 vm emulator.createDalvikVM(); // 可以在这里设置JNI相关处理器如果需要 // vm.setJni(new MyJni()); // 4. 加载我们关心的目标so DalvikModule dm vm.loadLibrary(new File(path/to/your/libencrypt.so), false); // false表示不立即执行初始化函数 dm.callJNI_OnLoad(emulator); // 手动调用JNI_OnLoad module dm.getModule(); // 5. 可选加载一些App可能依赖的其他so比如libcrypto.so // vm.loadLibrary(new File(libcrypto.so), true); } public String generateToken(byte[] inputData) { // 1. 将Java的byte[]转换为unidbg中的DvmObject? (jbyteArray) DvmObject? jinputData new ByteArray(vm, inputData); // 2. 获取JNI环境 DvmClass encryptorClass vm.resolveClass(com/xxx/bee/network/security/Encryptor); // 实际上对于JNI函数调用我们通常直接使用emulator的backend来调用函数地址 // 3. 找到目标Native函数的地址 long functionAddress module.findSymbolByName(Java_com_xxx_bee_network_security_Encryptor_generateToken).getAddress(); System.out.println([] Target function address: 0x Long.toHexString(functionAddress)); // 4. 准备调用。JNI函数原型jstring func(JNIEnv* env, jclass clazz, jbyteArray data) // 在unidbg中我们使用vm的JniFunctions工具来创建虚拟的JNI环境参数 // 更直接的方式是使用emulator.eFunc()调用并手动设置寄存器/栈参数对于ARM // 这里演示一种更高级但清晰的方式通过DvmMethod的callJniMethod // 由于这是一个实例方法非静态我们需要一个“假”的Encryptor对象 DvmObject? encryptorInstance encryptorClass.newObject(null); // 定义方法的签名(JNIEnv*, jobject, jbyteArray) - jstring // 在DVM中非静态Native方法签名是 (Lcom/xxx/bee/.../Encryptor; [B)Ljava/lang/String; // 但直接调用JNI函数我们需要模拟JNI调用约定。 // 简便方法使用Unidbg提供的JniFunction工具类包装 // 实际上对于简单的直接调用我们可以封装一个“桥接”方法。 // 这里为了清晰展示另一种常见模式通过创建一个假的Java方法来触发JNI调用不推荐复杂。 // 更推荐的做法是直接进行Native调用如下述注释。 System.out.println([-] 直接调用JNI函数较为复杂通常需要根据函数原型手动设置参数。); System.out.println([-] 一个更实用的方法是在unidbg中实现一个对应的Java类然后调用其native方法让unidbg自动路由。); // 让我们换一种更标准的方法在unidbg的VM中注册这个Native函数然后通过Java层调用。 return callNativeFunctionDirectly(inputData, functionAddress); } private String callNativeFunctionDirectly(byte[] inputData, long funcAddr) { // 对于ARM32参数通过R0, R1, R2, R3传递多余的下栈。 // JNI函数第一个参数是JNIEnv*第二个是jclass/jobject第三个是jbyteArray。 // 我们需要构造这些参数。 emulator.getBackend().reg_write(ArmConst.UC_ARM_REG_R0, vm.getJNIEnv()); // JNIEnv* emulator.getBackend().reg_write(ArmConst.UC_ARM_REG_R1, 0); // jclass对于静态方法是类引用非静态是对象引用。这里先假设为0NULL或一个假对象指针需要根据实际情况调整。 // 创建一个jbyteArray对象 Number ret vm.addLocalObject(new ByteArray(vm, inputData)); emulator.getBackend().reg_write(ArmConst.UC_ARM_REG_R2, ret.intValue()); // jbyteArray // 开始执行函数 emulator.eFunc(funcAddr, 0); // 第二个参数是返回值存放的寄存器不eFunc用于调用一个函数其原型是 Number eFunc(long address, Number... args)这里用法不对。 // 正确调用方式使用emulator.eFunc(funcAddr, vm.getJNIEnv(), 0, ret.intValue()); // 但eFunc要求参数是Number...且会自动按调用约定设置。对于ARM它可能默认是栈传递这很复杂。 System.out.println([-] 直接汇编级调用需要深入理解调用约定容易出错。); System.out.println([] 建议使用unidbg的高级APIvm.callJNIMethod 或通过DvmMethod调用。); // 作为演示我们假设调用成功并读取返回值R0寄存器 long resultPtr emulator.getBackend().reg_read(ArmConst.UC_ARM_REG_R0).intValue() 0xffffffffL; // 从resultPtr这个jstring指针中读取字符串内容 // 这需要访问JNIEnv的函数表非常繁琐。 return SIMULATED_TOKEN; // 占位符 } public static void main(String[] args) { BeeEncryptTest test new BeeEncryptTest(); byte[] input new byte[] {0x74, 0x65, 0x73, 0x74}; // test 的字节这里应该是MD5时间戳 String token test.generateToken(input); System.out.println(Generated token: token); } }上面的代码展示了基本框架但也暴露了直接调用 JNI 函数的复杂性。实际上unidbg 提供了更优雅的方式通过实现一个虚拟的 Java 类并注册对应的 Native 方法然后像在真实 Android 中一样调用这个 Java 方法。unidbg 会自动处理 JNI 调用路由到我们指定的 so 函数。4.3 更优雅的方式实现虚拟 JNI 调用我们创建一个虚拟的Encryptor类并告诉 unidbg它的generateToken这个 Native 方法实现就在我们 so 库的某个函数地址上。// 在BeeEncryptTest类中添加一个setup方法 private void setupVirtualClass() { // 1. 在VM中定义我们的虚拟类 vm.setVerbose(true); // 打开详细日志方便调试 // 2. 创建一个DvmClass对应我们的Encryptor DvmClass encryptorClass vm.resolveClass(com/xxx/bee/network/security/Encryptor); // 3. 获取目标Native函数的地址从so中 long nativeFuncAddr module.findSymbolByName(Java_com_xxx_bee_network_security_Encryptor_generateToken).getAddress(); // 4. 为这个类注册Native方法实现 // 方法签名 (byte[]) - String encryptorClass.registerNativeMethod(generateToken([B)Ljava/lang/String;, new JniMethod() { Override public JniObject call(Emulator? emulator, DvmObject? dvmObject, JniEnv jniEnv, VaList vaList) { // vaList 包含了Java方法传入的参数 // 第一个参数是jobject (this)对于非静态方法 // 第二个参数开始是Java方法的参数 DvmObject? byteArrayObj vaList.getObject(0); // 获取byte[]参数 byte[] inputBytes byteArrayObj.getValue(); // 获取byte[]的值 System.out.println([JNI] Input bytes length: inputBytes.length); System.out.println([JNI] Input hex: bytesToHex(inputBytes)); // 现在我们需要“调用”so里的原生函数。 // 但我们已经在这个函数里了实际上unidbg的registerNativeMethod是用来实现Java Native方法的 // 而不是用来桥接到另一个so函数。如果我们想直接执行so里的代码需要换一种思路。 // 正确的思路这个JniMethod的实现应该用emulator.eFunc去执行so里的机器码。 // 但这样又回到了手动设置寄存器/栈的复杂局面。 // 实际上unidbg 的 registerNativeMethod 通常用于我们**自己用Java代码实现**这个Native方法。 // 对于调用已有的so函数更常见的做法是 // a) 用Frida确认这个JNI函数内部是否只是简单包装实际逻辑在另一个内部函数如native_generate。 // b) 然后在unidbg中直接调用那个内部函数绕过JNI封装。 // 假设我们通过逆向发现在libencrypt.so里还有一个导出函数叫 generate_token_internal long internalFuncAddr module.findSymbolByName(generate_token_internal).getAddress(); if (internalFuncAddr ! 0) { // 使用emulator.eFunc调用这个内部函数它可能接受更简单的参数如char* input, char* output // 这里需要根据实际函数原型编写调用代码涉及内存分配、指针传递等。 // 篇幅所限不展开。 } // 临时返回一个假值 return new StringObject(vm, TOKEN_FROM_UNIDBG); } }); // 5. 现在我们可以在unidbg中像调用Java方法一样调用它了 DvmObject? encryptorInstance encryptorClass.newObject(null); ByteArray inputArray new ByteArray(vm, test_input.getBytes()); JniObject result encryptorInstance.callJniMethodObject(emulator, generateToken([B)Ljava/lang/String;, inputArray); System.out.println(Result from virtual call: result.getValue()); }这段代码展示了 unidbg 中处理 JNI 的两种思路一是直接进行底层的 Native 调用复杂二是利用 unidbg 的 Java 虚拟机机制注册 Native 方法并实现它。对于逆向 so 库我们往往需要结合两者先用第二种方式验证 so 加载和基础调用是否正常然后重点逆向 so 内部的纯 C 函数并用第一种方式直接调用这样更清晰。4.4 算法还原与参数补全在实际操作中通过 Frida 我们知道了输入是MD5(body) timestamp。但在 unidbg 中我们还需要补全算法可能依赖的其他上下文全局变量/上下文so 可能在JNI_OnLoad或某个初始化函数中设置了一些全局密钥、设备 ID 等。我们需要在 unidbg 中模拟这些初始化过程。可以通过 Frida 在JNI_OnLoad函数入口和出口下断点打印内存变化或者在 unidbg 中直接调用JNI_OnLoad上面代码已做。系统调用算法可能使用了gettimeofday,/dev/urandom,pthread等。unidbg 提供了IOResolver来模拟文件系统和系统调用你需要根据 so 的导入表Import Table来添加对应的处理。例如如果 so 调用了time()你需要在 unidbg 中返回一个可控的时间戳。外部函数调用算法可能调用了其他 so 的函数如libcrypto.so中的MD5_Init,AES_encrypt等。你需要将相应的 so 也加载到 unidbg 中或者自己实现这些函数。unidbg 的AndroidResolver会自动加载一些 Android 系统 so但对于非系统库需要手动loadLibrary。一个成功的标志是在 unidbg 中传入与 Frida 捕获的完全相同的输入字节数组能得到完全相同的zzz输出。为了达到这一点可能需要反复对比调试使用 unidbg 的emulator.attach().debug()功能进行单步跟踪并与 IDA Pro 等静态分析工具结合理解每一段代码的作用。5. 从 unidbg 到独立代码移植当你在 unidbg 中能稳定复现算法后最后一步就是将算法逻辑翻译成独立的代码如 Python、Java 或 C。这一步更像是“代码翻译”工作。梳理逻辑根据 unidbg 的调试和静态分析画出算法的流程图。明确输入、输出、每一步的运算哈希、对称加密、非对称加密、编码等。提取关键常量从 so 文件中提取出所有的魔术数字、常量表、S-Box、密钥等。这些通常存储在.rodata段。可以使用 IDA Pro 或readelf -x .rodata libencrypt.so命令导出。选择实现库根据算法类型选择成熟的库。如果是 AES可以用 Python 的cryptography库如果是 RSA可以用rsa库如果是自定义的混淆算法那就需要自己实现。编写代码并验证用目标语言实现算法并用多组测试数据来自 Frida 抓包进行验证确保输出完全一致。例如假设最终分析出zzz是HMAC-SHA256(密钥, MD5(body)timestamp)的结果然后进行 Base64 编码最后取特定长度。那么 Python 复现代码可能如下import hashlib import hmac import time import base64 def generate_zzz(body: str, secret_key: bytes) - str: # 1. 计算请求体的MD5 md5_hash hashlib.md5(body.encode()).digest() # 2. 获取当前时间戳秒级可能还需要特定格式 timestamp int(time.time()) timestamp_bytes timestamp.to_bytes(8, little) # 假设是64位小端序 # 3. 拼接 message md5_hash timestamp_bytes # 4. 计算HMAC-SHA256 hmac_digest hmac.new(secret_key, message, hashlib.sha256).digest() # 5. 自定义编码或截取根据逆向结果 # 假设是取前16字节的十六进制大写 zzz hmac_digest[:16].hex().upper() return zzz # 从so中提取的密钥 SECRET_KEY bytes.fromhex(0123456789ABCDEF...) body {action: query, data: test} zzz generate_zzz(body, SECRET_KEY) print(zzz)6. 常见问题排查与实战心得在整个从 Frida 到 unidbg 的逆向过程中会遇到无数坑。这里记录几个最典型的问题一Frida 脚本注入后 App 立刻闪退。可能原因App 有强大的反调试或反注入检测。排查检查 logcat 日志看是否有FRIDA,DEBUG,ptrace等关键词的报错。尝试使用隐藏性更好的 Frida 模式如frida-server改名并运行在非默认端口使用-D参数连接。也可以尝试在 Frida 脚本最开始就 Hook 反调试函数如ptrace,fork并绕过。心得对抗反调试是一场猫鼠游戏。有时最简单的办法是寻找一个没有加固或反调试较弱的历史版本 App 入手。问题二unidbg 加载 so 时崩溃报错Invalid memory read。可能原因so 依赖的其他库没有正确加载so 的JNI_OnLoad或初始化函数需要特定的环境如某些全局变量已设置。排查使用readelf -d libencrypt.so查看其动态依赖NEEDED确保所有依赖的 so 都已放入 unidbg 的搜索路径并被加载。在 unidbg 中打开详细日志emulator.attach().debug()看崩溃在哪条指令然后对照 IDA Pro 分析该指令在访问什么内存是否未初始化。心得unidbg 调试需要耐心。从崩溃点往前回溯看是哪个函数调用链导致了非法内存访问。经常需要补全缺失的系统调用或外部函数实现。问题三unidbg 模拟出的结果与 Frida 抓到的结果不一致。可能原因输入参数不对算法依赖的随机数、时间戳等动态值在两次运行中不同so 内部有基于运行环境的分支如检测模拟器。排查确保输入字节数组完全一致包括字节顺序。在 unidbg 中 Hookgettimeofday、/dev/urandom等系统调用返回与 Frida 抓包时相同的值。检查 so 中是否有cpuid或检测ro.build属性的代码在 unidbg 中伪造相应的返回值。心得完全一致是最高追求。要像法医一样对比所有细节。保存好 Frida 抓包时的完整上下文时间、输入、输出作为 unidbg 调试的黄金标准。问题四算法过于复杂混淆严重难以静态分析。可能原因so 使用了控制流扁平化、指令虚拟化等高级混淆技术。对策不要强求完全理解每一行汇编。动态分析Frida unidbg的优势在于你可以在关键点如输入输出、密钥扩展处下断点直接观察内存中的数据变化。采用“黑盒”与“灰盒”结合的方式通过多次输入输出对推测算法整体结构是分组加密还是流加密是否有非线性变换然后重点逆向密钥处理部分。对于极度复杂的混淆可以考虑使用动态符号执行如 angr或直接使用 unidbg 作为“计算器”只关心最终结果。个人体会逆向工程没有银弹。Frida 和 unidbg 是两件无比强大的武器但更重要的是分析者的思路和耐心。从高层Java到底层Native从动态运行到静态代码不断假设、验证、修正。每一次成功还原算法不仅是对技术的提升更是对逻辑思维和解决问题能力的极好锻炼。最后记得在法律和道德允许的范围内进行所有分析尊重知识产权。