Unity Mono游戏逆向实战：Frida Hook绕过碰撞死亡判定

1. 项目概述：一次从零开始的Unity Mono游戏逆向实战

最近在折腾一款老游戏，叫《极限摩托》（Trial X），是个典型的手机重力感应控制摩托车的游戏。玩过的朋友都知道，这游戏难度不低，摩托车稍微一歪，碰到障碍物就判定失败，游戏结束。作为一个喜欢“动手”的逆向爱好者，我就在想，能不能在不修改游戏安装包（APK）的情况下，让角色“金刚不坏”，怎么撞都不死呢？这个想法听起来有点“作弊”的嫌疑，但从技术角度看，这是一个非常经典的Unity Mono架构安卓游戏逆向分析课题。它涉及到如何定位游戏逻辑、理解Unity引擎的执行流程，并最终通过运行时Hook技术精准干预游戏判定。整个过程就像一次外科手术，需要精准地找到“病灶”（死亡判定函数）并“下刀”（拦截调用），而工具就是Frida。这篇文章，我就来完整复盘这次逆向实战，从拿到APK开始，到最终成功绕过碰撞死亡判定的全过程。无论你是对安卓逆向、Unity游戏安全，还是Frida动态插桩技术感兴趣，相信都能从中获得一条清晰的、可复现的技术路径。

2. 逆向环境与工具链准备

工欲善其事，必先利其器。在开始逆向之前，搭建一个稳定、高效的工作环境至关重要。这次实战主要涉及安卓逆向和动态分析，因此我们的工具链也围绕这两个核心展开。

2.1 核心工具选型与配置

首先，我们需要一台Root过的安卓真机。为什么强调真机？因为在后续的实践中我发现，像雷电、夜神这类安卓模拟器，虽然方便，但在处理某些原生库（Native Library）的加载和Frida Hook时可能会遇到兼容性问题。例如，模拟器可能对ARM架构的so库进行了一层转译或非标准加载，导致Frida无法像在真机上那样直接通过模块名（如libmono.so）找到并附加。为了避免不必要的麻烦，一部已经获取Root权限的安卓手机是最佳选择。我使用的是一台闲置的旧款高通芯片手机，刷入了Magisk来获取Root权限。

接下来是核心三件套：Frida、ADB和Apktool。

• Frida：这是我们本次的“手术刀”。它是一个强大的动态代码插桩框架，允许我们向目标进程注入JavaScript或Python脚本来拦截函数调用、修改内存数据等。我们需要在电脑（客户端）和手机（服务端）分别安装。
  • 电脑端：通过Python的pip安装即可：pip install frida-tools。安装后，可以使用frida --version检查是否成功。
  • 手机端：需要根据手机的CPU架构下载对应的frida-server。通过adb shell getprop ro.product.cpu.abi命令可以查看架构，常见的是arm64-v8a。将下载的frida-server-xx.x.x-android-arm64推送到手机并赋予执行权限。
• ADB (Android Debug Bridge)：这是与手机通信的桥梁。用于安装APK、推送文件、获取进程列表、开启端口转发等。它是Android SDK Platform-Tools的一部分，需要单独下载并配置到系统环境变量中。
• Apktool：一个用于反编译和回编译APK文件的工具。虽然我们最终的目标是不修改APK，但在分析阶段，我们需要用它来拆解APK，查看其内部结构，特别是判断游戏使用的是Mono还是IL2CPP脚本后端。这对于后续的Hook策略有决定性影响。

注意：Frida客户端与服务端的版本需要尽量匹配，否则可能出现连接失败或协议不兼容的问题。一个简单的原则是，安装frida-tools时，它会自动拉取匹配的Frida核心库。你只需确保手机上的frida-server主版本号（如17.x）与电脑端的Frida主版本号一致即可。

2.2 目标APK的初步侦查

拿到游戏APK后，第一步不是直接运行，而是先“拆开”看看。使用Apktool进行反编译：

apktool d trial_x_game.apk -o output_dir

反编译完成后，我们重点观察几个目录：

1. lib/目录：这里存放着游戏使用的原生共享库（.so文件）。我们特别关注arm64-v8a（64位ARM）或armeabi-v7a（32位ARM）子目录。在这里，我发现了两个关键文件：libmono.so和libunity.so。libmono.so的存在是一个强烈信号，它表明这款Unity游戏很可能使用的是Mono脚本后端，而不是IL2CPP。IL2CPP后端通常会生成libil2cpp.so。
2. assets/bin/Data/Managed/目录：这是Unity Mono游戏的“心脏”。里面包含了编译后的C#程序集，主要是Assembly-CSharp.dll（开发者编写的游戏逻辑）和UnityEngine.dll（Unity引擎核心库）。如果能顺利看到这些DLL文件，就几乎可以100%确认是Mono架构。对于IL2CPP，这个目录下通常是空的或者只有一些元数据文件，真正的代码被编译进了libil2cpp.so。

通过这步侦查，我们确定了目标：一个使用Unity Mono架构的安卓游戏。这意味着游戏的所有C#逻辑（包括我们关心的碰撞检测和死亡判定）最终都会通过Mono运行时（libmono.so）来解释或编译执行。这为我们后续的Hook点选择提供了明确方向——我们不需要去分析复杂的IL2CPP元数据，而是可以直接瞄准Mono运行时的核心函数。

3. Unity Mono架构与Hook策略深度解析

在动手写Hook脚本之前，我们必须先理解Unity Mono游戏在安卓上是如何运行的。知其然，更要知其所以然，这样才能在茫茫函数海中找到那个关键的“开关”。

3.1 Unity Mono执行流水线

一个典型的Unity Mono游戏，其代码执行可以简化为以下流水线：

Unity 物理引擎/碰撞检测 → C# 脚本函数（如 OnCollisionEnter） → .NET IL 字节码 → Mono 运行时解释/编译（mono_runtime_invoke） → 原生机器码执行

关键在于mono_runtime_invoke这个函数。它是Mono运行时中用于调用托管（C#）方法的核心入口。无论游戏里定义了多么复杂的类和方法，当它们需要被引擎调用时（比如每帧更新的Update，发生碰撞时的OnCollisionEnter），最终都会汇聚到mono_runtime_invoke这里，由它将IL字节码转换为原生代码并执行。

这就给我们提供了一个绝佳的统一拦截点。与其去海量的C# DLL中寻找具体的死亡判定方法（可能名字经过混淆），不如直接Hook这个底层的、必经的调用枢纽。只要我们能在这个枢纽里识别出我们不想执行的那个方法（比如Bone.OnCollisionEnter），然后让它“失效”，就能达到我们的目的。

3.2 为什么选择Hook mono_runtime_invoke？

这个策略有几个显著优势：

1. 通用性强：只要游戏是Mono架构，此方法基本都适用。无需针对每个游戏做大量静态分析。
2. 精准拦截：我们可以在Native层精确过滤方法名和类名，避免误伤其他正常游戏逻辑。
3. 无需修改APK：所有操作在内存中进行，属于运行时修改。游戏本体文件没有任何变化，避免了重打包可能带来的签名校验、资源损坏等问题。
4. 动态灵活：通过Frida脚本，我们可以随时开启、关闭或修改Hook逻辑，实现动态调试和测试。

当然，这个方法的前提是你能准确识别出哪个C#方法是负责死亡判定的。这需要结合静态分析和动态日志来定位。

4. 实战：定位与拦截死亡判定函数

理论清晰后，我们进入实战环节。目标是找到那个让游戏角色“死亡”的函数，并阻止它执行。

4.1 启动Frida与附加进程

首先，确保手机上的frida-server已经运行：

adb shell su cd /data/local/tmp chmod +x frida-server-17.5.1-android-arm64 ./frida-server-17.5.1-android-arm64 &

然后在电脑上，我们需要获取目标游戏的进程ID（PID）。可以先启动游戏，然后使用命令：

adb shell ps -A | grep <游戏包名> # 例如：adb shell ps -A | grep com.galapagossoft.trial

记下PID（例如19480）。接着，编写一个初步的Frida脚本（我们命名为mono_trace.js），用于附加进程并Hookmono_runtime_invoke，目的是打印出所有被调用的C#方法，从中寻找线索。

4.2 编写方法追踪脚本

这个脚本的核心逻辑是：替换mono_runtime_invoke函数，在每次调用时，通过Mono Runtime提供的API（如mono_method_get_name,mono_class_get_name）获取当前正在执行的C#方法名和类名，并打印到控制台。

// mono_trace.js console.log("[*] Starting Mono Runtime Trace..."); var mono = Process.findModuleByName("libmono.so"); if (!mono) { console.log("[-] libmono.so not found!"); return; } console.log("[+] libmono.so base: " + mono.base); // 获取关键函数地址 var mono_runtime_invoke_ptr = mono.getExportByName("mono_runtime_invoke"); var mono_method_get_name_ptr = mono.getExportByName("mono_method_get_name"); var mono_method_get_class_ptr = mono.getExportByName("mono_method_get_class"); var mono_class_get_name_ptr = mono.getExportByName("mono_class_get_name"); // 创建NativeFunction以便调用 var mono_method_get_name = new NativeFunction(mono_method_get_name_ptr, 'pointer', ['pointer']); var mono_method_get_class = new NativeFunction(mono_method_get_class_ptr, 'pointer', ['pointer']); var mono_class_get_name = new NativeFunction(mono_class_get_name_ptr, 'pointer', ['pointer']); // 保存原始函数 var orig_mono_runtime_invoke = new NativeFunction( mono_runtime_invoke_ptr, 'pointer', ['pointer', 'pointer', 'pointer', 'pointer'] ); // 替换函数 Interceptor.replace(mono_runtime_invoke_ptr, new NativeCallback(function(method, obj, params, exc) { var className = ""; var methodName = ""; // 获取类名和方法名 var klass = mono_method_get_class(method); if (!klass.isNull()) { var classNamePtr = mono_class_get_name(klass); if (!classNamePtr.isNull()) { className = classNamePtr.readCString() || ""; } } var methodNamePtr = mono_method_get_name(method); if (!methodNamePtr.isNull()) { methodName = methodNamePtr.readCString() || ""; } // 打印调用日志（可加过滤条件避免刷屏） if (className.includes("Controller") || methodName.includes("Collision") || methodName.includes("Death") || methodName.includes("Fail")) { console.log(`[Invoke] ${className}::${methodName}`); } // 调用原始函数，不影响游戏运行 return orig_mono_runtime_invoke(method, obj, params, exc); }, 'pointer', ['pointer', 'pointer', 'pointer', 'pointer'])); console.log("[+] mono_runtime_invoke hook installed.");

使用Frida加载脚本并附加到游戏进程：

frida -U -p 19480 -l mono_trace.js

4.3 分析日志与定位关键函数

启动游戏，故意让角色碰撞死亡。观察控制台输出的日志。你会看到大量方法被调用。我们需要从中筛选出与失败、死亡、碰撞相关的。

在我的这次实战中，日志显示了类似这样的序列：

[Invoke] Bone::OnCollisionEnter [Invoke] FailController::Start [Invoke] FailController::OnGUI ...

这个序列非常具有启发性：

1. Bone::OnCollisionEnter：这很可能是碰撞事件触发的第一个脚本方法。Bone可能是角色骨骼或碰撞体的组件名，OnCollisionEnter是Unity的标准碰撞事件函数。
2. FailController::Start：紧接着碰撞，一个名为FailController的组件被启动（Start方法在组件启用时调用一次）。
3. FailController::OnGUI：这可能是在屏幕上绘制“失败”或“游戏结束”UI的方法。

由此，我们可以做出一个合理的推断：Bone.OnCollisionEnter是碰撞事件的入口，而FailController的启动标志着死亡流程的开始。因此，我们的拦截点可以设在Bone.OnCollisionEnter。只要阻止这个方法正常执行，后续的FailController启动流程可能就不会被触发，或者即使触发也因为缺少前置条件而无效。

实操心得：动态追踪时，日志可能会非常庞大。建议一开始使用宽松的过滤条件（如包含特定关键词），定位到可疑的类和方法后，再修改脚本，精确只打印这几个方法，并观察它们被调用的时机和顺序，以确认因果关系。

5. 实现精准Hook：让碰撞失效

定位到关键函数后，下一步就是修改Hook脚本，从“记录”变为“拦截”。

5.1 编写拦截脚本

我们创建新的脚本mono_block_collision.js。这次，在mono_runtime_invoke的替换函数中，加入条件判断：如果检测到正在调用的是Bone::OnCollisionEnter，则直接返回一个空指针（或表示“成功执行但无异常”的指针，如ptr(0)），而不再调用原始函数。

// mono_block_collision.js console.log("[*] Attempting to block collision death..."); var mono = Process.findModuleByName("libmono.so"); if (!mono) { console.log("[-] libmono.so not found!"); return; } var mono_runtime_invoke_ptr = mono.getExportByName("mono_runtime_invoke"); var mono_method_get_name_ptr = mono.getExportByName("mono_method_get_name"); var mono_method_get_class_ptr = mono.getExportByName("mono_method_get_class"); var mono_class_get_name_ptr = mono.getExportByName("mono_class_get_name"); var mono_method_get_name = new NativeFunction(mono_method_get_name_ptr, 'pointer', ['pointer']); var mono_method_get_class = new NativeFunction(mono_method_get_class_ptr, 'pointer', ['pointer']); var mono_class_get_name = new NativeCallback(mono_class_get_name_ptr, 'pointer', ['pointer']); var orig_mono_runtime_invoke = new NativeFunction( mono_runtime_invoke_ptr, 'pointer', ['pointer', 'pointer', 'pointer', 'pointer'] ); Interceptor.replace(mono_runtime_invoke_ptr, new NativeCallback(function(method, obj, params, exc) { var className = ""; var methodName = ""; var klass = mono_method_get_class(method); if (!klass.isNull()) { var classNamePtr = mono_class_get_name(klass); if (!classNamePtr.isNull()) { className = classNamePtr.readCString() || ""; } } var methodNamePtr = mono_method_get_name(method); if (!methodNamePtr.isNull()) { methodName = methodNamePtr.readCString() || ""; } // 核心拦截逻辑 if (className === "Bone" && methodName === "OnCollisionEnter") { console.log(`[!!! BLOCKED !!!] ${className}::${methodName}`); // 返回一个表示“成功”的空结果，阻止原函数执行 return ptr(0); } // 对于其他方法，正常执行 return orig_mono_runtime_invoke(method, obj, params, exc); }, 'pointer', ['pointer', 'pointer', 'pointer', 'pointer'])); console.log("[+] Collision death hook installed. Game should be invincible now.");

5.2 测试与效果验证

用Frida加载这个拦截脚本并附加到游戏进程：

frida -U -p <PID> -l mono_block_collision.js

现在，进入游戏，操纵摩托车撞向障碍物。你会发现，角色虽然可能因为物理引擎的反馈而弹开或翻滚，但游戏画面没有弹出“失败”界面，游戏也没有结束，可以继续操作。这意味着我们的Hook成功了！Bone.OnCollisionEnter函数被我们“吞掉”了，它原本要执行的死亡判定逻辑（可能是设置一个isDead标志、触发失败事件等）没有执行，从而绕过了死亡。

注意事项：直接返回ptr(0)并不总是安全的。mono_runtime_invoke的返回值通常是该方法调用结果的指针。对于返回void的方法，返回0通常是可行的。但如果被拦截的方法有返回值，且游戏逻辑依赖这个返回值，直接返回0可能导致游戏崩溃或逻辑错误。更稳健的做法是：先调用原始函数获取结果，然后根据情况决定是否修改结果，或者对于void方法，调用原函数后直接返回原结果。但在本例中，OnCollisionEnter是Unity事件，返回类型为void，直接返回0是常见且有效的做法。

6. 进阶技巧与问题排查实录

一次成功的Hook背后，往往伴随着多次的尝试和问题排查。下面分享几个我在实战中遇到的关键问题和解决思路。

6.1 如何应对方法名混淆？

不是所有游戏都像示例这样使用清晰的Bone和OnCollisionEnter命名。很多商业游戏会对C#代码进行混淆，类名和方法名可能变成a、b、c或ClassA、MethodB这样无意义的字符串。

应对策略：

1. 动态分析结合静态分析：即使名字混淆，方法的行为和调用时机不会变。我们依然可以通过mono_trace.js脚本，在角色死亡时打印出所有被调用的方法。虽然名字是a::b，但它的调用时机（碰撞瞬间）是确定的。我们可以尝试拦截这个时机出现的所有可疑方法。
2. 分析调用栈：Frida可以获取并打印调用栈（Backtrace）。在Hookmono_runtime_invoke时，不仅打印当前方法，也打印是谁调用了它。这有助于理解函数在游戏逻辑中的上下文，即使名字混淆，也能通过上下文推断其作用。
3. 反编译DLL：用.NET反编译工具（如dnSpy、ILSpy）打开assets/bin/Data/Managed/Assembly-CSharp.dll。即使类名方法名混淆，但字符串常量、某些特定的API调用（如GameObject.Find("FailUI")、Application.LoadLevel）可能没有混淆。通过搜索这些关键字符串，可以定位到相关方法，再回到动态日志中寻找对应的混淆名。

6.2 Hook失败的可能原因与排查

1. libmono.so未找到：
   • 可能原因：游戏不是Mono架构（是IL2CPP），或者frida-server架构与游戏不匹配。
   • 排查：用Process.enumerateModules()打印进程所有模块，确认是否有libmono.so。检查APK的lib目录确认架构。
2. 游戏崩溃：
   • 可能原因：Hook的函数签名不正确；在回调函数中进行了非法内存操作；拦截方法后返回了错误的值。
   • 排查：简化脚本，先只做日志打印，不拦截。确认Hook点正确。仔细核对NativeFunction和NativeCallback的函数签名（参数类型、返回值类型），必须与mono_runtime_invoke的原型完全匹配。
3. Hook无效，游戏依然死亡：
   • 可能原因：拦截的类名或方法名不准确；死亡判定可能不在OnCollisionEnter，而在OnTriggerEnter、FixedUpdate或其他地方；或者游戏有多个碰撞体组件。
   • 排查：放宽拦截条件，例如只拦截包含Collision的所有方法，或者拦截FailController的所有方法。观察日志，确认在死亡瞬间，我们期望拦截的方法确实被调用了。

6.3 性能考量与优化

Hookmono_runtime_invoke意味着拦截了游戏中每一个C#方法的调用。如果游戏逻辑复杂，每秒调用次数可能成千上万。在我们最初的追踪脚本中，如果无条件打印所有日志，会导致控制台刷屏且可能影响游戏性能。

优化建议：

• 条件过滤：像我们最终脚本那样，只对感兴趣的特定类和方法进行判断和操作。
• 采样打印：可以设置一个计数器，每N次调用打印一次日志，减少输出。
• 使用更高效的匹配：在回调函数内部，将字符串比较放在最后。可以先比较指针或使用更快的哈希检查。

7. 扩展思路：从“无敌”到“修改”

成功绕过死亡判定只是第一步。基于同样的技术框架，我们可以做更多事情：

1. 修改游戏数值：我们可以Hook负责计算伤害、分数、速度的方法。在mono_runtime_invoke中，不仅拦截，还可以修改传入的参数（params）或篡改返回值。这需要更深入地理解Mono运行时中方法参数的结构，通常需要解析MonoMethod和参数数组。
2. 调用游戏内部函数：利用Frida的NativeFunction，我们可以主动调用libmono.so中的其他函数，例如mono_runtime_invoke本身，来触发游戏内的特定功能，比如无条件增加金币、解锁关卡。
3. 针对IL2CPP架构：如果游戏是IL2CPP后端，思路类似，但目标不同。IL2CPP将C#代码直接编译为C++，函数符号名会变得冗长且唯一。我们需要分析libil2cpp.so，寻找与游戏逻辑相关的函数符号（通常可以通过字符串引用或Metadata来定位），然后直接Hook这些C++函数。工具上可能会借助Il2CppDumper来生成符号映射表。

这次针对Unity Mono游戏的逆向实战，核心在于理解引擎的执行模型。通过抓住mono_runtime_invoke这个“牛鼻子”，我们能够以一种相对通用和高效的方式，干预游戏的逻辑执行。整个过程就像是在游戏的“翻译官”（Mono运行时）那里安插了一个监听器兼过滤器，在它把C#指令翻译给系统执行之前，我们就可以进行审查和干预。这种方法比直接修改DLL或内存漫无目的地搜索要精准和优雅得多。当然，每个游戏都有其独特性，具体的类名、方法名和逻辑需要具体分析，但这条从架构分析到动态Hook的技术路径，为分析同类Mono游戏提供了一个坚实可靠的模板。