磁盘镜像制作与证据固定

一、概述

只有这一步会物理接触原始检材。

产出的镜像就是后面所有分析的天花板。镜像阶段丢了数据、混进了写操作、或者哈希链断了，后面再精巧的结论都站不住。

目标很直白：不改变检材状态，尽可能忠实地复制出每一位（bit）。三个关键词缺一不可：

目标	含义	保障手段
完整	全盘逐扇区复制，含分区表、未分配空间、删除文件残留	全盘而非分区、不启用稀疏跳过
忠实	不引入任何非原始数据的写入	硬件写保护器、只读接入
可证	能证明镜像与原始检材逐位一致	制作时同步计算哈希 + 日志

翻车都集中在这三处：选错源设备（系统盘当数据盘，或者 if= 与 of= 写反直接把检材覆盖掉）、裸拷贝不做哈希（事后补不回来）、忽略源盘正在被系统使用（在线制作时文件系统还在写，镜像内部自相矛盾）。

最贵的是 if= 与 of= 写反。命令行上这两个参数长得几乎一样，写反了就是把镜像内容直接写进原始检材。这不是"镜像做得不对"，是检材被永久销毁。这条属不可逆操作，本篇 4.1 组专门处理它——命令里没有第二个确认机制能救你。

本篇处理的证据形态是"原始介质 → 镜像文件"这一段，产出物通常是 DigiForensics.dd（RAW 裸镜像）或它的 E01 封装形式。RAW 与 E01 的差别不只是容器：E01 分段存储、每段自带哈希、支持压缩，代价是普通字节工具读不了。选哪个不是格式偏好，是后面工具链的事，见证据格式与转换。

在取证流程中的位置：本篇是采集环节的主干，处在整个流程的最上游——后面所有环节的结论都建立在"这份镜像与原始检材一致"这个前提上，而这个前提只有本篇能建立。上游依赖是硬件层面的准备，见取证装备与写保护器（接驳顺序、型号选型、耗材）；授权与委托手续见合规授权与法律边界与证据保管链与委托证明。下游分两条路：离线场景直接进只读挂载与安全接入；在线场景（系统还在跑）走本板块的远程勘验与在线取证——关机动作会销毁内存里的一切，这条岔路必须在动手前就想清楚。

本篇的处置主链是六步，其中第 5 步不可跳过：

步骤	动作	产出	什么时候就该停
1	环境准备与源设备识别	设备型号、容量、序列号、分区表	设备数量与预期不符时先停下来核对
2	图形化工具制作（Windows 首选）	带哈希的镜像	—
3	命令行制作（Linux 首选）	同上，dcfldd 可断点续做	—
4	E01 格式制作	分段镜像 + 每段哈希	—
5	验证	镜像哈希、坏扇区统计、抽样比对	哈希对不上就不要进入分析阶段
6	记录与封存	保管链记录、原始检材处置	—

第 5 步是唯一不能妥协的一步。它不只是"算一下哈希"，还包括坏扇区数量的统计、镜像头部与原始设备分区表的比对、以及至少一次内容抽样。

哈希对不上却继续做完整分析，是这个领域最昂贵的错误之一：你会花几天得出一个基于损坏数据的所有结论，然后在报告阶段发现全部作废。

第 1 步也值得单说：源设备识别错一次的代价，远大于后面每一步的总和。 笔记本有几块盘、RAID 有几个成员、SD 卡插在读卡器上还是直接挂载、NVMe 会不会被识别成普通块设备——动手前用 lsblk / fdisk -l 核对一遍，成本是三分钟。

原始检材的完整内容、逐扇区无遗漏、镜像与原件逐位一致、镜像的哈希值与制作时间线、以及镜像里有多少坏扇区（及其分布规律——连续坏簇通常指向物理损伤，零散坏扇可能来自写入时已存在的老化）。

做不出时间线——镜像是时点快照，它记录"关机那一刻是什么样"，不记录"这半年里发生过什么"；拿不到易失证据——内存、页交换、运行中的进程状态、当前网络连接、磁盘缓存，这些在关机瞬间就消失了，需要在线手段（见远程勘验与在线取证）；RAID 阵列必须拆开处理，把它当单盘只会得到一堆无意义的碎片；以及闪存的逻辑块与物理块不对应（FTL 映射与磨损均衡），这意味着"扇区号"在闪存介质上不是一个稳定的物理地址概念。

读者前提：你需要熟悉 fdisk -l / mmls 的分区表输出、能读懂设备命名（/dev/sd* vs /dev/nvme* vs /dev/mapper/*），并且清楚 if= 与 of= 写反会直接销毁证据。第一次做实体检材之前，建议先在虚拟磁盘上把整条命令链跑一遍。镜像做出来之后，接下来的只读分析见只读挂载与安全接入与虚拟机仿真。

镜像是时点快照，它能证明"关机那一刻盘上是什么样"，不能证明"这半年里发生过什么"。时间线的绝大部分内容需要从元数据、日志、注册表里重建，而不是从镜像的拍摄时间推断。那些需要跨源合并、归一化基准、标注置信度的工作，见时间线重建。

最后一条，也是本篇唯一不能妥协的纪律：哈希必须在制作时算。 事后对镜像文件算一遍哈希，只能证明"这个文件现在没变"，证明不了"它采集时就是完整的"——因为你不知道采集过程中是不是已经有扇区读不出来、被工具跳过了。这两句话在法庭上的分量完全不同，而区分它们只需要在制作时多按一个参数。

二、核心原理

2.1 物理镜像 vs 逻辑镜像

维度	物理镜像（Physical）	逻辑镜像（Logical）
采集对象	整块设备的扇区序列	某个卷 / 文件 / 目录
包含分区表	是	否
包含未分配空间	是	否
包含删除文件残留	是（视文件系统而定）	否
丢失分区间隙	否	是
取证价值	最高，可做全盘时间线	有限，工具兼容性差

实战原则：默认永远做物理镜像。 只有在特殊场景（虚拟化、存储池、单卷容量远超可用存储）才考虑逻辑镜像，且必须在报告中明确标注这是逻辑镜像。

逻辑镜像会丢掉"分区之间的间隙"（gap between partitions）。攻击者藏数据的经典位置恰恰包括 MBR 末尾到第一个分区之间、分区表之间的空隙、以及分区末尾到磁盘末尾。未分配空间是反取证软件的默认藏身处。

2.2 写保护的三种层次

层次	手段	可靠性	说明
硬件写保护	写保护器（Write Blocker）	★★★★★	SATA/USB/PCIe 专用型号，物理层面阻断写信号
系统只读	losetup -r、blockdev --setro	★★★★	依赖 OS 与驱动，无法防御恶意代码
软件约定	"我们小心点不写"	☆	不可依赖

关键认识：如果原始检材已被挂载过、或电脑上运行过未知程序，那么软件层面的只读就失去意义——恶意代码可能已在内核驻留。此时唯一补救是：立刻断电、停止使用该机、用硬件写保护器保护"剩余状态"，并在报告中如实记录"检材固定前已被使用"。

主控也是一条污染路径：SSD 主控会记录访问日志（下单时间、常用软件，甚至残留的快递面单信息），有时比磁盘内容更能证明设备来源。这就是新购专用硬盘盒比现成 USB-SATA 桥接芯片更可靠的原因。

2.3 直连方式的选择

方式	适用	风险	说明
主板直连	SATA / M.2 / NVMe	最低	需拆机，速度与稳定性最佳
专用硬盘盒（信封盒）	已封存设备的临时读取	低	确认盒容量与协议支持；主控可能有缓存
USB 转 SATA 廉价桥接	2.5" 小容量 SATA	中高	主控可能延迟落盘，掉电即数据不一致
USB 直连移动硬盘	移动盘/U盘	中	容量多在 2 TB 以下；桥接行为不可控

识别不可靠桥接的关键：制作完成后断开重连，再次验证哈希。两次读到的内容不同，说明设备内部有缓存或落盘问题，该介质不可信。

NVMe 注意：SATA 写保护器接不了 NVMe（协议不同，不是接口外形问题），需 PCIe 转接 + NVMe 专用写保护方案。

2.4 多盘与 RAID：绝对不能当作单盘

服务器和台式机常见双盘、RAID 0/5/10，这是新手最容易造成无法挽回损失的场景。

阵列类型	制作方式	能否逐盘分析
RAID 0 / 10	逐盘制作，必须记录盘序	需重组后分析
RAID 1	任意一盘可单独使用（内容相同）	可以
RAID 5	逐盘制作，记录 N+1 全部盘	需重组
硬件 RAID（带缓存+BBU）	⚠️ 先断电再拆，否则缓存未落盘	需厂商工具重建
SSD 阵列	每块盘可能是独立卷或 RAID 分区	用 mmls 逐盘确认

硬件 RAID 卡的致命陷阱：RAID 卡通常带 512 MB–4 GB 写缓存，靠电池（BBU）或电容维持。断电前取下硬盘，缓存中的数据全部丢失且不可恢复——这些数据往往正是最近几分钟的写入。正确做法：接上 RAID 卡并正常关机，让缓存安全刷盘；确认缓存已 flush（LED 状态或厂商工具）后再拆盘。软件 RAID（mdraid / ZFS / btrfs） 的处理见第 10 篇服务器取证。

2.5 制作时机与哈希计算

场景	做法	内存证据	一致性风险
可关机且有授权	正常关机后断电	丢失	低（有干净关机记录）
可关机但要求保内存	休眠（hibernate）后搬走	保留	中（hiberfil.sys 存在）
不可关机（如服务器在跑业务）	热插拔/在线镜像	保留	高（文件系统持续变更）
现场服务器	内存采集 + 热镜像 + 逻辑采集	保留	最高

休眠是关机与保持内存之间的最佳折中：系统把内存完整写入 hiberfil.sys 后断电，既保住内存内容，又避免非正常断电对文件系统一致性的破坏，事后可从 hiberfil.sys 还原。注意 Windows Server 2008 R2 及更早版本默认禁用休眠。

哈希必须在制作时同步算。对 500 GB 磁盘单独跑一次 SHA-256 需完整读盘一遍；先 dd 再 sha256sum 就是读盘两次。dcfldd 的价值在于数据从源盘读进内存块的那一刻同步计算哈希再写出——磁盘 I/O 是瓶颈，内存运算几乎免费，哈希等于白送。

hashconv=before 表示对源数据（转换前）计算，取证场景应始终用它，因为要证明的是原始检材的指纹。

---

三、操作步骤

3.1 第 1 步：环境准备与源设备识别（Ubuntu/Debian）

在动手前把"哪个设备是检材"确认三遍。接入前先跑一遍 lsblk 作为基线，接入后再跑一遍做对比——这样能证明"我接入的设备就是新出现的那个"：

# 1) 安装工具
sudo apt update && sudo apt install dcfldd ewf-tools sleuthkit

# 2) 接入前基线快照
lsblk -o NAME,SIZE,MODEL,SERIAL,RO,TYPE,MOUNTPOINTS | tee /evidence/lsblk-before.txt

# 3) 接入检材（通过写保护器）

# 4) 接入后再次快照并与基线 diff
lsblk -o NAME,SIZE,MODEL,SERIAL,RO,TYPE,MOUNTPOINTS | tee /evidence/lsblk-after.txt
diff /evidence/lsblk-before.txt /evidence/lsblk-after.txt

RO 列是关键。显示 1 说明内核已把该设备标记为只读；若显示 0，说明写保护器没有正确工作。容量、型号、序列号三者与勘验记录全一致后，再确认它没有被挂载——findmnt --source /dev/sdb 应该输出为空。

3.2 第 2 步：FTK Imager 图形化制作（Windows 首选）

FTK Imager 是司法鉴定领域使用最广的采集工具之一（闭源、免费分发，商业公司维护），优势在于操作留痕完整（自动生成日志）和多设备并发采集。

1. File → Add Disk Image... → 选 Device 类型 → 选中物理盘（选 Physical Drive，不是分区）
2. 填写 Case Number、Evidence Number、Unique Description、Examiner——不要留默认值，这四项是案件报告的直接引用源
3. Destination Path 选证据目录，Image Type 选 Raw Device (dd) 或 E01
4. 勾选 Verify image after creation（必勾），然后 Start

设备列表里物理盘显示为 PhysicalDrive0、PhysicalDrive1，分区则显示为盘符，选错是新手最常见的事故。在 Evidence Device Information 区域勾选 Create evidence image of multiple devices，单个 capture 任务即可采集多块盘并自动编号（DigiForensics.E01、DigiForensics_1.E01）——这对多盘服务器和 RAID 阵列尤其有价值。

制作完成后还可用 File → Verify Disk Image 单独再验一次，该操作重读镜像并与 E01 头中存储的哈希比对。

3.3 第 3 步：dcfldd 命令行制作（Linux 首选）

基础制作（健康介质）：

sudo dcfldd if=/dev/sdb of=/evidence/DigiForensics.dd \
  bs=4M hash=sha256 hashlog=/evidence/DigiForensics.dd.sha256 statusinterval=256

bs=4M 是现代介质的合理起点。健康介质用大块（1M–8M）提升吞吐；有坏道的介质必须降到 512 或 4k，否则一次坏道会连带丢掉周围 4 MB。

参数	作用	关键点
conv=noerror	遇读错误继续，不中止	不写这个参数，盘一坏就整个中断
conv=sync	出错块补零，保持输出偏移对齐	不写会导致后续所有数据错位
errlog=	错误详情写入日志	这是唯一的坏道位置记录
vf=	事后逐字节复验源盘与镜像	替代"再跑一遍 sha256sum"，可发现所有差异

conv=sync 为什么必须加：dcfldd 以 bs 为单位搬运。若 bs=4M 时第 100 MB 处有 1 个坏扇区，不加 sync 它可能只读了 4 MB − 1 扇区就跳过，结果是输出从这一处整体前移 511 字节，后面所有数据的偏移全部错误。sync 保证失败块被补零写满，输出长度与输入严格一致。这不是可选优化，是数据正确性的前提。

纯 GNU dd 备选方案：dcfldd 未安装时可用 dd，但要手动补齐它的三项核心能力——续错、补齐、记录错误：

sudo dd if=/dev/sdb of=/evidence/DigiForensics.dd bs=4M \
  conv=noerror,sync status=progress \
  iflag=direct 2>>/evidence/DigiForensics-dd.err
sha256sum /evidence/DigiForensics.dd | tee /evidence/DigiForensics.dd.sha256

conv=sync 的语义与 dcfldd 完全一致；iflag=direct 让内核绕过页缓存、直接读块设备，避免读到已被缓