WeChat 4.1+ key extraction: root cause + solution (PBKDF2 passphrase derivation)

[TANGandXUE]

Problem

WeChat 4.1+ (Linux/macOS) no longer caches raw database encryption keys in the x'<64hex_key><32hex_salt>' format in process memory. This breaks the memory scanning approach used by this project and all similar tools.

Related issues: #49, jackwener/wx-cli#30, Thearas/wechat-db-decrypt-macos#9

Root Cause

We performed exhaustive analysis:

• 387 million 16-byte-aligned HMAC brute-force candidates across all 20 WeChat processes → 0 hits
• Raw database salt bytes found in ephemeral subprocesses (alive for seconds, then exit)
• The x'<hex>' patterns in main process memory contain different salts — they are not the database keys

The actual mechanism: WeChat 4.1+ stores a passphrase (not raw key) in memory. The enc_key is derived via:

enc_key = PBKDF2-SHA512(passphrase, db_salt, iterations=256000, dklen=32)

This is consistent with SQLCipher's standard PRAGMA key behavior — the passphrase is passed to sqlite3_key(), and SQLCipher internally derives the raw key. Previous versions cached the post-derivation raw key in x'<hex>' format (which skips PBKDF2). Version 4.1+ stopped doing that.

Solution

ELF Static Analysis + GDB Breakpoint + PBKDF2 Derivation

1. Auto-locate breakpoint via ELF analysis

Search .rodata for com.Tencent.WCDB.Config.Cipher, trace LEA RSI xrefs in .text, find function head. This gives the breakpoint virtual address automatically for any WeChat version — no manual reverse engineering needed.

Verified offsets:

• WeChat 4.1.1.4 Linux x86_64: 0x673A830
• WeChat 4.1.0.10: 0x658FC90
• WeChat 4.1.0.16: 0x6586C90

2. GDB breakpoint capture

Attach GDB to WeChat, set breakpoint, user re-logs in, read passphrase from *(void**)($rsi+8) (32 bytes). Detach immediately.

3. PBKDF2 derivation

For each database file, read its 16-byte salt from page 1, derive:

enc_key = hashlib.pbkdf2_hmac("sha512", passphrase, salt, 256000, dklen=32)

Result: 23/23 databases verified successfully on WeChat 4.1.1.4 Linux.

4. Caching

Save passphrase to disk (chmod 600). On subsequent runs, derive keys from saved passphrase — no GDB needed. If keys file already exists and validates, skip derivation entirely (instant startup).

Standalone Tool

We open-sourced this as: https://github.com/TANGandXUE/wcdb-key-tool

Single Python file, zero third-party dependencies (uses ctypes for libcrypto), auto-adapts to new versions.

Suggested Integration

The key change needed in find_all_keys_linux.py:

1. After memory scan finds 0 matching keys, try loading saved passphrase + PBKDF2 derivation
2. If no saved passphrase, fall back to GDB capture flow
3. Add elf_analyzer module for auto breakpoint offset detection

Happy to submit a PR if there's interest in integrating this approach.

[ylytdeng]

这是颠覆性的研究，非常感谢！ 🙏 387M HMAC 暴力 → 0 hits 的实验设计非常扎实，PBKDF2 派生模型完全解释了为什么 #49 / #27 / #26 等长期 issue 没法解决。

关于平台覆盖的几个澄清

标题写的是 "Linux/macOS"，想确认下：

1. Windows 行为

我昨天用 Windows 4.1.9.30 跑 `find_all_keys.py`：

```
扫描完成: 5.1s, 5 个进程, 144 hex 模式
结果: 24/27 salts 找到密钥（3 个未匹配是惰性加载没激活的 db）
decrypt_db.py 成功解出所有 24 个
```

也就是说 Windows 4.1.x 似乎还在用 raw key 缓存格式？或者你的研究里也覆盖了 Windows 但行为不同？

2. macOS 行为

我们 macOS 用 `find_all_keys_macos.c`（C 版扫描器）扫的也是 raw key hex pattern。对 4.0.x 工作但 4.1.7+ 报告失败（issue #23）。你的 PBKDF2 方案理论上对 macOS 也成立？

3. ELF analyzer 的跨平台性

你提到 `.rodata` 搜 `com.Tencent.WCDB.Config.Cipher` + LEA RSI xref 自动定位 breakpoint，这套方法：

• macOS 上需要换成 Mach-O 解析吗？
• Windows 上 PE 解析？或者 Windows 不需要这套方案（如果上面 Just had a try #1 确认 Windows 还能扫 raw key）？

强烈欢迎 PR 集成

非常欢迎你提 PR，建议路径（如果你已经有规划无视）：

1. `find_all_keys.py` 顶层 dispatcher 加 fallback 链：内存扫描 → 失败时 → 加载已保存 passphrase + PBKDF2 → 仍失败 → GDB 流程
2. 新增 `elf_analyzer.py` 模块做自动 breakpoint 检测
3. passphrase 缓存文件位置约定（建议 `~/.config/wechat-decrypt/passphrase` 或 `all_keys.json` 同目录），权限 `0o600`
4. macOS 走 `lldb` 而不是 GDB（macOS 不带 GDB），并复用我们已有的 codesign + `get-task-allow` entitlement 文档（参考 `docs/bugfix/mac-deploy-issues.md` 里 `task_for_pid failed: 5` 那段）
5. 至少 1 个测试覆盖 PBKDF2 derive 的金标准 vector

我们项目最近合并节奏比较快（btc-z / Belugary / lurui1997 都在贡献），review 周转一般 1-2 天内。

`wcdb-key-tool` 仓库我会去看一下。再次感谢这个研究！