关键词：磁盘镜像、dcfldd、FTK Imager、ewfacquire、写保护器、RAID、哈希校验、坏扇区处理
难度：入门
前置知识：磁盘分区结构、扇区与簇、MD5/SHA-256 基本概念
一、概述
只有这一步会物理接触原始检材。
产出的镜像就是后面所有分析的天花板。镜像阶段丢了数据、混进了写操作、或者哈希链断了，后面再精巧的结论都站不住。
目标很直白：不改变检材状态，尽可能忠实地复制出每一位（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 是司法鉴定领域使用最广的采集工具之一（闭源、免费分发，商业公司维护），优势在于操作留痕完整（自动生成日志）和多设备并发采集。
File → Add Disk Image... → 选 Device 类型 → 选中物理盘（选 Physical Drive，不是分区）- 填写
Case Number、Evidence Number、Unique Description、Examiner——不要留默认值，这四项是案件报告的直接引用源
Destination Path 选证据目录，Image Type 选 Raw Device (dd) 或 E01- 勾选
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 让内核绕过页缓存、直接读块设备，避免读到已被缓存的旧数据。但它挡不住其他进程同时写这个设备——写保护器才是唯一的保证。
代价是 dd 无法在采集过程中算哈希，只能事后补一次读盘。dcfldd 存在的意义就在这里
