AI取证实战第10期：安卓微信8.0.69版本数据库解密实战

从 E01 到微信明文库：一条完整的取证链

安卓微信数据库解密实战 · 双案例完整版
8.0.27 大库（1243 条）× 8.0.69 小库（26 条）

拿到一部手机的 E01 镜像，在让AI做题得时候，最常被问到的第一个问题就是："微信能不能解？"答案是能。但前提是你能把三样东西同时对上：UIN、设备标识、SQLCipher 参数。少一个，或者对错了版本，你就会在"密码错误"和"database disk image is malformed"之间反复横跳。

这篇文章用两份真实检材把整条链路拆开讲：镜像怎么固定 → 文献怎么查 → 版本怎么判 → 密钥怎么算 → 老格式为什么打不开 → WAL 怎么回放 → 数据怎么变成案情 → 已删除的图怎么捞回来。
两份检材是两个极端：一份 119 GiB 真机、1243 条消息；一份 64 GiB 模拟器、只有 26 条消息却藏着一条完整证据链。同一套方法在两个极端上都成立——这才是最有说服力的地方。

零、两份检材速览

项目	检材 A · lihh_Phone.E01	检材 B · 手机镜像.E01
体积	3.4 GB / 119 GiB	2.5 GB / 64.1 GiB
来源	真机	逍遥安卓模拟器
微信版本	8.0.27 （2220）	8.0.69 （3040）
ABI / SDK	armeabi-v7a / 31	arm64-v8a / 36
UIN	-692417256 （负）	851368963 （正）
真实 IMEI	A250f5016ec6f558（未采用）	Aa486cd166f3ef31（未采用）
实际密钥	2c45652	b21f44d
数据表	227	249
消息 / 联系人	1243 / 364	26 / 32
镜像内附件	675 个	15 项（含已删除）
明文库	8,010,752 B	1,401,856 B
完整性	ok	ok

一、先把证据固定住

任何分析之前，第一件事不是挂载，而是读取并记录镜像自身的元数据。这些信息会原样出现在最终报告里，也是证明"我没动过原始检材"的第一道防线。

$ ewfinfo lihh_Phone.E01
$ ewfinfo 手机镜像.E01

项目	检材 A	检材 B
格式 / 压缩	EnCase 6 / deflate	EWF / deflate
扇区数	250,542,720	134,427,443
介质 MD5	d4d1db591106dcc9997cf3712c8f9a9d	0177b083acd8a432ad6bb3360bd1041f
采集时间	2023-12-15 16:32:26	2026-05-20 22:51:22
案件编号	Case02-20231215-155230	Case03-20260520-211721
检材描述	—	MEmu96-2026041400027FFF-disk2.vmdk

新手要点 · 其实根本不用挂载

Sleuth Kit 可以直接读 E01，mmls / fls / icat 都原生支持 EWF。挂载只在你想用其他不支持 E01 的工具时才必要。
如果确实要挂：ewfmount xxx.E01 /mnt/ewf 必须 -u root 且挂载点可写，否则报 user has no write access to mountpoint。

二、先查文献，再动手

这一步被大多数人跳过，结果就是"照着某篇 2019 年的教程做，做完发现版本对不上"。本次先检索并通读了 12 篇来源，结论高度一致：

来源	核心结论
博客园《Android 设备的微信数据分析》	密钥 = Left7(MD5(IMEI + UIN))
残垣拾遗《微信聊天记录数据库解密工作流》	高版本不申请电话权限，IMEI 位实为硬编码 1234567890ABCDEF
掘金《Android 逆向分析实例（三）》	Frida hook WCDB openDatabase 实证密码为 7 位十六进制
看雪《微信 8.0.38 版本数据库解密分析》	8.0.3x 密钥仍由"设备标识 + UIN"两参数派生
CSDN《逆向分析微信 EnMicroMsg.db 加密机制》	全库加密，header 也加密，无明文特征
《A look at WeChat security》	password = mangle(deviceid + uin)[:7]，cipher_use_hmac = OFF
综合结论	Android 端微信主库密钥统一为 key = MD5(IMEI_or_fixed + UIN)[0:7]；优先用真实 IMEI，取不到时用硬编码串 1234567890ABCDEF

三、定位两个关键值

mmls -t dos image.E01      # 列出分区表
fsstat -o <offset> image.E01  # 找挂载点为 /data 的 ext4

值	来源文件	A 实测	B 实测
UIN	auth_info_key_prefs.xml → _auth_uin	-692417256	851368963
IMEI 候选	WLOGIN_DEVICE_INFO.xml（hex → ASCII）	A250f5016ec6f558	Aa486cd166f3ef31
库路径	/data/data/com.tencent.mm/MicroMsg/<32位>/	662f8004…59a7	bbbe46ac…0e2e

坑位 1 · UIN 有正有负，符号必须保留

检材 A 拼接时必须用字符串 "-692417256"，不是 "692417256"。丢掉负号，MD5 前 7 位完全不同，你会白试一整天。
检材 B 的 851368963 是正数——不要因为见过负数就习惯性加负号。

四、密钥推导：本次最关键的一坑

两组候选，一行 Python 就能分出胜负：

# 检材 A
md5("A250f5016ec6f558" + "-692417256")[:7]  # 5a96855 ✗
md5("1234567890ABCDEF" + "-692417256")[:7]  # 2c45652 ✓

# 检材 B
md5("Aa486cd166f3ef31" + "851368963")[:7]    # 88a81d8 ✗
md5("1234567890ABCDEF" + "851368963")[:7]    # b21f44d ✓

两份检材镜像里明明有真实 IMEI，但微信都没用它——用的是硬编码前缀。这就是多数教程失效的根因：微信 6.0 之后不再申请 READ_PHONE_STATE 权限，拿不到 IMEI 时直接回落到固定串。从 8.0.27（2022）到 8.0.69（2026），四年、三十多个版本，这条规则纹丝未动。

新手要点 · 怎么一眼判断密钥对不对

别反复跑 sqlcipher 命令行试参数，直接解密第 1 页，看明文字节：
· offset 16-17 = 04 00 → page size 1024
· offset 18-19 = 01 01 → 写/读版本
· offset 20 = 10 → reserved = 16
对上了就是它。这比什么都快。

五、为什么 sqlcipher 4.x 打不开

本次两份库都是 SQLCipher 1.x 兼容格式，参数如下：

参数	值
page_size	1024（reserve 16 → 可用 1008）
KDF	PBKDF2-HMAC-SHA1，4000 轮，32 字节
加密	AES-256-CBC，IV 存放页尾 reserve 区（每页独立）
HMAC	关闭
salt	文件首 16 字节

sqlcipher 4.x 默认强制做 HMAC 校验，cipher_compatibility = 1 / 2 / 3 全都试过，一律 hmac check failed。这时候别再调参了，直接用 Python 手工解密：

# 第 1 页：前 16 字节是 salt
明文 = b"SQLite format 3\x00" + AES-CBC(key, iv=页尾16B, ct=file[16:1008])
# 其他页
明文 = AES-CBC(key, iv=页尾16B, ct=page[0:1008]) + b"\x00" * 16

坑位 2 · reserved 字段不能清零

解密后 header offset 20 的 reserved 必须保持 16。很多教程让你"顺手置 0"，结果一打开就是 database disk image is malformed。
原因：页内所有偏移都是按 usable = page_size - reserve = 1008 组织的，你把 reserve 抹了，SQLite 算出来的 cell 位置全错。

六、WAL 回放：最新消息都在这里

光解主库会丢数据——微信主库旁边还有一个 EnMicroMsg.db-wal，最近的消息往往只存在于 WAL 里。检材 A 本次 WAL 有 379 帧。帧结构：24 字节帧头 + 1024 字节页。

步骤	动作
1	逐帧取出页数据，用同样方式 AES 解密
2	在明文上重算 SQLite checksum（不是密文）
3	写回 .db-wal 文件
4	PRAGMA wal_checkpoint(TRUNCATE) 合并
5	VACUUM INTO 导出干净的标准 SQLite

坑位 3 · checksum 的基数

WAL 帧头的 checksum 是对已解密的明文计算的，不是密文。这一点错了，回放时 SQLite 会在第 1 帧就丢弃整个 WAL，你会以为"WAL 是空的"。

七、成果对照

指标	检材 A	检材 B
数据库对象 / 数据表	597 / 227	— / 249
message	1243 条 / 26 会话	26 条 / 3 会话
rcontact	364	32
chatroom	4	0
可还原附件	675 个	15 项
最新消息时间	2023-12-14 16:55:04	2026-05-20 18:25:07
完整性	integrity_check = ok	integrity_check = ok

$ sqlite3 EnMicroMsg_decrypted.db
sqlite> SELECT count(*) FROM message;    -- A: 1243  B: 26
sqlite> SELECT count(*) FROM rcontact;    -- A: 364   B: 32
sqlite> PRAGMA integrity_check;            -- ok

八、从数据到案情：26 条消息的证据链

检材 B 只有 26 条消息，但把三层串起来——数据库记录 → 时间线 → 镜像内文件——案情三要素（行为、标的、平台佐证）一个不少。这是"小数据也能出结论"的最好演示。

机主身份（来自 userinfo 表）：wxid_24opmgsmequxxx「摸鱼的陈师傅」，绑定手机 18965420415。

线索 A · 伪造营业执照交易

对象：wxid_28a27rfk55rxxx，昵称"谢"，备注"以贾充真"（以假充真谐音）

时间	向	消息
05-17 21:11:49	收	725731（疑似验证码）
05-20 01:23:24	发	我是摸鱼的陈师傅
05-20 01:25:09	发	上回我们碰头说的那个证做出来了吗
05-20 01:26:56	收	[图片]（见第九章恢复物证）
05-20 01:27:05	收	你康效果如何
05-20 01:28:18	发	我彩打出来
05-20 01:28:44	发	下次还会有这样的需求，或者朋友需要我推你
05-20 18:24:33	收	陈总，上次给你做了几张，要先结算啊
05-20 18:25:02	收	[系统] 你的账号被限制与对方聊天

线索 B · 品牌门店铺设

对象：wsw101958xxxx，昵称"C-Shigure"，备注"糖醋里脊"

时间	向	消息
05-20 16:56:07	发	小李，考察得怎么样啊？
05-20 16:56:19	收	老板，非常顺利
05-20 16:56:33	收	厦门这边这个品牌非常多，可以铺设到其他城市
05-20 16:56:50	收	[图片]（见第九章恢复物证）
05-20 16:57:17	发	非常好，回来给你加奖金！

九、关键物证：删了原图，却漏了缩略图

两条线索各对应一张图。走 icat 按 inode 直接取，文件系统里标"已删除"的照样能捞出来——ext4 删除只是解除链接，数据块还在。

物证 1 · 营业执照样张（线索 A · 已删除原图）

文件名	bc01e38121efd463c152796036508a96.jpg
大小	1,245,850 字节
魔数	PNG · 1222×864 （后缀 .jpg 是骗人的）
SHA-256	f6f80fce339c6dbb4e73c66b4040655bdc5d4ca51cd925e3343f6da4938bf0b7
文件系统状态	已删除 ✔ 恢复成功
内容定性	带"SCJDOL/SEJDSL"占位水印的营业执照样张

物证 2 · 真实门店照（线索 B · 正常文件）

文件名	87591e12745a50cbb9bd9230025a74a8.jpg
大小	699,330 字节
类型	JPEG · 1280×864
SHA-256	772a336657498c16b279f4290c45f7df7c3e1cd60278ff905576b2386c335b26
内容定性	某面包连锁品牌门店实拍（"GOOD CAKE / GOOD BREAD / GOOD DAY"）

取证要点 · 三条

1. 嫌疑人只删了大图，漏了缩略图。th_bc01e381…jpg 还留在 image2 里，icat 照样能取。
2. 微信 image2 目录的扩展名不可信。文件名后缀是 .jpg，实际魔数是 PNG——一定要看 magic，不要看后缀。
3. ImgInfo2 里的 origImgMD5 是"服务器原图"哈希，跟本地恢复文件的 MD5 对不上是正常的——微信下到本地会转码压缩。校验要用本地文件自己的哈希。

十、平台风控：系统消息也是证据

除了用户对话，message 表里还藏着微信安全中心的系统消息：

type	来源	摘录
318767153	weixin（微信团队）	微信安全提醒：该微信号因使用外挂、模拟器等非官方客户端程序或其他违规……
10000	wxid_28a27rfk55rs22	你的账号被限制与对方聊天……（×2）

系统消息是证据链的天然佐证——平台已经替我们做了风控标记，时间戳精确到秒，是不可篡改的第三方记录。分析时一定要把 type=10000 / 318767153 等非聊天消息单独捞一遍。

十一、从脚本到工具：一键到底

上面每一步手工做一遍，熟悉原理是必要的。但到了现场，没人有时间让你跑五个脚本。于是把整条链封装成了一个 .exe：加载 E01 / DD → 自动定位微信目录 → 自动探密钥 → 解密合并 → 浏览器预览，全程不挂卷、不改原始检材。

功能	说明
会话 / 联系人 / 朋友圈	消息按类型还原，图片/语音/视频/表情不再是裸 XML
附件提取	按 inode 从镜像取回原文件（含已删除），导出后自动算 MD5/SHA256 自证
应用版本识别	AXML + packages.xml 双源校验，报告第三章直接给出版本号
关系图谱	10 维语义维度推断，方向由 isSend 判定，每条边附证据
检索 / 报告 / 归档	跨会话检索；报告自带 ewfinfo 元数据；HTML 归档可直接打印

▲ 主界面内嵌的关系图谱页（标签栏 · 工具栏 · Canvas 力导向 · 详情卡）

十二、取证小技巧

1. 关系方向查 isSend，不靠语感

看到「好，老板，我这几天找找看」，直觉是对面在叫机主老板。但查 isSend 才发现——这句话是机主发的，机主才是下属。判断谁是谁的上级，永远查字段，不要读句子。

2. 遇到销售话术，要抑制人际维度

「投研助理-王伟」这种名字很容易被判成上下级。但只要文本里出现涨停/开户/入金/荐股/名额/限时一类词，就应该退出人际维度竞争，改判【买卖/客户】。话术是关系的伪装。

3. 语音文件是 SILK，不是 AMR

微信语音后缀是 .amr，文件头却是 #!SILK_V3——比标准 SILK 还多一个前导字节 0x02。普通播放器放不出来；内置解码器可转 24 kHz WAV 直接听。

4. 删了大图，别忘了缩略图

本次嫌疑人删了 1.24 MB 原图，但 th_ 前缀的缩略图还留在 image2。"删除"在取证里从来不等于"消失"，文件系统层和数据库层要分别看一遍。

5. 扩展名不可信，看魔数

本次物证 1 文件名后缀 .jpg，实际是 PNG；语音后缀 .amr，实际是 SILK。判定文件类型一律读前 8~16 字节，别让名字替你做判断。

十三、一条链，复个盘

环节	关键点
固定	ewfinfo 记 MD5，全程只读
调研	12 篇文献收敛出统一公式
定版本	AXML + packages.xml 双源，版本不在 DB
定位	UIN 符号要保留；IMEI 只是候选
推导	硬编码 1234567890ABCDEF 优先命中（两份都命中）
解密	SQLCipher 1.x 手工解；reserved 保 16
回放	明文上重算校验和 → checkpoint → VACUUM INTO
验证	integrity_check = ok 才能往下走
取证	数据库 ↔ 时间线 ↔ 镜像内文件三层互证

本文所有参数均来自两份检材实测（仅为模拟练习数据，不是真实案例数据）：
· 检材 A lihh_Phone.E01 — 微信 8.0.27 / UIN -692417256 / 密钥 2c45652 / 主库 + 379 帧 WAL / 1243 条消息 / 675 个附件
· 检材 B 手机镜像.E01 — 微信 8.0.69 / UIN 851368963 / 密钥 b21f44d / 249 表 / 26 条消息 / 2 张关键图片（含 1 张已删除）
环境：WSL2 Ubuntu + libewf + Sleuth Kit 4.x + Python3(cryptography)，封装工具为本地离线 .exe

说明：文中涉及的图片为教学演示样本（含明显占位水印与模板字段），不涉及真实身份信息。本文仅用于电子数据取证教学，请勿用于任何伪造用途以及其他用途。

敬请各位大佬关注：小谢取证

扫取二维码获取

更多精彩

小谢取证