逆向工程密码学【免费下载链接】WechatDecrypt微信消息解密工具项目地址https://gitcode.com/gh_mirrors/we/WechatDecrypt点击查看免费下载导读本文围绕开源仓库 WechatDecrypt微信消息解密工具的 README.md 使用教程展开完整讲解如何编译该工具、将其部署到微信数据目录并借助dewechat ChatMsg.db一条命令把加密的微信数据库如 ChatMsg.db还原为可用 sqlite 直接打开的明文数据库。同时文章将深入 wechat.cpp 源码逐层剖析其背后的 SQLite 逐页解密、PBKDF2-HMAC-SHA1 密钥派生、HMAC-SHA1 完整性校验与 AES-256-CBC 解密实现让读者既能照章操作也能读懂底层原理。一、项目概览与仓库结构WechatDecrypt 是一个基于 Windows OpenSSL 的单文件 C 工具用于解密微信 PC 客户端本地保存的加密 SQLite 数据库。微信把聊天记录存放在以微信 ID 命名的目录下数据库文件如ChatMsg.db本身是加密的无法直接打开本工具读取加密文件后按页还原出明文 SQLite 数据库输出为dec_前缀的新文件。仓库结构非常精简全部源码与文档仅三个文件文件说明README.md使用教程编译、部署路径与解密命令wechat.cpp核心实现单文件 C 解密程序约 150 行LICENSEMIT 开源协议整个解密逻辑全部集中在 wechat.cpp 中主流程由main()与Decryptdb()两个函数承担没有额外的工程文件或构建脚本属于典型的“拿到源码直接编译”风格的小工具。二、环境准备与编译2.1 依赖条件从 wechat.cpp 的头部包含可以看出程序依赖两类组件Windows 运行环境#include Windows.h且代码中大量使用fopen_s、strcpy_s、sprintf_s等 MSVC 安全函数因此它面向 Windows 平台编译运行。OpenSSL 加密库使用了openssl/evp.hAES 加解密、PBKDF2、openssl/hmac.hHMAC-SHA1、openssl/aes.h、openssl/rand.h。编译时需要链接 OpenSSL 的libcrypto。2.2 编译示例仓库没有附带 Makefile 或 CMakeLists需要手动调用编译器。以 MinGW-w64 已安装 OpenSSL 的环境为例可参考如下命令实际请根据本机 OpenSSL 的 include/lib 路径调整-I、-L参数g wechat.cpp -o dewechat.exe -Iopenssl/include -Lopenssl/lib -lcrypto -lssl在 Visual Studio 环境下则用cl编译并链接 OpenSSL 库即可。编译成功后得到可执行文件按 README 的使用方式二进制名称应为dewechatWindows 下即dewechat.exe。三、部署把工具拷贝到微信数据库目录编译完成后README 给出的部署方式是把这个可执行文件拷贝到微信数据库目录。该目录通常在C:\Users\Administrator\Documents\WeChat Files\********\Msg其中路径里的星号********处就是需要解密的微信 ID——每个微信账号在WeChat Files下都有一个以自身 ID 命名的文件夹聊天数据库就存放在该文件夹下的Msg子目录中。把dewechat.exe放到Msg目录后后续只需在该目录下打开 CMD 执行解密命令即可。如果不想拷贝也可以把可执行文件放在任意位置运行命令时直接传入数据库文件的完整路径——从源码结构看main() 会把argv[1]原样作为文件名打开见 Decryptdb() 中的fopen_s(fpdb, dbfilename, rb)因此传入相对路径或绝对路径均被支持。四、解密实战CMD 命令与输出结果4.1 一条命令完成解密在Msg目录的 CMD 中执行dewechat ChatMsg.db即可解密当前目录下的ChatMsg.db。README 特别说明ChatMsg.db就是需要解密的微信数据库文件之一聊天消息数据库。4.2 解密成功后的输出解密成功后程序会在当前目录输出dec_ChatMsg.db即原文件名加上dec_前缀。README 明确说明用 sqlite 打开dec_ChatMsg.db即可查看解密后的明文数据。常见的打开方式包括 SQLiteStudio、DB Browser for SQLite 等 GUI 工具或sqlite3 dec_ChatMsg.db命令行工具。4.3 运行期交互与提示信息从 main() 可以看到程序支持两种调用形态带参数dewechat ChatMsg.db直接使用argv[1]作为文件名不带参数程序会提示请输入文件名:等待用户在命令行手工输入数据库文件名后再开始解密。解密过程中程序会逐页打印进度。结合 wechat.cpp 的源码可以观察到这些关键提示提示信息触发场景打开文件错!文件不存在或无法以rb方式打开解密数据页:x/y每解密一页打印一次进度哈希值错误!当前页 HMAC-SHA1 完整性校验失败密钥不匹配或文件损坏解密成功!全部页面解密完成注意任一页面的哈希校验失败都会直接终止程序并等待按键退出说明工具对“密钥与文件不匹配”的情况有内置的防御性检查。五、源码级解密原理wechat.cpp 逐层拆解解密不是简单地用一把钥匙打开文件而是遵循一套 SQLite 逐页加密方案。下面按 Decryptdb() 的执行顺序拆解。5.1 整库读入与盐Salt提取程序先把整个加密文件读入内存缓冲区fseek(fpdb, 0, SEEK_END); long nFileSize ftell(fpdb); fseek(fpdb, 0, SEEK_SET); unsigned char* pDbBuffer new unsigned char[nFileSize]; fread(pDbBuffer, 1, nFileSize, fpdb);随后取文件前 16 字节作为派生密钥用的盐unsigned char salt[16] { 0 }; memcpy(salt, pDbBuffer, 16);也就是说加密库文件的头部 16 字节以明文形式存放盐而解密时这 16 字节并不会被解密——首页解密会跳过它们并在输出文件中将其还原为 SQLite 文件头详见 5.6。同时程序还会生成一份用于 HMAC 密钥派生的mac_salt规则是对盐逐字节异或0x3amac_salt[i] ^ 0x3a;5.2 密钥派生PBKDF2-HMAC-SHA1工具没有直接使用一个静态密钥而是通过 PBKDF2-HMAC-SHA1 从“主密码 盐”派生出 32 字节的 AES 密钥PKCS5_PBKDF2_HMAC_SHA1((const char*)pass, sizeof(pass), salt, sizeof(salt), DEFAULT_ITER, sizeof(key), key);其中pass[]是源码中硬编码的 32 字节主密码数组wechat.cpp源码注释明确写道“PC 端密码是经过 OllyDbg 得到的 32 位 pass”——即该密码来自对微信 PC 客户端进程的动态调试/逆向分析而非可自行配置的明文口令。用于页面校验的 HMAC 密钥则进一步从主密钥派生迭代次数仅为 2PKCS5_PBKDF2_HMAC_SHA1((const char*)key, sizeof(key), mac_salt, sizeof(mac_salt), 2, sizeof(mac_key), mac_key);5.3 页面结构与“保留区”reserve加密库按固定大小页面组织数据。PC 端每页 4096 字节源码注释给出了页面内的布局//4048数据 16IV 20 HMAC 12即每页由 4048 字节密文数据、16 字节 IV、20 字节 HMAC-SHA1 摘要以及 12 字节余量构成合计 4096。程序用以下逻辑计算尾部保留区大小int reserve IV_SIZE; // 16 reserve HMAC_SHA1_SIZE; // 20 36 reserve ((reserve % AES_BLOCK_SIZE) 0) ? reserve : ((reserve / AES_BLOCK_SIZE) 1) * AES_BLOCK_SIZE; // 对齐到 16 的倍数 → 48因此每页尾部 48 字节为保留区其中[4048, 4064)16 字节 AES-CBC IV[4064, 4084)20 字节 HMAC-SHA1 校验值[4084, 4096)12 字节余量。5.4 逐页 HMAC-SHA1 完整性校验在解密每一页之前程序先用mac_key对该页的密文数据从当前偏移到 4064 字节处连同页码计算 HMAC-SHA1并与页面尾部存储的 20 字节校验值比对HMAC_Init_ex(hctx, mac_key, sizeof(mac_key), EVP_sha1(), NULL); HMAC_Update(hctx, pTemp offset, DEFAULT_PAGESIZE - reserve - offset IV_SIZE); HMAC_Update(hctx, (const unsigned char*)nPage, sizeof(nPage)); HMAC_Final(hctx, hash_mac, hash_len); if (0 ! memcmp(hash_mac, pTemp DEFAULT_PAGESIZE - reserve IV_SIZE, sizeof(hash_mac)))将页码纳入 HMAC 计算意味着各页之间的校验值相互绑定任何一页内容被替换或篡改都会导致校验失败这正是防止“页序调换攻击”的标准做法。校验失败时程序打印哈希值错误!并终止。5.5 AES-256-CBC 解密通过校验后程序使用 32 字节主密钥key和本页尾部存储的 IV对页面数据执行 AES-256-CBC 解密并显式关闭填充EVP_CIPHER_CTX_set_padding(ectx, 0)因为密文长度正好是 16 字节 AES 块大小的整数倍EVP_CipherInit_ex(ectx, EVP_get_cipherbyname(aes-256-cbc), NULL, NULL, NULL, 0); EVP_CIPHER_CTX_set_padding(ectx, 0); EVP_CipherInit_ex(ectx, NULL, NULL, key, pTemp (DEFAULT_PAGESIZE - reserve), 0); EVP_CipherUpdate(ectx, pDecryptPerPageBuffer offset, nDecryptLen, pTemp offset, DEFAULT_PAGESIZE - reserve - offset);解密长度与起始偏移因页而异首页从偏移 16 开始解密 4032 字节其余页从偏移 0 开始解密 4048 字节。5.6 首页 SQLite 文件头恢复与输出落盘SQLite 数据库文件的标准头是 16 字节的SQLite format 3而加密库把这 16 字节位置用作明文盐。因此解密首页时程序把解密缓冲区的前 16 字节替换回标准 SQLite 头if (nPage 1) { memcpy(pDecryptPerPageBuffer, SQLITE_FILE_HEADER, offset); }每页解密完成后页面尾部 48 字节保留区IV HMAC 余量被原样拷贝到输出缓冲区的相同位置随后整页 4096 字节追加写入以dec_前缀命名的输出文件sprintf_s(decFile, dec_%s, dbfilename); fopen_s(fp, decFile, ab); fwrite(pDecryptPerPageBuffer, 1, DEFAULT_PAGESIZE, fp);也就是说输出的dec_ChatMsg.db在每页尾部仍保留 48 字节的 IV/HMAC 痕迹但这部分字节落在 SQLite 页面数据区内不影响 SQLite 正常读取整库因此可以放心用 sqlite 工具直接打开。六、核心常量与参数速查表以下常量均直接来自 wechat.cpp是理解与移植该算法时的关键数值常量 / 参数值含义SQLITE_FILE_HEADERSQLite format 3SQLite 标准文件头16 字节IV_SIZE16AES-CBC 初始化向量长度HMAC_SHA1_SIZE20HMAC-SHA1 摘要长度KEY_SIZE32派生出的 AES 密钥长度即 AES-256AES_BLOCK_SIZE16AES 分组大小用于保留区对齐DEFAULT_PAGESIZE4096PC 端每页字节数4048 数据 48 保留区DEFAULT_ITER64000PBKDF2-HMAC-SHA1 主密钥迭代次数reserve48每页尾部保留区16 IV 20 HMAC 12 余量对齐到 48pass[]32 字节硬编码主密码逆向自 PC 端输出文件命名dec_ 原文件名如dec_ChatMsg.db七、平台差异分支源码中预留的 Android 配置wechat.cpp 中通过条件编译宏ANDROID_WECHAT预留了一套移动端参数分支#ifndef ANDROID_WECHAT #define DEFAULT_PAGESIZE 4096 //4048数据 16IV 20 HMAC 12 #define DEFAULT_ITER 64000 #else #define NO_USE_HMAC_SHA1 #define DEFAULT_PAGESIZE 1024 #define DEFAULT_ITER 4000 #endif从源码结构看Android 分支定义了三个差异点页面大小降为 1024 字节、PBKDF2 迭代次数降为 4000并通过NO_USE_HMAC_SHA1关闭 HMAC 校验。不过需要说明的是本仓库中没有在任何构建入口定义ANDROID_WECHAT且整个源文件依赖Windows.h与 MSVC 安全函数实际可编译运行的场景仍是 Windows 桌面端Android 分支更接近源码中预留的算法参数说明而非本仓库现成可用的 Android 构建。八、局限性与注意事项主密码硬编码、依赖特定版本32 字节主密码直接内嵌在源码中且注释表明它来自对特定微信 PC 客户端版本的逆向调试OllyDbg。因此该工具的有效性绑定于对应微信版本的密钥与页面加密布局——微信升级、更换版本或数据格式调整后使用旧密钥解密新库可能导致哈希值错误!或解密失败。这是从 wechat.cpp 源码事实可以确认的边界条件。仅适用于本人数据工具用途是解密本机微信数据目录下的数据库应仅在合法、授权的场景下使用如数据迁移、本地存档分析不应用于未授权访问他人数据。代码中存在未实现的辅助函数源文件开头声明了CheckKey()与CheckAESKey()两个函数wechat.cpp但在当前版本中既未定义也未调用可推断为早期设计遗留不影响实际解密主流程。输出文件保留每页尾部 48 字节dec_输出文件每页末尾会原样保留 IV/HMAC 保留区虽然不影响 sqlite 读取但若追求“纯净”的 SQLite 文件可在此基础上自行剥离。九、相关文件索引想深入验证本文所述内容可直接阅读仓库中的以下文件README.md官方使用教程编译、部署路径、解密命令与输出文件说明wechat.cpp全部解密实现重点阅读main()第 32-43 行与Decryptdb()第 45-149 行LICENSEMIT 开源协议注明版权归属。整体来看WechatDecrypt 以极简的单文件实现演示了一条完整的微信数据库解密链路明文盐 → PBKDF2 派生主密钥与 HMAC 密钥 → 逐页 HMAC-SHA1 校验 → AES-256-CBC 解密 → SQLite 文件头还原。无论你是只想解密自己的聊天记录还是想研究微信本地数据库的加密方案这份代码都是值得对照阅读的入门级参考。赞分享逆向工程密码学【免费下载链接】WechatDecrypt微信消息解密工具项目地址https://gitcode.com/gh_mirrors/we/WechatDecrypt点击查看免费下载相关推荐微信如何加密你的聊天记录WeChatMsg拆解AES-256-CBCHMAC-SHA1加密机制微信如何加密你的聊天记录WeChatMsg拆解AES 256 CBCHMAC SHA1加密机制 WeChatMsg微信聊天记录导出工具 能提取 Wind桌面应用数据分析数据可视化Chatlog Alpha 微信数据库解密原理全解WCDB 加密、AES 与 all_keys.json 密钥映射指南Chatlog Alpha 微信数据库解密原理全解WCDB 加密、AES 与 all_keys.json 密钥映射指南 微信 4.x 的聊天记录并不是明文的—后端CLIMCP 服务即时通讯RAG人工智能AI 技能SeaTunnel FieldEncrypt 加密 Transform 插件实战指南AES-GCM/AES-CBC 字段加解密原理与配置SeaTunnel FieldEncrypt 加密 Transform 插件实战指南AES GCM/AES CBC 字段加解密原理与配置 SeaTunnel数据集成ETL大数据批处理流处理变更数据捕获上一篇从零开始打造专业级媒体播放体验mpv PlayKit 完全指南下一篇5个关键步骤彻底解锁mpv播放器从零到精通的专业配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
