* feat: macOS 图片 AES key 从磁盘 kvcomm 缓存派生(issue #23)
macOS 用户长期无法用 C 版 find_image_key_macos 从微信进程内存提取
V2 图片密钥(issue #23 报告 197K 候选全部失败)。新增
find_image_key_macos.py 走完全不同的路径:从磁盘 kvcomm 缓存
文件名派生密钥,无需扫描内存、无需 root、无需重签名。
派生算法
--------
- 扫 ~/.../app_data/net/kvcomm/key_<code>_*.statistic 文件名
- 对每个 (code, wxid) 候选:
xor_key = code & 0xFF
aes_key = MD5(str(code) + cleaned_wxid).hex()[:16] # ASCII 字符串
- 用 V2 _t.dat 文件 [0xF:0x1F] 16 字节做 AES-128-ECB 模板验证:
解出来必须是图像 magic(JPEG / PNG / GIF / WebP / wxgf)
- 为防短 magic 偶然命中,要求多个不同模板都通过验证才算成功
- 命中后写回 config.json 的 image_aes_key / image_xor_key,
monitor_web.py 自动加载
致谢
----
派生算法源自 @hicccc77 在 issue #23 的评论;参考实现见其 WeFlow
项目 (CC BY-NC-SA 4.0)。本模块是独立的 Python clean-room 实现,
未复制其 TypeScript 源码;函数边界与变量命名沿用算法的自然结构
(regex 模式 / MD5 调用顺序 / magic 字节表等不可避免地相同)。
健壮性细节
----------
- 多候选 kvcomm 路径:枚举 5 个不同的 macOS 微信版本路径布局
- 多模板交叉验证:默认收集 3 个不同密文,全部通过才算命中
- 已有 image_aes_key 仍有效时短路返回,不重写 config
- 原子写 config.json:tmp + os.replace + finally 清理 .tmp
- 多 wxid 候选:同时试 raw 和归一化后的 wxid(A_Hare_626a → A_Hare)
- print(flush=True) 逐次显式(与 find_image_key.py 风格一致)
测试
----
新增 tests/test_find_image_key_macos.py,53 个测试覆盖:
派生算法 / wxid 归一化 / kvcomm 路径推算(含多候选)/ 模板收集
(去重 / 子目录 / max_files 边界)/ AES 验证(5 种 magic / 短输入
/ 空 key)/ 多模板交叉验证 / 端到端集成(命中 / 各种失败分支)/
原子写 / main 短路(已有有效 key 不重写 / 已有错 key 落到派生)。
全部通过:python -m unittest discover tests → 88/88。
兼容性
------
- 无新增依赖(pycryptodome 已在 requirements.txt)
- 不改任何现有 Python 文件,零回归风险
- 现有 Windows / Linux 路径 (find_image_key.py / find_image_key_monitor.py) 不受影响
* feat: macOS 图片 AES key 加方案2 fallback (issue #68 思路)
PR #60 的方案1 (kvcomm 缓存派生) 在 kvcomm 缺失 / 多账号歧义 / 首次
启动等场景下会失败。@H3CoF6 在 issue #68 提出关键洞察:
wxid 目录后 4 位 hex == md5(str(uin))[:4]
意味着不需要 kvcomm,可以从 wxid 目录名 + 任意 V2 .dat 反推 uin。
本 commit 在保留 PR #60 方案1 不变的前提下,加方案2 作为 dispatcher
fallback。
方案2 算法
----------
1. 从 db_dir 提 wxid 后 4 位 hex 作为 md5 前缀目标
2. 扫多个 V2 .dat 末字节投票反推 xor_key (假设 JPG EOI 0xD9,
默认至少 3 个样本投票)
3. 枚举 0~2^32 中 (uin & 0xff == xor_key) 的 2^24 个候选,
md5(str(uin))[:4] 匹配 wxid 后缀 → 得 ~256 个 uin 候选
4. 对每个候选算 aes_key, 用 PR #60 的 verify_aes_key_against_all
做 AES 模板交叉验证, 唯一定位 uin
实现
----
- find_image_key_macos 重构为 dispatcher: 先方案1 (kvcomm),
失败 fallback 方案2 (候选搜索); 模板收集移到 dispatcher 共享
- 新增 helper: extract_wxid_parts, derive_xor_key_from_v2_dat,
bruteforce_uin_candidates
- 模块顶部 docstring 加方案2 算法说明 + @H3CoF6 致谢
(保留 PR #60 对 @hicccc77 的方案1 致谢)
clean-room 声明
---------------
方案2 按 issue #68 的算法描述独立实现,未引用 @H3CoF6 任何代码。
方案1 仍沿用 PR #60 实现 (其 clean-room 声明对 @hicccc77 / WeFlow
保持不变)。
健壮性细节
----------
- xor_key 反推默认 min_samples=3, 样本不足直接放弃方案2 (避免
1-2 个样本时一旦撞到非 JPG 就 lock 错 xor_key)
- wxid 后缀正则收紧为 [0-9a-fA-F]{4} (md5 hex), 非 hex 后缀直接
返回 None 而非误导用户跑空候选搜索
- 投票分歧时打印 warning, 但仍试取多数 (兼容 attach 含少量非 JPG)
- 删除重构后未用的 import glob; Counter 统一在模块顶部 import
测试
----
新增 17 个测试 (53 → 70), 全部 7.4s 内通过:
- ExtractWxidPartsTests (5)
- DeriveXorKeyFromV2DatTests (7, 含新增 below_min_samples 边界)
- BruteforceUinCandidatesTests (1, 真跑全空间金标准验证)
- FindViaBruteforceTests (3)
- DispatcherFallbackTests (1, mock 加速)
顺手修复 2 个 pre-existing 测试 fail
------------------------------------
test_account_with_4char_alnum_suffix_stripped 与
test_returns_raw_and_normalized_when_different 用 6-char 后缀
your_wxid_a1b2c3, 但 normalize_wxid 只去 4-char 后缀 (匹配真实
macOS 路径) → 测试期望与代码不一致, 长期 fail。统一改用 4-char
后缀让测试与 macOS 现实对齐。
兼容性
------
- API 不变: find_image_key_macos(db_dir) 签名 / 返回值不变
- 现有 53 个测试全部仍通过 (含 happy path / 各种返回 None 分支 /
main 短路 / 原子写)
- 真实数据验证: 在本地 macOS 微信 4.x 上方案2 端到端跑通, 结果
与方案1 完全一致
* fix: replace test fixture with synthetic uin/wxid (privacy hardening)
PR #60 测试 fixture 与 docstring 示例之前用了真实 uin (8 位十进制)
作为 golden value,并在 docstring 里把 wxid 后缀作为示例展示。虽然
单独的 uin/suffix 不直接 unlock 任何资产 (需要配合真实 wxid + 物理
访问加密文件),但行业最佳实践 (yt-dlp / openssl / Linux kernel test
fixture) 都明确要求用合成确定性值, 不绑定任何真实账号。
合成方案
--------
- uin: 12345678 (8 位, 一目了然 placeholder)
- suffix: md5("12345678")[:4] = "25d5" (派生, self-consistent)
- wxid_full 示例: your_wxid_25d5
- wxid_norm 示例: your_wxid
- aes_key_test_value: a0c093edddc98490 = md5("12345678your_wxid")[:16]
- xor_key: 0x4E (= 12345678 & 0xFF)
改动范围
--------
- tests/test_find_image_key_macos.py: 全部 fixture 改用合成值,
bruteforce 测试的 xor 也对应更新 (0x7F → 0x4E)
- find_image_key_macos.py:260 docstring 示例: 真实 wxid 字符串
替换为 placeholder
- 长 kvcomm 缓存文件名 fixture 同步合成 (避免暴露真实时间戳 / 内部 ID)
测试
----
70/70 仍通过 (7.1s), 合成 fixture self-consistent。
非范围 (历史 commit b37d440 仍含真 uin fixture)
-----------------------------------------------
按行业惯例不 force push 重写 PR history (代价: PR 显得有问题; 收益:
真 uin alone 不构成 unlock — 需配真 wxid + 物理设备)。本 commit 保证
未来 review 看到的是干净版本; 历史 commit 保留以维护 review 链完整性。
* feat: 方案2 多进程加速 (~60x speedup, 借鉴 PR #69)
吸收 @H3CoF6 在 PR #69 (https://github.com/ylytdeng/wechat-decrypt/pull/69)
的 3 个加速优化, 让方案2 fallback 从单核 ~7s 降到多核 ~0.1-1s 量级。
加速优化
--------
1. 多进程: cpu_count 个 worker 并行扫 0~2^32 候选 (multiprocessing)
2. 二进制 md5 比较: digest()[:2] 替代 hexdigest()[:4], 省 hex 转换开销
3. 内联 AES 验证 + 早停: worker 内 md5 命中 → 直接 AES cross-validate →
推 queue → 主进程 terminate 其他 worker (任一进程命中即胜, 无两 pass)
与 PR #69 的差异
----------------
- 保留 PR #60 的多模板 AES 交叉验证 (PR #69 单模板; 本实现不退化防短
magic 偶然命中的能力)
- 集成在 dispatcher 的 fallback 路径 (PR #60 双方案架构), 而非 main()
自动跑
- 保留 bruteforce_uin_candidates 单进程版本作为算法金标准 (测试 +
parallel 不可用时的 fallback)
实现细节
--------
- 模块顶层 _bruteforce_worker_chunk + _aes_template_match (multiprocessing
pickle 要求 worker 必须是 module-level 函数)
- 60s timeout + daemon=True worker (主进程异常退出时 worker 不变僵尸)
- _bruteforce_with_aes_parallel 是新生产入口
性能
----
本地 macOS 实数据验证: 多核 (M2 16 workers) ~0.1s, 单核基线 ~7s = 60x
加速。合成 fixture 命中更早, 70 测试总时长 7.4s 不变 (单进程金标准
test_real_bruteforce_against_golden 仍单跑 ~7s)。
致谢
----
方案2 加速三连 (multiprocessing + 二进制 md5 + 早停 queue) 思路源自
@H3CoF6 在 PR #69 的实现 (find_all_keys.py)。本 commit 按其算法思路
独立实现 (worker 函数 / chunk 划分 / Queue 通信 / terminate 等技术
模式是 multiprocessing 的自然结构), 未引用其源码。
* test: clean dead bruteforce mocks + add direct parallel coverage
B refactor 让 _find_via_bruteforce 不再调 bruteforce_uin_candidates,
原 mock 变成空跑 dead code。同时 _bruteforce_with_aes_parallel 之前
没有针对性单测, 覆盖只来自集成路径。
清理
----
- FindViaBruteforceTests.test_full_flow_with_mocked_bruteforce →
test_full_flow_finds_synthetic_uin (移除 dead mock + 改名反映真实行为)
- DispatcherFallbackTests.test_kvcomm_missing_falls_back_to_bruteforce
移除 dead mock (HOME patch 仍保留, 强制方案1 失败走 fallback)
新增 BruteforceParallelTests (4 个测试)
--------------------------------------
- test_worker_finds_known_uin_in_chunk: 直调 worker, 验证算法核心
- test_worker_no_match_returns_silently: 区间不含命中 → queue 保持空
- test_worker_skips_when_aes_fails: md5 命中但 AES 验证失败不入队
(防止短 magic / 单 gate 假阳)
- test_parallel_workers_1_finds_synthetic_uin: workers=1 验证 spawn +
pickle + queue 跨进程通信链路
Worker 直调 (无 process spawn) 跑 ms 级。Workers=1 spawn 测试 ~1s。
全套 74 个测试 (此前 70 + 4 新) 跑 8.5s。
设计选择
--------
- 不 mock multiprocessing.Process / Queue (会变成测 mock 库自己, 不测算法)
- multiprocessing.Queue.put 通过 feeder thread 异步刷, get_nowait() 会 race;
用 q.get(timeout=...) 给 feeder 充足时间
- 多进程 e2e 由 FindViaBruteforceTests / DispatcherFallbackTests 间接覆盖
(cpu_count workers, 真实 fixture), 这里只测函数契约避免重复 spawn 开销
343 lines
13 KiB
Markdown
343 lines
13 KiB
Markdown
# WeChat 4.x Database Decryptor
|
||
|
||
微信 4.0 (Windows、MacOS、Linux) 本地数据库解密工具。从运行中的微信进程内存提取加密密钥,解密所有 SQLCipher 4 加密数据库,并提供实时消息监听。
|
||
|
||
## 更新日志
|
||
|
||
## 防失联tg: https://t.me/wechat_decrypt
|
||
|
||
### 2025-03-03 — 富媒体内容 & 组合消息修复
|
||
|
||
- **表情包内联显示**: 自动从 emoticon.db 构建 MD5→CDN 映射,支持自定义表情(NonStore)和商店表情(Store),CDN 下载后本地缓存
|
||
- **富媒体内容解析**: 链接卡片(type 49)、文件、视频号、小程序、引用回复、位置分享等在 Web UI 中完整渲染
|
||
- **文字+图片组合消息不再丢失**: 修复同时发送文字和图片时只显示最后一条的问题(前端去重 key 增加消息类型)
|
||
- **隐藏消息检测**: 新增 `_check_hidden_messages` 机制,session.db 只保存最后一条消息摘要,现在会异步查 message DB 找回同一秒内的其他消息
|
||
- **MonitorDBCache 线程安全**: 引入 per-key 锁,防止多线程并发解密同一数据库导致文件损坏
|
||
- **Web UI 改进**: 消息气泡样式优化、群聊发送者显示、图片缩略图点击放大
|
||
|
||
## 原理
|
||
|
||
微信 4.0 使用 SQLCipher 4 加密本地数据库:
|
||
- **加密算法**: AES-256-CBC + HMAC-SHA512
|
||
- **KDF**: PBKDF2-HMAC-SHA512, 256,000 iterations
|
||
- **页面大小**: 4096 bytes, reserve = 80 (IV 16 + HMAC 64)
|
||
- **每个数据库有独立的 salt 和 enc_key**
|
||
|
||
WCDB (微信的 SQLCipher 封装) 会在进程内存中缓存派生后的 raw key,格式为 `x'<64hex_enc_key><32hex_salt>'`。三个平台(Windows / Linux / macOS)均可通过扫描进程内存匹配此模式,再通过 HMAC 校验 page 1 确认密钥正确性。
|
||
|
||
## 使用方法
|
||
|
||
### 环境要求
|
||
|
||
- Python 3.10+
|
||
- 微信 4.x
|
||
- `pip install -r requirements.txt`
|
||
|
||
Windows:
|
||
|
||
- Windows 10/11
|
||
- 微信正在运行
|
||
- 需要管理员权限(读取进程内存)
|
||
|
||
Linux:
|
||
|
||
- 64-bit Linux
|
||
- 需要 root 权限或 `CAP_SYS_PTRACE`(读取 `/proc/<pid>/mem`)
|
||
- `db_dir` 默认类似 `~/Documents/xwechat_files/<wxid>/db_storage`
|
||
|
||
macOS:
|
||
|
||
- macOS 10.15+(Apple Silicon / Intel 均可)
|
||
- 微信 4.x(macOS 版)
|
||
- Xcode Command Line Tools:`xcode-select --install`
|
||
- 需要对 `/Applications/WeChat.app` 做 ad-hoc 重签名(允许进程内存读取)
|
||
- 需要 root 权限运行扫描器
|
||
- `db_dir` 默认类似 `~/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/<hash>/Message`
|
||
|
||
### 安装依赖
|
||
|
||
```bash
|
||
pip install -r requirements.txt
|
||
```
|
||
|
||
Windows 如果遇到权限不足或全局环境不可写,可以改用:
|
||
|
||
```bash
|
||
py -m pip install --user -r requirements.txt
|
||
```
|
||
|
||
如果需要读取受保护的进程或把依赖安装到系统 Python,也可能需要以管理员身份打开终端。
|
||
|
||
### 快速开始
|
||
|
||
Windows:
|
||
|
||
```bash
|
||
python main.py
|
||
python main.py decrypt
|
||
```
|
||
|
||
Linux:
|
||
|
||
```bash
|
||
python3 main.py decrypt
|
||
```
|
||
|
||
macOS(密钥扫描用 C 版本,见下文 [macOS 数据库密钥扫描](#macos-数据库密钥扫描-wechat-4x) 章节):
|
||
|
||
```bash
|
||
# 1. 重新签名(首次及微信升级后各一次)
|
||
sudo codesign --force --deep --sign - /Applications/WeChat.app
|
||
|
||
# 2. 编译并运行扫描器
|
||
cc -O2 -o find_all_keys_macos find_all_keys_macos.c -framework Foundation
|
||
sudo ./find_all_keys_macos
|
||
|
||
# 3. 解密
|
||
python3 decrypt_db.py
|
||
```
|
||
|
||
程序会自动完成:配置检测 → 内存扫描提取密钥 → 解密。首次运行会自动检测微信数据目录并生成 `config.json`。微信只要在运行中即可,无需重启或重新登录。
|
||
|
||
如果自动检测失败(例如微信安装在非默认位置),手动创建 `config.json`:
|
||
```json
|
||
{
|
||
"db_dir": "D:\\xwechat_files\\你的微信ID\\db_storage",
|
||
"keys_file": "all_keys.json",
|
||
"decrypted_dir": "decrypted",
|
||
"wechat_process": "Weixin.exe"
|
||
}
|
||
```
|
||
|
||
Linux 版 `config.json` 示例:
|
||
|
||
```json
|
||
{
|
||
"db_dir": "/home/yourname/Documents/xwechat_files/your_wxid/db_storage",
|
||
"keys_file": "all_keys.json",
|
||
"decrypted_dir": "decrypted",
|
||
"wechat_process": "wechat"
|
||
}
|
||
```
|
||
|
||
macOS 版 `config.json` 示例:
|
||
|
||
```json
|
||
{
|
||
"db_dir": "/Users/yourname/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/<hash>/Message",
|
||
"keys_file": "all_keys.json",
|
||
"decrypted_dir": "decrypted",
|
||
"wechat_process": "WeChat"
|
||
}
|
||
```
|
||
|
||
`db_dir` 路径:Windows 可在微信设置 → 文件管理中找到;Linux 默认在 `~/Documents/xwechat_files/<wxid>/db_storage`;macOS 在 `~/Library/Containers/com.tencent.xinWeChat/.../Message`(`<hash>` 是微信随机生成的账号目录)。
|
||
|
||
### Web UI 说明
|
||
|
||
`python main.py` 启动后打开 http://localhost:5678 查看实时消息流。
|
||
|
||
- 30ms 轮询 WAL 文件变化 (mtime)
|
||
- 检测到变化后全量解密 + WAL patch (~70ms)
|
||
- SSE 实时推送到浏览器
|
||
- 总延迟约 100ms
|
||
- **图片消息内联预览**(支持旧 XOR / V1 / V2 三种 .dat 加密格式)
|
||
|
||
#### HTTP API
|
||
|
||
| 端点 | 说明 |
|
||
|------|------|
|
||
| `GET /api/history` | 最近消息列表 (JSON) |
|
||
| `GET /api/history?chat=群名` | 按群名/用户名过滤消息 |
|
||
| `GET /api/history?since=1712000000` | 增量拉取(返回该时间戳之后的消息) |
|
||
| `GET /api/history?chat=群名&since=ts&limit=100` | 参数可组合使用 |
|
||
| `GET /api/tags` | 所有联系人标签及成员 (JSON) |
|
||
| `GET /api/tags?name=同事` | 按标签名过滤 |
|
||
| `GET /stream` | SSE 实时消息推送 |
|
||
|
||
将特定群消息存到自己的数据库:监听 `/stream` 或轮询 `/api/history?chat=群名&since=上次时间戳`,写入即可。
|
||
|
||
### MCP Server (Claude AI 集成)
|
||
|
||
将微信数据查询能力接入 [Claude Code](https://claude.ai/claude-code),让 AI 直接读取你的微信消息。
|
||
|
||
```bash
|
||
pip install -r requirements.txt
|
||
```
|
||
|
||
注册到 Claude Code:
|
||
|
||
```bash
|
||
claude mcp add wechat -- python C:\Users\你的用户名\wechat-decrypt\mcp_server.py
|
||
```
|
||
|
||
或手动编辑 `~/.claude.json`:
|
||
|
||
```json
|
||
{
|
||
"mcpServers": {
|
||
"wechat": {
|
||
"type": "stdio",
|
||
"command": "python",
|
||
"args": ["C:\\Users\\你的用户名\\wechat-decrypt\\mcp_server.py"]
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
注册后在 Claude Code 中即可使用以下工具:
|
||
|
||
| Tool | 功能 |
|
||
|------|------|
|
||
| `get_recent_sessions(limit)` | 最近会话列表(含消息摘要、未读数) |
|
||
| `get_chat_history(chat_name, limit, offset, start_time, end_time)` | 指定聊天的消息记录,支持时间范围和分页 |
|
||
| `search_messages(keyword, chat_name, start_time, end_time, limit, offset)` | 统一搜索消息;支持全库、单个聊天对象、多个聊天对象、时间范围和分页 |
|
||
| `get_contacts(query, limit)` | 搜索/列出联系人 |
|
||
| `get_contact_tags()` | 列出所有联系人标签及成员数量 |
|
||
| `get_tag_members(tag_name)` | 获取指定标签下的所有联系人,支持模糊匹配 |
|
||
| `get_new_messages()` | 获取自上次调用以来的新消息 |
|
||
| `get_voice_messages(chat_name)` | 列出某会话所有语音消息(local_id、时长、时间戳) |
|
||
| `decode_voice(chat_name, local_id)` | 解码 SILK 语音为本地 WAV 文件 |
|
||
| `transcribe_voice(chat_name, local_id)` | 转录语音为文字(自动检测语言) |
|
||
|
||
前置条件:需要先运行 `python main.py` 或 `python find_all_keys.py` 完成密钥提取。
|
||
|
||
说明:`search_messages` 的 `limit` 最大为 `500`;`get_chat_history` 支持更大的 `limit`,但消息很多时仍建议配合 `offset` 分页读取。
|
||
|
||
#### ⚠️ 语音转录隐私
|
||
|
||
`transcribe_voice` 默认使用本地 Whisper(CPU),数据全程留在本机。`transcribe_chat.py` 批量 CLI 共享同一份配置。
|
||
|
||
如需切换到 OpenAI Whisper API(更快、Mandarin 精度更高),在 `config.json` 中:
|
||
|
||
```json
|
||
{
|
||
"transcription_backend": "openai",
|
||
"openai_api_key": "sk-..."
|
||
}
|
||
```
|
||
|
||
启用后**语音文件会上传至 OpenAI 服务器**进行转录。需 `pip install openai`。
|
||
|
||
- 成本:约 $0.006 / 分钟(OpenAI 计价)
|
||
- 文件 > 25MB 在上传前被拒绝(OpenAI 上限)
|
||
- 首次启用云后端时 stderr 会打一行警告
|
||
- `transcription_backend` 或 `openai_api_key` 任一缺失时静默回退 local
|
||
- 切换后端后,旧缓存条目(backend 不匹配)会自动重新转录
|
||
|
||
**[查看使用案例 →](USAGE.md)**
|
||
|
||
### 图片解密 (V2 格式)
|
||
|
||
微信 4.0 (2025-08+) 的 .dat 图片文件使用 AES-128-ECB + XOR 混合加密 (V2 格式)。AES 密钥的获取方式因平台而异:
|
||
|
||
**Windows / Linux**(从进程内存扫描):
|
||
|
||
```bash
|
||
# 1. 在微信中打开查看 2-3 张图片(点击看大图)
|
||
# 2. 立即运行密钥提取(持续监控版):
|
||
python find_image_key_monitor.py
|
||
|
||
# 或单次扫描版:
|
||
python find_image_key.py
|
||
```
|
||
|
||
> AES 密钥仅在微信查看图片时临时加载到内存中。如果扫描未找到密钥,请先在微信中查看几张图片,然后立即重新运行脚本。
|
||
|
||
**macOS**(从磁盘 kvcomm 缓存派生,**无需扫描进程内存**):
|
||
|
||
```bash
|
||
python find_image_key_macos.py
|
||
```
|
||
|
||
无需提前在微信中查看图片,无需 root 权限,无需重签名。脚本会扫描 `~/Library/Containers/com.tencent.xinWeChat/.../app_data/net/kvcomm/key_*.statistic` 文件名提取派生码 `code`,配合 `db_dir` 路径里的 wxid,按 `aes_key = MD5(str(code) + cleaned_wxid)[:16]` / `xor_key = code & 0xFF` 的规则推算密钥,并用一张 V2 `_t.dat` 缩略图做 AES 模板验证。解决 [issue #23](https://github.com/ylytdeng/wechat-decrypt/issues/23)(macOS 内存扫描器 197K 候选全部失败)。
|
||
|
||
派生算法的发现归功于 [@hicccc77](https://github.com/hicccc77) 在 issue #23 的[评论](https://github.com/ylytdeng/wechat-decrypt/issues/23),参考实现见其 [WeFlow 项目](https://github.com/hicccc77/WeFlow/blob/dev/electron/services/keyServiceMac.ts)(CC BY-NC-SA 4.0)。本仓库的 `find_image_key_macos.py` 是基于该算法的独立 Python clean-room 实现。
|
||
|
||
密钥会自动保存到 `config.json` 的 `image_aes_key` / `image_xor_key` 字段。之后 `monitor_web.py` 启动时会自动加载,图片消息将显示内联预览。
|
||
|
||
## 文件说明
|
||
|
||
| 文件 | 说明 |
|
||
|------|------|
|
||
| `main.py` | **一键启动入口** — 自动配置、提取密钥、启动服务 |
|
||
| `config.py` | 配置加载器(自动检测微信数据目录) |
|
||
| `find_all_keys.py` | 平台分发入口(Windows / Linux) |
|
||
| `find_all_keys_windows.py` | Windows 版内存扫描提 key |
|
||
| `find_all_keys_linux.py` | Linux 版内存扫描提 key |
|
||
| `decrypt_db.py` | 全量解密所有数据库 |
|
||
| `mcp_server.py` | MCP Server,让 Claude AI 查询微信数据 |
|
||
| `monitor_web.py` | 实时消息监听 (Web UI + SSE + 图片预览) |
|
||
| `monitor.py` | 实时消息监听 (命令行) |
|
||
| `decode_image.py` | 图片 .dat 文件解密模块 (XOR / V1 / V2) |
|
||
| `find_image_key.py` | 从微信进程内存提取图片 AES 密钥(Windows / Linux) |
|
||
| `find_image_key_monitor.py` | 持续监控版密钥提取(Windows / Linux,推荐) |
|
||
| `find_image_key_macos.py` | macOS 版图片密钥派生(从磁盘 kvcomm 缓存推算,无需扫描内存) |
|
||
| `latency_test.py` | 延迟测量诊断工具 |
|
||
| `find_all_keys_macos.c` | macOS 版内存密钥扫描器 (C, Mach VM API) |
|
||
|
||
## 技术细节
|
||
|
||
### WAL 处理
|
||
|
||
微信使用 SQLite WAL 模式,WAL 文件是**预分配固定大小** (4MB)。检测变化时:
|
||
- 不能用文件大小 (永远不变)
|
||
- 使用 mtime 检测写入
|
||
- 解密 WAL frame 时需校验 salt 值,跳过旧周期遗留的 frame
|
||
|
||
### 图片 .dat 加密格式
|
||
|
||
微信本地图片 (.dat) 有三种加密格式:
|
||
|
||
| 格式 | 时期 | Magic | 加密方式 | 密钥来源 |
|
||
|------|------|-------|---------|---------|
|
||
| 旧 XOR | ~2025-07 | 无 | 单字节 XOR | 自动检测 (对比 magic bytes) |
|
||
| V1 | 过渡期 | `07 08 V1 08 07` | AES-ECB + XOR | 固定 key: `cfcd208495d565ef` |
|
||
| V2 | 2025-08+ | `07 08 V2 08 07` | AES-128-ECB + XOR | 从进程内存提取 |
|
||
|
||
V2 文件结构: `[6B signature] [4B aes_size LE] [4B xor_size LE] [1B padding]` + `[AES-ECB encrypted] [raw unencrypted] [XOR encrypted]`
|
||
|
||
### 数据库结构
|
||
|
||
解密后包含约 26 个数据库:
|
||
- `session/session.db` - 会话列表 (最新消息摘要)
|
||
- `message/message_*.db` - 聊天记录
|
||
- `contact/contact.db` - 联系人
|
||
- `media_*/media_*.db` - 媒体文件索引
|
||
- 其他: head_image, favorite, sns, emoticon 等
|
||
|
||
## macOS 数据库密钥扫描 (WeChat 4.x)
|
||
|
||
macOS 版微信 4.x 使用 SQLCipher 4 加密本地数据库,密钥格式为 `x'<64hex_key><32hex_salt>'`。C 版扫描器通过 Mach VM API 扫描微信进程内存提取密钥。
|
||
|
||
### 前置条件
|
||
|
||
- macOS (Apple Silicon / Intel)
|
||
- WeChat 4.x (macOS 版)
|
||
- Xcode Command Line Tools: `xcode-select --install`
|
||
- 微信需要 ad-hoc 签名(或安装了防撤回补丁):
|
||
`sudo codesign --force --deep --sign - /Applications/WeChat.app`
|
||
|
||
### 编译和使用
|
||
|
||
```bash
|
||
# 编译
|
||
cc -O2 -o find_all_keys_macos find_all_keys_macos.c -framework Foundation
|
||
|
||
# 运行(自动查找微信进程、扫描内存、匹配 DB salt)
|
||
sudo ./find_all_keys_macos
|
||
|
||
# 或指定 PID
|
||
sudo ./find_all_keys_macos <pid>
|
||
```
|
||
|
||
输出 `all_keys.json`,格式兼容 `decrypt_db.py`,可直接用于解密:
|
||
|
||
```bash
|
||
python3 decrypt_db.py
|
||
```
|
||
|
||
## 免责声明
|
||
|
||
本工具仅用于学习和研究目的,用于解密**自己的**微信数据。请遵守相关法律法规,不要用于未经授权的数据访问。
|