Chapter 14 — Key Takeaways
The big idea
Forensic acquisition is the one step you cannot redo, so you do it once and you do it provably. You capture a complete, sector-by-sector copy of the device — not its files — through a write-blocker that makes "read-only" a physical fact, you prove the copy is identical with cryptographic hashes, and you wrap the whole thing in a gap-free chain of custody. The original is sacred: image first, verify, and from that moment work only on the copy. Get this wrong and nothing built on top of it can be trusted, no matter how brilliant the analysis; get it right and even a hostile expert has nowhere to stand.
Why image the whole device
- A physical image captures unallocated space (deleted data with no pointer), file slack, the partition table, inter-partition gaps, and hidden HPA/DCO regions — exactly where evidence usually hides. A file copy throws all of that away.
- An operating system writes to a disk the instant it sees it — mounting, journal replay, timestamp updates, indexing. Every write changes the hash and breaks your ability to prove the evidence is unaltered. That is why write-blocking is non-negotiable.
Write-blocking, tools, and formats at a glance
| Decision | Reach for | Because |
|---|---|---|
| Write protection (court) | Hardware blocker (Tableau, WiebeTech) | Host-independent, NIST CFTT-tested, a single concrete fact to defend |
| Write protection (supplement) | Software (blockdev --setro, CAINE/SIFT, registry) |
Useful, but depends on correct config and the OS you don't trust |
| Trusted free Windows imaging | FTK Imager | Point-and-click, clean report (MD5+SHA-1) |
| Fast Linux imaging + SHA-256 | Guymager | Multithreaded; re-reads source to verify |
| Scripted / headless / piecewise | dcfldd / dc3dd |
On-the-fly dual hashing, window hashes, error log |
| The model behind them all | dd (conv=noerror,sync) |
Universal baseline — and the last resort |
| Universal, no metadata | raw / .dd | Every tool reads it; size == source |
| Court default | E01 (EWF) | Embedded metadata, per-chunk integrity, compression, self-verifying |
| Huge / partial / sparse | AFF4 | Stores only data-bearing extents; cloud-scale |
Hashing and chain of custody
- Compute MD5 and SHA-256: MD5 catches accidental change instantly and matches legacy hash sets; two algorithms defeat collision concerns. MD5 = 128 bits, SHA-256 = 256 bits.
- The three-link chain: hash the source during the read → hash the image and confirm it equals the source → re-verify before every analysis session. A mismatch is never noise — stop, document, investigate.
- The hash proves the bits; the chain of custody proves the people. Courts demand both. Labels, photographs, anti-static and Faraday bags, numbered tamper-evident seals, locked storage, and a transfer log with no gaps: if it isn't documented, it didn't happen.
You can now…
- ☐ Explain why a forensic image copies the whole device — slack, unallocated, HPA/DCO included — and why an OS silently alters an unprotected source.
- ☐ Choose and validate hardware vs. software write-blocking and defend the choice in one plain sentence.
- ☐ Acquire with
dd,dcfldd, FTK Imager, or Guymager, and pick raw vs. E01 vs. AFF4 for the job. - ☐ Compute, record, and verify MD5 and SHA-256 across the full chain — and respond correctly to a mismatch.
- ☐ Maintain a defensible chain of custody and document an acquisition so it survives cross-examination.
Looking ahead
Chapter 15 — Live Response and Triage Forensics. This chapter assumed you could power the machine off. Often you cannot: a full-disk-encrypted volume is unlocked, or the evidence lives in RAM and dies with the power. Next you learn the order of volatility, how to capture memory and running state before they vanish, and how to triage at speed when full imaging must wait.
One sentence to carry forward: You get exactly one chance to capture the original perfectly — so image first, verify with two hashes, account for every minute, and never touch the original again.