微信聊天记录自救:工具全灭之后,我用调试器 8 轮断点撬开了自己的数据库

我在工地上做项目管理,业余养了一个"AI 军师"团队帮我处理信息。工作上 8 个微信群每天几百条消息,靠人肉盯根本盯不过来,我的目标很简单:让 AI 每天自动读群消息,挑出"@我的、要我办的",列成清单。

要做到这件事,得先能读到微信存在自己电脑本地的聊天记录数据库。这个数据库是加密的——用的是 SQLCipher,可以理解为"给整个文件柜上了一把 AES-256 的锁,每一页文件单独加密"。

然后我发现:这条路比想象的难走得多。

一夜之间,现成的工具全灭了

先是查现成的方案,结果像看讣告:

• chatlog、PyWxDump:被微信官方发律师函,作者删库跑路;
• wechat-dump-rs:GitHub 全站封锁,连 fork 都被清空;
• wxauto(模拟鼠标操作):不支持微信 4.0 以上的新版本;
• 最后的 DLL 注入方案能用,但有封号风险——这是我的工作微信,赌不起。

更麻烦的是,微信 4.1 版本做了加固:以前密钥就明晃晃放在进程内存里,扫一遍就能捡到;4.1 之后内存里只剩一个"密码坯子"(passphrase),真正的钥匙要拿它再做一轮很慢的运算(PBKDF2,把密码用 SHA-512 反复"搅拌" 25.6 万次)才能算出来。所有老工具,一夜报废。

第一次尝试:照抄别人的答案,零命中

macOS 上有现成的成功思路:苹果系统的加密库有个公开函数,微信算钥匙时会调用它,用调试器(debugger——能让程序在指定位置"暂停下来让你围观"的工具)在那个函数上设个断点,等微信一登录,密码坯子就从函数参数里掉出来。

Windows 上对应的系统函数叫 BCryptDeriveKeyPBKDF2。我们挂上调试器,设好断点,登录微信——

零命中。一次都没有。

后来才确认:微信 4.1 的 Windows 版根本不用系统的加密库,搅拌算法是自己实现的。抄答案失败,因为考题不一样。

最容易上当的坑:抓到一个"长得就像钥匙"的东西

换个思路:在微信主程序(一个 184MB 的 DLL)里做静态分析,找到它配置加密参数的位置,设断点。这次命中了一百多次,抓到一个 32 字节的随机值——高熵、稳定、长得就一副"密钥脸"。

然后对它做了几百种组合的数学验证,全部失败。

那个东西只是加密功能的"配置参数",不是密码坯子。这是整个过程中最容易走错的弯路:在密码学里,长得像钥匙不算数,能开锁才算数。判断标准只有一个——HMAC 校验(可以理解为数据库第一页上盖了个防伪钢印,只有真钥匙才能对上印)。

思路反转:别问钥匙放在哪,守在开门的那一刻

连着又失败两轮:用硬件断点追踪那个假钥匙被谁读,只追到一堆内存拷贝;扫描全部 1.5GB 进程内存、验证约 2000 万个候选,一无所获——坐实了 4.1 的钥匙算出即用、绝不常驻。

到这里,与其继续问"钥匙放在哪",不如换个问法:钥匙总在开门的那一刻出现在锁孔里,那我就守在锁孔边上。

"锁孔"是什么?微信每次打开数据库,都要执行一串 SQLCipher 的配置指令(pragma),钥匙只在这一刻被使用。我们在程序里找到处理这些指令的代码位置,设下 4 个断点,让调试器托管微信启动、登录、开库——

断点命中 794 次,每次把现场(寄存器和栈内存)完整拍照。然后写个脚本,把照片里每个 32 字节的片段都当成候选钥匙,逐个做那 25.6 万次搅拌、再对钢印。

第 18 段照片里的一个候选,钢印对上了。真钥匙到手。

当天,24 个数据库全部解密,8 个工作群的消息流水一样读出来。现在每个工作日 12:10 和 17:47,Windows 计划任务自动跑一遍:重新解密、增量读取、按轻重缓急分级、关键词标亮,等我打开 AI,摘要和当日清单已经躺好了。

干货:这套方法的四步

整套思路对任何"密钥不常驻内存"的加密软件都适用:

1. 静态定位:在二进制里搜特征字符串(比如 "aes-256-cbc" 这类加密配置指令),用交叉引用(XREF)找到使用它们的代码地址;
2. 断点蹲守:cdb(WinDbg 命令行版)托管启动目标程序,断点命中时转储寄存器和栈;
3. 候选穷举:把转储里每个对齐的 32 字节窗口当候选,做 PBKDF2 派生;
4. 钢印裁判:派生结果对数据库第一页做 HMAC 校验,对上了才算抓到——没通过校验的候选,长得再像密钥也是垃圾。

核心代码就三行(Python):

enc_key = hashlib.pbkdf2_hmac("sha512", candidate, salt, 256000, dklen=32)
# salt = 数据库文件头 16 字节;再用 enc_key 对第一页做 HMAC-SHA512 比对
# 比对通过 → candidate 就是真 passphrase

经验总结

• 验证先行,别信直觉。那个假钥匙消耗了我们最多的时间,因为它"太像了"。密码学问题里,数学验证是唯一的裁判。
• 断点要下在"使用点",不是"配置点"。找密钥不要问它存哪,要找它在哪个瞬间被用。
• 排除法要留档。每条走不通的路都写进文档(系统函数断点无效、内存扫描无效、配置值是坑),防止自己和别人重走。
• 人机协作的正确姿势:人负责定方向和拍板("注入方案封号风险大,否了""模拟鼠标不准用,继续攻克解密"),AI 负责执行和穷举。方向错了,执行再快也是白跑——这次是我否掉了两条捷径,AI 把最难的那条路走通了。

结尾

工具会死,律师函会来,平台会封锁——但"数据就在我自己电脑上"这个事实不会变。读懂自己的数据,谁的人生不需要一次呢?

你在用 AI 解决过什么"没有现成工具"的问题?评论区聊聊。

合规说明:全程只在自己电脑、自己微信账号上操作,解密产物永不外传、不上云。

素材点

• 冲突-转折-结果完整链:工具全灭(冲突)→ 假钥匙坑(低谷)→ 思路反转守锁孔(转折)→ 794 次命中出真钥匙(结果)。
• 金句:"别问钥匙放在哪,守在钥匙开门的那一刻。"
• 金句:"在密码学里,长得像钥匙不算数,能开锁才算数。"
• 数字记忆点:184MB 程序、25.6 万次搅拌、1.5GB 内存 2000 万候选、794 次断点、32 个字节、24 个库。
• 人机协作故事:人否掉两条捷径(注入/模拟鼠标),AI 走通最难的路。

备选标题

• 微信 4.1 解密实战:8 轮断点、794 次命中,我抢回了自己的聊天记录
• 所有微信工具都被下架后,我和 AI 花一天时间逆向了自己的数据库
• AI 实战踩坑:一个"长得就像密钥"的假钥匙,骗了我们一下午