一、概述
电子证据有一个物理世界证据没有的性质：单向衰变。一旦被改写就无法还原，一旦被污染就无法自证。硬盘上的一个扇区被覆盖，原内容不在任何备份里；一份台账漏记一段时间，那段时间的状态永远说不清。
所以保全、采集、检验、分析、报告这五个阶段必须分开，每个阶段回答一个不同的问题：东西在不在原样？能不能完整复制？里面有什么？这些说明什么？怎么让别人相信？阶段划分不是为了流程好看，是为了在每个不可逆节点之前设置验证关卡。
关键在于关卡的前置性质：前一阶段的产出不合格，绝不能进入下一阶段。这句话听起来像常识，实际上是取证实践中最常见的失败模式——采集时没接写保护器，但后面四个阶段照样做完了，只是结论在质证时整体失效。
这套五阶段划分本身构成工作流，它不在某一环里，而是定义所有环节的边界。它是取证概念与分类的展开：那篇说为什么要分阶段，这里说每个阶段做什么、什么算合格。也是取证技能树的骨架——技能树按能力层次组织学习顺序，流程按阶段组织工作顺序，两者交叉起来才是完整的实践路径。
上游是合规约束：合规授权与法律边界决定你从哪个阶段开始有权工作。没有授权，连保全都不成立。下游是三个具体的执行入口——保全与采集进镜像制作，检验与分析进文件系统取证总览，报告阶段的局限性表述则贯穿所有技术篇的第四章。
各阶段的产出物形态有各自的落点。
案件工作目录是后面所有记录的落点，产物分类放置本身就是可追溯性的物理基础。现场状态照片、封条与序列号登记是保全阶段的产物，案例里设备到所时是关机状态，这个记录决定了后面"无法提取内存中可能残留的会话信息"这条局限怎么写。
DigiForensics.dd 与 DigiForensics.hashlog 是采集阶段产物，用 dcfldd hash=md5,sha256 hashlog=... 一次完成。哈希必须边读边算，因为先读完再回头算哈希覆盖的就不是同一批字节了。
检验阶段的产物是提取出的 $MFT / Prefetch / hive / UserAssist。操作日志与工具版本记录覆盖全流程，这是可追溯性的唯一载体，也最容易被忽视、最容易被击穿。复核者按同一 SOP 重跑的记录是可重复性的实证形式。DigiForensics.hashlog 与 DigiForensics.dd 是同一次读操作的两个产物。
能回答的是这些：五个阶段各自的退出条件是什么、采集阶段为什么是"复制"而不是"分析"（三层理由：技术层怕工具 bug、流程层要并行、法律层只需证明副本等于原件）、McCée 原则与黄金规则分别管什么、以及真实性 / 完整性 / 可追溯性三者中哪一个最容易被击穿（可追溯性）。
不解决的是这些：每个阶段具体怎么操作，这里给的是关卡与判据，执行细节在各技术篇；三套原则在具体场景里怎么权衡，例如"若必须动原始数据"与取证效率冲突时怎么办；可重复性的技术实现，自动化程度越高越容易满足这个要求，具体工具选型在各技术篇的第七章；流程合法性的法律依据，见合规授权与法律边界。
前提是先理解取证概念与分类里"取证与数据恢复不是一回事"那个区分。数据恢复允许反复试错，取证不允许，两者共用同一批命令但正确用法相反。
另外建议完整做过一次真实采集再回头看这套流程。如果你亲手接过写保护器、亲手看着 dcfldd 跑了四个小时，每个"必须"都会有体感；如果没做过，那些原则读起来会很像教条。
二、核心原理
2.1 五阶段与各自的关卡
| 阶段 |
核心问题 |
关键动作 |
产出物 |
退出条件（验证） |
| 1. 保全 Preservation |
东西还在不在原样？ |
记录状态、封装、防篡改 |
状态照片、封条编号、保管记录 |
封条编号与委托书一致、状态已留证 |
| 2. 采集 Acquisition |
能否完整复制？ |
写保护接入、制作镜像、算哈希 |
DigiForensics.dd、哈希日志 |
源介质哈希 == 镜像哈希 |
| 3. 检验 Examination |
里面有什么？ |
恢复、提取、筛选、去噪 |
文件清单、关键字命中、解密结果 |
提取物可被独立打开读取 |
| 4. 分析 Analysis |
这说明什么？ |
关联、推理、构建时间线 |
时间线、行为重建、结论 |
每条结论有第二条独立证据 |
| 5. 报告 Reporting |
怎么让人相信？ |
撰写、复核、交接 |
鉴定意见书/分析报告 |
复核人签字、无内部矛盾 |
阶段不可跳跃，但可迭代。分析阶段发现需要新数据，回到检验阶段重新提取是正常的；但回到采集阶段重做镜像，通常意味着第一次采集出了问题。
2.2 采集阶段的核心：为什么是"复制"而不是"分析"
采集的产物是副本，原始介质在整个流程中始终只读。理由有三层。
第 1 层 技术层：分析工具可能有 bug，写入目标会让证据失真
第 2 层 流程层：多个分析员需要并行工作同一份数据
第 3 层 法律层：法庭上只需证明"副本 = 原件"，而非"分析未影响原件"
这也解释了为什么哈希校验必须在采集时同步完成——只有"边读边算"才能保证哈希覆盖的是刚读出的那批字节。若先读完再回头算，中间若有写入，哈希就对不上了。
2.3 McCée 原则（数字取证的基本原则）
| # |
原则 |
含义 |
在流程中的落点 |
| 1 |
不改变原始数据 |
任何操作都不得修改原介质 |
写保护器、只读挂载 |
| 2 |
记录所有过程 |
每个步骤、参数、时间都要留痕 |
操作日志、命令历史 |
| 3 |
可重复性 |
另一名合格人员用相同方法应得到相同结果 |
SOP 文档、工具版本记录 |
| 4 |
用哈希验证 |
用数学方法证明数据未被改变 |
采集前后双哈希 |
第 3 条是最难落实也最容易被质疑的。"可重复"不等于"结果相同"——自动化程度越高、工具越明确，可重复性越强。手工用十六进制编辑器翻找的结论，很难通过可重复性审查。
四条原则各有一个可以当场检查的落点：第 1 条看挂载点是否 ro、采集命令是否只有读通道；第 2 条看操作日志能否还原出"谁在什么时候跑了什么参数"；第 3 条看复核者拿到工具名、版本号、命令行后能否跑出同一结果；第 4 条看 H0 与 H1 是否都留了值。
只做对前三条而漏掉第四条的情况很常见：流程记录很完整，但没有数学证据支撑"数据没变过"，质证时仍然会被追问。
2.4 取证黄金规则（Golden Rules）
这组规则偏向"防错"，与 McCée 的"做对"互补：
| 规则 |
说明 |
| 绝不动原始数据 |
任何写入都可能毁灭证据 |
| 若必须动，先想清楚 |
确实需要访问原件时，必须能解释每一步和后果 |
| 全程留痕 |
每一次交接、每一次操作都要能被第三方复现 |
| 由负责人负全责 |
流程合规性由主办人负责，不能有"我以为是同事弄的" |
2.5 三大属性：真实性、完整性、可追溯性
这是评价一份电子数据是否"合格"的三个维度：
| 属性 |
含义 |
如何证明 |
| 真实性 Authenticity |
数据确实来自所述来源，未被伪造 |
元数据链、设备绑定、多源印证 |
| 完整性 Integrity |
数据采集后未被改变 |
哈希校验链（源→镜像→分析后） |
| 可追溯性 Traceability |
每一步操作都有记录，可被第三方复核 |
保管链文档、操作日志、工具版本 |
实务判断：三者中可追溯性最容易被忽视，也最容易在质证时被击穿。哈希只能证明"没变过"，不能证明"没动过手脚"——后者要靠保管链和过程记录。
三、操作步骤
步骤 1：建立案件工作目录
目录结构固定，避免后续混乱
mkdir -p /case/2024-DG-001/{01_photo,02_acquire,03_examine,04_analysis,05_report}
cd /case/2024-DG-001
创建证据登记簿（哈希日志最终落在这里）
printf '%s
'
"案件编号: 2024-DG-001"
"检材名称: DigiForensics.dd"
"采集时间: <填写>"
"采集人: <填写>" > 02_acquire/case.log
步骤 2：保全（记录状态，固定边界）
1) 核对检材标识
lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINTS
2) 确认未挂载——挂载过的分区可能被写入
findmnt | grep -E 'sd[a-z]'
3) 记录设备固件层可见容量（应对 HPA/DCO 隐藏容量）
sudo hdparm -I /dev/sdX | head -30
sudo hdparm -N /dev/sdX
拍照是必须的：外包装、封条、接口、开机指示灯、屏幕状态。
步骤 3：采集（写保护 + 镜像 + 哈希）
硬件写保护器串接后，读取源盘
sudo dcfldd if=/dev/sdX of=02_acquire/DigiForensics.dd
hash=md5,sha256 hashlog=02_acquire/DigiForensics.hashlog
bs=4M conv=noerror,sync status=on
独立复算，确认与采集时一致
sha256sum 02_acquire/DigiForensics.dd
失败盘改用 ddrescue（详见板块 2）
sudo ddrescue -n /dev/sdX 02_acquire/DigiForensics.dd 02_acquire/DigiForensics.map
sudo ddrescue -d -r3 /dev/sdX 02_acquire/DigiForensics.dd 02_acquire/DigiForensics.map
步骤 4：检验（先定范围，再动提取）
第 1 步 全局摸底：分区、卷、文件总数、最早/最晚时间
第 2 步 建立基线：确认"正常"是什么样（软件清单、常用账号）
第 3 步 关键字收敛：按案件假设搜索
第 4 步 重点对象深挖：命中文件的元数据、关联对象、时间上下文
建立整体时间范围（判断是否需要外部时间基准）
fdisk -l 02_acquire/DigiForensics.dd
步骤 5：分析（每条结论配一条验证）
以"某文件在案发时间被打开"为例，验证不能只有一条：
证据 1：NTFS 的 $LogFile 中存在对应 MFT 记录修改
证据 2：该文件的 Prefetch/Amcache 有执行痕迹
证据 3：紧邻时段的前后文件访问记录与之吻合
→ 三条独立证据互相印证，结论成立
步骤 6：报告（让不懂技术的人能读懂）
结构建议：
1 基本情况（检材、委托、检材状态）
2 检验过程（工具、版本、参数、哈希核对结果）
3 检验结果（发现了什么，在什么位置）
4 分析意见（这些发现意味着什么，推理链条）
5 局限性（未能检验的部分、客观限制）
局限性章节是加分项，不是减分项。 明确写出"因设备处于锁屏状态，未能提取 X 数据"，比隐瞒后被对方发现要好得多。
四、常见陷阱
流程类失误有一个共同特征：它们大多发生在"看起来在推进工作"的地方。跳阶段、先分析后校验、边采集边分析——每一种都让人感觉更高效，代价却落在流程的可辩护性上。
2.1 那句话是全篇的基准：前一阶段的产出不合格，绝不能进入下一阶段。本章按阶段边界、采集细节、结论与可追溯性四组展开。
★ 标记表示该操作会造成不可逆的检材改变或证据效力损失，执行前必须停下来确认。
4.1 阶段边界
陷阱 1：★ 边采集边分析
现象：一边跑 dcfldd 采集，同时在另一台机器或同一个源设备上打开分析工具看数据；或者干脆用挂载点当工作目录，采集还在跑就开始翻文件。
原因：2.2 讲清了采集产物是副本、原始介质全程只读的三层理由，其中第一层就是"分析工具可能有 bug，写入目标会让证据失真"。
而"边采边看"的吸引力非常具体——你不用等几小时的采集时间就能开始判断方向，这在项目紧张时显得很务实。但它把一个已验证的流程换成了一个未验证的：写保护器此时承受的不只是读命令，还有另一条通路上的访问。
2.4 的黄金规则第一条是"绝不动原始数据"。这里的"动"包括"别人可能在动"。
影响：两难境地的核心是证据效力，不是效率。
如果另一路操作写入了任何内容，源介质哈希与镜像哈希就不再匹配，而这个不匹配无法事后解释——你不知道是被分析工具写的，还是被系统自动日志写的。而 2.1 把"源介质哈希 == 镜像哈希"定为采集阶段的退出条件，条件不满足就没有进入下一阶段的资格。
核查：采集完成前不做任何分析，且分析永远在副本上进行：
采集期间：本机只做采集，不打开任何分析工具
sudo dcfldd if=/dev/sdX of=02_acquire/DigiForensics.dd
hash=md5,sha256 hashlog=02_acquire/DigiForensics.hashlog
bs=4M conv=noerror,sync status=on
采集完成并通过退出条件后：复制工
