普通视图

今天 — 2026年4月19日高金的博客

人机协作逆向：用 AI + Frida 打通微信 4.1.8 macOS 数据库密钥提取

作者 Gao JIn

2026年4月18日 22:37

<blockquote>当内存特征扫描失效、标准 Hook 无功而返时，一个开发者与 AI 如何通过多轮迭代，最终找到微信 4.1.8 的密钥派生入口。</blockquote><hr><h2 id="一、背景：旧方案突然失效"><a href="#一、背景：旧方案突然失效" class="headerlink" title="一、背景：旧方案突然失效"></a>一、背景：旧方案突然失效</h2><code>chatlog</code> 项目长期依赖一套相对稳定的 macOS 密钥提取逻辑：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>vmmap 定位内存区域 → lldb dump 内存 → 搜索 fts5(% 特征字节 → 固定偏移取 32B Key → DB 验证 </pre></td></tr></table></figure>但在用户升级到 微信 4.1.8 后，这条链路彻底断裂。运行 <code>./bin/chatlog key --debug</code> 时，程序能正常读完 94 个内存区域，然后陷入漫长的静默，最终超时退出——Key 一个都没找到。<hr><h2 id="二、第一回合：AI-做诊断，人类给环境"><a href="#二、第一回合：AI-做诊断，人类给环境" class="headerlink" title="二、第一回合：AI 做诊断，人类给环境"></a>二、第一回合：AI 做诊断，人类给环境</h2>用户把问题抛给 AI：<blockquote>“我发现现在微信版本升级了，无法获取到 key。”</blockquote>AI 的第一反应是排查代码路径。通过阅读 <code>chatlog</code> 源码，AI 迅速定位到 V4 Extractor 的两个 Pattern：<ul><li>Pattern 1: <code> fts5(%</code>（<code>20 66 74 73 35 28 25 00</code>）</li><li>Pattern 2: 16 个零字节（<code>00 00 ...</code>）</li></ul>AI 列出可能的故障点，但用户没有手动去贴日志，而是直接说：<blockquote>“你直接运行看看吧。”</blockquote>AI 执行 <code>./bin/chatlog key --debug</code>，观察到内存读取正常、但匹配全部失败。接着 AI 检查微信二进制：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>strings /Applications/WeChat.app/Contents/MacOS/WeChat | grep -c "fts5" # 输出: 0 </pre></td></tr></table></figure>关键发现：<code>fts5</code> 在微信 4.1.8 里完全消失了。 这是旧方案失效的根因。<hr><h2 id="三、第二回合：人类抛出新线索，AI-转换思路"><a href="#三、第二回合：人类抛出新线索，AI-转换思路" class="headerlink" title="三、第二回合：人类抛出新线索，AI 转换思路"></a>三、第二回合：人类抛出新线索，AI 转换思路</h2>AI 解释了问题的本质：内存布局变了，需要找新的 Pattern 或换更稳定的 Hook 思路。此时用户提供了一个关键的外部信息：<blockquote>“wx_key 你参考看看这个项目是 windows 的，但是你看看他是怎么找 key 的”</blockquote>AI 读取 <code>wx_key</code> 的源码后，核心思路被点亮：<blockquote>Windows 版不扫描数据，而是 Hook 函数。 它在 <code>Weixin.dll</code> 代码段里搜索机器码 pattern，定位到处理 Key 的函数，安装 Inline Hook，等微信调用时直接拦截参数。</blockquote>这是一个比内存扫描稳定得多的方案。用户接着问：<blockquote>“frida hook 你能做吗”</blockquote>AI 回答：能。于是进入下一轮技术攻坚。<hr><h2 id="四、第三回合：AI-搭建-Frida-环境，踩坑与修正"><a href="#四、第三回合：AI-搭建-Frida-环境，踩坑与修正" class="headerlink" title="四、第三回合：AI 搭建 Frida 环境，踩坑与修正"></a>四、第三回合：AI 搭建 Frida 环境，踩坑与修正</h2>AI 开始动手：<ol><li>安装 Frida：<code>pip3 install frida-tools</code></li><li>寻找目标函数：先尝试 Hook <code>libsqlite3.dylib</code> 的 <code>sqlite3_key</code> / <code>sqlite3_key_v2</code></li></ol><h3 id="坑-1：Frida-17-API-变更"><a href="#坑-1：Frida-17-API-变更" class="headerlink" title="坑 1：Frida 17 API 变更"></a>坑 1：Frida 17 API 变更</h3>写脚本时踩了第一个坑——旧教程里的 <code>Module.findExportByName</code> 在 Frida 17 中报错：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>TypeError: not a function </pre></td></tr></table></figure>AI 通过快速测试定位到新 API：<figure class="highlight javascript"><table><tr><td class="gutter"><pre>1 2 3 4 </pre></td><td class="code"><pre>// 正确写法 Process.getModuleByName("libsqlite3.dylib").findExportByName("sqlite3_key") // 或 Module.getGlobalExportByName("sqlite3_key") </pre></td></tr></table></figure><h3 id="坑-2：sqlite3-key-根本没被调用"><a href="#坑-2：sqlite3-key-根本没被调用" class="headerlink" title="坑 2：sqlite3_key 根本没被调用"></a>坑 2：sqlite3_key 根本没被调用</h3>修正 API 后，Hook 安装成功。AI 让用户关闭微信，用 <code>frida.spawn</code> 重新启动并注入脚本。用户登录微信，AI 监控输出——60 秒内一个 Key 都没捕获到。这说明 微信 4.1.8 macOS 并未使用标准 SQLCipher 的 <code>sqlite3_key</code> 接口。加密逻辑完全内嵌在 140MB 的 <code>wechat.dylib</code> 中，自己管理密钥派生和 VFS 层加解密。<hr><h2 id="五、第四回合：转移战场到-PBKDF2"><a href="#五、第四回合：转移战场到-PBKDF2" class="headerlink" title="五、第四回合：转移战场到 PBKDF2"></a>五、第四回合：转移战场到 PBKDF2</h2>既然 <code>chatlog</code> 的解密代码明确告诉我们：<ul><li>算法：PBKDF2-HMAC-SHA512</li><li>迭代次数：256000</li><li>输出长度：32 字节</li></ul>那么微信启动数据库时，一定会在某个时刻做密钥派生。macOS 上最可能的系统入口是 <code>CommonCrypto</code> 中的 <code>CCKeyDerivationPBKDF</code>。AI 更新 Frida 脚本，新增对 <code>CCKeyDerivationPBKDF</code> 的 Hook，并加上过滤条件：<figure class="highlight javascript"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </pre></td><td class="code"><pre>var pbkdf2 = Module.getGlobalExportByName("CCKeyDerivationPBKDF"); Interceptor.attach(pbkdf2, { onEnter: function(args) { var algo = args[0].toInt32(); // 2 = kCCPBKDF2 var prf = args[5].toInt32(); // 5 = kCCPRFHmacAlgSHA512 var rounds = args[6].toInt32(); var pwdLen = args[2].toInt32(); if (algo === 2 && prf === 5 && rounds > 1000) { var hex = toHex(args[1], pwdLen); send({type: "key", key: hex, rounds: rounds, len: pwdLen}); } } }); </pre></td></tr></table></figure><hr><h2 id="六、第五回合：捕获成功，人类验证"><a href="#六、第五回合：捕获成功，人类验证" class="headerlink" title="六、第五回合：捕获成功，人类验证"></a>六、第五回合：捕获成功，人类验证</h2>脚本就绪后，用户让AI 关闭微信，运行脚本几秒钟后，终端输出：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>[KEY] via CCKeyDerivationPBKDF len=32 rounds=256000 dkLen=32 24f52f003edd470e97e73fc63f4b89bb0cb9efa09b8a40d685c75c47df21fc11 </pre></td></tr></table></figure>Key 捕获成功。但还没完。用户紧接着提出验证要求：<blockquote>“你根据这个 key 测试一下是否能 chatlog decrypt”</blockquote>AI 立刻用捕获到的 Key 执行解密：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 4 </pre></td><td class="code"><pre>./bin/chatlog decrypt \ --data-dir ~/Library/Containers/com.tencent.xinWeChat/Data/Documents/xwechat_files/... \ --data-key 24f52f003edd470e97e73fc63f4b89bb0cb9efa09b8a40d685c75c47df21fc11 \ --work-dir /tmp/chatlog_test </pre></td></tr></table></figure>输出：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>decrypt success </pre></td></tr></table></figure>Key 有效，数据库成功解密。<hr><h2 id="七、核心方法论：人机协作的分工"><a href="#七、核心方法论：人机协作的分工" class="headerlink" title="七、核心方法论：人机协作的分工"></a>七、核心方法论：人机协作的分工</h2>回顾整个过程，人类与 AI 的分工非常清晰：<table><thead><tr><th>角色</th><th>贡献</th></tr></thead><tbody><tr><td>人类</td><td>提供运行环境、触发问题、给出关键外部线索（<code>wx_key</code>）、决定尝试 Frida、执行微信登录操作、提出最终验证需求</td></tr><tr><td>AI</td><td>快速阅读大量源码做根因分析、搭建 Frida 环境、编写/调试 Hook 脚本、处理 API 兼容性问题、执行最终验证</td></tr></tbody></table>如果没有人类抛出的 <code>wx_key</code> 项目，AI 可能会继续在内存扫描或 sqlite3 Hook 的思路上打转；如果没有 AI 的快速代码阅读和脚本编写能力，从诊断到验证可能需要数小时甚至数天。<hr><h2 id="八、关键踩坑清单"><a href="#八、关键踩坑清单" class="headerlink" title="八、关键踩坑清单"></a>八、关键踩坑清单</h2><h3 id="1-特征字节依赖生命周期极短"><a href="#1-特征字节依赖生命周期极短" class="headerlink" title="1. 特征字节依赖生命周期极短"></a>1. 特征字节依赖生命周期极短</h3>微信 4.1.8 直接从二进制中移除了 <code>fts5</code> 字符串，导致基于内存布局的扫描方案瞬间破产。<h3 id="2-标准-SQLCipher-API-是个假目标"><a href="#2-标准-SQLCipher-API-是个假目标" class="headerlink" title="2. 标准 SQLCipher API 是个假目标"></a>2. 标准 SQLCipher API 是个假目标</h3>macOS 系统库里有 <code>sqlite3_key</code>，但微信根本不调用。Hook 之前必须做实际验证，不能凭假设行事。<h3 id="3-Frida-版本陷阱"><a href="#3-Frida-版本陷阱" class="headerlink" title="3. Frida 版本陷阱"></a>3. Frida 版本陷阱</h3>Frida 17 废弃了 <code>Module.findExportByName</code>，大量网络教程已过时。实际动手测试才能发现。<h3 id="4-必须在-spawn-模式下拦截"><a href="#4-必须在-spawn-模式下拦截" class="headerlink" title="4. 必须在 spawn 模式下拦截"></a>4. 必须在 <code>spawn</code> 模式下拦截</h3>attach 到已运行的微信会错过所有启动时的密钥派生。先 <code>pkill WeChat</code>，再用 <code>frida.spawn()</code> 启动，是捕获 Key 的必要条件。<hr><h2 id="九、完整可用脚本"><a href="#九、完整可用脚本" class="headerlink" title="九、完整可用脚本"></a>九、完整可用脚本</h2>以下脚本已保存至项目根目录 <code>wechat_key_hook.py</code>，可直接使用：<figure class="highlight python"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 </pre></td><td class="code"><pre>#!/usr/bin/env python3 import frida import sys import time JS = r""" function toHex(ptr, len) { try { var arr = new Uint8Array(ptr.readByteArray(len)); return arr.map(b => b.toString(16).padStart(2, '0')).join(''); } catch(e) { return null; } } var pbkdf2 = Module.getGlobalExportByName("CCKeyDerivationPBKDF"); if (pbkdf2) { Interceptor.attach(pbkdf2, { onEnter: function(args) { var algo = args[0].toInt32(); var prf = args[5].toInt32(); var rounds = args[6].toInt32(); var pwdLen = args[2].toInt32(); if (algo === 2 && prf === 5 && rounds > 1000) { var hex = toHex(args[1], pwdLen); if (hex) send({type:"key", key:hex, rounds:rounds, len:pwdLen}); } } }); send("[+] CCKeyDerivationPBKDF hooked @ " + pbkdf2); } """ print("[*] Spawning WeChat...") pid = frida.spawn("/Applications/WeChat.app/Contents/MacOS/WeChat") session = frida.attach(pid) script = session.create_script(JS) def on_msg(message, data): if message['type'] == 'send': payload = message['payload'] if isinstance(payload, dict) and payload.get('type') == 'key': print(f"\n[!!!] KEY CAPTURED: {payload['key']}") else: print(payload) script.on('message', on_msg) script.load() frida.resume(pid) time.sleep(60) session.detach() </pre></td></tr></table></figure><hr><h2 id="十、后续展望"><a href="#十、后续展望" class="headerlink" title="十、后续展望"></a>十、后续展望</h2>这次实践验证了 Hook 加密算法入口 比 内存特征扫描 更稳定、更跨版本。下一步可以将 Frida Hook 封装为 <code>chatlog key</code> 的新后端（例如 <code>--frida</code> 模式），让 macOS 用户不再需要关闭 SIP 或依赖 <code>lldb</code>，大幅降低使用门槛。<blockquote>一个人类开发者 + 一个能读代码、写脚本、跑验证的 AI，可以在一个小时内完成传统上需要数天的逆向工程闭环。</blockquote> 本文作者：高金 本文地址： <a href="https://igaojin.me/2026/04/18/%E4%BA%BA%E6%9C%BA%E5%8D%8F%E4%BD%9C%E9%80%86%E5%90%91%EF%BC%9A%E7%94%A8-AI-Frida-%E6%89%93%E9%80%9A%E5%BE%AE%E4%BF%A1-4-1-8-macOS-%E6%95%B0%E6%8D%AE%E5%BA%93%E5%AF%86%E9%92%A5%E6%8F%90%E5%8F%96/">https://igaojin.me/2026/04/18/人机协作逆向：用-AI-Frida-打通微信-4-1-8-macOS-数据库密钥提取/</a> 版权声明：转载请注明出处！<div id="gitalk-container"></div><script src="https://cdn.bootcss.com/blueimp-md5/2.12.0/js/md5.min.js"></script><link rel="stylesheet" href="https://unpkg.com/gitalk/dist/gitalk.css"><script src="https://unpkg.com/gitalk/dist/gitalk.min.js"></script><script>var gitalkConfig = {"clientID":"935e92a5333436856348","clientSecret":"e655566eaf920d216ec6283978d67874bf0850a6","repo":"jin10086.github.io","owner":"jin10086","admin":["jin10086"],"distractionFreeMode":false,"id":"page.date","createIssueManually":false}; gitalkConfig.id = md5(location.pathname);var gitalk = new Gitalk(gitalkConfig); gitalk.render("gitalk-container"); </script>

昨天以前高金的博客