Skip to content

report.md

Latest commit

 

History

History
67 lines (44 loc) · 3.28 KB

report.md

File metadata and controls

67 lines (44 loc) · 3.28 KB

微信 PC 端数据库与数据机制研究报告

1. 概述

本报告旨在详细解析微信 PC 端（Windows）的本地数据存储逻辑、数据库结构及加密机制。所有结论均源自对实际运行机制和数据文件的深度技术分析。

2. 数据库文件分布

根据文件系统扫描逻辑，核心数据库文件分布如下：

数据库类型 命名规则 典型路径 功能描述
会话索引 Session.db db_storage/session/ 存储联系人列表、会话列表及基础元数据。
消息分库 message_{N}.db db_storage/message/ 存储实际的聊天消息内容。N 通常为 0-199，实现数据分片存储。
媒体索引 media_{N}.db db_storage/message/ 存储语音、视频等附件的索引信息及部分元数据。
文件映射 hardlink.db db_storage/hardlink/ 存储加密图片文件（.dat）与实际会话路径的映射关系。

3. 消息存储机制

3.1 分库策略

聊天记录主要分布在 message_0.db 到 message_199.db 中。系统会根据会话 ID（如 wxid）计算哈希或其他算法，将其路由到特定的分库中。

3.2 表结构命名

每个分库中包含多张消息表，表名通常遵循以下规则：

  • 格式: Msg_{MD5}
  • 说明: 其中 {MD5} 是会话 ID（如 ChatID）的 MD5 哈希值。

4. 多媒体数据机制

4.1 图片存储与加密

图片文件存在三种加密版本，由文件头前6字节标识：

版本代码 文件头特征 (Hex) 加密算法实现 备注
0 (无特定固定头) decryptDatV3 (纯 XOR) 利用 JPG/PNG 尾部特征倒推 XOR Key
1 07 08 56 31 08 07 decryptDatV4 (AES-128-ECB) 使用内置的静态 AES 密钥
2 07 08 56 32 08 07 decryptDatV4 (AES-128-ECB) 使用运行时获取的用户 AES 密钥

V4 解密细节:

  1. 文件头 15 字节为 Header。
  2. Header[6-10]: AES数据长度 (aesSize)。
  3. Header[10-14]: XOR数据长度 (xorSize)。
  4. AES部分: 从第15字节开始，长度为 aesSize (需对齐16字节)，使用 aes-128-ecb 解密并移除 PKCS7 填充。
  5. XOR部分: 紧接 AES 部分之后，长度为 xorSize，使用 XOR 运算解密。

4.2 图片路径映射 (Hardlink.db)

  1. 查询: 通过图片的 MD5 在 image_hardlink_info 表中查询包含 dir1, dir2, file_name 的记录。
  2. 映射: dir1 和 dir2 仅为整数索引，需关联 dir2id 表解析为实际的字符串目录名（通常是哈希过的用户名）。
  3. 还原: 最终还原出类似 msg/attach/{user_hash}/{path_hash}/Img/{filename} 的物理路径。

4.3 语音消息 (Silk)

语音数据不与文本消息存储在同一数据库，而是独立存储在 media_{N}.db 中，且采用了复杂的查找策略：

  • 存储格式: Silk 编码。
  • 表名: VoiceInfo 。
  • 字段特征: 数据列为 voice_data，时间列为 create_time。
  • 精确查找: 优先尝试通过消息的 local_id 或 svr_id 精确匹配。

4.4 表情包

表情包 CDN 图片链接存储在扩展库的 kNonStoreEmoticonTable 表中，可以通过表情包文件的 MD5 哈希值查询对应的 cdn_url。