1. 项目概述当Hook遇上混淆一场逆向工程师的“捉迷藏”在移动安全逆向和动态分析领域Frida 无疑是神器级别的存在。它能让我们像外科手术一样精准地拦截和修改目标应用在运行时的函数调用、参数和返回值。然而现实往往比理想骨感。当你信心满满地写好一个Java.perform脚本准备对某个关键业务逻辑进行Hook时控制台却冷冷地抛出一行Error: java.lang.ClassNotFoundException或者你的Hook点静默无声没有任何日志输出——十有八九你撞上了“代码混淆”这堵墙。这不仅仅是技术问题更像是一场精心设计的“捉迷藏”。开发者为了保护核心逻辑和知识产权会使用ProGuard、R8Android、OLLVMNative等工具对代码进行混淆。原本清晰可读的类名com.example.payment.Processor可能变成a.b.c.a方法名validateTransaction则变成了a()或b(String, int)。你的Hook脚本是基于原始符号写的面对这堆“乱码”自然就失去了目标。所以“Frida 混淆代码 Hook 不到”这个标题精准地戳中了无数逆向分析工程师和移动安全研究员的痛点。它不是一个简单的报错而是一个需要系统性解决方案的挑战。本文将从一个老逆向的角度分享一套从思路到实操用于定位和Hook混淆后类与方法的完整方案。无论你是想分析某个应用的通信协议还是验证其安全机制亦或是进行合法的自动化测试这套方法都能帮你拨开迷雾找到那个被隐藏起来的“关键函数”。2. 核心思路拆解从“盲人摸象”到“按图索骥”面对混淆代码最忌讳的就是毫无头绪地胡乱尝试。我们需要将问题分解建立一套科学的定位流程。核心思路可以概括为放弃对“名字”的依赖转而依靠代码的“结构特征”、“行为特征”和“数据流特征”。2.1 为什么传统的基于名称的Hook会失效这很好理解。Frida 的Java.use(‘com.example.Class’)或Interceptor.attach(Module.findExportByName(null, ‘functionName’))这类API严重依赖于确切的类名、方法名或函数名。混淆工具的工作正是系统性地重命名这些标识符同时可能辅以控制流平坦化、指令替换等手段让代码变得难以阅读但不改变其运行时逻辑理想情况下。因此你的脚本是在用“旧地图”找“新地名”必然失败。2.2 定位混淆目标的四大核心策略我们的策略需要从多个维度进行交叉验证提高定位的准确性和效率。2.2.1 特征匹配法寻找不变的“锚点”混淆会改变名字但不会或很难改变一些固有的特征。这些特征就是我们的“锚点”。类结构特征一个类继承自哪个父类实现了哪些接口类中有哪些成员变量字段即使类名和字段名都变了这些继承关系和字段结构在运行时是稳定的。例如一个负责网络请求的类很可能实现了Runnable或继承自AsyncTask。方法签名特征方法名变了但它的参数类型和返回值类型呢一个进行MD5计算的方法很可能接收一个String或byte[]参数并返回一个String。通过枚举所有方法并过滤参数为(Ljava/lang/String;)Ljava/lang/String;的方法就能大大缩小范围。字符串常量代码中的硬编码字符串如URL、API路径、密钥的提示文本、错误信息通常不会被混淆。在方法体中搜索特定的字符串是定位关键方法的捷径。2.2.2 动态行为追踪法让应用自己“暴露”在目标应用执行特定操作时如点击登录、发起支付动态地观察哪些类和方法被频繁调用或处于调用栈的关键位置。调用栈分析Hook一些Android系统API如android.app.Activity.onCreate,android.view.View.onClick在回调中打印调用栈。那个在用户点击后立即出现在栈顶附近的、名字奇怪的类很可能就是我们的目标。方法执行追踪使用Frida的Stalker或简单的Java.enumerateMethods进行粗粒度的跟踪观察在触发某个功能时哪些方法被首次调用或调用次数异常。2.2.3 数据流分析法追踪数据的“流向”关注我们感兴趣的数据从哪里来到哪里去。例如我们想找到加密函数可以先找到加密后的输出数据比如一个Base64字符串然后逆向追踪生成这个数据的函数。输入输出监控对可能处理目标数据类型的类进行批量Hook打印它们的输入和输出。比如对所有参数包含byte[]的方法进行模糊Hook观察何时输出了我们监控到的密文。对象实例监控找到承载关键数据的对象如一个包含Token的类实例然后回溯创建和修改该实例的所有方法。2.2.4 外部信息辅助法利用“侧信道”信息日志信息应用本身或配套的SDK可能会输出一些日志其中可能包含混淆前的类名或方法名尤其在Debug版本中。配置文件与资源AndroidManifest.xml中的组件声明、资源ID (R.string.xxx) 与代码的关联有时能提供线索。旧版本或未混淆版本如果存在历史版本对比分析是最高效的方法。未混淆的库文件.so或SDK也能提供清晰的符号信息。实操心得在实际操作中几乎没有单一策略能百分百成功。“特征匹配”用于快速筛选候选目标“动态追踪”用于验证目标的行为“数据流分析”用于精准定位逻辑链而“外部信息”则作为重要的线索补充。你需要像侦探一样将这些线索拼凑起来。3. 实操工具箱Frida在定位混淆代码中的高级用法有了思路我们需要强大的工具来实施。Frida本身及其丰富的API就是我们最好的武器。3.1 枚举与搜索大海捞针的“磁铁”首先我们需要遍历目标进程中的类和方法这是所有工作的基础。3.1.1 枚举所有已加载的类Java.perform(function() { // 枚举所有已加载的类 Java.enumerateLoadedClasses({ onMatch: function(className) { // 可以根据包名进行初步过滤例如只关心某个包下的类 if (className.includes(“com.targetapp.”)) { console.log(“[Class Found] “ className); // 进一步分析这个类... } }, onComplete: function() { console.log(“Enumeration complete.”); } }); });3.1.2 枚举类的所有方法一旦找到一个可疑的类就需要深入其内部。Java.perform(function() { var targetClass Java.use(“a.b.c.d”); // 假设这是一个可疑的混淆类名 var methods targetClass.class.getDeclaredMethods(); for (var i 0; i methods.length; i) { var method methods[i]; console.log(“Method: “ method.getName() “, Signature: “ method.toString()); // 打印出的toString通常包含完整的签名如public java.lang.String a.b.c.d.a(java.lang.String,int) } });这里有个关键点getDeclaredMethods()返回的是java.lang.reflect.Method对象数组调用其toString()方法可以得到包含参数和返回值类型的完整签名这比单纯的方法名有用得多。3.1.3 基于特征的暴力搜索结合枚举和特征匹配我们可以写一个“搜索脚本”。Java.perform(function() { Java.enumerateLoadedClasses({ onMatch: function(className) { try { var clazz Java.use(className); // 策略1检查父类或接口 if (clazz.class.getSuperclass() clazz.class.getSuperclass().getName().contains(“SomeBaseClass”)) { console.log(“[Potential Target by Inheritance] “ className); } // 策略2检查类中的方法签名 var methods clazz.class.getDeclaredMethods(); for (var i in methods) { var method methods[i]; var methodStr method.toString(); // 搜索返回值类型为String参数为(String, int)的方法 if (methodStr.includes(“java.lang.String”) methodStr.includes(“java.lang.String,int”)) { console.log(“[Potential Target by Method Signature] Class: “ className “, Method: “ methodStr); } // 搜索方法体内可能包含的特定字符串需要Hook方法并检查更动态 } } catch (e) { // 忽略无法使用的类如系统类 } }, onComplete: function() { console.log(“Search complete.”); } }); });3.2 动态Hook与参数打印设置“监控探头”当我们筛选出几个候选方法后下一步就是动态Hook它们观察其输入输出这是验证其功能的关键。3.2.1 对单个可疑方法进行HookJava.perform(function() { var suspectedClass Java.use(“a.b.c.d”); var suspectedMethod suspectedClass.a.overload(‘java.lang.String’, ‘int’); // 假设方法’a’有两个参数 String和int suspectedMethod.implementation function(arg1, arg2) { console.log(“\n[“ this.$className “.a] called!”); console.log(“Arg1 (String): “ arg1); console.log(“Arg2 (int): “ arg2); var retVal this.a(arg1, arg2); // 调用原方法 console.log(“Return Value: “ retVal); // 可以在这里修改返回值 // retVal “Hooked!”; return retVal; }; console.log(“Hook placed on a.b.c.d.a(String, int)”); });3.2.2 批量Hook与模糊匹配对于大量候选方法手动写Hook太低效。我们可以编写一个“模糊Hook”脚本。Java.perform(function() { var targetPackage “a.b”; // 目标包名前缀 Java.enumerateLoadedClasses({ onMatch: function(className) { if (!className.startsWith(targetPackage)) return; try { var clazz Java.use(className); var methods clazz.class.getDeclaredMethods(); for (var i in methods) { var method methods[i]; var methodName method.getName(); var methodSig method.toString(); // 定义你的Hook条件例如Hook所有返回String的方法 if (methodSig.includes(“)Ljava/lang/String;”)) { // JNI签名表示返回String console.log(“[Attempting Hook] “ className “.” methodName); try { // 这是一个复杂点需要根据方法签名动态获取overload // 简化示例假设方法没有重载 clazz[methodName].implementation function() { var args Array.prototype.slice.call(arguments); console.log([${className}.${methodName}] Args:, args); var result this[methodName].apply(this, arguments); console.log([${className}.${methodName}] Return:, result); return result; }; } catch (hookError) { // 可能因为重载、静态方法等原因失败跳过即可 // console.warn(“Hook failed for “ methodName “: “ hookError); } } } } catch (e) { // 忽略异常 } }, onComplete: function() { console.log(“Bulk hook attempt finished.”); } }); });注意事项批量Hook非常强大但也非常危险。它可能Hook到系统关键方法或高频方法导致应用崩溃或性能急剧下降。务必在模拟器或备用测试机上操作并先从小范围包名开始测试。3.3 调用栈与调用追踪绘制“函数地图”知道一个方法被调用时的“上下文”至关重要。3.3.1 获取并打印调用栈在Hook的函数里可以方便地获取调用栈。suspectedMethod.implementation function(arg1, arg2) { console.log(“\n[“ this.$className “.a] called!”); // 打印Java调用栈 var stackTrace Java.use(“android.util.Log”).getStackTraceString(Java.use(“java.lang.Exception”).$new()); console.log(“Call Stack:\n“ stackTrace); // 过滤栈信息只显示应用自身的调用 var stackLines stackTrace.split(‘\n’); for (var i 0; i stackLines.length; i) { if (stackLines[i].includes(“a.b”) || stackLines[i].includes(“com.target”)) { // 你的目标包名 console.log(“Relevant Stack: “ stackLines[i]); } } return this.a(arg1, arg2); };3.3.2 使用Frida Stalker进行指令级追踪针对Native层如果关键逻辑在Native层如.so库且被OLLVM混淆就需要更底层的工具。Frida的Stalker可以追踪线程的指令执行流。Interceptor.attach(Module.findExportByName(“libtarget.so”, “JNI_OnLoad”), { onEnter: function(args) { console.log(“[] libtarget.so JNI_OnLoad called. Starting Stalker...”); // 在当前线程开始追踪 Stalker.follow({ events: { // 收集调用call和返回ret事件 call: true, ret: true, }, onReceive: function(events) { // 解析并打印事件 var parsed Stalker.parse(events, { stringify: false, // 不转为字符串性能更好 }); // 这里可以过滤和输出你关心的地址/符号 console.log(parsed.map(line line[1]).join(‘\n’)); } }); }, onLeave: function(retval) { Stalker.unfollow(); console.log(“[-] Stalker stopped.”); } });Stalker会产生海量数据必须结合过滤策略比如只追踪特定模块或函数调用附近的指令。4. 实战案例定位一个混淆后的登录密码加密方法假设我们要分析某App的登录流程其密码在发送前被加密但相关代码已被混淆。4.1 第一步动态捕捉加密前后的数据首先我们需要知道加密后的密文长什么样。我们可以用Frida Hook网络请求库如OkHttp的Call.execute()或RequestBody.writeTo抓取发送出去的数据包。假设我们抓取到POST数据中有一个字段encryptedPassword”a1B2c3D4e5F6g7H8...”看起来像是Base64编码的二进制数据。4.2 第二步逆向寻找加密函数现在我们知道输出是byte[]或String。我们的策略是Hook Java的Base64编码方法因为密文可能是Base64先找到Base64编码的地方其输入就是加密后的字节数组。var Base64Class Java.use(“android.util.Base64”); var encodeToString Base64Class.encodeToString.overload(‘[B’, ‘int’); encodeToString.implementation function(bytes, flags) { var stack Java.use(“android.util.Log”).getStackTraceString(Java.use(“java.lang.Exception”).$new()); // 检查调用栈里是否有我们的目标包名 if (stack.includes(“a.b.c”)) { console.log(“\n[Base64.encodeToString] called from target app!”); console.log(“Input bytes (hex): “ Array.from(bytes).map(b (‘0’ (b 0xFF).toString(16)).slice(-2)).join(‘ ‘)); console.log(“Partial Stack:\n“ stack.split(‘\n’).slice(0, 8).join(‘\n’)); // 只看前几行 } return this.encodeToString(bytes, flags); };运行脚本并触发登录我们可能在日志中看到Base64被一个a.b.c.d.e()方法调用并且输入的字节数组看起来是规律性的可能是AES/3DES加密后的结果。定位加密函数现在我们知道a.b.c.d.e()方法输出了加密字节数组。我们去Hook这个方法。首先需要确定它的完整签名。通过之前枚举的方法我们可能发现类a.b.c.d中有一个方法签名是public byte[] e(byte[])。这非常可疑var CryptoClass Java.use(“a.b.c.d”); CryptoClass.e.overload(‘[B’).implementation function(inputBytes) { console.log(“\n[“ this.$className “.e] ENCRYPTION SUSPECTED!”); console.log(“Input (likely password bytes): “ Array.from(inputBytes).map(b (‘0’ (b 0xFF).toString(16)).slice(-2)).join(‘ ‘)); console.log(“Input as String: “ Java.use(“java.lang.String”).$new(inputBytes)); var result this.e(inputBytes); console.log(“Output (encrypted bytes): “ Array.from(result).map(b (‘0’ (b 0xFF).toString(16)).slice(-2)).join(‘ ‘)); return result; };触发登录如果这个方法的输入是明文密码的字节输出与之前Base64编码前的字节一致那么恭喜a.b.c.d.e()就是我们要找的加密函数4.3 第三步进一步分析找到函数后我们可以分析其内部调用在Hook中打印更详细的调用栈看它是否调用了javax.crypto.Cipher.getInstance(“AES/ECB/PKCS5Padding”)等标准API从而确定算法。定位密钥密钥可能来自另一个混淆方法、一个静态字段、或者一个资源文件。可以HookCipher.init()方法或者直接Dumpa.b.c.d类的所有静态字段值来寻找。5. 常见问题与高级排查技巧在实际操作中你会遇到各种“坑”。这里记录一些典型问题和解决思路。5.1 Hook失败ClassNotFoundException 或 Method not found原因1类尚未加载。Android的类加载是懒加载的。你的脚本执行时目标类可能还没被ClassLoader加载。解决使用Java.choose(className, callbacks)在堆上枚举已存在的实例或者将Hook代码包裹在setImmediate或监听特定事件如Activity创建后再执行。原因2混淆导致的方法重载冲突。混淆可能产生多个同名方法a()仅参数不同。overload()指定不正确。解决使用类名[‘方法名’].overloads数组来查看所有重载然后根据参数类型签名选择合适的索引进行Hook。var allOverloads targetClass.a.overloads; console.log(“Number of overloads: “ allOverloads.length); allOverloads.forEach(function(overload, index) { console.log(“Overload “ index “: “ overload.argumentTypes.map(t t.className).join(‘, ‘)); }); // 然后选择正确的overload进行Hook allOverloads[0].implementation function(...){...};5.2 应用检测到Frida并崩溃这是一个猫鼠游戏。应用可能通过检测端口、进程名、文件、内存特征等方式发现Frida。常见绕过思路修改Frida-server名称和端口使用-l 0.0.0.0:8080指定非默认端口27042并重命名frida-server文件。使用定制编译的Frida有些项目提供了去除明显特征的Frida-server二进制文件。Patch应用的反调试逻辑如果应用在Native层检测ptrace或TracerPid可以用Frida提前Hook这些检测函数使其返回假值。使用非标准注入方式如frida-gadget嵌入到App中而非动态注入。5.3 性能问题与稳定性批量Hook导致卡顿或崩溃这是最常见的问题。务必精确过滤不要Hook系统类如java.、android.开头的和高频方法如View.onDraw。优先使用特征匹配缩小范围再进行Hook。Stalker产生数据洪流一定要设置过滤条件比如只追踪特定模块的代码段Stalker.follow(pid, { events: { call: true }, range: { base: module.base, size: module.size } })或者只在关键函数入口触发Stalker。5.4 对抗高级混淆OLLVM控制流平坦化对于Native层的OLLVM混淆静态分析几乎失效。动态分析是唯一出路。关键点识别并Hook那些未被混淆或难以混淆的边界函数。例如JNI函数Java_com_example_xxx、系统库函数libc的strlen、memcpy、或自定义的加密函数入口通过字符串或常量搜索找到。使用Frida的指令跟踪在边界函数处开启Stalker记录下输入参数和最终返回值。通过多次执行归纳出输入与输出的关系而不必理解中间混乱的控制流。符号执行与模拟对于极度复杂的逻辑可以结合使用Frida和Unicorn等CPU模拟引擎尝试进行符号化执行但这属于高阶技巧。5.5 工具链辅助不要只依赖Frida。结合其他工具能事半功倍。Objection基于Frida的命令行工具可以快速执行如android hooking list classes、android hooking search methods等命令进行初步侦察。Jadx/Ghidra/IDA Pro静态反编译工具。即使代码混淆字符串、资源引用、导入函数表、简单的控制流仍然是可见的。用它们来辅助理解程序结构定位可能的切入点。日志分析使用logcat或Hookandroid.util.Log来捕获应用内部的调试信息有时会有意外收获。定位混淆后的代码是一个耐心、细致且需要创造力的过程。它没有银弹核心在于对目标应用行为的深刻理解以及对Frida等动态分析工具的灵活运用。从模糊的特征出发通过动态的观察和验证一步步收紧包围圈最终锁定目标。每一次成功的Hook都是对逆向思维的一次胜利。
1. 项目概述当Hook遇上混淆一场逆向工程师的“捉迷藏”在移动安全逆向和动态分析领域Frida 无疑是神器级别的存在。它能让我们像外科手术一样精准地拦截和修改目标应用在运行时的函数调用、参数和返回值。然而现实往往比理想骨感。当你信心满满地写好一个Java.perform脚本准备对某个关键业务逻辑进行Hook时控制台却冷冷地抛出一行Error: java.lang.ClassNotFoundException或者你的Hook点静默无声没有任何日志输出——十有八九你撞上了“代码混淆”这堵墙。这不仅仅是技术问题更像是一场精心设计的“捉迷藏”。开发者为了保护核心逻辑和知识产权会使用ProGuard、R8Android、OLLVMNative等工具对代码进行混淆。原本清晰可读的类名com.example.payment.Processor可能变成a.b.c.a方法名validateTransaction则变成了a()或b(String, int)。你的Hook脚本是基于原始符号写的面对这堆“乱码”自然就失去了目标。所以“Frida 混淆代码 Hook 不到”这个标题精准地戳中了无数逆向分析工程师和移动安全研究员的痛点。它不是一个简单的报错而是一个需要系统性解决方案的挑战。本文将从一个老逆向的角度分享一套从思路到实操用于定位和Hook混淆后类与方法的完整方案。无论你是想分析某个应用的通信协议还是验证其安全机制亦或是进行合法的自动化测试这套方法都能帮你拨开迷雾找到那个被隐藏起来的“关键函数”。2. 核心思路拆解从“盲人摸象”到“按图索骥”面对混淆代码最忌讳的就是毫无头绪地胡乱尝试。我们需要将问题分解建立一套科学的定位流程。核心思路可以概括为放弃对“名字”的依赖转而依靠代码的“结构特征”、“行为特征”和“数据流特征”。2.1 为什么传统的基于名称的Hook会失效这很好理解。Frida 的Java.use(‘com.example.Class’)或Interceptor.attach(Module.findExportByName(null, ‘functionName’))这类API严重依赖于确切的类名、方法名或函数名。混淆工具的工作正是系统性地重命名这些标识符同时可能辅以控制流平坦化、指令替换等手段让代码变得难以阅读但不改变其运行时逻辑理想情况下。因此你的脚本是在用“旧地图”找“新地名”必然失败。2.2 定位混淆目标的四大核心策略我们的策略需要从多个维度进行交叉验证提高定位的准确性和效率。2.2.1 特征匹配法寻找不变的“锚点”混淆会改变名字但不会或很难改变一些固有的特征。这些特征就是我们的“锚点”。类结构特征一个类继承自哪个父类实现了哪些接口类中有哪些成员变量字段即使类名和字段名都变了这些继承关系和字段结构在运行时是稳定的。例如一个负责网络请求的类很可能实现了Runnable或继承自AsyncTask。方法签名特征方法名变了但它的参数类型和返回值类型呢一个进行MD5计算的方法很可能接收一个String或byte[]参数并返回一个String。通过枚举所有方法并过滤参数为(Ljava/lang/String;)Ljava/lang/String;的方法就能大大缩小范围。字符串常量代码中的硬编码字符串如URL、API路径、密钥的提示文本、错误信息通常不会被混淆。在方法体中搜索特定的字符串是定位关键方法的捷径。2.2.2 动态行为追踪法让应用自己“暴露”在目标应用执行特定操作时如点击登录、发起支付动态地观察哪些类和方法被频繁调用或处于调用栈的关键位置。调用栈分析Hook一些Android系统API如android.app.Activity.onCreate,android.view.View.onClick在回调中打印调用栈。那个在用户点击后立即出现在栈顶附近的、名字奇怪的类很可能就是我们的目标。方法执行追踪使用Frida的Stalker或简单的Java.enumerateMethods进行粗粒度的跟踪观察在触发某个功能时哪些方法被首次调用或调用次数异常。2.2.3 数据流分析法追踪数据的“流向”关注我们感兴趣的数据从哪里来到哪里去。例如我们想找到加密函数可以先找到加密后的输出数据比如一个Base64字符串然后逆向追踪生成这个数据的函数。输入输出监控对可能处理目标数据类型的类进行批量Hook打印它们的输入和输出。比如对所有参数包含byte[]的方法进行模糊Hook观察何时输出了我们监控到的密文。对象实例监控找到承载关键数据的对象如一个包含Token的类实例然后回溯创建和修改该实例的所有方法。2.2.4 外部信息辅助法利用“侧信道”信息日志信息应用本身或配套的SDK可能会输出一些日志其中可能包含混淆前的类名或方法名尤其在Debug版本中。配置文件与资源AndroidManifest.xml中的组件声明、资源ID (R.string.xxx) 与代码的关联有时能提供线索。旧版本或未混淆版本如果存在历史版本对比分析是最高效的方法。未混淆的库文件.so或SDK也能提供清晰的符号信息。实操心得在实际操作中几乎没有单一策略能百分百成功。“特征匹配”用于快速筛选候选目标“动态追踪”用于验证目标的行为“数据流分析”用于精准定位逻辑链而“外部信息”则作为重要的线索补充。你需要像侦探一样将这些线索拼凑起来。3. 实操工具箱Frida在定位混淆代码中的高级用法有了思路我们需要强大的工具来实施。Frida本身及其丰富的API就是我们最好的武器。3.1 枚举与搜索大海捞针的“磁铁”首先我们需要遍历目标进程中的类和方法这是所有工作的基础。3.1.1 枚举所有已加载的类Java.perform(function() { // 枚举所有已加载的类 Java.enumerateLoadedClasses({ onMatch: function(className) { // 可以根据包名进行初步过滤例如只关心某个包下的类 if (className.includes(“com.targetapp.”)) { console.log(“[Class Found] “ className); // 进一步分析这个类... } }, onComplete: function() { console.log(“Enumeration complete.”); } }); });3.1.2 枚举类的所有方法一旦找到一个可疑的类就需要深入其内部。Java.perform(function() { var targetClass Java.use(“a.b.c.d”); // 假设这是一个可疑的混淆类名 var methods targetClass.class.getDeclaredMethods(); for (var i 0; i methods.length; i) { var method methods[i]; console.log(“Method: “ method.getName() “, Signature: “ method.toString()); // 打印出的toString通常包含完整的签名如public java.lang.String a.b.c.d.a(java.lang.String,int) } });这里有个关键点getDeclaredMethods()返回的是java.lang.reflect.Method对象数组调用其toString()方法可以得到包含参数和返回值类型的完整签名这比单纯的方法名有用得多。3.1.3 基于特征的暴力搜索结合枚举和特征匹配我们可以写一个“搜索脚本”。Java.perform(function() { Java.enumerateLoadedClasses({ onMatch: function(className) { try { var clazz Java.use(className); // 策略1检查父类或接口 if (clazz.class.getSuperclass() clazz.class.getSuperclass().getName().contains(“SomeBaseClass”)) { console.log(“[Potential Target by Inheritance] “ className); } // 策略2检查类中的方法签名 var methods clazz.class.getDeclaredMethods(); for (var i in methods) { var method methods[i]; var methodStr method.toString(); // 搜索返回值类型为String参数为(String, int)的方法 if (methodStr.includes(“java.lang.String”) methodStr.includes(“java.lang.String,int”)) { console.log(“[Potential Target by Method Signature] Class: “ className “, Method: “ methodStr); } // 搜索方法体内可能包含的特定字符串需要Hook方法并检查更动态 } } catch (e) { // 忽略无法使用的类如系统类 } }, onComplete: function() { console.log(“Search complete.”); } }); });3.2 动态Hook与参数打印设置“监控探头”当我们筛选出几个候选方法后下一步就是动态Hook它们观察其输入输出这是验证其功能的关键。3.2.1 对单个可疑方法进行HookJava.perform(function() { var suspectedClass Java.use(“a.b.c.d”); var suspectedMethod suspectedClass.a.overload(‘java.lang.String’, ‘int’); // 假设方法’a’有两个参数 String和int suspectedMethod.implementation function(arg1, arg2) { console.log(“\n[“ this.$className “.a] called!”); console.log(“Arg1 (String): “ arg1); console.log(“Arg2 (int): “ arg2); var retVal this.a(arg1, arg2); // 调用原方法 console.log(“Return Value: “ retVal); // 可以在这里修改返回值 // retVal “Hooked!”; return retVal; }; console.log(“Hook placed on a.b.c.d.a(String, int)”); });3.2.2 批量Hook与模糊匹配对于大量候选方法手动写Hook太低效。我们可以编写一个“模糊Hook”脚本。Java.perform(function() { var targetPackage “a.b”; // 目标包名前缀 Java.enumerateLoadedClasses({ onMatch: function(className) { if (!className.startsWith(targetPackage)) return; try { var clazz Java.use(className); var methods clazz.class.getDeclaredMethods(); for (var i in methods) { var method methods[i]; var methodName method.getName(); var methodSig method.toString(); // 定义你的Hook条件例如Hook所有返回String的方法 if (methodSig.includes(“)Ljava/lang/String;”)) { // JNI签名表示返回String console.log(“[Attempting Hook] “ className “.” methodName); try { // 这是一个复杂点需要根据方法签名动态获取overload // 简化示例假设方法没有重载 clazz[methodName].implementation function() { var args Array.prototype.slice.call(arguments); console.log([${className}.${methodName}] Args:, args); var result this[methodName].apply(this, arguments); console.log([${className}.${methodName}] Return:, result); return result; }; } catch (hookError) { // 可能因为重载、静态方法等原因失败跳过即可 // console.warn(“Hook failed for “ methodName “: “ hookError); } } } } catch (e) { // 忽略异常 } }, onComplete: function() { console.log(“Bulk hook attempt finished.”); } }); });注意事项批量Hook非常强大但也非常危险。它可能Hook到系统关键方法或高频方法导致应用崩溃或性能急剧下降。务必在模拟器或备用测试机上操作并先从小范围包名开始测试。3.3 调用栈与调用追踪绘制“函数地图”知道一个方法被调用时的“上下文”至关重要。3.3.1 获取并打印调用栈在Hook的函数里可以方便地获取调用栈。suspectedMethod.implementation function(arg1, arg2) { console.log(“\n[“ this.$className “.a] called!”); // 打印Java调用栈 var stackTrace Java.use(“android.util.Log”).getStackTraceString(Java.use(“java.lang.Exception”).$new()); console.log(“Call Stack:\n“ stackTrace); // 过滤栈信息只显示应用自身的调用 var stackLines stackTrace.split(‘\n’); for (var i 0; i stackLines.length; i) { if (stackLines[i].includes(“a.b”) || stackLines[i].includes(“com.target”)) { // 你的目标包名 console.log(“Relevant Stack: “ stackLines[i]); } } return this.a(arg1, arg2); };3.3.2 使用Frida Stalker进行指令级追踪针对Native层如果关键逻辑在Native层如.so库且被OLLVM混淆就需要更底层的工具。Frida的Stalker可以追踪线程的指令执行流。Interceptor.attach(Module.findExportByName(“libtarget.so”, “JNI_OnLoad”), { onEnter: function(args) { console.log(“[] libtarget.so JNI_OnLoad called. Starting Stalker...”); // 在当前线程开始追踪 Stalker.follow({ events: { // 收集调用call和返回ret事件 call: true, ret: true, }, onReceive: function(events) { // 解析并打印事件 var parsed Stalker.parse(events, { stringify: false, // 不转为字符串性能更好 }); // 这里可以过滤和输出你关心的地址/符号 console.log(parsed.map(line line[1]).join(‘\n’)); } }); }, onLeave: function(retval) { Stalker.unfollow(); console.log(“[-] Stalker stopped.”); } });Stalker会产生海量数据必须结合过滤策略比如只追踪特定模块或函数调用附近的指令。4. 实战案例定位一个混淆后的登录密码加密方法假设我们要分析某App的登录流程其密码在发送前被加密但相关代码已被混淆。4.1 第一步动态捕捉加密前后的数据首先我们需要知道加密后的密文长什么样。我们可以用Frida Hook网络请求库如OkHttp的Call.execute()或RequestBody.writeTo抓取发送出去的数据包。假设我们抓取到POST数据中有一个字段encryptedPassword”a1B2c3D4e5F6g7H8...”看起来像是Base64编码的二进制数据。4.2 第二步逆向寻找加密函数现在我们知道输出是byte[]或String。我们的策略是Hook Java的Base64编码方法因为密文可能是Base64先找到Base64编码的地方其输入就是加密后的字节数组。var Base64Class Java.use(“android.util.Base64”); var encodeToString Base64Class.encodeToString.overload(‘[B’, ‘int’); encodeToString.implementation function(bytes, flags) { var stack Java.use(“android.util.Log”).getStackTraceString(Java.use(“java.lang.Exception”).$new()); // 检查调用栈里是否有我们的目标包名 if (stack.includes(“a.b.c”)) { console.log(“\n[Base64.encodeToString] called from target app!”); console.log(“Input bytes (hex): “ Array.from(bytes).map(b (‘0’ (b 0xFF).toString(16)).slice(-2)).join(‘ ‘)); console.log(“Partial Stack:\n“ stack.split(‘\n’).slice(0, 8).join(‘\n’)); // 只看前几行 } return this.encodeToString(bytes, flags); };运行脚本并触发登录我们可能在日志中看到Base64被一个a.b.c.d.e()方法调用并且输入的字节数组看起来是规律性的可能是AES/3DES加密后的结果。定位加密函数现在我们知道a.b.c.d.e()方法输出了加密字节数组。我们去Hook这个方法。首先需要确定它的完整签名。通过之前枚举的方法我们可能发现类a.b.c.d中有一个方法签名是public byte[] e(byte[])。这非常可疑var CryptoClass Java.use(“a.b.c.d”); CryptoClass.e.overload(‘[B’).implementation function(inputBytes) { console.log(“\n[“ this.$className “.e] ENCRYPTION SUSPECTED!”); console.log(“Input (likely password bytes): “ Array.from(inputBytes).map(b (‘0’ (b 0xFF).toString(16)).slice(-2)).join(‘ ‘)); console.log(“Input as String: “ Java.use(“java.lang.String”).$new(inputBytes)); var result this.e(inputBytes); console.log(“Output (encrypted bytes): “ Array.from(result).map(b (‘0’ (b 0xFF).toString(16)).slice(-2)).join(‘ ‘)); return result; };触发登录如果这个方法的输入是明文密码的字节输出与之前Base64编码前的字节一致那么恭喜a.b.c.d.e()就是我们要找的加密函数4.3 第三步进一步分析找到函数后我们可以分析其内部调用在Hook中打印更详细的调用栈看它是否调用了javax.crypto.Cipher.getInstance(“AES/ECB/PKCS5Padding”)等标准API从而确定算法。定位密钥密钥可能来自另一个混淆方法、一个静态字段、或者一个资源文件。可以HookCipher.init()方法或者直接Dumpa.b.c.d类的所有静态字段值来寻找。5. 常见问题与高级排查技巧在实际操作中你会遇到各种“坑”。这里记录一些典型问题和解决思路。5.1 Hook失败ClassNotFoundException 或 Method not found原因1类尚未加载。Android的类加载是懒加载的。你的脚本执行时目标类可能还没被ClassLoader加载。解决使用Java.choose(className, callbacks)在堆上枚举已存在的实例或者将Hook代码包裹在setImmediate或监听特定事件如Activity创建后再执行。原因2混淆导致的方法重载冲突。混淆可能产生多个同名方法a()仅参数不同。overload()指定不正确。解决使用类名[‘方法名’].overloads数组来查看所有重载然后根据参数类型签名选择合适的索引进行Hook。var allOverloads targetClass.a.overloads; console.log(“Number of overloads: “ allOverloads.length); allOverloads.forEach(function(overload, index) { console.log(“Overload “ index “: “ overload.argumentTypes.map(t t.className).join(‘, ‘)); }); // 然后选择正确的overload进行Hook allOverloads[0].implementation function(...){...};5.2 应用检测到Frida并崩溃这是一个猫鼠游戏。应用可能通过检测端口、进程名、文件、内存特征等方式发现Frida。常见绕过思路修改Frida-server名称和端口使用-l 0.0.0.0:8080指定非默认端口27042并重命名frida-server文件。使用定制编译的Frida有些项目提供了去除明显特征的Frida-server二进制文件。Patch应用的反调试逻辑如果应用在Native层检测ptrace或TracerPid可以用Frida提前Hook这些检测函数使其返回假值。使用非标准注入方式如frida-gadget嵌入到App中而非动态注入。5.3 性能问题与稳定性批量Hook导致卡顿或崩溃这是最常见的问题。务必精确过滤不要Hook系统类如java.、android.开头的和高频方法如View.onDraw。优先使用特征匹配缩小范围再进行Hook。Stalker产生数据洪流一定要设置过滤条件比如只追踪特定模块的代码段Stalker.follow(pid, { events: { call: true }, range: { base: module.base, size: module.size } })或者只在关键函数入口触发Stalker。5.4 对抗高级混淆OLLVM控制流平坦化对于Native层的OLLVM混淆静态分析几乎失效。动态分析是唯一出路。关键点识别并Hook那些未被混淆或难以混淆的边界函数。例如JNI函数Java_com_example_xxx、系统库函数libc的strlen、memcpy、或自定义的加密函数入口通过字符串或常量搜索找到。使用Frida的指令跟踪在边界函数处开启Stalker记录下输入参数和最终返回值。通过多次执行归纳出输入与输出的关系而不必理解中间混乱的控制流。符号执行与模拟对于极度复杂的逻辑可以结合使用Frida和Unicorn等CPU模拟引擎尝试进行符号化执行但这属于高阶技巧。5.5 工具链辅助不要只依赖Frida。结合其他工具能事半功倍。Objection基于Frida的命令行工具可以快速执行如android hooking list classes、android hooking search methods等命令进行初步侦察。Jadx/Ghidra/IDA Pro静态反编译工具。即使代码混淆字符串、资源引用、导入函数表、简单的控制流仍然是可见的。用它们来辅助理解程序结构定位可能的切入点。日志分析使用logcat或Hookandroid.util.Log来捕获应用内部的调试信息有时会有意外收获。定位混淆后的代码是一个耐心、细致且需要创造力的过程。它没有银弹核心在于对目标应用行为的深刻理解以及对Frida等动态分析工具的灵活运用。从模糊的特征出发通过动态的观察和验证一步步收紧包围圈最终锁定目标。每一次成功的Hook都是对逆向思维的一次胜利。
