2026-07-28~29 微信4.1聊天记录读取攻坚战复盘

背景与目标

目标:让 AI 军师能读取 8 个甬金项目工作群的群消息,自动分类(要办的/要存的/知会的)、存档重要文件、解读通知。原始设想(上午的工作协同方案)是装个 chatlog 就完事,结果演变成一天一夜、五条路线的攻坚战。环境:Windows 11 + 微信 4.1.11.25(当时最新)。

过程回顾

尝试 1:chatlog(首选方案,开局即死)

上午方案里首推 chatlog(解密本地库+HTTP/MCP 接口)。下午一查:2025-10-20 作者收到微信官方函件,已删库,只留一封告别信。同类工具 PyWxDump、留痕同样被律师函下架。整个"本地库解密"工具生态已被定点清除。

尝试 2:wxauto(UI 自动化,兼容性死)

改装 wxauto 模拟人看屏幕读消息。微信 4.x 主窗口类名是 Qt51514QWindowIcon,wxauto 只认 3.9 的窗口类,初始化即报"无效的窗口句柄"。结论:wxauto 不支持微信 4.0+。 顺带被老板毙了这条路本身:"一个群一个群去点,这破效率谁吃得消"——有理。

尝试 3:wechat-dump-rs(仓库被封,拿不到)

找到专为 4.0 设计的 Rust 工具——GitHub 全站封锁(Repository access blocked),fork 也全被清空成只剩 README。第三方下载站有 exe,但来路不明的二进制不敢往工作微信上放。

尝试 4:内存扫描(原理性死)

找到存活的 Python 工具 wechat-decrypt(审过代码:只读本地、无外联)。两次全内存扫描,0 密钥命中。根因(从 wcdb-key-tool 的 README 才搞明白):微信 4.1 起不再在内存缓存明文密钥,只在登录瞬间用 passphrase 做一次 PBKDF2 派生——所有 x'<hex>' 模式扫描工具在新版上原理性失效。

尝试 5:cdb 断点抓 passphrase(实验路线,五连败)

wcdb-key-tool 的思路:登录瞬间断 BCryptDeriveKeyPBKDF2 系统函数抓 passphrase(Linux/macOS 已真机验证,Windows 无人验证过)。装 WinDbg(winget 一次成功,SDK 安装器反而三连败:静默安装 0x3e9、Git Bash 把 /layout 参数转成路径 C:/Program Files/Git/layout、bundle 检测父进程退出)。然后连环踩坑:

1. 工具解析误判:作者脚本的标记字符串出现在命令回显里,秒退假命中;
2. cdb 退出带走微信:调试器进程死亡 → 被调试的微信一起死。微信一晚上被迫重启 4 次,老板炸了:"不要把我的微信老是结束掉,然后等着我登录";
3. 符号解析失败:bcryptprimitives!BCryptDeriveKeyPBKDF2 无法解析——用 pefile 查导出表才发现这个函数只在 bcrypt.dll 导出(RVA 0x25d0),bcryptprimitives 里根本没有;
4. cdb stdin EOF 自杀:后台运行时 stdin 读到 EOF,cdb 在断点提示符处直接退出(又带走微信)。解法:tail -f /dev/null | cdb -g -G ... 挂住 stdin;
5. 参数顺序坑:cdb -o "exe" -cf script 会把 -cf 当成目标程序的参数,选项必须全部放在 exe 前面;
6. 最终结论:断点挂好、进程稳定、用户登录全程监听——零命中。实锤了作者自己标注的开放问题:微信 4.1 Windows 版自己实现了 PBKDF2,根本不调系统函数。这条路线原理性死亡。

终局:wx_key 与"不打的仗"

知乎线索找到 wx_key(明确支持 4.1.x)——主仓库同样被 DMCA 清空(作者留了一篇阴阳怪气的"致歉信"),靠 fork takeaway1/wx_key + gh-proxy 镜像拿到完整源码。一看真相:DLL 注入 + VEH Hook + shellcode + 系统调用隐藏的完整注入框架,还需要装几个 GB 的 Visual Studio 编译。

老板拍板(我作为军师也是这个建议):工作微信不冒注入风险,走保底方案——中转文件夹 + 每日 17:47 自动巡检分类。仗打到这里,选择不打了。

关键踩坑

• 坑1:工具生态情报过时 → 上午方案推荐的 chatlog 下午就发现已下架 → 教训:方案里的工具推荐必须落地前重新验证存活状态;
• 坑2:cdb 进程死亡连带杀死微信 → 根因:调试器与被调试进程的生命绑定 → 解法:断点命令里写 .detach/qd(抓到就自动脱离),绝不 taskkill;
• 坑3:后台 cdb 读到 stdin EOF 自杀 → tail -f /dev/null | cdb -g -G 三件套(挂 stdin、跳过初始断点、跳过退出断点);
• 坑4:Git Bash 路径转换吃掉安装参数 → /layout 变 C:/Program Files/Git/layout,exe 弹报错框 → MSYS_NO_PATHCONV=1 或改用 cmd 调用;
• 坑5:没验证就承诺 → "装个工具就完事"的方案和实际的"生态全灭+架构改防"落差太大 → 教训写进档案:未经验证的方案先在测试环境跑通,再动生产环境。

最终方案(已落地)

inbox/wechat/中转站/   ← 本人拖入群文件/通知/截图
        ↓ 每工作日 17:47(cron 6de8df1d)
AI 巡检:按 groups.json 的 8 群分级 + 关键词
  P0 要办(政策处理/征迁/借地/赔偿/迁改/协调)→ 行动建议 + 进清单
  P1 关注 → 解读 + 利弊分析
  P2 知会 → 一句话摘要
  重要文件 → 存档 notes/ + kb sync
  处理完 → 移"已处理"子目录

做得好的地方

1. 每一次失败都拿到了确定性结论:不是"好像不行",是"原理性不行+证据"(内存扫描 0 命中、断点零命中、pefile 验证导出表)——排除法做干净了,后人不走回头路;
2. 安全审查没放水:第三方 exe 不用、fork 源码先审(wechat-decrypt 确认无外联)、注入框架拉到源码看了真面目再决策;
3. 全程留档:五条路线的生死簿写进了 ideas/20260728_AI工作协同方案.md,工具留在 tools/wechat_watch/ 可复用;
4. 风险决策是对的:注入方案能成,但拿绑着全部工作关系的微信号去赌"罕见但不是零"的封号风险,期望值是负的。

复盘与改进

1. 最大的失误是顺序:应该先花 30 分钟做"工具生态存活+版本兼容性"侦察,再宣布方案——实际是方案先出口,侦察后补,导致一天都在填上午挖的坑;
2. 实验性方案不该在生产环境试错:老板的微信一晚上重启 4 次、重登录 3 次,沟通成本和信任损耗远超技术成本;正确姿势是先拿测试机/小号验证;
3. 保底方案应该第一天就上:中转文件夹零成本零风险,价值即时可得;高科技路线没跑通前,低保真通道就该一直在跑;
4. 待办:微信读取自动化保持观望——社区工具迭代很快(4.1 的 wx_key 从出现到被 DMCA 也就几个月),每隔一两个月重新侦察一次,有非注入方案再升级。