[方案/征求合并] macOS Apple Silicon 通用数据库密钥提取：受控临时重签、登录时捕获与自动恢复

[coderscsy]

macOS Apple Silicon 数据库密钥提取集成提案

上游背景

这是对 #88（macOS 无法稳定获取密钥）的已验证方案提案，也吸收了 #87 暴露的“运行时改动已签名 App Bundle 会破坏后续启动校验”问题。

现有正式腾讯签名微信在部分 Mac 上无法被捕获组件附加，表现为 PROCESS_ACCESS_DENIED。本地派生版本已经完成一次真实端到端验证；希望先征求维护者对集成边界和安全模型的意见，再整理最小 PR。

目标

为 WeChatDataAnalysis 提供一个不依赖旧密钥缓存、可验证、失败可恢复的 macOS Apple Silicon 密钥提取流程。工具只处理当前用户有权访问的本机微信数据，不联网、不上传密钥或聊天内容。

本提案解决的是正式腾讯签名微信进程无法被现有捕获组件稳定附加的问题。它不是绕过账号登录：用户必须亲自在手机端确认登录，并在受控流程中重新登录同一账号。

已验证范围

• Apple Silicon Mac；
• 微信 4.x 沙盒数据目录；
• 微信 4.1.12 的一次端到端验证；
• 使用活动数据库首页完成 WCDB 密钥密码学校验；
• 成功、取消、捕获超时和异常路径均恢复腾讯官方签名微信。
• 定向测试 57 项通过，本地派生分支完整测试 836 项通过；
• 发布审计确认安装包不包含数据库、日志、偏好、密钥缓存、个人绝对路径或本地证书材料。

Intel Mac、未来微信版本以及多套并行安装仍需单独验收，不能从 Apple Silicon 的结果推断为已支持。

根因

1. 正式腾讯签名微信受到 macOS 进程保护，直接附加可能返回 PROCESS_ACCESS_DENIED。
2. 微信 4.x 的活动数据库位于 Documents/app_data/xwechat_files；同账号可能残留 Documents/xwechat_files 旧副本。
3. 如果用旧副本首页的 salt 校验本次登录候选，正确密钥也会被拒绝，最终表现为固定时长超时。
4. ad-hoc 签名的应用每次重建都会改变指定要求，macOS 的完全磁盘访问授权可能失效。

建议状态机

1. 环境检查

• 微信路径必须解析为明确的 .app，不接受宽泛目录或通配符；
• 校验当前微信为腾讯官方签名；
• 验证 LLDB、Apple Silicon 架构、工作目录可写；
• 微信 4.x 只选择 app_data/xwechat_files 活动库；权限不足时立即报错，不回退旧副本；
• 读取目标数据库首页，拒绝明文 SQLite、短文件和不可读文件。

2. 准备和可恢复备份

• 正常退出微信；
• 在同一 APFS 卷创建写时复制工作副本或恢复槽；
• 保存官方版本号、构建号、CDHash 和备份位置；
• 重签只发生在受控工作副本；
• 原版和工作副本通过同卷原子换位，避免直接修改最近启动且受保护的 bundle；
• 所有路径和状态写入当前用户私有目录，权限为 0700/0600。

3. 首次登录与断点预检

• 启动临时签名微信，让用户正常登录并进入聊天主界面；
• LLDB 短暂附加，解析系统 PBKDF2 断点和按模块 UUID 管理的内部返回断点；
• 只验证断点位置可执行，随后立即分离；
• 预检无可用断点时停止，不要求用户退出账号。

4. 重新登录时实时捕获

• 用户先在未监测状态退出到二维码页；
• 启动 LLDB 监测后，再由用户扫码并在手机确认登录；
• 通用路径监测 CCKeyDerivationPBKDF，仅接受符合 WCDB 参数形状的调用；
• 内部返回断点作为按微信模块 UUID 显式登记的备用路径，未知版本不猜偏移；
• 先读取并匹配目标数据库 salt，再读取 32 字节候选；
• 候选必须通过目标数据库首页 HMAC 校验才算成功。

5. 保存和恢复

• 只保存已经由活动数据库验证的 32 字节密钥；
• 密钥文件权限为 0600，安装包、日志和 Issue 不包含密钥；
• 无论成功、取消、超时还是异常，都关闭临时微信并原子恢复官方 bundle；
• 恢复后再次执行深度代码签名校验，确认 Tencent Developer ID 和 Team ID；
• 状态文件只在恢复完成后删除，应用重启时优先处理未完成恢复。

诊断要求

超时不能只显示“未获取密钥”。建议记录不含敏感内容的计数：

• PBKDF2 断点触发次数；
• 参数形状匹配次数；
• 目标数据库 salt 命中次数；
• 内部返回断点触发次数；
• 候选数据库校验失败次数。

这样可以区分“没有触发重新登录计算”“选错账号或数据库”“断点版本不兼容”和“候选布局变化”。日志不得打印候选密钥、数据库首页或用户路径。

通用化与签名

• 公共 Release 应由项目现有 Developer ID Application 证书签名并公证；
• 源码本机构建可以显式使用一张长期固定的本地自签名代码证书；
• 不能把某个开发者的本地证书、私钥或签名元数据放进仓库或安装包；
• 默认 ad-hoc 构建仅适合一次性开发测试，升级后可能需要重新授予隐私权限；
• 固定 bundle identifier 和固定指定要求可让完全磁盘访问权限在同一签名身份升级时延续。

建议的上游集成边界

1. 将捕获状态机放在 Python 后端的 macOS 密钥服务中；
2. Electron 仅负责展示步骤、打开系统设置和退出确认，不直接处理密钥；
3. 复用现有账号检测结果，但在微信 4.x 强制规范化到活动 app_data 数据库；
4. 密钥写入现有受限 key store，再由现有解密流程消费；
5. 保留项目现有私有原生运行时作为独立能力，纯 LLDB 流程不应静默下载或执行未知二进制；
6. 未知微信模块 UUID 时只保留系统 PBKDF2 路径，并给出明确兼容性诊断。

安全边界

• 仅处理用户本人或已明确授权的数据；
• 不支持远程附加、后台静默捕获、绕过手机确认或批量账号操作；
• 不修改微信网络行为，不注入长期驻留代码；
• 不把重签微信作为日常客户端；
• 每次开始前验证官方备份，每次结束后验证官方恢复；
• 不把聊天数据库、媒体、日志、密钥、个人路径或证书私钥提交到 Git。

最小验收清单

• 活动库和旧库并存时始终选择活动库；
• 完全磁盘访问缺失时立即失败且不改动微信；
• 断点预检失败时不要求退出账号；
• 登录捕获成功后可以解开当前活动数据库；
• 使用错误账号登录时不会保存候选；
• 超时、取消、应用崩溃和系统重启后都能恢复官方微信；
• 恢复后的微信通过 codesign --verify --deep --strict；
• 发布审计确认包内没有数据库、日志、偏好、密钥缓存、个人绝对路径和本地证书材料；
• Apple Silicon 的单元测试、打包校验和一次真实端到端验证全部通过。

如果维护者认可这个状态机和临时重签边界，可以继续按上游当前目录结构拆成一个最小、可审查的 PR，并把微信版本/模块 UUID 兼容表与回归测试分开维护。

[2977094657]

方向原则上可以继续评审，请按正文边界提交最小 Draft PR，并附可复现测试、Apple Silicon 真实端到端记录、异常恢复验证及发布包审计结果

[coderscsy]

已按要求提交最小 Draft PR：#103。PR 保留现有 macOS helper 和默认 UI/API，只提交可恢复的 LLDB 捕获后端、48 项可复现定向测试、Apple Silicon 真实端到端脱敏记录、异常恢复矩阵与发布包审计脚本/结果。未提交数据库、密钥、日志、本机路径、证书或二进制，敬请按 Issue 正文边界评审。

[Souseohyun]

在 Apple Silicon (M 系列) / macOS 26 / 微信 4.1.13 (build 269578) 上实测了本 PR 的 clone 方案,反馈两个问题,供开源社区大家参考。

问题一:clone 副本在登录时静默闪退

前置阶段全部正常:prepare 成功克隆容器并起了 WeChat Debug - WCDA 副本,matched_salt_count=21;preflight 也通过,pbkdf_locations=1、ready_for_monitoring=True。

问题出在 capture 阶段:输入管理员密码授权、手机端点击确认登录后,debug 副本没有进入主界面就直接闪退,脚本随后一直停在 capture 阶段等待直到超时。

关键困难是抓不到任何日志定位死因:

~/Library/Logs/DiagnosticReports/ 下没有任何 WeChat 相关的崩溃报告(.ips),说明它不是 crash,而是被干净地终止/主动退出;
闪退前屏幕没有弹出任何提示框(没有"已损坏/无法验证开发者"之类);
现象稳定复现。

推测是重签的 debug 副本在登录流程中触发了微信自身的完整性/签名自检后主动退出,但由于没有日志无法确证。如果作者能在 capture 阶段加一些针对副本退出原因的日志捕获(比如监听副本进程的退出码/信号),会更容易定位这类问题。

问题二(可能更关键):4.1.13 的 PBKDF 迭代轮数是 2,与当前断点过滤条件不符

因为 clone 方案走不通,我改用"对正版微信 ad-hoc 重签 + 关闭 SIP + lldb 附加已登录进程"的方式抓密钥,复用了本 PR 的 build_lldb_salt_capture_script 逻辑。发现一个版本差异:

本 PR 的 shape 过滤条件要求 rounds==256000,但在 4.1.13 上,CCKeyDerivationPBKDF 实际是以 rounds=2 被调用的(其余 algorithm=2 / password_len=32 / salt_len=16 / prf=5 均与预期一致)。因此所有调用都因 rounds 不匹配被过滤,pbkdf_shape_hits 恒为 0,抓不到密钥。

进一步观察:rounds=2 这些调用的 password 参数(x1 指向的 32 字节)本身就是已解出的数据库主密钥——微信在做页 HMAC 子密钥派生时把主密钥当作输入传入。据此直接抓取 x1 的 32 字节,即为可用的 WCDB 主密钥,最终在本项目主程序的手动输入密钥功能中验证解密成功。

所以对 4.1.x 较新版本,建议:要么放宽/参数化 rounds 过滤,要么直接在 rounds 较小的 HMAC 派生调用处抓取 password 作为主密钥候选,再用目标库首页 HMAC 校验。

环境信息汇总:Apple Silicon,macOS 26,微信 4.1.13 build 269578,SIP 已关闭。

补充:一条绕过 clone 闪退的替代路径(供参考,非替代方案)

既然 clone 副本在登录时闪退且难以定位,我实测了另一条思路,在本机跑通了。核心区别是不重签副本、也不做二次登录,而是直接抓稳定运行的正版微信:

关闭 SIP(csrutil disable),解除内核对 task_for_pid 的限制;
对正版微信做 ad-hoc 重签去掉 hardened runtime:sudo codesign --force --deep --sign - /Applications/WeChat.app;
正常启动并登录微信,进入主界面;
lldb 附加到这个已登录的进程,在 CCKeyDerivationPBKDF 下断点,在微信触发数据库解密时抓 rounds=2 调用的 password(即主密钥)。

和 clone 方案相比的权衡:

代价:需要关闭 SIP,且正版微信被 ad-hoc 重签(签名从官方变为 ad-hoc,重装即可恢复);安全性上不如 clone 方案"干净"。
好处:没有一次性副本,因此不存在副本登录闪退问题;而且抓取发生在微信稳定登录之后,时序宽松,不用抢"登录瞬间"。

一个实操注意点:微信会缓存已建立的数据库连接,附加后若只点开已打开过的会话不会触发新的密钥派生。最可靠的触发方式是重启微信、在其启动加载数据的过程中附加抓取,启动解密必然会调用一次 PBKDF。

所以这条路可以作为 clone 方案之外的兜底——对愿意接受关 SIP、且只需抢救自己数据的用户,它绕过了当前 clone 方案最脆弱的登录闪退环节。当然,如果 clone 方案的闪退能被修复,它无需关 SIP 的优势仍然更适合作为默认路径。

[coderscsy]

感谢这份非常具体的 4.1.13 build 269578 实测，两个问题都确认有处理价值。

关于 rounds=2：现有 Draft 的 rounds == 256000 严格过滤确实会漏掉你观察到的页 HMAC 子密钥派生调用。修复不会简单放开 rounds，而是只接受两个明确 profile：

• rounds=256000：salt 必须精确等于目标数据库首页 salt；
• rounds=2：salt 必须精确等于目标数据库 salt 逐字节异或 0x3A 后的 HMAC salt，此时读取 32 字节 password 作为数据库主密钥候选；
• 两条路径最终都必须通过所选目标数据库首页 HMAC 校验，其他 rounds、错误 salt 或未通过验真的候选全部拒绝且不保存。

关于 clone 副本静默退出：捕获脚本已补进程结束诊断，在 process continue 返回后记录非敏感的 PID、LLDB 进程状态、退出码和截断后的退出原因；副本提前结束时返回专用错误，不再继续等待到普通超时。诊断同时保留 PBKDF2 调用数、两种 rounds 命中数、salt 命中数和候选拒绝数，但不会打印候选密钥、数据库首页或用户路径。

对应的两项回归已经加入，本地当前定向测试结果为 50 passed in 1.21s。兼容文档也会明确区分：4.1.13 build 269578 的 rounds=2 来自社区实测，逻辑回归已覆盖，但 clone 登录成功路径仍需在该 build/机器上复测，不能提前宣称完全兼容。

关闭 SIP 并重签正式微信的路径不会作为默认方案或合并前提；它的安全代价过高，只保留为社区实验背景，不写入正式操作引导。等更新进入 #103 后，如果方便，希望你用相同环境复测一次并反馈新的退出状态诊断。