证据文件格式与格式转换 - Wiki 文档

关键词：E01、EWF、segment 分段、RAW、VMDK、AFF4、QCOW2、ewfinfo、ewfexport、ewfacquire、格式转换难度：进阶 前置知识：磁盘镜像制作、压缩算法基本概念、MD5/SHA-256

一、概述

同一个物理磁盘的逐位副本，可以被包装成十几种完全不同的文件。选错格式影响的是证据可用性：数据可能无法被检验方打开、压缩后无法证明原始哈希、或者存储开销直接压垮预算。

格式选择的核心矛盾只有三个：

矛盾	说明
通用性 vs 效率	RAW 任何工具都能读但体积 1:1；E01 自带压缩与元数据但需要 EWF 库
自证性 vs 简洁性	E01/AFF4 内置哈希与采集元数据；RAW 什么都没有
可移植 vs 可管理	单文件便于传输；分段文件便于分卷与并行

为什么这件事值得单独成篇：镜像制作（01-镜像制作）在采集端就要决定输出格式，而那个决定的后果要到几周后才显现——当检验方打不开你的文件、或者你在转换过程中丢了哈希链时，返工成本极高。

格式不是采集时的技术细节，它直接决定这份检材在别人手上还有没有证据价值。在委托方要求"把检材直接交给我们分析"、或者需要通过邮件/网盘把几百 GB 的镜像传出去时，这个选择就是决定性的。

本篇处理的五种格式与它们的实质差别：

格式	结构要点	自带哈希	体积	谁需要它
RAW / dd	裸字节流，无任何元数据	❌	1:1	通用工具链、体积充足的外场场景
E01（EWF）	分段（Segment）结构，每段独立压缩	✅ 每段 + 整体	可压缩	法庭交付的主流选择
AFF4	段模型 + 任意元数据扩展	✅	可压缩	需要挂载为挂载点的场景
VMDK	两种形态：稀疏（extent 列表）/ 扁平（整块）	视形态而定	稀疏省空间	虚拟机仿真
VHDX	块级表 + 每块 CRC32	✅ 块级	动态增长	Hyper-V / 虚拟化平台

这张表里最容易被误解的一行是 E01 的"加密"。E01 内置的"加密"字段默认是弱加密，作用是阻止误读，不是保护机密——这一点必须先讲清楚，否则会有人以为"用了 E01 就安全了"，或者反过来以为"没设强密码就不专业"。相关技术在 2.4。

同一行的另一面是 VMDK 的两种形态：稀疏型只记录哪些块被占用（省空间，但依赖 backing file 链，链断了整个镜像就废了），扁平型是整块文件（简单直接，体积 1:1）。这个选择决定了仿真环境能不能被安全地"退场"——相关机制见虚拟机仿真。

另一条必须提前知道的规则：转换不改变数据内容，任何转换都必须能用哈希证明转换前后完全一致。

E01 → RAW 之后，RAW 文件的哈希应当等于原始采集时记录的哈希；不相等就说明转换过程出了问题（丢段、错位、编码问题），这个算式是本篇第四章 4.3 组的核心判据。

分段与哈希的连续性是本篇最需要提前想清楚的一层。 E01 把数据切成多个段（Segment），每段独立压缩、每段自带哈希、段有顺序。这带来一个实践后果：一个 500 GB 的镜像会是几百个文件，而"一个证据文件"这个概念在 E01 上是不成立的——正确的是"一个文件组"。

只拷贝其中一个 .E01 文件（常见于分段边界写错、或者用邮件/IM 传大文件时的分包错误），得到的是一段无法解释的碎片。本篇第四章 4.1 组专门处理这个，判定方法比"文件数对不对"要复杂，因为合法分段数取决于分段大小设置。

VMDK 的 backing file 链是同一类问题的另一种形态。 稀疏 VMDK 只记录"哪些块被写过"，未写入的部分指向一个父盘文件。父盘一旦移动或丢失，子盘就完全无法打开，而这在"把差分盘拷给别人分析"的场景里极易发生。

这两种格式的共同教训是：它们优化的都是存储效率，代价是"文件集合必须作为一个整体流转"。

在取证流程中的位置：本篇是采集与分析之间的转换层。上游是镜像制作——采集端可以直接输出 E01，也可以先出 RAW 再转，两条路径的记录要求不同。下游是所有读取环节：RAW 任何工具都能直接读，E01 需要 EWF 库或先转成 RAW，而转换本身是本篇要处理的证据链问题。读完之后进只读挂载与安全接入，需要动态行为观察则走虚拟机仿真（VMDK 格式正是那一篇的主要输入）。格式本身的规范定义在证据文件格式。

这个转换层的关键特点是：它是全流程里唯一一个"合法地主动改写检材副本"的环节。

其它环节要么只读（分析），要么根本不该碰原始检材（采集阶段用写保护器隔离）。只有转换，你明知道在做字节层面的改动，还要证明改动没改变内容。

理解这一点，本篇的所有判据就都能串起来了。

本篇能回答什么：五种格式的内部结构差异、E01 的分段与压缩机制、VMDK 两种形态的区别、如何用 ewfinfo 读出 E01 的元数据与采集信息、如何验证 E01 完整性、以及如何在转换后证明数据未变。

本篇不能回答什么：格式不能替代证据链——一个 E01 文件里没有采集者的身份、采集时间、工具版本，这些元数据齐备也不意味着证据链完整；内置哈希也不能替代外部记录——它只能证明"文件内部自洽"，不能证明"这个文件是从哪台设备来的"；以及格式本身在法庭上的可接受性，那是工具验证报告（CFTT / NIST 层面）的问题，不是文件结构的问题。

还有一个反向的能力边界值得写明：本篇的任何操作都不能恢复已经丢失的数据。 如果采集时 E01 分段参数设错导致丢段、或者压缩算法在转换时被误选，那部分数据在源文件里就已经不存在了——转换层能做的只是发现"对不上"，而发现之后的补救必须回到采集环节重新镜像。

这就是为什么本篇的所有方法论都指向同一个原则：每个可验证的环节都要留下可验证的记录。

读者前提：你需要先理解哈希在证据链中的作用（哈希与完整性校验），并能分辨"校验和"与"密码学哈希"在用途上的差别。格式选择的决策点在镜像制作，本篇讲的是选择之后如何处理。如果你还没做采集，直接读本篇第三章的第 1、2 步就够了——把 E01 转 RAW 和验证完整性是最常用的两个动作。

二、核心原理

2.1 五种格式的底层结构对比

维度	RAW / DD	E01 (EWF-E01)	VMDK	AFF4	QCOW2
本质	裸扇区流	压缩分块 + 表文件	虚拟磁盘描述 + 扩展文件	容器 + 段 + 元数据	稀疏 + 快照链
压缩	无	deflate / bzip2	无（可稀疏）	可选	可选
内置哈希	无	MD5 + 可选 SHA-1/256	无	有	无
采集元数据	无	有（案件号、勘验员、时间）	无	有	无
分段	手工 split	原生分段	稀疏扩展文件	段文件	后备链
加密	无	弱（见 2.4）	无	可选	AES（不推荐）
工具支持	★★★★★	★★★★	仅虚拟化软件	★★	★★★
存储开销	1:1	约 0.3–0.6:1	视稀疏度	视压缩	视稀疏度

关键认知：RAW 之所以仍是"最通用"的格式，恰恰因为它什么包装都没有——它就是数据本身。任何格式转换出问题时，RAW 是最后的可信基准。

2.2 E01 的分段（Segment）机制

这是 E01 最重要的设计。E01 实际是一组 .E01、.E02、.E03… 文件的集合，而非单个文件。第一个分段保存表数据（table data），后续分段保存数据块（table sections）。

DigiForensics.E01   ← 第 1 段：文件头 + 卷/表元数据 + 存储桶索引
DigiForensics.E02   ← 第 2 段：续表的表数据
DigiForensics.E03   ← 第 3 段：压缩后的数据块
DigiForensics.E04   ← 第 4 段：续续
...

分段大小（-S）的常见取值与用意：

取值	用意	适用
2 GB（业界默认/习惯值）	兼容老工具与老文件系统	绝大多数案件的推荐值
4 GB	在兼容与效率间折中	大容量盘，工具版本较新
1.4 GB（libewf 默认）	保守兼容	不指定时的工具默认
任意（EnCase 6/7）	>2 GB 分段	仅 encase6/encase7 格式支持

为什么 2 GB 成了默认约定：1990 年代末 FAT32 文件系统的单文件上限是 4 GB（更早是 2 GB）。分段设计让 E01 集合能跨越这个限制——拷到 FAT32 介质上不会因为单文件超限而失败。虽然现在很少有人用 FAT32 存证据，但 EnCase 等商业工具的兼容习惯被继承了下来，所以 2 GB 至今仍是安全选择。

分段带来的三个实际好处：

分卷传输：可以用 U 盘、光盘等介质分批搬运，途中某一段损坏只需重传该段
并行处理：ewfverify/e01hash 可多线程并发校验多段
细粒度归档：归档时按段粒度打包，不必动整个证据集

分段带来的一个坑：DigiForensics.E03 单独存在时毫无意义——它依赖 .E01 中的索引才能定位数据。传输或归档时必须整组一起处理。只拷走某个中间段，得到的是损坏的证据。

2.3 E01 的压缩与编码

压缩方式	说明
`none`	不压缩，体积 1:1，但速度快
`empty-block`	只压缩全零块（已删除的空间常是全零），压缩率一般但极快
`fast`	deflate 快速档
`best`	deflate 最大压缩率，取证默认首选

压缩是逐 chunk 独立进行的（chunk 由 -b 指定，默认 64 扇区 = 32 KB）。这带来一个重要性质：支持随机访问。读取某个偏移时，只需解压它所在的 chunk，不必从头解压整个镜像。

这也是 E01 比"把整个盘 gzip 一下"快得多的原因。

2.4 E01 的"加密"：一个必须说清的事实

E01 的密码功能不是加密。 EnCase 的 legacy password 只是一个存储在文件头中的校验值，用于阻止非授权工具修改 E01，不提供任何机密性。

绕开取证工具直接处理文件即可读取内容；设密码反而降低可审计性——他人无法用工具验证你的镜像。

结论：不要给证据文件设置密码。 它不提供安全价值，只制造麻烦。需要保护介质时用磁盘级加密（LUKS / BitLocker To Go），并单独记录密钥保管流程。

2.5 VMDK 的两种形态

形态	结构	陷阱
单体 VMDK	一个 `.vmdk` 文件，含描述符+数据	简单，但无压缩
分裂 VMDK（split）	一个几 KB 的描述符 `.vmdk` + 多个 `-s001.vmdk` 扩展文件	只拷描述符 = 只拷了个 2 KB 的文本清单，磁盘数据全在扩展文件里

分裂 VMDK 的 2 GB 分片同样是 FAT32 时代的遗产。取证时必须拷贝整个目录。

2.6 转换时哈希的连续性

转换是最容易破坏证据链的操作，因为原始哈希是基于源格式的。正确做法是建立一条链：

原始检材 ──制作时计算──> DigiForensics.E01（内置 MD5 + SHA-256）
                              │ ewfexport
                              ▼
                      DigiForensics.dd（独立复算 SHA-256）

只有当两端 SHA-256 相同时，才能说"转换保持了数据完整性"。 "文件能打开""大小一致"都不构成验证。

三、操作步骤

3.1 第 1 步：用 ewfinfo 查看 E01 元数据

sudo apt install ewf-tools        # Ubuntu / Debian
ewfinfo -d iso8601 /evidence/DigiForensics.E01

典型输出与解读：

Acquiry information
Case number:        CASE-2026-0142
Description:        Dell OptiPlex 7010 512GB SSD
Examiner name:      勘验员姓名
Acquisition date:   2026-09-28T14:32:07+00:00
EWF information
File format:        EnCase 6
Sectors per chunk:  64                ← chunk = 32 KB
Compression method: deflate
Compression level:  best compression
Set identifier:     869910fc-e143-4908-9328-afedf4a7be1e
Media information
Media type:         fixed disk
Is physical:        yes
Bytes per sector:   512
Number of sectors:  1000215216
Media size:         478.9 GiB (514110344448 bytes)
Digest hash information
MD5:                ae1ce8f5ac079d3ee93f97fe3792bda3
SHA-1:              3b1e...

Set identifier 是同一个采集任务的全集标识——同一台机器的多块盘会有相同的 Set identifier。这个字段在多盘案件中用来证明"这几块盘是在同一次采集任务中获取的"，很有价值。

常用选项：-m 只看介质信息、-i 只看采集信息、-e 只看读错误信息、-f dfxml 输出 DFXML。

3.2 第 2 步：验证 E01 完整性

# 校验镜像与其内置哈希（libewf 标准工具）
ewfverify /evidence/DigiForensics.E01

输出会逐项报告 MD5/SHA-1/SHA-256 的校验结果，"success" 才是通过。不同 libewf 版本支持的参数略有差异，脚本化前先跑 ewfverify --help 确认本机能力。

3.3 第 3 步：E01 → RAW 导出

完整命令见第七节。关键点：

参数	含义
`-f raw`	输出格式：`raw` / `files` / `ewf` / `encase6` / `encase7` / `ftk` / `ewfx` 等
`-t`	目标文件名（不带扩展名）；填 `-` 可写 stdout（仅 raw 支持）
`-S`	分段大小，libewf 默认 1.4 GiB
`-b`	每 chunk 读取扇区数（16–32768，默认 64）
`-o` / `-B`	起始偏移 / 导出字节数，用于只导出部分卷
`-u`	无交互模式
`-l`	日志（同时记录 MD5 摘要）
`-d sha1`	追加摘要，但 `raw` 与 `files` 格式下该值不生效

导出后立即验证：sha256sum 算出的值与 ewfinfo -m 报告的 E01 内置 SHA-256 必须逐字符一致。不一致说明导出过程有问题（磁盘满、传输损坏、源 E01 本身损坏），必须查明原因后才能继续。

3.4 第 4 步：RAW → E01 转换

把已有 dd 镜像包装成 E01（用于压缩归档或交付检验方），源参数用文件路径：

ewfacquire -u \
  -t /evidence/DigiForensics-archived \
  -f encase6 -c deflate:best -d sha256 -S 2G \
  -C "CASE-2026-0142" -E "E-001" \
  -D "由 DigiForensics.dd 转换而来" -e "勘验员姓名" \
  -l /evidence/convert.log \
  /evidence/DigiForensics.dd

转换后必须验证：先 ewfverify 新 E01，再确认它的内置 MD5 与原 dd 的 md5sum 一致。

3.5 第 5 步：其他转换路径与归档记录

qemu-img 与 xmount 的完整调用见第七节（VMDK 拆分时需指定具体扩展文件）