QQ聊天记录数据库解密全平台实战：从 wrapper.node 定位到密钥提取与 SQLCipher 解锁

【免费下载链接】qq-win-db-key全平台 QQ 聊天数据库解密项目地址: https://gitcode.com/gh_mirrors/qq/qq-win-db-key

聊到 QQ 数据库解密，很多人第一反应是"这是黑客才碰的东西"。但真实场景往往朴素得多：换手机、重装系统、清理缓存之后，发现自己多年的聊天记录被锁在了一堆.db文件里，官方导出功能要么只支持 PC 端、要么格式受限。本文要介绍的qq-win-db-key项目，就是一套覆盖 Windows、Android、iOS、macOS、Linux 五大平台的 QQ 数据库解密工具集——它不修改 QQ 安装包、不注入任何恶意逻辑，只做一件事：在登录过程中"借"出数据库密钥，再交给 SQLCipher 去解锁。接下来，我会带你从原理到实操完整走一遍。

一、先弄懂三件事：数据在哪、密钥在哪、突破口是什么

在敲任何命令之前，先建立正确的认知模型。这套方案能成立，靠的是三个环环相扣的事实。

第一，数据躺在 SQLCipher 加密的 SQLite 文件里。QQ NT 版（包括新版桌面端和移动端）的聊天记录、账号资料都存储在本地数据库中，但这些.db文件不是普通的 SQLite，而是经过 SQLCipher 加密的。SQLCipher 是 SQLite 的加密分支，没有密钥，你用任何数据库工具打开都只会看到一堆乱码。

第二，密钥由内存中的关键函数"保管"。SQLCipher 的解密入口是sqlite3_key_v2这个 C 接口（QQ 内部封装为nt_sqlite3_key_v2）。每次登录，QQ 都会把密钥作为参数传给它。只要能在这个函数被调用的瞬间截获参数，就等于拿到了开锁的钥匙。

第三，各平台的突破口高度一致：wrapper.node。这是 QQ NT 跨平台架构的产物——一个 Node.js 原生插件（Native Addon），承担了数据库读写等底层能力，而nt_sqlite3_key_v2恰好就编译在它里面。于是，无论 Windows 的 PE、Linux 的 ELF、macOS 的 Mach-O，还是 Android 的libkernel.so，我们都可以用"字符串定位 → 反汇编回溯 → 动态断点"这套通用思路处理。这个洞察，正是qq-win-db-key能够做到一份代码思路覆盖五个平台的根基。

二、动手前的三个准备动作

解密属于高风险操作，准备阶段决定了你后面是"有惊无险"还是"血本无归"。

动作一：备份，备份，还是备份。最稳妥的方式是先用 PCQQ（Windows 旧版）自带的"导出消息记录（mht 格式）"做一份纯文本备份；移动端则用系统备份功能整体备份应用数据。这一步花十分钟，能避免后面所有的不确定性。

动作二：准备基础工具。Python 3.8+ 是运行脚本的基础；按平台不同还需要 Frida（Android/iOS 动态注入）、GDB（Linux）、lldb（macOS，Xcode Command Line Tools 自带）、PowerShell 5.1+（Windows）；最后准备一个 SQLCipher 命令行工具或 DB Browser for SQLCipher 用于解锁验证。

动作三：评估运行环境。强烈建议在虚拟机、备用机或不常用的设备上先跑通流程；涉及 Android 的 Frida 注入需要 root 权限并关闭 SELinux，这个环境要求我们稍后细说。拿到源码后先通读脚本逻辑，确认没有疑虑再执行。

三、Windows 主线实战：从自动定位到一键出密钥

项目名就叫qq-win-db-key，Windows NTQQ 自然是打磨最完善的主线。核心脚本是scripts/windows/ntqq/windows_ntqq_get_key.ps1，它把"静态分析 + 动态调试"两件事封装成了一键流程。

步骤一：克隆项目并检查脚本

git clone https://gitcode.com/gh_mirrors/qq/qq-win-db-key cd qq-win-db-key/scripts/windows/ntqq

步骤二：直接运行（默认自动检测）

powershell -ExecutionPolicy Bypass -File .\windows_ntqq_get_key.ps1

脚本会依次做四件事，每步都有彩色日志输出：

1. 从注册表自动定位 QQ 安装目录和版本，找到versions\<版本号>\resources\app\wrapper.node；
2. 解析这个 PE64 文件：先在.rdata段搜索特征字符串nt_sqlite3_key_v2: db=%p zDb=%s，拿到字符串 RVA；
3. 在.text段反汇编中找到引用该字符串的LEA指令（RIP 相对寻址），再借助异常目录回溯出包含它的函数 RVA；
4. 以DEBUG_ONLY_THIS_PROCESS方式启动 QQ 并附加调试器，等待wrapper.node加载后，在"函数基址 + RVA"处写入0xCC软件断点。

步骤三：在 QQ 窗口登录账号

断点设好后，脚本会提示你登录目标账号。登录瞬间nt_sqlite3_key_v2被调用，断点触发，调试器读取 x64 调用约定下第 4 个参数（寄存器R8，即密钥指针），校验为 16 字节可打印 ASCII 后打印出来：

======================================== 找到密钥: XXXXXXXXXXXXXXXX ========================================

如果只想做静态分析、不想启动调试器，加-NoDebugForKey参数即可，脚本会只输出函数 RVA 和 LEA 指令位置，方便你配合 IDA Pro 手工核对。

四、其余四个平台的差异化打法

Windows 之外，每个平台的技术选型都因地制宜，但都遵循同一条主线。

Linux：GDB 接管 ELF 分析

scripts/linux/linux_qq_get_key.py走的是"纯命令行静态分析 + GDB 动态调试"路线：先用readelf -lW解析程序头与.rodata段的映射，再用strings定位特征字符串的文件偏移，用objdump反汇编.text找出引用该字符串的指令地址（结果会缓存到ref_off_cache文件，避免重复计算）。随后进入 GDB，在dlopen处断下、等wrapper.node加载、算出基址，在引用处设断点回溯到函数入口，最后等rdx（密钥长度）等于 16 时读取rsi指向的 16 字节密钥。注意这是 x86_64 SysV 调用约定，寄存器语义和 Windows 完全不同，不要混用。

Android：Frida 特征码扫描注入

scripts/android/android_get_key.py面向 8.9.58 起的多个版本，用 Frida 注入 QQ 进程。它先枚举模块找到libkernel.so，再用Memory.scanSync按 ARM64 指令特征码（一串FD 7B BD A9 ...）定位key_v2函数，Interceptor.attach后在onEnter里读取参数：x2是密钥指针、x3是密钥长度，同时把目标数据库名、密钥的字符串形式和十六进制形式全部打印出来。运行前要求：关闭 Magisk Hide 与 Shamiko、禁用 SELinux、不要使用 x86 模拟器（ARM64 指令特征码在模拟器上无效）。在 Termux 里需要先把frida-server重命名后以 root 启动。

iOS：偏移量直挂

scripts/ios/ios_get_key.js更直接——针对 QQ iOS v9.0.1.620（SQLCipher v4.5.1），把sqlite3_key_v2的模块内偏移量0xDA1BFB4写死，Module.findBaseAddress加偏移后直接Interceptor.attach。它甚至额外实现了从sqlite3*结构体逐层解引用出数据库文件名的逻辑，方便你区分哪个库对应哪把钥匙。iOS 侧需要具备 Frida 注入能力的越狱或半越狱环境。

macOS：lldb 免关 SIP

scripts/macos/arm-nosip/qq_key_extractor.py特别强调了"无需关闭 SIP"：用lldb -n QQ -w等待进程，加载 Python 模块后自动解析 Mach-O 的 fat 头与__text段、定位特征字符串、找到函数虚拟地址，qq-setbp一条命令完成设断点，登录时密钥自动打印。全程只读进程内存，不触碰系统保护。

旧版 PCQQ 的补充武器

scripts/windows/pcqq/目录还保留着针对旧版 PCQQ 的工具，包括数据库导出脚本和两个重加密工具。其中pcqq_DANGER_rekey.py文件名里的DANGER是故意的——重加密会改写数据库文件结构，属于高危操作，除非你完全清楚自己在做什么，否则不要碰。

五、拿到密钥之后：SQLCipher 解锁与验证

密钥到手只是第一步，解锁数据库还要保证加密参数与建库时完全一致，否则照样打不开：

sqlcipher encrypted.db PRAGMA key = '你的16字节密钥'; PRAGMA cipher_page_size = 4096; PRAGMA kdf_iter = 64000; PRAGMA cipher_hmac_algorithm = HMAC_SHA512; PRAGMA cipher_kdf_algorithm = PBKDF2_HMAC_SHA512; SELECT count(*) FROM sqlite_master;

其中cipher_page_size、kdf_iter这几项必须逐一对上，参数不对会直接报file is not a database。不同 QQ 版本、不同平台的默认参数可能不同，具体数值请以项目配套文档站（QQDecrypt）维护的说明为准；如果解密失败，优先怀疑参数而非密钥。执行SELECT能正常返回即代表解锁成功，此时可以用.dump导出内容，或直接交给 DB Browser for SQLCipher 图形化浏览。

六、进阶技巧：让提取更稳、更快、更省心

技巧一：静态分析先行，减少动态调试次数。Windows 脚本的-NoDebugForKey模式、Linux 脚本的ref_off_cache缓存，本质上都是"把解析结果沉淀下来"。批量处理多个 QQ 版本时，先跑一遍静态分析建立版本指纹库，再针对性调试，能省下大量重复反汇编时间。

技巧二：版本升级后优先对比指令特征。Android 脚本里的特征码是按版本维护的（version_scripts字典）。QQ 升级后如果脚本失效，先用objdump/IDA 对比新旧版本的nt_sqlite3_key_v2反汇编，通常只需更新特征码或偏移量即可恢复兼容。

技巧三：多账号、多库场景写个调度壳。把"提取密钥 → 按账号目录匹配数据库 → 逐库解密"封装成一个循环脚本，配合日志记录每次的密钥归属和结果，比手工一个个跑可靠得多。iOS 脚本里那段从结构体反推文件名的逻辑，就是为这种场景准备的。

七、高频问题排查手册

问题一：脚本提示找不到wrapper.node。多为版本目录结构变化或安装路径非默认。Windows 脚本支持-WrapperNodePath手动指定路径，Linux 脚本则要检查/opt/QQ/resources/app/wrapper.node是否存在，或者直接改脚本里的路径常量。

问题二：断点没触发、拿不到密钥。先确认是不是已经在 QQ 窗口完成了登录操作——函数只在登录流程中被调用。其次确认版本兼容性：脚本是按特定版本验证的，跨大版本可能失效。Windows 上还要排查杀毒软件是否拦截了调试器附加。

问题三：Android 注入失败或闪退。依次核对：SELinux 是否已禁用、Magisk Hide/Shamiko 是否关闭、frida-server版本是否与 PC 端 Frida 匹配、是否误用了 x86 模拟器。可以在 PC 端用frida-ps -U验证设备连接是否正常。

问题四：密钥拿到了但解密报file is not a database。几乎可以断定是加密参数不匹配，重点核对cipher_page_size和kdf_iter，必要时用PRAGMA integrity_check验证文件完整性。另外确认你解的是不是对应账号的那份数据库。

八、风险与合规边界：请把"安全"二字刻在流程里

这部分必须说透，不能回避。qq-win-db-key的 README 开篇就是醒目的警告：尽管部分脚本经过实验验证，但工具可能破坏聊天记录，甚至可能触发风控导致封号。具体风险包括三类：

• 数据风险：重加密、调试中断、异常写入都可能导致数据库损坏，聊天记录不可逆丢失；
• 账号风险：动态注入、调试器附加等行为可能被客户端安全机制识别，极端情况下导致账号异常；
• 法律风险：使用方式必须符合所在地法律法规以及《QQ 软件许可及服务协议》。

因此请务必遵守：仅用于个人数据备份与学习研究，禁止任何商业用途；操作前用官方导出功能备份、在虚拟机或备用机测试；及时清理临时文件和日志；不将解密数据用于法律取证。本项目不对脚本结果的完整性、准确性作任何担保，开发者也不承担相关行为导致的直接或间接责任。使用即代表你已理解并接受这些边界。

九、写在最后

把qq-win-db-key的整套方案走通一遍，你收获的其实不只是"拿到了自己聊天记录的钥匙"——更是一次完整的跨平台逆向思维训练：从特征字符串到指令引用，从调用约定到寄存器语义，从静态分析到动态调试，五大平台的差异最终都收敛到了同一条技术主线。这套方法论完全可以迁移到其他 Electron 类应用、其他 SQLCipher 数据库的分析中去。

最后再强调一次：技术无好坏，边界在人。工具帮你解锁数据，但解锁之后的每一份数据，都值得你用最谨慎的态度对待。

【免费下载链接】qq-win-db-key全平台 QQ 聊天数据库解密项目地址: https://gitcode.com/gh_mirrors/qq/qq-win-db-key