微信dat文件解析：异或密钥推导与Python批量还原

简介这款微信dat文件解析工具专门面向需要从微信电脑客户端中提取图片和表情包的用户可解析本地聊天数据中的.dat文件将其恢复为JPG、PNG等通用图片格式方便后续查看、存档或二次编辑。资源共241个文件压缩包大小约86.17MB其中exe为直接运行的程序入口dll与jar承担核心解析和跨平台支持properties与cfg等文件用于参数配置gif文件可作为转换效果参考整体目录结构清晰便于使用者定位所需模块。目前已有2568人学习/下载适合需要批量备份微信图片素材、整理自定义表情包或利用图片素材进行二次创作的人群。工具在设计上明确不读取聊天记录注重隐私边界同时内置了必要的运行组件降低了普通用户手动处理二进制文件的难度使不熟悉内部数据结构的用户也能快速上手。对于受微信本地文件加密存储困扰的用户而言这份工具包提供了直接可用的解析方案。1. 微信 dat 文件不是加密是异或混淆想备份图片先看这篇第一次在电脑端微信的目录里看到 .dat多数人的第一反应是“微信把图片加密了”。实际拆过字节就知道微信电脑端没用任何真正的加密算法它只是拿一个单字节密钥把 JPG、PNG、GIF 原始文件里的每个字节逐个异或了一遍让文件头变得不可读。微信dat文件解析工具要做的就是把这个密钥找出来把异或反转回去让图片恢复到能打开、能归档的 jpg/png/gif。这篇文章从原理一路讲到可复现的 Python 脚本覆盖 PC 微信 3.x/4.x 常见目录、图片与表情包的区别以及批量转换时真正让新手翻车的细节适合要备份聊天图片、整理本地数据或准备做私有化图片归档工具的工程师直接照做。2. 一个字节定密钥从文件头反推微信 dat 的异或规则如果说“加密”是黑匣子那 XOR 混淆更像一层窗户纸。微信为什么选择这种在密码学上毫无强度、却又广为流传的做法我的判断是性能优先本地聊天记录如果每次读取图片都要走一遍真正解密CPU 开销会放大而单字节异或在现代 CPU 上是极廉价的逐字节操作。微信显然没有把这层混淆当作安全边界它只是让普通用户不能直接双击打开、不能直接拷贝替换属典型的防君子不防小人。对要做数据恢复、图片归档的人来说这反而是好消息密钥规律足够简单解析工具只需十几行核心代码就能还原。2.1 异或规则是整文件同一个 key不是分块加密一个常见错误认知是微信会不会对文件分块、每块用不同 key我处理过多个版本的微信缓存绝大多数 dat 图片是同一个 key 从头到尾作用于整个文件。也就是说只要拿到一个 key后续所有字节都能逐字节还原。这个结论可以用很简单的抽样验证把同一目录下两个不同 dat 文件的对应字节再做一次异或如果结果出现可读的文件头相似性说明它们只差一个固定偏移更直接的办法是枚举常见文件头去试 key下面马上写。为什么两个字节就够单字节异或的前提是原始字节流头部是确定的 magic。JPG 以FF D8 FF开头PNG 以89 50 4E 47开头GIF 以GIF89a开头。加密后的第一个字节等于原始首字节异或 key所以key 加密首字节 XOR 原始首字节再用第二个字节验证加密第二字节 XOR key是否等于原始第二字节。两个字节都命中格式和 key 基本就锁定了。2.2 常见图片格式的文件头与密钥推导公式原始格式文件头十六进制开头两个字节JPGFF D8 FF E0 / FF D8 FF E10xFF 0xD8PNG89 50 4E 47 0D 0A0x89 0x50GIF47 49 46 38 39 61GIF89a0x47 0x49BMP42 4D0x42 0x4D推导公式写成这样假设是 JPG那么key dat_bytes[0] ^ 0xFF再检查dat_bytes[1] ^ key 0xD8。如果成立基本可以确定是 JPG不成立就换 PNG 的0x89和0x50继续试。只取首字节和第二个字节验证即可不需要读完整个文件。四种 magic 都验证失败时这个 dat 很可能不是图片或表情包比如微信登录态文件、数据库分片或其他缓存不要把它当作“key 找错了”先跳过更省事。2.3 手工推算 key 的最小 Python 片段下面这个脚本足够做手工验证批量落地时再把它接进完整工具。from pathlib import Path MAGIC { jpg: b\xff\xd8, png: b\x89P, gif: bGIF, bmp: bBM, } def detect_key(raw_head: bytes): 仅凭前两个字节反推单字节异或 key for ext, magic in MAGIC.items(): key raw_head[0] ^ magic[0] if (raw_head[1] ^ key) magic[1]: return ext, key return None, None if __name__ __main__: p Path(rD:\temp\img_0.dat) head p.read_bytes()[:2] ext, key detect_key(head) print(ext, key if key is not None else unknown)raw_head[0] ^ magic[0]是反向求 key第二步校验raw_head[1]与 key 异或后是否等于第二个 magic 字节。循环里按 JPG、PNG、GIF、BMP 的顺序试命中即返回。如果返回 unknown不要急着认定文件损坏先确认这个 dat 是不是真的来自Image或Emoji目录。这段脚本仅供验证批量处理时还要考虑路径、线程、日志和重复文件放到下一章。2.4 为什么有些 dat 用“假定 JPG”解不出来我见过最多的翻车是把所有 dat 都当 JPG 处理。微信发图会根据图片来源选择不同容器相机原图多是 JPG截图另存是 PNG动图是 GIF自定义表情包也可能是 GIF 或 PNG。全局按 JPG 猜 key遇到 PNG 和 GIF 就会解出花屏或打不开。正确做法是让每个文件独立做四次 magic 试探而不是先猜一个格式再批量套用。另一个坑是微信 4.x 新版的某些临时文件也用.dat后缀但根本不是图片直接跳过可以省很多时间。2.5 为什么有的工具会声称“所有 dat 同一 key”微信在某个会话、某个时间段写入的图片大多数时候是同一 key因为客户端在不同版本会用固定 key。很多在线小工具也因此只做“入目录→导出目录”不做识别。但对混合来源目录保险起见逐文件识别成本几乎为零本方案就按逐文件识别设计。3. 把微信dat文件解析工具写成 Python 脚本目录定位、多线程转出上一章把原理讲透了这一章给出完整实现。工具负责三件事定位微信 dat 所在目录、对每个文件独立推 key、按真实文件头写出正确后缀。为了避免把你的聊天记录目录写乱主程序会带--dry-run分支先预览再执行。3.1 先定位微信电脑端把 dat 放在哪些目录不同版本目录不一样。老版本 3.x 常见在C:\Users\用户名\Documents\WeChat Files\微信号\FileStorage\Image\2023-06\下4.x 之后一部分机器改成了C:\Users\用户名\Documents\xwechat_files\微信号\FileStorage\Image\...。表情包则在同级的Emoji目录。与其背路径不如直接在微信“设置—文件管理”里看当前存储位置然后把根目录记下来。我用脚本只处理FileStorage以内的Image和Emoji子目录避免把整个WeChat Files都扫一遍那里还有聊天数据库、临时文件和其它非 dat 缓存。可以用下面的 Python 片段快速定位到 FileStorage 根from pathlib import Path def find_storage_roots() - list[Path]: docs Path.home() / Documents roots [] for base_name in (WeChat Files, xwechat_files): base docs / base_name if not base.exists(): continue for account_dir in base.glob(*): storage account_dir / FileStorage if storage.exists(): roots.append(storage) return roots for root in find_storage_roots(): print(root)这个函数只收集到FileStorage一级后面的rglob(*.dat)就在这个范围内做不会扫到微信的数据库和配置目录。如果返回空列表大概率微信数据目录被迁移到了其它盘或自定义了位置去微信设置里看一眼就能确认。3.2 核心转换函数异或还原 文件头识别写转换函数之前先定义文件头识别函数。这里不用 Python 3.13 中已被移除的imghdr直接用 magic 匹配行为完全可控。from pathlib import Path HEADER_MAGIC [ (jpg, b\xff\xd8\xff), (png, b\x89\x50\x4e\x47), (gif, b\x47\x49\x46\x38), (bmp, b\x42\x4d), ] def sniff_ext(head: bytes): 用文件头判断解码后的真实格式返回扩展名或 None for ext, magic in HEADER_MAGIC: if head.startswith(magic): return ext return None def dat_to_image(src: Path, out: Path, key: int) - str | None: 把单个 dat 还原成图片返回输出路径识别失败返回 None data src.read_bytes() dec bytearray(len(data)) for i in range(len(data)): dec[i] data[i] ^ key ext sniff_ext(bytes(dec[:16])) if ext is None: return None out out.with_suffix(. ext) if not out.parent.exists(): out.parent.mkdir(parentsTrue, exist_okTrue) out.write_bytes(dec) return str(out)sniff_ext用前 16 字节而不是 2 字节是因为 JPG 的第三字节FF、PNG 的第四字节4E能进一步压低误判概率。bytearray在循环里逐字节写入比反复拼接 bytes 开销小这是处理几万个小文件时肉眼可见的差别。调用时注意out要传“无后缀”路径因为with_suffix会替换掉原有后缀如果传入xxx.jpg就会被换成.png反而出错。3.3 批量转换主程序多线程、min_size 与 dry_run批量执行要控制三个参数线程数、最小文件大小、是否只预览。线程数默认 4 而不是 CPU 核数因为这种小文件任务是 IO 密集线程太多反而把时间花在锁和上下文切换上。from concurrent.futures import ThreadPoolExecutor def detect_key_strict(head: bytes): 三字节校验进一步降低误报 for ext, magic in HEADER_MAGIC: k0 head[0] ^ magic[0] if all((head[i] ^ k0) magic[i] for i in range(1, min(len(magic), len(head)))): return ext, k0 return None, None def process_one(src: Path, src_root: Path, out_root: Path, min_size: int): if src.stat().st_size min_size: return head src.read_bytes()[:16] ext, key detect_key_strict(head) if ext is None: print(f[skip] 非图片 dat: {src.name}) return rel src.relative_to(src_root) out out_root / rel.with_suffix() dat_to_image(src, out, key) def extract_all(src_root: Path, out_root: Path, workers4, min_size1024): out_root.mkdir(parentsTrue, exist_okTrue) dat_files [p for p in src_root.rglob(*.dat)] with ThreadPoolExecutor(max_workersworkers) as pool: pool.map(lambda p: process_one(p, src_root, out_root, min_size), dat_files)detect_key_strict用的是三字节甚至四字节校验误报概率从二字节的 1/256 降到 1/65536 以下。min_size1024用来过滤 1KB 以下的缩略图和空文件——Image 目录里的thumb子目录经常产出几百字节的小图解出来也没归档价值。pool.map会保持任务顺序对日志友好文件数量极大时可以把dat_files换成生成器分批提交避免一次性把所有路径装进内存。命令行调用可以这样写加上--dry-run先看计划python weixin_dat_tool.py --src D:\MyWeChat\FileStorage \ --out E:\WeChatExport \ --workers 4 --min-size 5120 --dry-run--dry-run只扫描、识别、打印前若干个文件的结果不真正落盘。第一次跑新目录时先用它确认 key 和格式识别正常再放开全量转换。3.4 二次校验解出来的文件要能通过文件头复查转换完不等于结束还要抽查输出目录。微信不同版本的 dat 文件头部偶尔会出现偏移导致两字节校验通过、写出的图片却打不开。稳妥做法是转换后对输出文件再做一次sniff_ext和后缀比对for img in out_root.rglob(*): if not img.is_file(): continue ext sniff_ext(img.read_bytes()[:16]) if ext and img.suffix.lstrip(.) ! ext: print(f[warn] 后缀异常: {img} - .{ext})如果输出文件后缀和实际 magic 不一致说明写入阶段出了问题手动删掉重转那一批。大型目录里出现几条 warn 是正常的尤其是 GIF 和 PNG 混存的Emoji目录如果 warn 数量超过 1%优先怀疑detect_key_strict的 magic 表不全而不是文件本身坏了。4. 图片和表情包分开转目录差异、GIF 判定与输出命名很多人在微信 dat 转换时只盯着Image目录忽略了表情包也有人把所有 dat 混在一个输出目录里导致原图和缩略图、静态图和动图搅在一起。这一章把图片和表情包的差异拆开说清楚命名和去重策略。4.1 Image 与 Emoji 是两套不同的数据子目录内容重点关注FileStorage/Image聊天中的图片按YYYY-MM分目录原图外常见 Thumb 缩略图FileStorage/Emoji表情包、自定义表情包含 GIF 动图文件名随机重复表情多FileStorage/File聊天中传输的文件不一定是图片不要纳入图片转换流程两套目录建议分开输出因为后续处理策略不同Image 里的原图要保留原始时间顺序Emoji 里的 GIF 动图必须原样保存不能重编码。缩略图是 Image 目录里最占数量的干扰项遍历时按路径排除比事后按大小过滤更直接if any(part.lower() in (thumb, thumbs) for part in src.relative_to(src_root).parts): return这里relative_to(...).parts会把路径拆成元组只要某一层叫thumb或thumbs就跳过。这个判断放在process_one入参校验处能减少后续无效的read_bytes。4.2 按文件头决定扩展名而不是按 dat 文件名微信 dat 文件名形如f7a2e3...dat是随机生成的和原始图片名没有对应关系。我见过有人拿“dat 转 jpg”的在线工具一张张转慢不说遇到 GIF 会输出一张静态帧表情包直接废掉。正确姿势是用sniff_ext判断解码后的真实格式输出后缀由文件头决定。后续想统一成 JPG也请在解析完成后用 Pillow 转码而不是硬改扩展名——改后缀只会让图片软件按错误格式解码得到一张损坏图。4.3 重命名策略时间戳 MD5 去重同一张表情被发送多次在 Emoji 目录里会留下多个 dat解出来内容完全相同。直接按原文件名保存会得到一堆f7a2...jpg既不直观也没法去重。我一般用源文件 mtime 和 MD5 前 8 位拼一个可排序的名字import hashlib from datetime import datetime def unique_output_name(output_dir: Path, mtime: float, ext: str, data: bytes): digest hashlib.md5(data).hexdigest()[:8] ts datetime.fromtimestamp(mtime).strftime(%Y%m%d_%H%M%S) candidate output_dir / f{ts}_{digest}.{ext} n 1 while candidate.exists(): candidate output_dir / f{ts}_{digest}_{n}.{ext} n 1 return candidateMD5 前 8 位带来的是 32 位哈希空间个人归档场景够用while candidate.exists()兜底碰撞保证不覆盖已有文件。为什么用mtime而不是原始文件名因为 dat 文件名已经没有语义而 mtime 约等于图片写入本地的时间归档后一眼能看出哪些是某个月份的聊天图片。需要特别说明mtime 只是本地落盘时间不是对方发消息的精确时间这个方案只保证排序和去重不保证语义正确。4.4 表情包场景GIF 动图不要重编码GIF 文件头识别到后只做异或还原并原样保存不要调用 Pillow 再存一遍。GIF 支持多帧、透明和局部调色板重编码极容易丢动画或变色。转换工具的唯一职责是异或还原格式转换是另一码事。如果确实需要缩略图用 Pillow 打开第一帧做预览是安全的因为只读不写。微信自定义表情包的历史表情可能放在Emoji\custom这类子目录代码里用rglob(*.dat)不用关心具体层级路径过滤只挡thumb即可。5. 微信 dat 转换避坑清单5 个让新人翻车的场景下面五条是实际跑这个方案时最常遇到的问题按现象、原因、解决的顺序写你可以直接对照排查。5.1 转换出的图片花屏现象解出来的文件能打开但渲染出马赛克、色块或直接提示文件损坏。原因用了一个错误的 key而且这个错误 key 对文件头的第二个校验字节碰巧通过了概率 1/256导致文件写入后才发现。解决不要只看前两个字节把校验扩展到第三、第四字节也就是前面写的detect_key_strict。输出后再用sniff_ext对文件头做二次确认四种 magic 全部失败就跳过不写入目标目录。三字节校验会把误报概率压到接近 1/65536四字节更稳。5.2 按旧路径找不到 dat 文件现象按教程里的Documents\WeChat Files去找目录不存在或为空。原因微信 4.x 后部分安装把数据根目录改成了xwechat_files也有人手动把微信文件存储位置迁移到了其它盘。解决打开电脑微信的“设置—文件管理”看“聊天文件存储位置”那一项以它为准。如果机器上同时装了 3.x 和 4.x两个根目录都扫一遍。不要全盘rglob(*.dat)——磁盘上其它程序的 dat 后缀文件会拖慢扫描还干扰识别结果。5.3 转出来全是几十 KB 的小图原图没找到现象Image 目录转出一堆几百字节到几 KB 的图期待的聊天原图找不到。原因微信把缩略图放在当前目录或同级Thumb/thumbs子目录遍历时没有排除缩略图数量大输出时把原图淹没了。解决遍历路径时跳过含thumb的目录同时把min_size调高。典型参数聊天原图通常在几十 KB 以上自定义表情常见 100KB 到 1MB--min-size 5120可以先过滤掉 5KB 以下的缩略图如果还有遗漏再往下调。5.4 提示 PermissionError微信正在占用现象脚本跑到某个文件时报PermissionError: [Errno 13] Permission denied。原因微信客户端正开着部分 dat 文件被进程独占锁定Windows 下无法读取。解决转换前先退出电脑微信最干净。不想退出客户端时用robocopy 源目录 临时目录 /E /XF *.db先把FileStorage复制一份再处理复制完退出微信也可以。不需要第三方解锁工具关闭程序就是最有效的解锁方式。5.5 多线程开太大内存反而先爆现象workers32跑几万个文件内存占用飙升甚至程序被杀。原因每个线程同时read_bytes()整个图片32 个线程同时把字节串、bytearray、路径对象堆在内存里数量一多会明显膨胀更怕的是聊天里混着几十 MB 的“原图”。解决默认 4 个 worker 足够这种小文件任务是 IO 密集4 线程对 SATA/机械盘已经是上限附近。大文件可以加max_size过滤或分目录分批处理。把rglob结果改成生成器分批提交能进一步控制任务队列积压多线程才真正省时间而不是省内存。6. 给脚本加一个本地微信dat文件查看器模式预览、增量与清理批量转换跑通之后日常使用还要解决三个问题怎么确认 key 没选错、重复跑会不会浪费时间、清理时会不会误删源文件。这一章把最后三板斧补上。6.1 预览模式不落盘先生成缩略图跑全量之前先对每个子目录挑两个样本只解前 256KB 并生成缩略图拼到一个 HTML 索引页里。这样不用翻开磁盘目录浏览器里就能确认图片内容正常。from io import BytesIO from PIL import Image import base64 def preview_one(src: Path, key: int) - str: dec bytes(b ^ key for b in src.read_bytes()[: 256 * 1024]) img Image.open(BytesIO(dec)) img.thumbnail((120, 120)) buf BytesIO() img.save(buf, formatJPEG) return fimg srcdata:image/jpeg;base64,{base64.b64encode(buf.getvalue()).decode()}bytes(b ^ key for b in ...)只处理前 256KBJPG 缩略图足够渲染GIF 预览第一帧也够。如果 Pillow 在这里打不开说明 key 识别错了全量转换前就能发现。6.2 增量转换只处理新出现的 dat微信每天都会产生新图片重复全量转换会越跑越慢。用一个小 JSON 记录每个源文件的大小和 mtime下次转换时先比对def is_done(record, src: Path, out: Path): return (record.get(size) src.stat().st_size and record.get(mtime) src.stat().st_mtime and out.exists())微信重新下载或覆盖同一 dat 时 mtime 会变大小加 mtime 能覆盖大多数增量场景不用每个文件算 MD5速度更快。这个逻辑适合长期开着微信、每天都有新聊天图片的使用习惯。6.3 一条命令收尾dry-run → 全量 → 清理python weixin_dat_tool.py --src D:\MyWeChat\FileStorage \ --out E:\WeChatExport \ --workers 4 --min-size 5120 --preview --dry-run先带--dry-run看计划确认无误后去掉该参数跑全量。清理时只删输出目录里sniff_ext失败的文件源 dat 一律保留等确认目标图片全部正常后再手动删源目录。我有一次直接全量转换到源目录把一批 dat 覆盖掉从那以后输出目录永远放另一个盘且每次先 dry-run 再动手。这套流程我已经沿用了很久希望帮到你。本文还有配套的精品资源点击获取