微信 8.0.78 · Codex · reverse-skill · Android 逆向实战

周末了，分享一个最近做的小实验。

我用 Codex，花了大约 10 分钟，对 Android 微信进行了一次逆向修改，实现了消息防撤回。

测试版本：微信 8.0.78。

效果是：对方发送消息后，即使撤回，我这边依然能看到原来的内容。

更重要的是，退出并重新启动微信，之前保留下来的消息依然存在。

这不是一个单纯的界面效果，而是通过修改客户端的消息撤回处理逻辑实现的。

当然，这只是一次学习性质的实验，不建议直接拿自己的主力微信账号折腾。

01｜先看看效果

先放两张测试截图。

第一张是接收消息的微信。

对方发送了一条「你好」，以及一张图片。接收端仍然可以看到这些内容。

第二张是发送消息的微信。

发送方的聊天界面已经出现了两条「你撤回了一条消息」提示，但接收端依然保留着此前的消息。

这就是这次实验希望实现的效果：让客户端不再按照原有逻辑，将收到的消息改写成撤回提示。

从技术记录来看，我还完成了一次新文本消息的撤回测试，并在重启微信后再次确认原消息仍然存在。

图片防撤回效果有截图展示，但尚未形成与文本消息同等完整的独立验证记录。

02｜为什么突然想逆向微信？

起因其实很简单。

之前我看到过一个开源项目：

reverse-skill

项目地址：

https://github.com/zhaoxuya520/reverse-skill/tree/main

当时觉得挺有意思，就收藏了下来。

大家都知道，Mac 端微信的消息防撤回方案相对容易找到。

但是Android客户端的消息防撤回我却没找到，找到的也是无效的或者收费。

03｜准备工作：工具其实很简单

这次使用的核心工具只有一个：

Codex。

另外需要一个辅助项目：

reverse-skill。

以及一份用于研究的 Android 微信 APK。

我使用的版本是：

微信 8.0.78

APK 可以提前准备，也可以在授权连接的 Android 测试手机上提取已安装的应用包。

我的实际操作是连接手机，让工具分析手机上的微信安装包。

整个过程没有要求 AI 读取聊天内容。

这里需要特别提醒：

逆向之前，一定先备份微信聊天记录。

因为修改 APK 后，原来的官方签名会发生变化。

Android 对应用签名有校验机制，不同签名的安装包通常不能直接覆盖安装。

也就是说，可能需要卸载原版微信，再安装修改后的测试版本。

而卸载微信，就可能导致本地聊天记录丢失。

所以，最好使用备用手机、备用账号和独立测试环境。

04｜真正动手：给 AI 一句话

第一步，安装 reverse-skill。

第二步，准备好微信 APK，或者连接已经安装微信的 Android 手机。

第三步，打开 Codex，输入我的需求：

我是一个程序员，正在学习逆向相关的知识，请帮我完成微信的逆向并实现消息防撤回功能。

就这么简单。

接下来，我主要负责与 AI 配合、确认操作、进行测试。

AI 则负责分析 APK、定位相关代码，并研究修改方案。

以前这些工作需要自己大量搜索资料、反编译、定位代码和反复试错。

现在，AI 可以帮助完成其中99.9%探索和执行工作。

人的角色，正在从逐条执行操作，转向定义目标、判断方案、授权操作和验证结果。

05｜技术原理：微信是怎么撤回消息的？

这部分稍微讲一点技术细节。

这次逆向过程中，定位到了微信 8.0.78 中一个负责处理消息撤回的方法：

b41.t.c(String,long,p0,String,String,String)

它位于 APK 的 classes11.dex 中。

根据反编译分析，微信接收到撤回相关的系统消息后，会读取类似下面的字段：

.sysmsg.revokemsg.newmsgid

然后进入对应的撤回处理方法。

原来的处理逻辑，大致可以理解成：

收到撤回指令 → 查找原消息 → 修改消息内容和类型 → 更新本地消息表。

也就是说，消息撤回并不只是聊天界面上出现了一句「对方撤回了一条消息」。

客户端实际上还会执行本地消息记录的更新操作。

这就提供了一个研究方向：

如果阻止这段本地更新逻辑执行，会发生什么？

06｜关键修改：让撤回处理方法提前返回

这次实验采用的方案非常直接。

没有重新实现微信消息系统，也没有修改服务器通信协议。

而是在定位到的撤回处理方法入口，让它立即返回。

在 DEX 指令层面，测试补丁将目标位置的指令修改为 return-void。

于是原本的处理流程：

收到撤回消息 → 查找原消息 → 修改本地记录 → 显示撤回提示

变成了：

收到撤回消息 → 进入处理方法 → 立即返回

这样，后续修改本地消息记录的操作就不会继续执行。

从实际测试来看，这个思路对本次测试的文本消息有效。

但这里有一个需要注意的技术问题。

直接让整个方法返回，并不等于只关闭了消息撤回功能。

因为这个方法还可能涉及其他操作，例如消息引用状态、事件通知等。

这些附带影响，在本次实验中并没有得到完整验证。

因此，这是一种适合研究和验证原理的补丁方式，不代表它已经达到长期稳定使用的程度。

07｜修改完成，还要解决 APK 签名

找到目标代码，只是第一步。

Android APK 经过修改后，原来的签名通常就不能继续使用了。

因此，AI 还需要完成后续工作：

1. 修改目标 DEX。

2. 重新计算 DEX 校验值。

3. 重新打包 APK。

4. 使用本地测试证书签名。

5. 检查 APK 对齐和签名是否有效。

6. 安装到测试设备。

这次实验中，补丁后的 APK 通过了 ZIP 对齐及 v2/v3 签名检查。

对比结果显示，除了重新签名产生的文件之外，主要内容变化集中在 classes11.dex。

也就是说，这次修改范围相对集中。

但要强调：

重新签名后的微信，已经不是腾讯官方签名的原版安装包。

不能将其视为官方客户端，也不应该假设它能正常使用所有微信功能。

更不能忽视账号风控、数据安全和后续升级的问题。

08｜实际测试：撤回成功了，但消息还在

修改完成之后，开始测试。

我在手机上安装修改后的微信，并成功登录测试账号。

随后，使用另一个账号向它发送一条新的文本消息。

测试过程是：

第一步： 发送方发送「你好」。

第二步： 接收方确认收到消息。

第三步： 发送方执行撤回。

第四步： 检查接收方聊天界面。

结果：

发送方显示消息已经撤回，但接收方依然可以看到原来的「你好」。

这说明本次补丁确实改变了客户端对撤回消息的处理行为。

不过，仅仅看到消息还在，并不能说明修改完全成功。

还有一个问题：

重新启动微信后，消息会不会消失？

于是继续测试。

强制停止微信进程，再重新打开客户端，进入同一个聊天会话。

结果是：

原来的消息仍然存在。

这说明在本次测试条件下，消息不只是暂时保留在界面缓存中，重启之后仍然可以读取到原来的内容。

到这里，文本消息防撤回的单次测试，以及重启持久性测试，都通过了。

需要说明的是，本次技术记录只完整验证了一条新文本消息。不同消息类型、不同会话场景、XSpace 账号以及长期稳定性，仍需要更多测试。

09｜整个实验，我花了多久？

从提出需求、AI 分析，到修改、安装和测试，核心操作过程大约花了 10 分钟。

这里的时间是我这次实际体验的耗时，并不意味着任何人都能在 10 分钟内完成，也不意味着这是一套稳定、通用的微信修改方案。

但这件事让我感触很深。

以前想做 Android 逆向，你可能需要先熟悉：

• APK、DEX 和 Smali 的基本结构。

• JADX 等反编译工具。

• Android 应用签名机制。

• 代码调用链和数据存储逻辑。

• 真机调试与异常排查。

现在，AI 可以把这些知识与工具连接起来，帮助开发者快速开展一次完整的技术实验。

你仍然需要理解风险，判断结果是否可靠。

但从「我有一个想法」到「我真的动手验证」，中间的距离正在变短。

10｜AI 面前，人人平权？

这也是我最想分享的观点。

我做了很多年开发，经历过从手写大量代码，到搜索技术文档、使用开源库，再到今天和 AI 一起完成开发任务的过程。

过去，很多想法之所以没有实现，不一定是因为它们不够好。

而是因为实现门槛太高。

你可能有一个很好的产品想法，但不会写代码。

你可能发现某个软件存在问题，但不了解它的内部实现。

你可能想验证一种技术方案，但学习成本需要几周甚至几个月。

于是很多想法，就停留在了想法阶段。

AI 正在改变这种情况。

它并没有让所有人瞬间拥有相同的技术能力，也不会自动解决所有问题。

但它确实让更多人有机会接触过去门槛较高的技术领域。

以前，你需要先掌握大量工具，才能尝试解决一个问题。

现在，你可以先清楚地描述问题，再借助 AI 一边学习，一边验证解决方案。

这就是我所理解的：

AI 面前，人人平权。

不是人人都自动成为专家，而是更多人开始拥有动手尝试的机会。

11｜最后，几个重要提醒

这次实验仅供 Android 逆向技术学习与研究，不提供修改后的微信 APK，也不建议将其用于日常主力账号。

首先，修改后的 APK 需要重新签名，不能直接作为官方微信的更新包安装。

其次，卸载和重新安装可能造成聊天记录丢失，务必先备份并验证备份是否有效。

再次，使用非官方修改客户端可能存在微信账号被限制登录、临时封禁，以及隐私和安全风险。

最后，微信版本更新后，相关代码结构和调用逻辑都可能发生变化。本次针对 8.0.78 的分析，不能直接推广到其他版本。

不要因为 AI 能完成操作，就忽略操作本身的风险。

写在最后

这次微信防撤回实验，对我而言并不是为了长期使用一个修改版微信。

而是为了验证一件事：

当一个开发者有明确的目标，再配合合适的 AI 工具，原本复杂的技术探索，究竟可以被压缩到什么程度？

这次的答案，是大约 10 分钟。

下次可能是另一个 App，也可能是一个完全不同的技术领域。

真正值得关注的，不只是 AI 帮我们节省了多少时间。

而是那些过去觉得麻烦、太难、没必要尝试的想法，现在终于可以动手试一试了。

周末了，如果你也对逆向工程、AI 编程感兴趣，不妨从一个合法授权的测试应用开始，亲手验证一次。

想法不应该只停留在想法里。

我是魁歌，一名独立开发者，持续分享 AI、编程、产品和真实的技术实践。

本文为个人技术学习记录，测试结果仅对应文中所述环境，不构成对修改客户端安全性、兼容性或长期可用性的保证。