macOS WeChat 4.1.7: 图片AES密钥提取失败 — 198K候选全部无效

[sunyan034-cmd]

环境

• macOS 15.5 (Apple Silicon M4 Pro)
• WeChat 4.1.7 (ad-hoc signed)
• V2 .dat 文件: 36,162 个

问题

在 macOS 上无法提取图片 AES 密钥。穷举了所有方法，均未成功。

已尝试的方法

方法1: find_image_key_macos.c (ASCII 16-char 扫描)

• 编译运行，扫描 WeChat 进程 (PID varies)
• 提取到 197,857 个 16字符 ASCII 字母数字候选
• 用每个候选尝试解密最近的 V2 .dat 文件（5个大文件 96KB-431KB）
• 验证: 严格检查 JPEG (JFIF/EXIF marker)、PNG (8字节签名)、GIF、WebP
• 结果: 全部失败

方法2: find_image_key.c (16字节对齐二进制扫描)

• Round 1 完成，找到约 87 个候选
• 能产生 ff d8 ff 开头（通过 is_image_magic()），但 PIL Image.verify() 全部损坏
• is_image_magic() 首块检查偶然命中，实际 key 不对

方法3: find_image_key.c --deep (字节级扫描)

• 逐字节扫描，找到不对齐地址的候选
• 同样全部未通过 PIL 验证

关键观察

1. aes_size 始终为 1024
2. 409 个不同的 CT block 0 pattern
3. Pattern Just had a try #1 覆盖 12,918 个文件（35.7%）= 当前 session
4. 数据库密钥提取完全正常
5. 测试时正在查看图片（最新 .dat 修改时间 0 分钟前）

疑问

1. find_image_key.c / find_image_key_macos.c 是否有在 macOS 上成功提取过图片 key？
2. macOS 是否用了不同的 key 存储方式？（Security framework、Keychain、或非原始16字节形式）
3. 是否有其他 macOS 用户成功解密过 V2 图片？

参考

• 相关 issue: mac下图片key扫描耗时较久 #21 (macOS 扫描耗时) — 该用户同样扫了好久没出来

感谢优秀项目！数据库解密和消息监控在 macOS 上完美运行 🎉

[magic8ytes]

我在intel的macOS 15.7是这样的，跑了两天没出来，我都想自己去debug内存了，但是嫌时间成本高！
另外你M4 pro 芯片居然还跑macOS 15？

[ylytdeng]

感谢非常详细的测试报告！你的排查很彻底。

从你的测试结果来看，问题可能不是扫描逻辑的 bug，而是 WeChat 4.1.7 在 macOS 上改变了图片密钥的存储方式：

1. 数据库密钥提取正常 → mach_vm_read 和内存扫描本身没问题
2. 197K 候选全部无效 → 密钥可能不以原始 16 字节 AES key 形式存在于进程内存中
3. is_image_magic() 偶然命中但实际 key 不对 → 纯概率碰撞（JPEG magic FF D8 FF 只有 3 字节约束）

可能的原因：

• WeChat 4.1.7 可能改用 密钥派生（如从 master key + salt 派生图片密钥），内存中只有派生前的 key
• 密钥可能存储在 macOS Keychain 或通过 Security framework 管理，不直接暴露在进程堆内存中
• 密钥可能在使用后立即清零（secure memory），扫描时已经不在了

关于 "aes_size 始终为 1024" 的观察：这个很关键。如果所有文件的 aes_size 都是 1024，说明加密方式可能是统一的，也许可以从已知明文（比如已知图片的原始数据）反推密钥。

@bbingz 这个问题比较关键——目前有两位 macOS 用户（M4 Pro + Intel，WeChat 4.1.7）都无法提取图片密钥。find_image_key.c 在你的环境上测试时用的是哪个 WeChat 版本？4.1.7 是否改了图片密钥的存储机制？

[ylytdeng]

没mac没法验证了

[bbingz]

我认真对了一下当前仓库里的 find_image_key.c / decrypt_images.c 逻辑，感觉现在还不能据此下结论说 “WeChat
4.1.7 在 macOS 上改了图片 key 存储方式”。更大的问题，可能在于 验证方法 和 扫描覆盖范围。

find_image_key.c 的目标不是找“一个全局 AES key”，而是建立 CT block 0 -> AES key 的映射。V2
图片通常不是一个 key 解所有 .dat，而是不同 pattern 对应不同 key。
所以如果验证方式是“拿一个候选 key 去解任意最近 5 个 .dat 文件”，那即使这个 key
本身是真的，也会因为这些文件属于别的 pattern 而被误判为失败。

更合理的验证方式应该是：

1. 先按 .dat 文件头后面的第一个 16-byte ciphertext block（CT block 0）分组；
2. 候选 key 只拿去验证它命中的那个 pattern 的 sample file；
3. 最后把结果写成 image_keys.json 的 ct_hex -> key_hex 映射，再交给 decrypt_images.c 批量验证。

另外，macOS 上图片 key 不一定是 ASCII，也可能是二进制，甚至在非 16-byte 对齐位置。当前扫描器的覆盖大致是：

• Method 1：16-byte 对齐的原始二进制 key
• Method 2：未对齐的 ASCII / hex-like key
• --deep：只对 高优先级未解 pattern 做逐字节扫描

也就是说，--deep 并不是把 409 个 pattern 全都逐字节扫了一遍；如果很多 pattern
没进优先队列，结果看起来像“全扫过了”，实际并没有覆盖到。

还有一点：我后面其实又修了几次 find_image_key.c / decrypt_images.c，包括：

• Method 2 的字符集收窄
• verify_key() 的 AES 密文长度 / 文件大小校验
• fallback key 逻辑

但都不影响找图片 Key 的

环境

• macOS 15.5 (Apple Silicon M4 Pro)
• WeChat 4.1.7 (ad-hoc signed)
• V2 .dat 文件: 36,162 个

问题

在 macOS 上无法提取图片 AES 密钥。穷举了所有方法，均未成功。

已尝试的方法

方法1: find_image_key_macos.c (ASCII 16-char 扫描)

• 编译运行，扫描 WeChat 进程 (PID varies)
• 提取到 197,857 个 16字符 ASCII 字母数字候选
• 用每个候选尝试解密最近的 V2 .dat 文件（5个大文件 96KB-431KB）
• 验证: 严格检查 JPEG (JFIF/EXIF marker)、PNG (8字节签名)、GIF、WebP
• 结果: 全部失败

方法2: find_image_key.c (16字节对齐二进制扫描)

• Round 1 完成，找到约 87 个候选
• 能产生 ff d8 ff 开头（通过 is_image_magic()），但 PIL Image.verify() 全部损坏
• is_image_magic() 首块检查偶然命中，实际 key 不对

方法3: find_image_key.c --deep (字节级扫描)

• 逐字节扫描，找到不对齐地址的候选
• 同样全部未通过 PIL 验证

关键观察

1. aes_size 始终为 1024
2. 409 个不同的 CT block 0 pattern
3. Pattern Just had a try #1 覆盖 12,918 个文件（35.7%）= 当前 session
4. 数据库密钥提取完全正常
5. 测试时正在查看图片（最新 .dat 修改时间 0 分钟前）

疑问

1. find_image_key.c / find_image_key_macos.c 是否有在 macOS 上成功提取过图片 key？
2. macOS 是否用了不同的 key 存储方式？（Security framework、Keychain、或非原始16字节形式）
3. 是否有其他 macOS 用户成功解密过 V2 图片？

参考

• 相关 issue: mac下图片key扫描耗时较久 #21 (macOS 扫描耗时) — 该用户同样扫了好久没出来

感谢优秀项目！数据库解密和消息监控在 macOS 上完美运行 🎉

[hicccc77]

可以看看我的这个，目前测试秒获取且无任何报错~

[huanghe]

可以看看我的这个，目前测试秒获取且无任何报错~
你这个核心模块开源吗