一、概述
把一块 2 TB 硬盘完整复制下来，产出的那个 2 TB 文件就是 DD 镜像。
它最通用，最没有争议，也最脆弱。写到第 900 GB 断电，前面的成果全部作废。每做一次跨机拷贝，就多一次静默损坏的机会。更要命的是，它不记得自己是谁、从哪来、谁做的。
镜像文件不像案件卷宗那样装在档案袋里，它就是检材的副本。可副本和检材在法庭上是两件事——检材是原件，副本得自己说清"我是从哪个编号的检材、在谁的见证下、什么时候、用什么设备、以什么哈希复制出来的"。DD 做不到，E01 和 AFF4 可以。
要解决的无非三件事：用什么格式落盘，这个格式能不能自证没被改动，以及被打散成几十个文件之后还拼不拼得回去。
格式选择发生在采集环节的最后一步，位置很尴尬，它决定了后面所有分析步骤的输入形态。选成 E01，后面拿到的是压缩分段容器，任何只认裸流的工具都得先 ewfmount。选成 DD，后面一切直接，但交付时"这个文件凭什么可信"这个问题得你自己扛。
上游依赖两件事：镜像制作 决定了采集时的读取参数与坏扇区策略，取证装备与写保护器 决定了读出这些字节的通道是否可信。
下游支撑两件事：只读挂载与虚拟机仿真直接消费容器，而证据保管链与委托证明记录的一切哈希值，都依赖于"你哈希的到底是哪一层字节"这个问题有明确答案。
哈希这件事第四章陷阱 4 会展开：E01 内嵌的哈希针对解压后的原始字节流，对 E01 文件本身算哈希得到的是压缩后容器的指纹。这两个值不是一回事。混淆的代价是报告里出现一个指向不明、实际指控了错误对象的"完整性问题"。
落盘的容器长这样：
DigiForensics.E01 — EnCase 6 格式，文件头以 EVF 加 6 字节序列起始，内含 table / hash / x64 等 section，单块压缩默认 64 扇区 × 512 字节 = 32 KBDigiForensics.E02 … .E99 … .zzz — 续段。1 TB 介质通常产出约 26 个段文件，段序内嵌在文件头偏移 0x09DigiForensics.L01 — 同一个容器家族的不压缩变体，用于源介质已损坏、可能多次重读的场景DigiForensics.dd — 无文件头的裸比特流，没有自校验能力DigiForensics-sim.vmdk — 仿真用虚拟磁盘，文件头 KDMV，不含取证元数据.rdf 旁文件 — AFF4 的 RDF/XML 描述，承载案件编号、采集人、扩展属性DigiForensics_E01.tar — 交付包。它的哈希与 E01 内嵌哈希是两个不同的值，作用完全不同
拿到一个容器，能判断的是这些：段数对不对（完整性）、内嵌哈希能不能复现（内容有没有被动过）、.E01 与 .L01 在损坏源上的行为差异（能否安全地重复读取）、以及归档件应该交哪一个文件。
有几件事不归这里管。采集通道本身可不可信——写保护器是否真的阻断写入、坏扇区怎么处理，是镜像制作与装备篇的事。容器里装的字节对不对——分段和压缩都不改变原始内容，格式正确不等于内容正确。仿真跑出来的结果算不算检材——仿真是分析员主动制造的状态，第四章陷阱 8 讲清它必须单独登记，不能混进检材引用。怎么把 2 TB 跨机搬完——传输中断、断点续传、跨网段完整性是工程问题，这里只管搬完之后怎么验。
往下读之前，先确认你已经知道扇区与簇的层级关系（不然读不懂分段和 chunk）、哈希能证明什么不能证明什么（见哈希与完整性校验）、以及"只读接入"是纪律不是偏好（见只读挂载与安全接入）。
连"哈希算的是哪一段字节"都没概念的话，先回去读哈希篇，否则第四章陷阱 4 会变成你看不懂的题。
二、核心原理
2.1 格式总览
| 格式 |
文件头特征 |
压缩 |
内嵌哈希 |
元数据 |
典型用途 |
| DD / RAW |
无（裸比特流） |
无 |
无 |
无 |
实验室内部、大容量转存 |
| E01 |
EVF 起始 |
zlib/bzip2 |
MD5+SHA-1/SHA-256 |
有 |
正式交付、跨机构流转 |
| VMDK |
KDMV 起始 |
无 |
无 |
有 |
挂载到虚拟机做仿真 |
| AFF4 |
AFF4\\x00 起始 |
可变/zlib |
可配置 |
强（XML 描述） |
新型综合场景 |
| L01 |
LVF/EVF |
不压缩 |
有 |
有 |
超大镜像，规避 2 GB 分段限制 |
2.2 DD/RAW：裸比特流的本质
DD 镜像没有文件头。它就是按顺序排列的扇区。
好处是任何工具都能读，兼容性拉满。代价同样直接：镜像文件头部 512 字节一坏，整盘在工具眼里就是空的，而且未必告警。完整性只能靠你在外部记录的哈希——镜像自己不会说话。
确认它确实是裸流：前若干字节应直接呈现分区表特征
xxd -l 64 DigiForensics.dd
典型 MBR 签名：偏移 0x1FE 处为 55 AA
2.3 E01 的分段机制
E01 的核心设计是把一个大镜像拆成多个不超过约 2 GB 的段文件：
DigiForensics.E01 ← 第 1 段
DigiForensics.E02 ← 第 2 段
DigiForensics.E03 ← 第 3 段
...
DigiForensics.E99 ← 第 99 段
DigiForensics.EAA ← 之后改用字母后缀
DigiForensics.zzz ← 理论上限
每个段文件开头都是 13 字节的文件头：
偏移 0x00 8 字节 签名 "EVF" + 09 0D 0A FF 00
偏移 0x08 1 字节 0x01（字段区起始标记）
偏移 0x09 2 字节 段序号（从 1 开始）
偏移 0x0B 2 字节 0x0000（字段区结束标记）
⚠️ 关键点：一个 section 不能跨段文件。因此每段边界会形成一个"接缝"，压缩数据在接缝处结束。理解了这一点，才能解释为什么 E01 转换回 DD 后，某些偏移上的压缩块大小不连续。
2.4 E01 的 chunk、压缩与 CRC
| 概念 |
说明 |
| Chunk（块） |
每块默认 64 个扇区 × 512 字节 = 32 KB 原始数据 |
| 压缩 |
每块独立压缩（zlib/bzip2），因此可随机访问任意偏移而无需解压全文 |
| CRC32 |
每个 section 带 CRC32；压缩块用最高位标记是否压缩 |
| Table section |
记录每个 chunk 在哪个段文件的哪个偏移，实现快速随机读取 |
| Hash section |
存放采集时计算的 MD5 / SHA-1 / SHA-256，针对解压后的原始字节流 |
正因为每块独立压缩，E01 才能随机访问——直接跳到偏移 0x10000000 那一块读，不用解压前面所有数据。DD 做不到这点。
压缩比不如整体压缩，是这个设计要付的账。
E01 的元数据以制表符和换行分隔的文本形式存在（zlib 压缩后放在 header section），常见字段：
c 案件编号
n 证据编号
e 鉴定人/操作者
a 唯一描述
m 采集日期
av 生成程序与版本
2.5 VMDK 的定位
VMDK 是虚拟磁盘格式。取证场景里主要两个用途：
- 把镜像挂进虚拟机仿真，让系统"自己跑起来"以触发应用加载数据
- 作为中间交换格式，在工具链之间传递
但它不适合作为最终归档格式：没有内嵌取证元数据，也不内嵌采集哈希。归档仍应落到 E01 或 AFF4。
2.6 AFF4：面向未来的容器
AFF4 的设计哲学不同。它不规定"镜像长什么样"，而是提供一个描述数据流的框架：
- 图像被抽象为
ImageStream（体积/哈希/压缩方式都可配置）
- 元数据用 RDF/XML（.rdf 旁文件） 表达，可携带任意扩展属性
- 天然支持"一个证据容器里有多个流"（如同时包含磁盘镜像、内存镜像、pcap）
2.7 实际选择的决策表
| 约束条件 |
建议格式 |
理由 |
| 需要交付给对方/跨机构流转 |
E01 |
内嵌哈希+元数据，通用可验证 |
| 实验室内部、存储充裕、追求速度 |
DD |
写入最快，无压缩开销 |
| 需要挂载进虚拟机 |
VMDK（或 E01 后转 VMDK） |
虚拟化软件直接可用 |
| 需要同时存多路数据 + 强元数据 |
AFF4 |
可扩展容器 |
| 原始介质已损坏、可能读出不同结果 |
L01 或带 hashconv 的 E01 |
不压缩，支持多次校验 |
| 对端设备明确只认 RAW |
先存 E01，再导出 DD |
保留归档同时满足兼容 |
三、操作步骤
步骤 1：采集时直接产出 E01
ewfacquire：libewf 套件的命令行采集工具
sudo ewfacquire -t /case/DigiForensics
-f encase6 -c deflate:best -d sha256
-C "2024-DG-001" -E "01" -e "Examiner"
-D "Laptop SSD 1TB"
/dev/sdX
产出 DigiForensics.E01 及后续段文件。-d sha256 让它同时记录哈希。
步骤 2：查看与验证 E01
查看容器信息（段数、尺寸、采集元数据）
ewfinfo DigiForensics.E01
验证完整性——对照容器内嵌的哈希重算
ewfverify DigiForensics.E01
ewfverify 是"证据文件自检"的标准动作。输出里会分别给出 MD5 与 SHA-256 的校验结果。
步骤 3：挂载为裸流以使用只读工具
ewfmount 把 E01 呈现为一个可读的裸镜像文件
sudo mkdir -p /mnt/ewf
sudo ewfmount DigiForensics.E01 /mnt/ewf
挂载后裸流位于 /mnt/ewf/ewf1
现在任何只认 raw 的工具都能直接用
sudo fdisk -l /mnt/ewf/ewf1
用完后必须正常卸载
sudo umount /mnt/ewf/ewf1 && sudo rmdir /mnt/ewf
步骤 4：格式转换
E01 → DD（导出裸流，体积会显著变大）
sudo ewfexport -t /case/DigiForensics-dd -f raw DigiForensics.E01
DD → E01（Linux 侧）
sudo ewfimage -t /case/DigiForensics -f encase6 -c def
