三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

UE4游戏安全实战：从线程发包到HOOK加密解密的逆向分析

发布时间：2026/8/12 21:16:15 三亩地 编程学习日记
UE4游戏安全实战：从线程发包到HOOK加密解密的逆向分析

1. 项目概述：一场从“数据流”切入的攻防实战

如果你是一名对游戏安全、逆向工程感兴趣的开发者或安全研究员，那么UE4引擎的游戏绝对是一个绝佳的“练手场”。这个项目标题“UE4游戏安全实战：从线程发包到HOOK加密解密的逆向分析”，听起来技术栈很深，但它本质上描绘了一条非常清晰的实战路径：从最外围的网络数据包捕获与分析开始，深入到游戏内部处理数据的线程，最终定位并干预其核心的加密解密逻辑。这就像一场外科手术，目标不是破坏游戏，而是彻底理解其内部通信与数据保护机制。对于想学习游戏反外挂、协议分析、或是单纯想理解现代游戏客户端如何保护自身数据的开发者来说，这条路径涵盖了从入门到进阶的核心技能。

为什么是UE4？因为它太流行了。从独立游戏到3A大作，虚幻引擎4（以及现在的UE5）构建了海量的游戏世界。引擎的流行意味着其底层架构、内存管理、网络模块和常见的加密模式都有很强的规律性。一旦你掌握了一套针对UE4的分析方法论，你就能触类旁通，快速切入许多不同的游戏。这次实战，我们将模拟一个典型场景：分析一款使用UE4开发的网络游戏，目标是理解其客户端与服务器之间的通信协议，特别是加密部分，并尝试通过HOOK技术来动态加解密数据。这绝不是为了制作外挂，而是为了深入理解安全机制的实现与潜在的脆弱点，这对于构建更安全的游戏或进行安全审计至关重要。

2. 核心思路拆解：庖丁解牛，层层递进

面对一个复杂的UE4游戏客户端，直接一头扎进数GB的二进制文件里寻找加密函数，无异于大海捞针。一个高效、结构化的分析思路是成功的关键。我们的整体策略可以概括为“由外而内，动静结合”。

2.1 第一阶段：网络层监听与协议初探

一切始于数据流。游戏客户端与服务器的所有交互，最终都体现为网络上的数据包。因此，我们的第一步永远是抓包。使用像Wireshark这样的专业工具，或者针对游戏进程更精准的WinPcap/Raw Socket工具，捕获游戏运行时的网络流量。这个阶段的目标不是解密内容，而是观察：

  • 连接模式：是TCP长连接还是UDP？服务器IP和端口是什么？
  • 数据包特征：是否有明显的包头（比如长度字段、命令字）？数据包是明文还是肉眼可见的乱码（加密迹象）？
  • 交互频率：哪些操作（如移动、攻击、打开背包）会触发发包？触发前后的数据包变化有什么规律？

通过对比不同操作下的数据包，我们可以初步判断协议的大致结构。例如，移动操作可能发送包含坐标、方向的小数据包，而登录操作则可能发送包含账号密码（显然是加密的）的较大数据包。这个阶段建立起的“数据包-游戏行为”映射关系，是后续逆向分析的路标。

2.2 第二阶段：内存定位与线程分析

网络数据包最终是由游戏进程内的某个或某几个线程组包并发送的。我们的下一个目标，就是在内存中找到负责“发包”的关键代码位置。这里，动态分析工具大显身手。

  • 使用Cheat Engine进行内存扫描：这是逆向UE4游戏的经典入门步骤。因为UE4有一套相对固定的对象管理系统（UObject、GNames、GObjects等），我们可以利用这些特征快速定位游戏世界中的实体，比如玩家自身的角色对象。通过Cheat Engine扫描玩家角色的生命值、坐标等已知变化的数据，我们可以找到这些数据在内存中的地址。更重要的是，通过查找“访问该地址的代码”，我们往往能顺藤摸瓜，找到读写这些数据的函数，而这些函数很可能就在处理游戏逻辑和网络同步的线程上下文中。
  • 线程发包函数定位：UE4的网络层通常基于其自身的NetDriver和Channel体系。发送数据最终会调用到FSocket::Send或sendto这样的系统API。我们可以通过调试器在这些系统API上设置断点，当游戏发送数据包时，断点触发。此时查看调用堆栈（Call Stack），就能清晰地看到游戏内部从业务逻辑到网络层的完整调用链。堆栈中属于游戏模块（而非系统DLL）的、层级较高的函数，很可能就是我们要找的“线程发包函数”，比如某个UPlayerController的ServerMove函数实现，或者某个RPC（远程过程调用）的发送函数。

2.3 第三阶段：加密函数识别与HOOK介入

找到了发包函数，我们就逼近了加密发生的时刻。通常，游戏会在数据组包完成之后、调用系统发送函数之前，对数据包进行加密。

  • 识别加密函数：在发包函数内部或附近进行代码分析（使用IDA Pro或Ghidra进行静态分析，配合x64dbg动态调试）。寻找一些典型特征：对数据缓冲区进行循环操作、调用一些看起来像XOR、AES_encrypt、或自定义的复杂位运算函数、或者有明显的密钥调度过程。也可以通过对比加密前后缓冲区的内容变化来辅助判断。
  • HOOK技术选型：为了动态地分析或干预加密解密过程，我们需要“钩住”（HOOK）关键函数。这里有几个主流选择：
    • Detours/MinHook：这是Windows平台上成熟稳定的API HOOK库，通过修改函数头部的指令实现跳转。它稳定可靠，适合HOOK游戏内部函数或简单的系统API。
    • Frida：一个动态插桩工具包，它通过注入一个JavaScript运行时到目标进程，让你能够用JavaScript脚本动态地HOOK函数、修改参数、监视调用。它的优势是脚本化、跨平台（支持Android/iOS/Windows等），动态交互能力极强，特别适合快速原型分析和复杂逻辑的跟踪。
    • 自定义Inline Hook：最底层的方式，直接编写汇编代码修改目标函数开头的几个字节，跳转到你自己的代码。这种方式最灵活，但实现复杂，稳定性需要精心处理（如保存寄存器状态、处理线程安全）。

在本实战中，为了平衡效率与灵活性，我们可能会选择MinHook来HOOK关键的内部加密函数，因为它对Windows原生程序支持好；同时，在需要快速探索和动态修改逻辑时，可以辅助使用Frida进行脚本化的侦查和测试。

注意：在实际操作中，务必明确你的目的。如果是学习与研究，应在自己拥有合法权限的环境（如自己编译的测试游戏、明确允许安全研究的游戏）中进行。未经授权对他人运营的游戏进行逆向和HOOK可能违反用户协议甚至法律。

3. 工具链准备与环境搭建

工欲善其事，必先利其器。一套顺手的工具链能极大提升逆向分析的效率和体验。以下是针对本次UE4游戏安全实战的核心工具推荐与配置要点。

3.1 静态分析工具：代码地图绘制者

静态分析工具用于在不运行程序的情况下，反汇编二进制文件，分析其代码结构、函数调用关系和逻辑流。

  • IDA Pro（主力）：逆向工程领域的“瑞士军刀”。它强大的反汇编引擎、图形化视图、交叉引用（Xrefs）功能和丰富的插件生态（如FindCrypt用于识别加密常量）使其成为静态分析的不二之选。对于UE4游戏，可以利用其识别C++的RTTI（运行时类型信息）和虚表结构，帮助还原类层次。
  • Ghidra（免费替代/辅助）：美国国家安全局开源的工具，功能同样强大，完全免费。它的反编译能力有时比IDA更出色，能生成可读性更高的伪C代码。可以配合IDA使用，利用Ghidra进行深入的代码逻辑分析，用IDA进行快速的导航和标注。
  • 关键插件与脚本：
    • UE4逆向辅助脚本：GitHub上存在一些针对UE4引擎的IDA Python脚本或Ghidra脚本，可以自动解析GNames、GObjects等UE4全局表，将内存地址解析为可读的类名和函数名，这是逆向UE4游戏的“开图”神器。
    • FindCrypt / Signsrch：这些插件/工具可以扫描二进制文件，识别其中使用的加密算法（如AES、RSA、MD5）的常量（S盒、魔数），是快速定位加密函数的关键。

3.2 动态调试工具：实时现场侦察兵

动态调试工具用于在游戏运行时，实时监控和修改其内存、寄存器、执行流程。

  • x64dbg / OllyDbg：强大的Windows用户态调试器。x64dbg对64位程序支持更好，是现代游戏的首选。我们主要用它来下断点、跟踪执行流、查看和修改内存/寄存器、分析调用堆栈。在定位发包线程和加密函数时，动态调试是必不可少的。
  • Cheat Engine：虽然常被看作“修改器”，但其内存扫描、指针查找、代码注入和调试器功能极其强大。对于快速定位游戏数据（血量、坐标）和查找访问这些数据的代码，CE的效率无与伦比。它的“找出是什么访问了这个地址”功能，是逆向数据流的神器。
  • 调试器配置要点：
    • 隐藏调试器：很多游戏带有反调试保护，会检测调试器的存在。x64dbg和CE都有插件或选项可以隐藏自身（如ScyllaHide插件）。在开始调试前，务必先配置好反反调试措施，否则游戏可能会崩溃或退出。
    • 符号文件：如果游戏发布时附带PDB调试符号文件（某些开发版或测试版可能泄露），一定要加载它。这将直接显示函数名和部分数据结构，让逆向难度直线下降。
    • 硬件断点：对于检测非常敏感的函数，软件断点（INT 3）可能被游戏检测到。此时可以使用硬件断点（对执行、读写内存设断），它们更难被检测。

3.3 网络与HOOK工具：数据流与逻辑拦截器

  • Wireshark：网络协议分析的标准工具。配置过滤器只捕获目标游戏进程的流量，减少干扰。学会使用其“追踪TCP流”功能，可以重组完整的应用层对话。
  • Process Monitor：微软的Sysinternals工具套件之一。它可以实时监控进程的文件、注册表、网络和进程活动。有时可以用来辅助分析游戏启动时加载了哪些DLL、读取了哪些配置文件（可能包含密钥）。
  • MinHook：一个轻量级的HOOK库。我们将它编译成DLL，注入到游戏进程中，用于HOOK我们找到的关键加密/解密函数。它的API简洁，稳定性高。
  • Frida：动态插桩框架。我们需要在PC上安装frida-tools，并准备一个JavaScript脚本。对于被分析的游戏进程，可以通过frida命令附着（Attach）上去，或者将Frida注入到进程中。随后，脚本中编写的HOOK逻辑就会生效。Frida非常适合快速测试HOOK点是否有效，以及动态地修改函数参数和返回值。

3.4 开发与辅助环境

  • Visual Studio：用于编译我们自己的HOOK DLL、测试代码。需要熟悉C++和Windows API编程。
  • Python：用于编写自动化脚本，例如解析内存数据、与调试器交互（通过pykd或frida的Python绑定）、批量处理分析结果。
  • 一个干净的测试环境：最好是虚拟机快照。因为逆向分析过程中游戏崩溃、被检测导致封号是家常便饭。一个可以快速恢复的测试环境能节省大量时间。

4. 实战演练：定位线程发包与加密函数

理论准备就绪，现在让我们进入实战环节。假设我们分析的游戏叫“FantasyWorld”，一个典型的UE4第三人称MMORPG。

4.1 步骤一：网络行为建模与抓包

首先，正常启动游戏并登录。打开Wireshark，开始捕获所有流量。在游戏中执行几个清晰的操作序列：

  1. 原地站立不动，捕获“空闲状态”流量。
  2. 向前走几步，停止。
  3. 打开背包，再关闭。
  4. 对怪物进行一次普通攻击。

停止抓包，在Wireshark中设置过滤器ip.addr == <游戏服务器IP>。观察不同操作对应的数据包。你可能会发现：

  • 即使站立不动，也有规律的小心跳包（比如每2秒一个，长度固定）。
  • 移动时，会连续产生多个小包，长度相近。
  • 打开背包和攻击时，会产生一个或几个明显更大的数据包。

将“移动开始”和“移动结束”附近的数据包单独保存出来。对比它们的内容，虽然大部分是乱码，但可能会发现包头有规律，比如前2个字节是包长度，接着2个字节可能是命令号（Opcode）。这个初步的协议结构猜测需要后续在内存中验证。

4.2 步骤二：使用Cheat Engine定位关键数据与代码

启动Cheat Engine，附加到“FantasyWorld.exe”进程。

  1. 扫描玩家坐标：在游戏中，让角色移动到某个特定位置（如X=100.0， Y=200.0， Z=50.0）。在CE中，使用“浮点数”类型进行首次扫描。然后移动角色到另一个位置，进行“再次扫描”，直到筛选出少量地址。通过“手动添加地址”并修改数值，在游戏中验证哪个地址真正控制角色位置。找到准确的坐标地址（通常是三个连续的浮点数，代表X, Y, Z）。
  2. 查找访问代码：在坐标地址上右键，“找出是什么访问了这个地址”。CE会显示一个空白列表。回到游戏，让角色移动。列表中会出现访问该地址的汇编指令。记录下这些指令的地址（如Game.exe+123ABC）。
  3. 分析调用上下文：在x64dbg中附加游戏进程，转到上一步记录的指令地址。在此处设置断点。回到游戏移动角色，断点命中。现在，查看调用堆栈。堆栈中会显示是从哪个函数调用到这个写入坐标的指令的。这个上层函数，很可能就是处理玩家输入（键盘/鼠标）并更新坐标、同时准备发送移动数据包的逻辑所在。这个函数就是我们接近网络层的第一个重要跳板。

4.3 步骤三：追溯至网络发送函数

在找到的坐标更新函数中，我们需要寻找与网络发送相关的调用。在x64dbg中单步执行（F7/F8）这个函数，观察它是否调用了诸如send、WSASend、或UE4自身的网络发送函数（名称可能包含Send、Flush、Replicate等）。

  • 一个更直接的方法是：在Wireshark确认的游戏发包时刻，在x64dbg中对WSASend或sendto设置断点。当断点触发时，仔细查看调用堆栈。忽略ws2_32.dll和ntdll.dll中的系统函数，在游戏模块（如Game.exe）中的、最靠近用户逻辑的那个函数，极有可能就是我们要找的“最终发包函数”。我们称它为SendPacket_Final。
  • 在SendPacket_Final函数内部设置断点，再次触发移动操作。观察函数参数：通常第一个参数是Socket句柄，第二个参数是指向发送缓冲区的指针，第三个参数是缓冲区长度。我们的核心目标就是发送缓冲区和缓冲区长度。

4.4 步骤四：识别加密逻辑

现在，我们在SendPacket_Final函数入口处断住。查看指向缓冲区的指针（比如在RCX寄存器或栈上）。使用x64dbg的内存窗口查看该缓冲区的内容。

  1. 记录明文（如果存在）：在函数入口处，缓冲区里的数据可能已经是加密后的。我们需要向上回溯。在调用SendPacket_Final之前，数据是如何被填入这个缓冲区的？
  2. 回溯加密点：从SendPacket_Final的调用者开始，逆向分析代码。寻找对发送缓冲区进行填充和处理的循环或函数调用。关键线索包括：
    • 循环处理：对缓冲区逐字节或逐块进行运算的循环。
    • 常量参与：代码中引用了某些固定的数值数组（可能是S盒）或大整数（可能是密钥或初始化向量IV）。
    • 特定函数调用：调用了名称可疑的函数，如sub_XXXXXX，但其内部有大量位运算（xor,shl,shr,ror）或查表操作。
    • 对比验证：在疑似加密函数调用前和调用后，分别查看缓冲区内容。如果调用后数据变得完全不可读，且长度可能发生变化（如AES加密后长度对齐到16字节），那这里就是加密函数。
  3. 使用静态分析辅助：将疑似加密函数的地址记下来，到IDA Pro中查看其反编译代码。结合FindCrypt插件的结果，看是否能识别出标准的加密算法（如AES、TEA、XXTEA等）。UE4游戏也常用其自带的加密库或简单的XOR流加密。

假设我们找到了一个函数，它接收原始数据缓冲区和长度，以及一个密钥指针，输出加密后的数据。我们将其命名为EncryptPacket。这个函数就是我们的核心目标。

5. HOOK实现：拦截与操纵加密过程

找到EncryptPacket函数后，我们就可以通过HOOK来拦截它，实现数据的动态加解密、日志记录或修改。这里我们以使用MinHook为例，展示如何实现一个HOOK DLL。

5.1 创建MinHook HOOK项目

在Visual Studio中创建一个新的“动态链接库(DLL)”项目。

  1. 引入MinHook库：从GitHub下载MinHook源码，将其添加到项目中，或者通过vcpkg等包管理器安装。
  2. 编写HOOK代码：
    // dllmain.cpp #include <Windows.h> #include <cstdio> #include "MinHook.h" // 定义原始函数类型。这需要根据逆向分析得到的函数签名来精确匹配。 // 假设 EncryptPacket 签名为：void EncryptPacket(void* pInput, size_t inputLen, void* pOutput, size_t* pOutputLen, const void* pKey); typedef void (__cdecl* tEncryptPacket)(void*, size_t, void*, size_t*, const void*); tEncryptPacket fpOriginalEncryptPacket = nullptr; // 原始函数指针 // 我们的HOOK函数 void __cdecl DetourEncryptPacket(void* pInput, size_t inputLen, void* pOutput, size_t* pOutputLen, const void* pKey) { // 1. 打印或保存原始输入数据（加密前的明文） FILE* fLog = fopen("packet_log.txt", "ab"); if (fLog) { fprintf(fLog, "[Pre-Encrypt] Len: %zu\n", inputLen); fwrite(pInput, 1, inputLen, fLog); fprintf(fLog, "\n---\n"); fclose(fLog); } // 2. （可选）在这里修改pInput数据，实现包修改 // 例如，如果知道某个字段是坐标，可以在这里篡改它。 // 3. 调用原始函数，执行真正的加密 fpOriginalEncryptPacket(pInput, inputLen, pOutput, pOutputLen, pKey); // 4. 打印或保存加密后的输出数据 fLog = fopen("packet_log.txt", "ab"); if (fLog && pOutputLen) { fprintf(fLog, "[Post-Encrypt] Len: %zu\n", *pOutputLen); fwrite(pOutput, 1, *pOutputLen, fLog); fprintf(fLog, "\n==========\n"); fclose(fLog); } } // DLL入口点 BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { if (ul_reason_for_call == DLL_PROCESS_ATTACH) { // 初始化MinHook if (MH_Initialize() != MH_OK) { OutputDebugStringA("MinHook初始化失败"); return FALSE; } // 计算目标函数地址。假设我们通过逆向分析得到 EncryptPacket 的偏移是 Game.exe + 0x78ABCD // 这里需要获取Game.exe的模块基址 HMODULE hGame = GetModuleHandleA(NULL); // 主模块通常是游戏exe uintptr_t baseAddr = (uintptr_t)hGame; uintptr_t targetAddr = baseAddr + 0x78ABCD; // 替换为你的实际偏移 // 创建HOOK if (MH_CreateHook((LPVOID)targetAddr, &DetourEncryptPacket, (LPVOID*)&fpOriginalEncryptPacket) != MH_OK) { OutputDebugStringA("创建HOOK失败"); MH_Uninitialize(); return FALSE; } // 启用HOOK if (MH_EnableHook((LPVOID)targetAddr) != MH_OK) { OutputDebugStringA("启用HOOK失败"); MH_Uninitialize(); return FALSE; } // 可以在这里打开一个控制台窗口方便调试（仅Debug用） // AllocConsole(); freopen("CONOUT$", "w", stdout); printf("[HOOK DLL] 已成功注入并启用HOOK。\n"); } else if (ul_reason_for_call == DLL_PROCESS_DETACH) { // 清理HOOK MH_DisableHook(MH_ALL_HOOKS); MH_Uninitialize(); } return TRUE; }

    关键点：函数签名tEncryptPacket的定义必须绝对准确，包括调用约定（__cdecl,__stdcall,__fastcall）、参数类型和顺序。一个字节的偏差都会导致栈损坏和崩溃。这需要从逆向分析中仔细确认。

5.2 注入DLL到游戏进程

编译生成DLL后，需要将其注入到游戏进程。有多种方法：

  • 使用注入工具：如Extreme Injector、Process Hacker等图形化工具。
  • 远程线程注入：编写一个小的注入器程序，使用CreateRemoteThread和LoadLibraryA将DLL路径写入目标进程并加载。
  • 通过调试器加载：在x64dbg中，可以在游戏暂停时，使用命令loaddll YourHook.dll来加载。

注入成功后，如果HOOK安装正确，游戏调用EncryptPacket时就会先执行我们的DetourEncryptPacket函数。我们在函数中写入文件packet_log.txt，就能捕获到加密前后的数据包内容。

5.3 使用Frida进行快速脚本化HOOK

对于快速验证和动态探索，Frida非常高效。假设我们已经通过逆向找到了EncryptPacket函数的地址偏移0x78ABCD。

  1. 编写Frida脚本(hook_encrypt.js)：
    // hook_encrypt.js const baseAddr = Module.getBaseAddress('Game.exe'); const encryptFuncAddr = baseAddr.add(0x78ABCD); Interceptor.attach(encryptFuncAddr, { onEnter: function(args) { // args[0], args[1]... 对应函数的第一个，第二个...参数，根据调用约定调整 // 假设是__cdecl，参数都在栈上，这里需要根据实际分析调整。 // 更通用的方法是使用Frida的API读取栈上的参数，或者先通过调试确定参数位置。 console.log(`[+] EncryptPacket called!`); console.log(` Input Buffer @ ${args[0]}`); console.log(` Input Length: ${args[1]}`); // 将输入缓冲区内容打印为hex const inputBuf = args[0]; const inputLen = args[1].toInt32(); console.log(hexdump(inputBuf, { offset: 0, length: inputLen, header: true, ansi: true })); }, onLeave: function(retval) { // 函数返回后的处理 console.log(`[-] EncryptPacket returned.`); } });
  2. 执行脚本：在命令行中，确保游戏进程正在运行，然后执行：
    frida -p <游戏PID> -l hook_encrypt.js
    或者使用-n参数按进程名附加。Frida会注入脚本，并在函数被调用时在控制台打印信息。你可以快速修改脚本，尝试读取或修改参数，而无需重新编译DLL。

6. 逆向分析中的密码学识别技巧

在静态分析中，快速识别加密算法能节省大量时间。以下是一些常见算法的特征：

算法关键常量/特征常见场景
AES查找S盒（Substitution Box）常量。在IDA中，FindCrypt插件可以识别。常量数组通常以63 7C 77 7B F2 6B 6F C5...开头。还有轮常数Rcon。网络协议加密、文件加密。可能是AES-128/192/256。
TEA/XTEA/XXTEA魔数0x9E3779B9（黄金比例的倒数）。代码结构简单，通常有多次循环（如32轮），每轮进行移位、加、异或操作。游戏数据包加密、资源文件加密。因其实现简单、速度较快。
RC4密钥调度算法（KSA）和伪随机生成算法（PRGA）。特征是两个循环变量i和j，以及对一个256字节的S盒数组进行交换操作。流加密，曾用于TLS、WEP等。
Base64编码表，通常是ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/。解码时会有判断字符是否为=（填充符）的逻辑。不是加密，是编码。常用于在协议中传输二进制数据。
自定义XOR可能使用一个固定密钥字节或密钥流，与明文逐字节异或。在IDA中可能表现为一个简单的循环，循环体内是xor [rdi+rax], cl之类的指令。最简单的混淆，常见于对强度要求不高的通信或资源保护。

实操心得：在UE4游戏中，除了标准的加密库，开发者也可能使用引擎自带的一些加密工具类，例如FAES、FEncryption等。在IDA中，可以搜索字符串引用，查找“Encrypt”、“Decrypt”、“AES”、“Key”等关键词，有助于快速定位相关函数。另外，注意观察游戏初始化阶段，密钥很可能从某个配置文件、注册表或通过网络交换获得，并存储在全局变量中。通过HOOK加密函数，打印出传入的密钥指针内容，有时可以直接拿到密钥。

7. 常见问题、反调试对抗与排查技巧

在实际操作中，你几乎一定会遇到游戏的反调试和反作弊机制。下面是一些常见问题及应对策略。

7.1 游戏崩溃或无法启动

  • 可能原因1：HOOK函数签名错误。这是最常见的原因。调用约定、参数个数或类型不匹配导致栈不平衡。
    • 排查：在调试器中，在原始函数入口和你的Detour函数入口都设断点，单步跟进，对比栈指针（RSP）的变化。确保onEnter和onLeave时栈是平衡的。仔细核对IDA反编译出的函数原型。
  • 可能原因2：DLL注入被检测。游戏会检查进程内异常的DLL模块。
    • 对策：使用更隐蔽的注入技术，如线程劫持、APC注入。或者尝试将HOOK代码直接写入游戏进程内存（通过WriteProcessMemory）并创建远程线程执行，而不使用独立的DLL模块。
  • 可能原因3：完整性检查。游戏会对关键代码段（如加密函数）进行CRC或哈希校验，发现被修改后崩溃。
    • 对策：寻找校验函数并绕过它，或者使用更底层的硬件断点（Hardware Breakpoint）来代替修改代码的HOOK。硬件断点不会改变原指令。

7.2 断点不触发或游戏异常退出

  • 可能原因：反调试检测。游戏可能使用了IsDebuggerPresent、CheckRemoteDebuggerPresent、NtQueryInformationProcess等API，或通过Trap Flag、INT 3扫描等方式检测调试器。
    • 对策：
      1. 使用插件：在x64dbg中启用ScyllaHide插件，并针对游戏进程选择合适的隐藏配置文件。
      2. 手动绕过：在调试器中，找到调用这些检测API的地方，修改其返回值（通常让返回0，表示没有调试器）。
      3. 时间差检测：有些游戏会测量两个操作之间的时间，如果因为单步调试导致时间过长，就判定为调试。遇到这种情况，需要找到检测点并绕过，或者尽量避免在检测代码处单步。

7.3 HOOK后数据包异常，服务器断开连接

  • 可能原因1：加密/解密过程被破坏。你的Detour函数修改了数据或密钥，但没有按照游戏原有的逻辑处理，导致生成的密文服务器无法解密。
    • 排查：确保你的Detour函数在调用原函数前后，缓冲区内容的变化符合预期。可以先实现一个“只记录、不修改”的HOOK，确认能正常工作后，再尝试修改数据。
  • 可能原因2：数据包校验。除了加密，数据包可能还有CRC32、MD5或自定义的校验和。你修改了明文数据后，如果没有同步更新校验和，服务器校验会失败。
    • 对策：在逆向分析时，注意寻找在加密函数之后，是否还有对数据包进行哈希或校验计算的代码。需要一并HOOK并修正校验值。

7.4 找不到加密函数或函数地址偏移不稳定

  • 可能原因：ASLR（地址空间布局随机化）。每次游戏启动，模块的加载基址都会变化，导致硬编码的偏移失效。
    • 对策：使用特征码搜索（Pattern Scan）来定位函数。在IDA中分析函数，找到一段独一无二的字节序列（特征码），并避开直接指针（因为指针值会变）。在你的HOOK DLL中，启动时动态搜索这段特征码，计算出函数的实际地址。这是制作稳定HOOK的必备技能。
    • 示例（概念）：
      uintptr_t FindPattern(const char* module, const char* pattern, const char* mask) { // 实现一个特征码扫描函数，在模块内存中搜索pattern // ... } // 在DllMain中 uintptr_t encryptedFuncAddr = FindPattern("Game.exe", "\x48\x89\x5C\x24\x10\x48\x89\x74\x24\x18\x55\x57\x41\x56", "xxxxxxxxxxxxxx"); if (encryptedFuncAddr) { // 创建HOOK }

7.5 Frida脚本无法附加或瞬间被游戏检测到

  • 可能原因：Frida的默认注入方式（如frida-server）比较明显，容易被游戏的反作弊系统（如EAC、BattlEye）检测。
    • 对策：
      1. 尝试使用frida的--no-pause等选项，或使用更低调的注入技术。
      2. 在游戏完全启动并进入主菜单后，再尝试附加。
      3. 对于防护极强的游戏，Frida可能不适用，需要回归到传统的调试器和手动汇编分析。

逆向分析是一场与游戏保护机制的持续博弈。保持耐心，从简单的、保护较弱的游戏开始练习，逐步积累经验和工具链。每一次成功的分析和HOOK，都会让你对Windows系统机制、x64汇编、编译器和游戏引擎的理解更深一层。记住，核心目标始终是学习和理解技术原理，将这些知识用于构建更坚固的防御，而非破坏。

编程学习 学习日记 实战经验
← 返回列表