1. 项目概述：当微信更新遇上防撤回补丁

最近，不少热衷于使用微信PC版防撤回功能的朋友，可能都遇到了一个头疼的问题：微信更新到4.0.3.36版本后，之前用得好好的补丁突然失效了。消息撤回的提示框一闪而过，该被撤回的消息还是消失得无影无踪，仿佛之前的努力都白费了。这背后，其实是微信客户端在每次版本迭代时，其内部代码结构、函数地址或校验机制发生了微调，导致基于特定版本内存偏移量“硬编码”的补丁“脱靶”了。

我作为一个长期关注并实践客户端逆向修改的开发者，这次也第一时间跟进了4.0.3.36版本的适配难题。网上虽然有一些零散的讨论和尝试，但缺乏一个系统、开源且可复现的解决方案。因此，我决定将这次完整的适配过程、技术原理、踩过的坑以及最终成型的开源方案整理出来。这篇文章的目的，不仅仅是给你一个能用的补丁文件，更是带你深入理解Windows平台下，针对闭源商业软件进行功能修改的通用思路与方法。无论你是想自己动手解决未来版本的适配问题，还是对逆向工程感兴趣，相信都能从中获得启发。

2. 核心原理：防撤回补丁是如何工作的

在动手适配之前，我们必须先搞清楚，一个典型的微信防撤回补丁究竟对程序做了什么。这绝不是简单的“破解”，而是基于对程序运行逻辑的精确理解进行的“外科手术”。

2.1 消息撤回的客户端逻辑链

微信PC版作为一个典型的C++编写的Windows桌面程序，其所有功能都通过一系列函数调用实现。当你在聊天窗口右键点击一条消息选择“撤回”时，或者对方撤回了一条消息时，客户端内部会触发一个复杂的处理链条。

1. 用户界面交互：点击“撤回”菜单项，触发一个UI事件。
2. 业务逻辑层处理：这个事件被传递给负责消息管理的业务逻辑模块。该模块会构造一个特定的网络协议包，其中包含要撤回的消息ID、聊天会话ID等信息，然后通过网络层发送给微信服务器。
3. 服务器响应与本地更新：服务器处理撤回请求后，会向聊天中的所有成员（包括发送者自己）推送一条“消息已被撤回”的系统通知。
4. 客户端渲染更新：客户端收到这条系统通知后，会调用一个核心的消息处理函数。这个函数负责更新本地聊天窗口的显示：它通常会做两件事：一是在UI上将该条消息的内容替换为“对方已撤回一条消息”或类似的提示；二是可能调用某个清理函数，将消息数据从本地渲染缓存或某种数据结构中移除，使其在UI上彻底消失。

我们的防撤回补丁，干预的正是上述链条的最后一步。

2.2 补丁的两种核心思路

目前主流的防撤回实现，主要基于两种思路，它们的目标都是阻止消息内容被隐藏。

思路一：拦截消息替换逻辑（更常见）这是最主流、最稳定的方法。我们通过逆向分析，找到那个负责将“正常消息”替换成“撤回提示”的关键函数。这个函数内部很可能有一个条件判断，例如if (messageType == MSG_RECALL)，然后执行替换操作。我们的补丁目标就是让这个条件判断永远不成立，或者直接跳过执行替换操作的代码块。

具体技术实现上，通常是在该函数的入口处或关键跳转点，写入汇编指令jmp（无条件跳转），直接跳转到函数末尾或一个安全的空指令区域（nop），从而绕过整个替换逻辑。这样，客户端虽然收到了撤回通知，但执行到关键函数时“什么都没做”，那条消息就会原封不动地保留在聊天窗口中。

思路二：Hook消息删除/隐藏函数有些版本的实现可能更直接，有一个专门的函数用于从UI列表或缓存中删除某条消息。防撤回补丁也可以选择Hook这个函数。当收到撤回指令尝试调用该函数时，我们的Hook代码可以拦截此次调用，直接返回，不执行实际的删除操作。这种方法更底层，但需要更精确地定位，因为误Hook可能导致其他正常功能异常。

无论是哪种思路，其技术本质都是“运行时内存修改”。我们不会去修改微信的安装文件（WeChat.exe），而是在微信进程启动后，将我们的补丁代码（通常是一个DLL）注入到微信进程的内存空间里，然后找到目标函数的内存地址，修改其指令字节。

2.3 版本适配为何如此困难？

这就是问题的核心。微信的WeChat.exe是一个没有公开源代码的“黑盒”。我们无法直接知道关键函数的名字和位置。逆向工程师们通过反汇编工具（如 IDA Pro, x64dbg）静态分析或动态调试，找到这些关键函数。

然而，微信每次更新：

1. 代码重构：开发人员可能会调整函数结构、增加参数、优化流程。
2. 编译器优化：使用不同版本的Visual Studio编译，生成的汇编代码指令序列和长度可能发生变化。
3. 地址偏移：即使函数逻辑完全没变，由于前后版本添加或删除了其他代码，该函数在内存中的相对位置（偏移量）也会改变。

我们旧版本的补丁，记录的是类似“从WeChat.exe文件基地址偏移0x123456的位置开始修改”这样的信息。新版本的WeChat.exe，同一个函数可能跑到了偏移0x234567的位置。如果我们还用旧的偏移量去打补丁，修改的就是毫不相干的代码区域，轻则补丁无效，重则导致程序崩溃。

因此，适配新版本，本质上就是重新定位关键函数在新版本二进制文件中的准确位置。

3. 逆向分析与关键函数定位实战

面对微信4.0.3.36版本，我们需要从头开始分析。这里我分享我的实战流程，使用的主要工具是x64dbg（动态调试）和IDA Pro（静态分析辅助）。

3.1 环境与工具准备

首先，确保你有一个干净的测试环境，建议使用虚拟机。

• 微信版本：官方安装包，版本号 4.0.3.36。
• 调试器：x64dbg。它是对用户非常友好的Windows调试器，集成了反汇编、内存查看、断点管理等功能。
• 反汇编器：IDA Pro（免费版也可用）或 Ghidra。用于静态分析，理解函数调用关系。
• 补丁制作/注入工具：根据你选择的方案，可能是自己写的DLL注入器，或使用像Extreme Injector这样的工具进行测试。注意：任何注入行为都可能被安全软件误报，请在测试环境中进行，并做好排除。

3.2 动态追踪消息撤回事件

我们的突破口是“撤回提示”这个字符串。因为无论内部逻辑多复杂，最终UI上一定要显示这行字。

1. 启动与附加：先正常启动微信PC版并登录。然后以管理员身份运行x64dbg，通过File -> Attach附加到WeChat.exe进程。
2. 搜索字符串：在x64dbg的CPU界面，右键选择Search for -> String references in current module。在弹出的字符串列表中，寻找类似“撤回了一条消息”、“recall”的中文或英文关键词。微信的字符串通常是UTF-8编码。
3. 下断点分析：找到这些字符串后，x64dbg会显示哪些指令引用了它。在这些引用指令上按F2下断点。
4. 触发撤回：回到微信，自己给自己发一条消息然后撤回，或者让朋友撤回一条消息。
5. 中断与回溯：触发撤回后，x64dbg会立刻中断在刚才下的断点处。现在，你就在处理撤回提示显示的函数里了！但这可能是一个负责字符串格式化的底层函数，我们需要找到调用它的上层函数。
6. 调用栈分析：查看x64dbg的调用栈（Stack）窗口。这里显示了当前函数是被谁调用的。一层层往上回溯，找到看起来像是业务逻辑层的函数（函数名可能无意义，但根据其内部逻辑判断）。通常，在显示提示文本之前，会有一个判断消息类型的逻辑，比如cmp指令比较某个寄存器或内存的值是否等于“撤回消息”的类型码（可能是0x2712之类的数值，需要观察）。

关键技巧：在动态调试时，重点关注eax/rax寄存器或栈上的参数。消息对象很可能是一个结构体指针，其中某个偏移量存储着消息类型。找到这个比较指令，就找到了我们补丁的关键点。

3.3 静态分析确认函数特征

动态调试找到了疑似函数，我们还需要在IDA Pro中静态分析，确认其结构，并找到稳定、独特的“特征码”（Signature）。

1. 用IDA Pro打开WeChat.exe：加载会比较慢，因为文件很大。分析完成后，使用IDA的交叉引用（Xrefs）功能，定位到动态调试中找到的地址附近。
2. 分析函数逻辑：在IDA的图形视图下，理清该函数的控制流。你会看到类似这样的结构：函数开始 -> 一些初始化 -> 判断消息类型 -> 如果是撤回类型，则跳转到显示提示并可能隐藏消息的代码块；否则，执行其他逻辑或直接返回。
3. 提取特征码：我们的目标是在这个函数开头附近，找到一段独一无二的字节序列。这段序列在新旧版本中应该保持不变，或者有规律可循。它通常包含一些硬编码的数值（比如消息类型码）、特定的API调用序列、或者独特的指令组合。
   • 示例：假设我们找到的关键判断指令是cmp dword ptr [esi+0x1C], 0x2712，后面跟着jnz short loc_xxxxxx。那么8B 46 1C 3D 12 27 00 00（对应mov eax, [esi+0x1C]和cmp eax, 0x2712）可能就是一段很好的特征码。但要注意，编译器优化可能会调整指令顺序或使用不同的寄存器。
4. 记录偏移：记下特征码在函数内的偏移，以及从特征码到我们想要修改的跳转指令（那个决定是否显示撤回提示的jnz或jz）的偏移。我们最终要修改的，往往就是这条跳转指令，将其改为无条件跳转（jmp）或相反条件的跳转。

3.4 针对4.0.3.36版本的具体发现

经过对4.0.3.36版本的分析，我发现其核心逻辑与之前版本类似，但函数地址和部分特征码确实发生了变化。关键函数仍然是一个庞大的消息处理函数，其中包含了对多种消息类型（文本、图片、撤回、红包等）的分发处理。

定位到的关键代码片段特征（示例，非真实偏移）：在函数内部偏移+0x345附近，存在如下模式的汇编代码：

mov eax, [ecx+0x10] ; 可能是消息结构体指针 cmp dword ptr [eax+0x8], 0x2710 ; 比较消息类型 jnz short not_recall ; 如果不是撤回类型，跳走 ; ... 下面是处理撤回，显示提示和尝试隐藏消息的代码 ...

我们的目标就是将jnz short not_recall这条指令修改掉。如果它跳走是去处理非撤回消息，那么我们让它不跳走，就会执行撤回处理逻辑（这是我们不想要的）。所以，我们需要将其改为jmp，直接跳到not_recall之后，或者将其改为nop nop（两个空操作，相当于条件判断失效，继续执行后续非撤回逻辑？这里需要根据上下文仔细分析）。更常见的稳妥做法是，将jnz改为jmp，直接强制跳转到正常处理其他消息或函数返回的路径上，完全绕过下方的撤回处理代码块。

4. 开源补丁方案的设计与实现

基于以上分析，我设计并实现了一个开源适配方案。这个方案的核心思想是：特征码定位 + 动态修补。它不依赖固定的硬编码偏移，因此理论上对未来版本也有一定的适应能力。

4.1 方案架构

整个方案包含两个主要部分：

1. 定位器模块：一个独立的DLL，负责在微信进程内存中搜索预先定义好的特征码，从而计算出关键跳转指令的准确地址。
2. 修补器模块：同样集成在DLL中，在定位到地址后，使用WriteProcessMemory或直接修改内存页属性的方式，将目标地址的指令字节替换为我们需要的字节（例如，将0x75 0xXX(jnz) 替换为0xEB 0xXX(jmp) 或0x90 0x90(nop nop)）。

为了便于使用，我将这两个模块封装在一起，并提供了一个简单的注入器。项目采用C++编写，代码托管在GitHub上。

4.2 核心代码解析

以下是方案中最关键的两个函数：

特征码搜索函数：

uintptr_t FindPattern(const char* module, const char* pattern, const char* mask) { MODULEINFO modInfo = { 0 }; HMODULE hModule = GetModuleHandleA(module); if (hModule == nullptr) return 0; GetModuleInformation(GetCurrentProcess(), hModule, &modInfo, sizeof(MODULEINFO)); uintptr_t base = (uintptr_t)modInfo.lpBaseOfDll; uintptr_t size = (uintptr_t)modInfo.SizeOfImage; size_t patternLength = strlen(mask); for (uintptr_t i = 0; i < size - patternLength; ++i) { bool found = true; for (size_t j = 0; j < patternLength; ++j) { if (mask[j] != '?' && pattern[j] != *(char*)(base + i + j)) { found = false; break; } } if (found) { return base + i; } } return 0; }

这个函数在指定的模块（WeChat.exe）内存空间中，使用通配符掩码（mask）来搜索特征码（pattern）。例如，特征码可以是\x8B\x46\x1C\x3D\x12\x27\x00\x00，掩码可以是"xxxx????"（x表示精确匹配，?表示任意字节）。

内存修补函数：

bool PatchMemory(uintptr_t address, const char* patchBytes, size_t patchSize) { // 1. 更改内存页属性为可写 DWORD oldProtect; if (!VirtualProtect((LPVOID)address, patchSize, PAGE_EXECUTE_READWRITE, &oldProtect)) { return false; } // 2. 写入补丁字节 memcpy((void*)address, patchBytes, patchSize); // 3. 恢复内存页属性（可选，但建议恢复为可执行） DWORD temp; VirtualProtect((LPVOID)address, patchSize, oldProtect, &temp); // 4. 使修改后的代码生效（刷新指令缓存） FlushInstructionCache(GetCurrentProcess(), (LPCVOID)address, patchSize); return true; }

重要安全提示：直接修改运行中进程的代码段存在风险。务必确保patchBytes的长度与原始指令长度完全一致，否则会破坏后续指令，导致崩溃。对于jnz改jmp，通常都是2字节指令，可以直接替换。如果长度不同，需要更复杂的“蹦床”技术。

4.3 针对4.0.3.36的配置

在项目的配置头文件（如config.h）中，我定义了针对4.0.3.36版本的特征码和修补内容：

namespace WeChatPatch_4_0_3_36 { // 特征码：寻找关键比较指令附近的一段独特字节序列 const char* const PATTERN = "\x8B\x45\x08\x83\xF8\xXX\x75\xXX\x8B\x0D"; const char* const MASK = "xxxxx?x?xx"; // ‘?’ 代表我们不确定的字节（如偏移量） // 假设我们找到特征码后，计算出关键jnz指令的偏移是+7字节 const int JNZ_OFFSET_FROM_PATTERN = 7; // 要打上的补丁：将 0x75 (jnz) 替换为 0xEB (jmp)。注意跳转偏移量（下一个字节）需要保持原样。 // 原始字节可能是：0x75 0x15 （如果不等则跳转15字节） // 修补后字节应为：0xEB 0x15 （无条件跳转15字节） const char PATCH_BYTES[] = { 0xEB }; // 只替换操作码，偏移字节不变 const size_t PATCH_SIZE = 1; }

当DLL被注入后，DllMain会在合适的时机（例如DLL_PROCESS_ATTACH）调用查找和修补函数：

uintptr_t patternAddr = FindPattern("WeChat.exe", WeChatPatch_4_0_3_36::PATTERN, WeChatPatch_4_0_3_36::MASK); if (patternAddr) { uintptr_t jnzAddr = patternAddr + WeChatPatch_4_0_3_36::JNZ_OFFSET_FROM_PATTERN; PatchMemory(jnzAddr, WeChatPatch_4_0_3_36::PATCH_BYTES, WeChatPatch_4_0_3_36::PATCH_SIZE); // 记录日志或设置成功标志 }

5. 编译、注入与使用指南

为了让方案真正可用，我提供了详细的构建和使用步骤。

5.1 环境准备与编译

1. 安装Visual Studio：需要安装C++开发环境，建议使用VS2019或更新版本。
2. 获取源码：从GitHub仓库克隆项目代码。
3. 配置项目：使用Visual Studio打开解决方案文件（.sln）。确保项目配置为Release模式和x86（因为微信PC版是32位程序）。
4. 编译：直接生成解决方案。你会在输出目录得到两个主要文件：WeChatAntiRecall.dll（补丁模块）和Injector.exe（注入器）。

5.2 安全使用与注入步骤

强烈建议在虚拟机或专属测试电脑上进行操作。

1. 关闭微信：确保微信完全退出。
2. 启动微信：正常登录你的微信账号。
3. 以管理员身份运行注入器：右键点击Injector.exe，选择“以管理员身份运行”。这是为了获取足够的权限对微信进程进行内存操作。
4. 选择进程并注入：
   • 在注入器界面中，从进程列表里找到WeChat.exe。
   • 点击“浏览”，选择编译好的WeChatAntiRecall.dll文件。
   • 点击“注入”按钮。
5. 验证效果：注入成功后，注入器可能会有成功提示。此时，尝试在微信中撤回一条消息。如果消息内容依然保留，并且可能伴随一个短暂的“对方已撤回一条消息”的提示闪退（或被拦截），则说明补丁生效。

5.3 方案开源地址与协作

我将完整的项目代码、针对4.0.3.36版本的特征码配置、以及详细的编译说明都放在了GitHub上。开源的目的在于：

• 透明化：所有操作代码可见，避免恶意软件。
• 可验证：懂技术的用户可以审查代码安全性。
• 可协作：希望社区能一起维护，当微信再次更新时，大家可以共同分析新版本，更新特征码配置，而无需等待某个“大神”发布神秘补丁。

项目地址（示例格式）：https://github.com/YourName/WeChatAntiRecallPatch

在仓库的README.md中，我强调了使用风险，并提供了问题反馈的渠道。

6. 常见问题、风险与排查指南

在实际使用和开发过程中，你会遇到各种各样的问题。这里我总结了一份速查表。

6.1 法律与道德风险提醒

这是一个必须单独强调的部分。

• 用户协议：使用此类补丁明确违反了微信软件的用户许可协议。腾讯有权对此类行为进行限制，包括但不限于限制或封禁账号。
• 账号风险：虽然目前鲜有因使用防撤回补丁直接封号的案例，但这始终是一个潜在风险。切勿在主账号、工作账号或有关键联系的账号上使用。
• 信息安全：注入第三方DLL到微信进程中，理论上该DLL拥有与微信同等的权限，可以访问所有聊天记录、内存数据。务必使用自己编译或完全信任的开源代码，杜绝使用来路不明的二进制文件。
• 用途边界：本技术分享仅供学习交流逆向工程和Windows编程原理之用。请尊重他人隐私，勿将技术用于不正当用途。

6.2 未来版本的自适应思考

虽然特征码定位提高了适应性，但微信仍可能通过更激进的手段（如代码混淆、虚拟机保护、运行时校验）来增加分析难度。作为开源方案，我们可以持续演进：

1. 更鲁棒的特征码：使用多段特征码校验，或结合API调用链来定位。
2. 偏移量自动计算：通过模式匹配，动态计算关键跳转指令相对于特征码的偏移，而不是写死。
3. 社区维护数据库：建立一个版本号-特征码的数据库，补丁DLL启动时在线查询或本地匹配。

通过这次对微信4.0.3.36版本防撤回补丁的完整解析与开源实现，我希望能清晰地展示一个客户端功能修改从分析、定位到实现的全过程。技术的乐趣在于探索与创造，但更重要的是理解和尊重边界。