46 min read

> Where you are: Part III, Chapter 14 of 40. Chapter 5 walked you through the forensic process end to end and introduced the court case that anchors this book; Part II taught you to get data back. This chapter zooms all the way in on the single most...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 14: Forensic Acquisition — Imaging Drives, Preserving Evidence, and Maintaining Chain of Custody

Where you are: Part III, Chapter 14 of 40. Chapter 5 walked you through the forensic process end to end and introduced the court case that anchors this book; Part II taught you to get data back. This chapter zooms all the way in on the single most consequential step of any investigation — turning a piece of seized hardware into a verified, defensible copy you can analyze without ever touching the original again. Everything in Part III stands on what you do here.

Learning paths: This is foundational for everyone, but it lives closest to 🔍 Forensic Examiner and 📜 Legal/eDiscovery — acquisition is where admissibility is won or lost. 🛡️ Incident Response practitioners read it with one asterisk: sometimes you cannot power a system off (Chapter 15), and the trade-offs start here. 💾 Data Recovery technicians should not skip it — "image first, work on the copy" protects an irreplaceable original even when no courtroom is in sight.

The step you cannot redo

Picture the laptop on the bench in front of you. It arrived in a sealed, signed evidence bag with a case number written on the label in permanent marker. It is, for the moment, the only copy of the truth that exists. Whatever happened on that machine — the files that were created, deleted, opened, hidden, or copied to a USB stick — is encoded in the magnetic domains or NAND cells inside it, exactly as the last user left it. Your job is to capture that state perfectly, prove that you captured it perfectly, and then never disturb the original again.

This is forensic acquisition: producing a bit-for-bit copy of source media, verifying it with cryptographic hashes, performing the capture through a write-blocker so the source cannot be altered, and documenting every transfer of custody from the moment of seizure to the moment a judge rules on the evidence. It is the second of this book's six recurring ideas made literal — the original is sacred — and it is the step you cannot redo. You can re-run an analysis a hundred times. You can re-carve, re-parse, re-interpret. But you get exactly one chance to capture the evidence in its pristine, as-seized condition. If you alter it during acquisition, there is no undo; the original state is gone, and with it goes your ability to say, under oath, "what I analyzed is identical to what was seized."

Chapter 5 sketched this process so you could see the whole arc — acquisition, preservation, analysis, reporting. This chapter is the deep version of the first two stages, written specifically for the forensic workflow, where the test is not merely "did I get the data?" but "can I prove, years from now and under cross-examination, that the data is unaltered and that I can account for it every minute it was in my custody?" Those are very different bars, and the difference is the whole subject of this chapter.

Why This Matters. A flawless analysis built on a flawed acquisition is worthless. Defense counsel does not need to disprove your findings if they can show your evidence is unreliable — a missing write-blocker, an undocumented hour, a hash you never computed. Acquisition is the load-bearing wall of the investigation. Build it wrong and everything above it collapses, no matter how elegant.

What "bit-for-bit" really means — and why you copy the whole device

When a normal user "copies a drive," they copy files — the things the file system will admit exist. A forensic acquisition copies the device: every sector, in order, from the first to the last, including all the regions the file system would never show you. That distinction is the entire reason forensic imaging exists, and it ties straight back to Part I.

Recall from Chapter 2 that storage is just an addressable array of fixed-size sectors (commonly 512 bytes on older drives, 4,096 bytes on modern "Advanced Format" media), and that "deleting" a file removes the file system's pointer to the data, not the data itself — the book's first theme, deleted ≠ destroyed. The bytes of a deleted file sit in unallocated space until something overwrites them. The tail end of the last cluster of a live file — the gap between where the file ends and where the cluster ends — is slack space, and it routinely contains fragments of whatever occupied that cluster before. None of this is visible through a file-copy. All of it is captured by a sector-by-sector image.

   A FILE COPY sees this:                A FORENSIC IMAGE captures this:

   ┌───────────────────────┐            ┌───────────────────────┐
   │  report.docx          │            │  report.docx          │  ← live file
   │  budget.xlsx          │            │  budget.xlsx          │
   │  photo.jpg            │            │  photo.jpg ░░slack░░   │  ← + file slack
   └───────────────────────┘            ├───────────────────────┤
        (allocated files only)          │ ▓ deleted resignation  │  ← unallocated:
                                        │ ▓ letter (no pointer)  │    "deleted" data
                                        │ ▓ old DB fragments     │    still present
                                        ├───────────────────────┤
                                        │ host protected area    │  ← hidden region
                                        │ (HPA/DCO)              │
                                        └───────────────────────┘

If you only copied files, you would throw away the most valuable evidence in most investigations: the deleted resignation letter in the IP-theft case, the carved photographs in the court case, the database fragments that prove what a system once held. A forensic image is the difference between "here are the files that exist" and "here is everything the device contains, present and past." When you acquire a physical drive, you also capture structures the operating system normally hides: the partition table, the gaps between partitions, and — if you handle it correctly — the Host Protected Area (HPA) and Device Configuration Overlay (DCO), two mechanisms by which a drive can report itself as smaller than it really is, leaving a hidden region where data can be stashed. We will return to those near the end.

Recovery vs. Forensics. The same act — making a complete copy of a drive — serves both disciplines, but the why differs, and the why changes the how. In data recovery, you image first because the original may be physically dying and is irreplaceable; one extra power-cycle of a failing drive can be its last, so you capture everything you can while you can and then work on the copy. In digital forensics, you image first because the original is evidence: you must be able to prove in court that your copy is identical to what was seized and that nothing — not even your own tools — modified it. Recovery prizes the copy because the data is precious. Forensics prizes the copy because the data must be provably unaltered. Both arrive at the same cardinal rule from opposite directions: never work on the original.

Write-blocking: making "read-only" a physical fact

Here is the uncomfortable truth that makes write-blocking non-negotiable: a modern operating system writes to a disk the instant you connect it, whether you tell it to or not. Plug a suspect drive into a running Windows machine and, before you click anything, the OS may:

  • mount the volume and assign it a drive letter;
  • read the file-system dirty bit and, on some configurations, clear it — a write;
  • create or update a System Volume Information folder and $RECYCLE.BIN;
  • replay the NTFS journal ($LogFile) or the ext4 journal, committing pending transactions — writes that change on-disk structures;
  • update last-access timestamps as it enumerates files;
  • kick off Windows Search / Spotlight indexing, which reads — and writes index metadata;
  • drop desktop.ini, thumbnail caches, or restore-point data.

Every one of those actions changes bytes on the disk. Every changed byte changes the disk's hash. And the moment the hash of the evidence differs from the hash recorded at seizure, you have, in the eyes of the court, altered the evidence. It does not matter that you did not mean to. It does not matter that the changes were trivial OS housekeeping that touched nothing relevant to the case. The chain that lets you testify "this is identical to what was seized" is broken, and a competent defense attorney will spend a long afternoon making sure the jury understands that you cannot prove your evidence is what you say it is. This is the book's third theme in action — every action leaves a trace — turned against you: the operating system's perfectly ordinary writes are traces that contaminate the scene.

A write-blocker breaks that loop by guaranteeing, at a level the host cannot override, that no write command ever reaches the source media. Reads pass through; writes are intercepted and discarded (or actively refused). The source is mounted, enumerated, hashed, and imaged exactly as it was, untouched.

Hardware write-blockers

A hardware write-blocker is a physical device that sits in the data path between the source drive and your workstation. The drive plugs into the blocker; the blocker plugs into the host. Internally, the blocker inspects every command crossing the bus and enforces a one-way policy: read, identify, and inquiry commands are forwarded to the drive and their responses returned to the host; write, format, and erase commands are blocked — either silently dropped, or answered with a benign "command complete" so the host's driver does not hang, while the command itself never touches the platters or NAND.

        SOURCE                 WRITE-BLOCKER                 EXAMINER HOST
   ┌──────────────┐        ┌────────────────────┐        ┌──────────────────┐
   │ Suspect drive│  SATA  │  reads  ───────────▶│  USB3  │ Imaging software │
   │ (evidence)   │═══════▶│  writes ──╳ BLOCKED │═══════▶│ (FTK / Guymager) │
   │              │◀═══════│  ◀── data returned  │◀═══════│                  │
   └──────────────┘        └────────────────────┘        └────────┬─────────┘
                              ▲ enforces one-way                   │ writes to
                                in hardware                        ▼
                                                            ┌──────────────┐
                                                            │ DESTINATION  │
                                                            │ image file   │
                                                            │ (.E01/.dd)   │
                                                            └──────────────┘

The two names you will hear constantly are Tableau (the long-time market leader, now part of Exterro) and WiebeTech (a CRU brand). Tableau's forensic bridges — devices such as the multi-interface T356789iu, the T8u USB 3.0 blocker, and the T7u for NVMe — cover SATA, SAS, IDE/PATA, USB, FireWire, and PCIe/NVMe sources, with a forward-facing USB or display port that reports the drive's identity and the blocker's status. WiebeTech's Forensic UltraDock and USB WriteBlocker line do the same job, and its Ditto FieldStation is a self-contained imager-plus-blocker for field work. The interface matters because you must match the source: a SATA blocker will not help with an M.2 NVMe SSD, which speaks PCIe, not SATA — a distinction we drew in Chapter 3 and one that trips up examiners who own one blocker and assume it fits everything.

Tool Tip. Record the write-blocker's make, model, firmware version, and serial number in your notes for every acquisition. When you are asked on the stand "how do you know the drive was not modified?", "I used a NIST-tested Tableau T8u, firmware 2.x, serial …, and validated it that morning" is an answer; "I used a write-blocker" is an invitation to twenty more questions. Many blockers print their firmware on a small display or via a companion utility — read it and write it down.

Software write-blockers

A software write-blocker enforces read-only at the operating-system level instead of in hardware. On Linux, you can mark a block device read-only with blockdev --setro /dev/sdb, mount file systems with options that suppress writes (-o ro,noload for ext file systems, where noload prevents the journal from being replayed, plus noatime to stop access-time updates), or — best of all — never mount the source at all and image straight from the raw device. Purpose-built forensic Linux distributions such as CAINE, SANS SIFT, and Paladin ship configured to not auto-mount attached media and to mount read-only when you do mount, precisely so an examiner cannot contaminate a drive by plugging it in.

On Windows, the classic software approach is a registry switch:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies
    WriteProtect  (REG_DWORD) = 1

With WriteProtect set to 1 (and a reboot or re-enumeration), Windows refuses writes to USB mass-storage devices. It is genuinely useful in a pinch — but read the fine print: it applies only to USB storage, it depends on the key being correctly set before the device is attached, it can be silently undone by another administrator or a Group Policy, and it does nothing for a drive connected over SATA. Those caveats are exactly why software blocking is a supplement, not a foundation, for evidentiary work.

Both approaches can prevent writes. Only one is easy to defend in court, and the reasons are worth stating plainly because you will eventually have to state them under oath:

  1. Independence from the host. A hardware blocker enforces read-only regardless of what operating system, driver, malware, or misconfiguration is running on the examiner's workstation. A software blocker is only as trustworthy as the OS enforcing it — and the OS is the very thing that wants to write.
  2. Validation and testability. The U.S. National Institute of Standards and Technology runs the Computer Forensics Tool Testing (CFTT) program, which publishes a hardware write-blocker specification and test reports for specific devices. You can point to an independent test result for the exact model you used. That is the language of Daubert admissibility (Chapter 25): a known, tested, error-characterized method.
  3. Simplicity of the claim. "A physical device in the cable refused all write commands" is a single, concrete, demonstrable fact. "A registry value was set, applied only to USB, and was not overridden by anything" is a chain of conditions, each of which the defense can probe.
  4. No reliance on correct configuration in the moment. The hardware does one job and does it whether or not you remembered a setting. Most forensic mistakes are configuration mistakes made under time pressure; hardware removes that failure mode.

Legal Note. This is not a personal preference; it is codified in widely cited guidance. The UK ACPO Principles of Digital Evidence open with "no action … should change data which may subsequently be relied upon in court." NIST SP 800-86, ISO/IEC 27037, and the SWGDE Best Practices for Computer Forensic Acquisitions all describe write protection during acquisition as standard practice. When your method matches published standards, your opponent has to argue against the standard, not just against you.

Try This. Before you trust any write-blocker, validate it the way the lab does. Boot a forensic Linux distro, record the SHA-256 of a scratch disk, attach that disk through the blocker, deliberately attempt dd if=/dev/zero of=/dev/sdX bs=512 count=1 against it, observe the write fail, then re-hash. Identical hash before and after = the blocker works. Do this for each blocker, each firmware, and log it. A write-blocker you have never tested is a write-blocker you cannot vouch for.

War Story. A corporate investigator, certain a departing engineer had copied source code to a personal drive, "just had a quick look" by booting the suspect's laptop from its own Windows installation to browse the Documents folder. Windows did what Windows does: it updated last-access times, wrote a new restore point, and touched dozens of system files — changing the very timestamps the case turned on, and making the disk hash worthless. The data was probably still there. The proof was not. The matter settled quietly because no one could defend the evidence. Every action leaves a trace, including yours: image first, look later, and look only at the copy.

Forensic imaging tools

Once the source is behind a write-blocker, you make the image. Four tools cover the overwhelming majority of real acquisitions, and you should be fluent in all of them because each fits a different situation: dd (universal, minimal), dcfldd (forensic dd with hashing), FTK Imager (the Windows GUI standard), and Guymager (the fast Linux GUI). They all produce the same fundamental thing — a complete copy of the source — but they differ in how they hash, log, handle errors, and package the result.

dd — the universal baseline

dd is the original UNIX disk-dump utility, present on essentially every Linux and macOS system. It reads from an input (if=) and writes to an output (of=) block by block. A bare acquisition looks like this:

# Image the entire physical device /dev/sdb to a raw file.
# (Run from a forensic boot environment, source behind a write-blocker.)
sudo dd if=/dev/sdb of=/mnt/evidence/2026-0142-item01.dd \
        bs=4M conv=noerror,sync status=progress

Read each operand, because every one matters in a forensic context:

  • if=/dev/sdb — the input file: the whole physical device (sdb), not a partition (sdb1). You want the entire disk, partition table and all.
  • of=…/2026-0142-item01.dd — the output file: a raw image on your evidence destination, named for the case and item.
  • bs=4M — the block size. Larger blocks (here 4 mebibytes) read faster than the tiny 512-byte default. It does not change the result, only the speed.
  • conv=noerror,sync — the critical forensic pair. noerror tells dd to keep going when it hits an unreadable sector instead of aborting; sync pads each short or failed read up to the full block size with NUL bytes. You must use them together: noerror alone would skip unreadable data and shift every subsequent byte to the wrong offset, silently corrupting the image's alignment. With both, an unreadable sector becomes a block of zeros in the right place, preserving every offset.
  • status=progress — GNU dd prints throughput and bytes copied so you are not staring at a dead terminal for two hours.

The output is a raw image: an exact byte-for-byte stream, the same size as the source, with no wrapper and no metadata. And there is the rub. Plain dd does not compute a hash, does not write a log, and handles errors crudely (a long run of bad sectors can take days as it retries). For forensics that means three separate problems: you have no integrity proof unless you hash separately, you have no record of what happened during the copy, and reading a failing source twice (once to image, once to hash) can be the read that finishes off the drive. dd is the honest baseline — understand it, because everything else is dd with the forensic gaps filled in — but it is rarely the right tool for evidence on its own.

dcfldd — dd built for forensics

dcfldd, written at the U.S. Defense Computer Forensics Lab, is dd with the missing pieces added: on-the-fly hashing of multiple algorithms, hash logging, per-window (piecewise) hashing, progress, error logging, and the ability to write multiple outputs at once. The same acquisition, done right:

sudo dcfldd if=/dev/sdb \
    hash=md5,sha256 \
    hashwindow=512M \
    md5log=/mnt/evidence/2026-0142-item01.md5 \
    sha256log=/mnt/evidence/2026-0142-item01.sha256 \
    hashlog=/mnt/evidence/2026-0142-item01.hashlog \
    errlog=/mnt/evidence/2026-0142-item01.errlog \
    conv=noerror,sync bs=4M \
    of=/mnt/evidence/2026-0142-item01.dd

hash=md5,sha256 computes both an MD5 and a SHA-256 of the data as it streams off the source — so the source hash is captured during the single read you have to do anyway. hashwindow=512M additionally hashes every 512 MiB region separately and logs each one. Those piecewise hashes are gold: if the image ever fails an overall verification, the window hashes localize which region changed, instead of leaving you with one useless "the whole thing is different." errlog records exactly which sectors were unreadable. Output looks like this:

   12800 blocks (51200Mb) written.
   ...
   61440 blocks (245760Mb) written.
   61521+0 records in
   61521+0 records out

   [hashlog excerpt]
   Total (md5): 9f2c1a7e4b0d63a8c5e21f7d90ab43c6
   Total (sha256): 4e1d8b9a6c0f23e7d5a1b4c8f02e96d3a7b5c1e0f8d2a4b6c9e3f1a07d5b2c8e

Tool Tip. A close cousin, dc3dd (from the U.S. Defense Cyber Crime Center), offers the same forensic features with slightly different syntax and is the preferred choice in some labs: dc3dd if=/dev/sdb of=image.dd hash=sha256 log=image.log. Pick one, learn its flags cold, and use it consistently — consistency is itself defensible.

FTK Imager — the Windows standard

FTK Imager (free from Exterro, formerly AccessData) is the most widely used acquisition tool in the world, largely because it is free, reliable, and runs on the Windows machines most examiners already use. It is a GUI (with a command-line build, and a portable "Lite" version you can run from a USB stick at a scene). To acquire a drive: File → Create Disk Image → Physical Drive, select the source, then choose your output. The dialog that defines the evidence is the part that matters:

   Select Image Type:   ( ) Raw (dd)    ( ) SMART    (•) E01    ( ) AFF

   Evidence Item Information
   ┌────────────────────────────────────────────────────────────┐
   │ Case Number:        2026-0142                                │
   │ Evidence Number:    01                                       │
   │ Unique Description: Dell Latitude 5420, internal NVMe SSD    │
   │ Examiner:           [your name / ID]                         │
   │ Notes:              Seized 2026-06-24, sealed bag SB-4471    │
   └────────────────────────────────────────────────────────────┘

   Image Destination:  E:\evidence\2026-0142-item01
   Fragment Size (MB): 0        Compression (0-9): 6
   [✓] Verify images after they are created
   [✓] Create directory listing of all files in the image

Set fragment size to 0 for a single segment (or to ~2,000 MB if you must move files across FAT32 media), choose a compression level for E01, and — this is the box examiners forget under pressure — check "Verify images after they are created." FTK then images the drive, computes the source hashes, reads the image back, recomputes, and compares. When it finishes it writes a plain-text summary you keep with the case:

Created By AccessData® FTK® Imager 4.7.1.2

Case Number:  2026-0142
Evidence Number: 01
Unique Description: Dell Latitude 5420, internal NVMe SSD
Examiner: [redacted]
Notes: Seized 2026-06-24, sealed bag SB-4471

Physical Evidentiary Item (Source) Information:
[Drive Geometry]
 Bytes per Sector: 512
 Sector Count: 500,118,192
[Physical Drive Information]
 Drive Model: Samsung MZVLB256HBHQ
 Drive Serial Number: S3TPNX0M412345
 Source data size: 244198 MB
[Computed Hashes]
 MD5 checksum:  9a1c0e6b4f7d2a83c5e10f9b6d4a72e8
 SHA1 checksum: 1f3c8a02b6d4e79f0c25a18b3d6e4f72a9c0b1d2

Image Verification Results:
 MD5 checksum:  9a1c0e6b4f7d2a83c5e10f9b6d4a72e8 : verified
 SHA1 checksum: 1f3c8a02b6d4e79f0c25a18b3d6e4f72a9c0b1d2 : verified

Note that FTK Imager computes MD5 and SHA-1 for its verification report. That is the historical pairing and it is court-accepted; if your lab policy requires SHA-256 (an increasingly common requirement), generate it separately with hashdeep, sha256sum, or by acquiring with Guymager, dcfldd, or ewfacquire, which support it natively. We will dig into why you want more than one algorithm in the hashing section.

Guymager — the fast Linux GUI

Guymager ships on CAINE, Paladin, and other forensic distros and is the tool to reach for when speed matters, because it is heavily multithreaded — it reads, compresses, and hashes in parallel across CPU cores, which on a fast workstation can saturate the source interface rather than the processor. The workflow is GUI-driven: it lists attached devices, you right-click the source → Acquire image, choose a format (Linux dd raw, Expert Witness Format in either the Guymager or EnCase sub-format, or AFF), enter the same case metadata fields, and tick the hash algorithms (MD5, SHA-1, SHA-256) and "calculate image hash / re-read source after acquisition for verification." Guymager images, then re-reads the source and reads back the image, hashing both, and writes an .info file:

GUYMAGER ACQUISITION INFO FILE
==============================
Version          : 0.8.13
Device           : /dev/sdb
Model            : Samsung_MZVLB256HBHQ
Serial           : S3TPNX0M412345
Size             : 256060514304 bytes (256.1GB / 238.5GiB)
Sector size      : 512 bytes
Format           : Expert Witness Format, sub-format Guymager, compressed

Hash calculation
================
MD5              : 9a1c0e6b4f7d2a83c5e10f9b6d4a72e8
SHA-256          : 4e1d8b9a6c0f23e7d5a1b4c8f02e96d3a7b5c1e0f8d2a4b6c9e3f1a07d5b2c8e

Verification (source vs image)
==============================
MD5 verified     : yes  (source image matches acquired image)
SHA-256 verified : yes  (source image matches acquired image)

State            : Finished successfully

Tool Tip — choosing among the four. Use FTK Imager when you are on Windows or at a scene with a laptop and want a trusted, free, point-and-click image with a clean report. Use Guymager when you want raw speed and SHA-256 on a Linux box. Use dcfldd/dc3dd when you need scripted, repeatable, headless acquisition (a rack of drives, a remote host over SSH) or piecewise hashing. Keep plain dd in your head as the model they are all built on — and for the moments when nothing else is available. Appendix C compares the full tool landscape; Appendix H is the command-line cheat sheet for all of them.

Image formats: raw, E01, and AFF4

The tool makes the copy; the format decides how that copy is stored, what travels with it, and how it proves its own integrity. Three formats dominate, and choosing among them is a real decision with consequences for storage, portability, and court.

Raw / dd (.dd, .img, .001)

A raw image is the data and nothing else: a literal byte-for-byte stream, identical in size to the source, with no header, no metadata, no compression. Its great virtues are universality and simplicity — every forensic tool on earth can read a raw image, because there is nothing to parse; it is just the disk. You can split it into fixed-size segments (.001, .002, …) to fit a destination's file-size limits. Because it is an exact copy, the first bytes of a raw image of an MBR-partitioned disk are simply the first sector of that disk:

Offset      Hex (first 16 and last 16 bytes of sector 0 in a raw image)        ASCII
0x00000000  33 C0 8E D0 BC 00 7C 8B  F4 50 07 50 1F FB FC BF   3.....|..P.P....
   ...                       (446 bytes of MBR boot code + 64-byte table)
0x000001F0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 AA   ..............U·
                                                         └──┴── 0x55AA boot signature

That 55 AA at offset 0x1FE is the MBR boot signature you met in Chapter 4 — proof, byte for byte, that a raw image carries the disk's structures exactly, with no wrapper between you and the evidence. The costs of raw are equally plain: it consumes the source's full capacity on your destination even if the drive is 90% empty zeros, and it carries no metadata, so the case number, examiner, and hashes have to live in separate files you must not lose.

E01 / EnCase Expert Witness Format

The Expert Witness Format (EWF), universally known by its .E01 extension, is the forensic container that solved raw's two weaknesses. Created in the EnCase ecosystem and now readable by virtually everything via the open-source libewf library (ewfacquire, ewfverify, ewfinfo, ewfmount), an E01 is a structured file that wraps the disk data together with case metadata, integrity checks, and compression.

Three features make it the default for evidentiary imaging:

  1. Embedded metadata. The header stores the case number, evidence number, unique description, examiner, acquisition date and time, and the acquiring application's name and version — inside the image, so the provenance travels with the data and cannot be separated from it.
  2. Built-in integrity, at two levels. The acquired media is stored in fixed-size chunks (by default 64 sectors = 32,768 bytes), and each chunk carries its own checksum (an Adler-32), so localized corruption is detected and located. The format also stores a hash of the entire acquired media — an MD5, and optionally SHA-1 — in a dedicated hash section, making the image self-verifying: ewfverify image.E01 re-reads the container, recomputes, and compares against the stored value, with no external hash file required.
  3. Compression. Chunks are compressed with zlib/deflate, and — crucially for forensics — runs of identical bytes collapse dramatically. A drive that is mostly empty (long stretches of 00) or a freshly wiped drive (long stretches of one pattern) images to a fraction of its raw size. A 256 GB SSD with 40 GB of real data can land in well under 60 GB of E01 segments.

E01 images are split into segments — .E01, .E02, … through .E99, then .EAA onward — so you can spread a large image across volumes. The container begins with a recognizable signature:

Offset      Hex                                               ASCII
0x00000000  45 56 46 09 0D 0A FF 00  01 01 00 00 ...           EVF.........
            └─────────── "EVF" + 09 0D 0A FF 00 ───────────┘
            8-byte EWF/E01 signature, then "fields start" (01),
            segment number, and the first section descriptor.

The newer EWF2 / Ex01 format (EnCase 7 and later, also supported by libewf) extends this with native SHA-256, AES-256 encryption of the evidence container, larger chunks, and better compression; its logical-evidence sibling is Lx01. For most day-to-day acquisitions, classic E01 remains the lingua franca, and any examiner or court-appointed expert can open it.

        RAW IMAGE                              E01 CONTAINER
   ┌───────────────────────┐         ┌──────────────────────────────────┐
   │                       │         │ Header: case#, evidence#,          │
   │   exact disk bytes,   │         │         examiner, date, tool ver   │
   │   sector 0 .. sector  │         ├──────────────────────────────────┤
   │   N, no wrapper,      │         │ Chunk 1 [data+Adler32] (zlib)      │
   │   no metadata,        │         │ Chunk 2 [data+Adler32] (zlib)      │
   │   no compression      │         │   ...   (empty runs ⇒ tiny)        │
   │                       │         ├──────────────────────────────────┤
   │   size == source      │         │ Hash section: MD5 (+SHA-1) of all  │
   └───────────────────────┘         │ media  →  self-verifying           │
     readable by everything          └──────────────────────────────────┘
                                       smaller + provenance built in

AFF4

The Advanced Forensic Format version 4 (AFF4) is the modern open standard built for problems the older formats handle poorly: enormous images, partial and logical acquisitions, multiple data streams, and cloud-scale evidence. An AFF4 container is, under the hood, a ZIP archive — you can literally unzip -l one to see its parts — with RDF/Turtle metadata describing the streams it holds. Its defining capability is sparse and arbitrary-extent imaging: AFF4 can store only the regions that contain data and describe the rest as known-empty, which is exactly what you want when you cannot or should not bit-copy an entire multi-terabyte array but must still produce a verifiable, court-meaningful image of the relevant extents. It supports block-level and linear hashing, deduplication, and embedding several pieces of evidence (and even logs) in one container. Tools include Evimetry and the open pyaff4 / aff4imager. (The original AFF by Simson Garfinkel is its deprecated predecessor; AFF4, by Cohen, Schatz, and others, is the successor you will encounter.)

Recovery vs. Forensics. Format choice is itself a place the two disciplines diverge. In a recovery job, your customer wants their data and their drive back today; the fastest path is often to clone the failing source straight onto a healthy replacement disk with ddrescue and hand it over — a raw, device-to-device copy, no container, no court. In forensics, you almost always acquire to E01 (or AFF4 for huge/partial captures): you trade a little speed for embedded provenance, per-chunk integrity, compression, and a file you can authenticate years later in front of a jury. Same drive, same bits — but one workflow optimizes for restoring service, the other for proving facts.

Hash verification: the evidence's fingerprint

A cryptographic hash is a function that takes any amount of input and produces a fixed-length digest — a string of hex digits — that is, for practical purposes, unique to that exact input. MD5 produces 128 bits (32 hex characters); SHA-256 produces 256 bits (64 hex characters). Two properties make hashing the backbone of evidence integrity. First, the function is deterministic and one-way: the same input always yields the same digest, but you cannot work backward from a digest to the data. Second, it exhibits the avalanche effect: changing a single bit of input changes roughly half the bits of the output, so even the tiniest alteration produces a wildly different, obviously non-matching digest. Watch what one changed letter does — dog to cog:

Input:  "The quick brown fox jumps over the lazy dog"
  MD5    = 9e107d9d372bb6826bd81d3542a419d6
  SHA256 = d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592

Input:  "The quick brown fox jumps over the lazy cog"   (d → c)
  MD5    = 1055d3e698d289f2af8663725127bd4b
  SHA256 = e4c4d8f3bf76b692de791a173e05321150f7a345b46484fe427f6acc7ecc81be

One letter changed, and every hex digit of both digests changed. That is the whole power of the technique for forensics: if even one byte of a multi-terabyte image were altered — by an OS write, a bad cable, a cosmic-ray bit flip, or a tampering hand — the hash would not match, and you would know. (For reference, the digest of nothing at all is a constant worth recognizing: MD5("") = d41d8cd98f00b204e9800998ecf8427e, SHA-256("") = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. You will see the empty-string MD5 turn up as the hash of zero-byte files.)

The verification chain

Hashing in acquisition is not one act but a chain, and you must understand each link:

  ┌─────────────┐  hash during read   ┌──────────────┐
  │  SOURCE     │────────────────────▶│ SOURCE hash  │  (computed once,
  │  (evidence) │                     │  H_src       │   on the single read)
  └─────────────┘                     └──────┬───────┘
        │ image                              │ must equal
        ▼                                    ▼
  ┌─────────────┐  read back & hash    ┌──────────────┐
  │  IMAGE      │────────────────────▶│ IMAGE hash   │  H_img == H_src ?
  │  (.E01/.dd) │                     │  H_img       │   ✓ faithful copy
  └─────────────┘                     └──────────────┘
        │ before EACH analysis session
        ▼
  ┌──────────────┐
  │ RE-VERIFY    │  recompute H_img, confirm it still == H_src
  │ image hash   │  ✓ unaltered since acquisition
  └──────────────┘
  1. Hash the source during acquisition. As the imaging tool reads the source, it hashes the stream — this captures H_src, the fingerprint of the evidence as acquired, in the single read you must perform anyway (vital for failing drives — see Limitations).
  2. Hash the image and compare. The tool reads the written image back and hashes it to get H_img. If H_img == H_src, the image is a faithful, bit-identical copy of the source. This is what "verified" means in the FTK and Guymager reports above.
  3. Re-verify before every analysis session. Each time you open the image to work, recompute its hash and confirm it still equals H_src. This proves the image has not changed since acquisition — that nothing in your lab, your tools, or your storage corrupted or altered it. The hash recorded at acquisition becomes the reference value you return to forever after.

You compute and check hashes constantly, with whatever tool is at hand:

# Linux: hash a finished raw image (both algorithms in one pass with hashdeep)
hashdeep -c md5,sha256 /mnt/evidence/2026-0142-item01.dd

# or individually
md5sum    /mnt/evidence/2026-0142-item01.dd
sha256sum /mnt/evidence/2026-0142-item01.dd

# Verify an E01 against its own stored hash (libewf)
ewfverify /mnt/evidence/2026-0142-item01.E01

# Windows: re-verify an image before analysis
Get-FileHash -Algorithm SHA256 'E:\evidence\2026-0142-item01.E01'
Get-FileHash -Algorithm MD5    'E:\evidence\2026-0142-item01.E01'

Why two algorithms — and what about MD5 being "broken"?

You will hear that MD5 is broken, and that is true in a specific sense: MD5 is no longer collision-resistant. Researchers can deliberately craft two different inputs that share one MD5 digest. So why does the forensic world still compute MD5? Because the threat that matters in evidence integrity is accidental change (a flipped bit, a stray write, a failing sector) and naive tampering — and against those, MD5 detects them instantly via the avalanche effect. A crafted collision requires an adversary to construct both files; it does not let anyone modify your specific evidence to match an existing hash (that would be a far harder pre-image attack, which MD5 still resists in practice). The professional answer, and the one you should adopt, is to compute both MD5 and SHA-256. An adversary would need to engineer a simultaneous collision in two different algorithms with different internal structure at once — computationally infeasible. Recording both also future-proofs the evidence: MD5 satisfies legacy expectations and lets you compare against historical hash sets (such as NSRL), while SHA-256 satisfies modern standards.

Legal Note. Hashing is the act that converts "I copied it" into "I can prove it is identical and unaltered." The acquisition hash is the evidence's fingerprint; it is written into the chain-of-custody record, recited in your report (Chapter 26), and quoted on the witness stand (Chapter 27). When you testify "the image I analyzed produced SHA-256 value 4e1d…c8e, identical to the value computed at acquisition," you are offering the court a mathematical guarantee of integrity that is essentially impossible to fake. That single sentence is often what makes digital evidence admissible.

What a hash mismatch means

If H_img does not equal H_src — or if a re-verification before analysis no longer matches the acquisition value — stop. A mismatch is never a rounding error; the hash either matches or it does not. It means the image is not a faithful, unaltered copy, and you must find out why before you do anything else. The common causes, roughly in order of likelihood:

  • A failing source returning unstable data. A dying drive can return different bytes for the same sector on successive reads (a marginal head, an unstable cell). The source itself is not deterministic, so no two images of it will ever hash the same. This is a drive problem, not an examiner error — but it must be documented, and it changes your method (ddrescue, piecewise hashing; see below and Chapter 8).
  • A write that slipped through. No write-blocker, a failed or misconfigured one, or the OS touched the source. The source changed between hashing and verification. This is the failure write-blocking exists to prevent.
  • Hardware faults in the path. A bad SATA/USB cable, a flaky adapter, or failing RAM in the workstation can corrupt bytes in transit. Swap components and re-image.
  • A bug, a full destination, or interrupted acquisition. Out-of-space, a crash mid-write, or a tool defect can truncate or corrupt the image.
  • Tampering. The reason the whole edifice exists. If everything else is ruled out, an unexplained mismatch on a previously verified image is a serious finding in its own right.

The correct response is procedural: document the mismatch and the conditions, preserve the logs and any piecewise hashes (which tell you where the difference is), re-acquire if the source is stable enough to allow it, and — if the source is a failing drive that will never hash consistently — record that limitation explicitly and rely on per-region hashing and the ddrescue map as your integrity record. "The drive's instability prevents a single reproducible hash; the following regions verified, the following did not" is an honest, defensible statement. Pretending the mismatch did not happen is not.

Chain of custody: accounting for every minute

A perfect, hash-verified image is necessary but not sufficient. The other half of admissibility is being able to answer a deceptively simple question: who has had this evidence, when, and what did they do with it, every step from seizure to courtroom? That documented, unbroken trail is the chain of custody, and it is as much a part of forensic acquisition as the imaging itself. The technical integrity (the hash) proves the data did not change; the chain of custody proves the evidence was controlled and accounted for by people you can name. Courts require both.

What the chain records

Every chain-of-custody log captures, at minimum, the identity of the item and a running record of every transfer:

EVIDENCE ITEM
  Case number:      2026-0142
  Evidence number:  01
  Description:      Dell Latitude 5420 laptop, S/N 7F2X9Q3,
                    internal Samsung NVMe SSD S/N S3TPNX0M412345
  Seized by:        Det. [name/badge]   Date/time: 2026-06-24 09:14
  Location seized:  [address / scene reference]
  Acquisition hash: SHA-256 4e1d…c8e   MD5 9a1c…2e8   (added 2026-06-25)

CHAIN OF CUSTODY (every transfer logged; no gaps)
  ┌────────────────────┬──────────────┬──────────────┬──────────────────┬──────────┐
  │ Date/Time          │ Released by   │ Received by   │ Purpose          │ Signature│
  ├────────────────────┼──────────────┼──────────────┼──────────────────┼──────────┤
  │ 2026-06-24 09:14   │ (scene)       │ Det. A.       │ seizure          │   ✔      │
  │ 2026-06-24 11:40   │ Det. A.       │ Evidence tech │ intake/storage   │   ✔      │
  │ 2026-06-25 08:05   │ Evidence tech │ Examiner      │ forensic imaging │   ✔      │
  │ 2026-06-25 14:20   │ Examiner      │ Evidence tech │ return to storage│   ✔      │
  └────────────────────┴──────────────┴──────────────┴──────────────────┴──────────┘

The governing maxim is blunt: if it isn't documented, it didn't happen. Every line is a hand-off with a date, a time, a "from" person, a "to" person, a purpose, and signatures from both. The instant there is a gap — an unaccounted-for hour, an unlabeled item, a transfer no one signed — the defense has an opening to argue the evidence could have been altered, swapped, or contaminated while no one was watching. They do not have to prove it was; raising a credible doubt about the chain can be enough to suppress the evidence entirely. Appendix F provides ready-to-use chain-of-custody and report templates.

The physical side: bags, labels, seals, and storage

Acquisition is also a physical-handling discipline, and the details are not bureaucratic theater — each one closes an avenue of attack on the evidence:

  • Photograph everything as received — the sealed bag, the labels, the device, its serial numbers, its condition — before you open anything. Photos timestamp the as-received state.
  • Evidence labels carry the case number, item number, a description, the seizing person, the date/time and location of seizure, and (once computed) the acquisition hash. The label is the item's identity.
  • Anti-static bags protect electronics from static discharge that could damage the very media you must read.
  • Faraday bags are mandatory for phones, tablets, and any wireless-capable device: they block cellular, Wi-Fi, Bluetooth, and GPS so the device cannot receive a remote wipe or remote-lock command, ping its location, or change state over the network while in your custody. (Keep such devices charged; a phone that dies may re-encrypt at rest and demand a passcode you do not have — a mobile-forensics concern we take up in Chapter 24.)
  • Tamper-evident bags and seals carry unique serial numbers; you sign across the seal so any later opening is visible and attributable. If you must open a sealed item to work, document the seal number, the opening, and reseal with a new numbered seal — logging both.
  • Storage is a locked, access-controlled evidence room or safe with environmental controls and its own access log. The sealed original lives there. You work from the image; the original comes out only when there is a documented reason, and that, too, is a chain-of-custody entry.
   CHAIN-OF-CUSTODY FLOW  (the original is sealed once and worked from copies)

   SCENE ──▶ TRANSPORT ──▶ INTAKE/LOG ──▶ ACQUISITION ──▶ STORAGE (sealed original)
  (seize,    (Faraday/     (label, bag,   (write-block,    (locked, logged)
   photo)     anti-static)  log, hash)     image, verify)        │
                                                                 ▼
                                              ANALYSIS on the IMAGE only ──▶ COURT
                                              (working copy, re-verified)   (testify
                                                                             to hash)

Chain of Custody. The chain and the hash are complementary, not redundant. The hash proves the bits are unchanged; the chain proves people controlled the item the whole time. A defendant can concede the hash matches and still attack a six-hour gap where the laptop sat on an unattended desk — "how do we know that is the same laptop, or that nothing was done to it then?" Conversely, an immaculate chain cannot rescue evidence with no integrity hash. You need both, every time, with no gaps in either.

Ethics Note. The devices you acquire are full of human lives — family photos, medical records, intimate messages, financial ruin, private grief — most of it irrelevant to your case. Handle every device as if its owner were standing behind you, because in a real sense they are. Acquire within the scope of your authority (the warrant or consent that authorizes you — Chapter 25), do not browse beyond it, and protect what you capture as the deeply personal data it is. This is the book's sixth theme made operational: behind every drive is a person, and your professionalism is the only thing standing between their privacy and a careless examiner. Chapter 28 takes up these duties — including the hard one of finding evidence you were not looking for — in full.

Worked example: acquiring the laptop in the court case

Let us walk the entire acquisition for the case that anchors this book — a child-exploitation investigation. We will treat it the way the work itself demands: clinically and procedurally only. There is no description of content here and there will be none anywhere in this book; the subject of this section is the integrity of the acquisition, because integrity is precisely what will later let an examiner testify that what was found was present at seizure and untouched by the examination. The dignity of victims and the fairness owed to the accused both rest on getting these mechanics exactly right.

A laptop was seized under warrant and delivered, sealed, to the lab. The acquisition proceeds:

  1. Receive and reconcile. Match the item to the chain-of-custody record and the warrant's scope. Confirm the seal number is intact and matches the log. Photograph the sealed bag, the labels, and the seal before opening.
  2. Document the device. Record make, model, and serial of the laptop; capacity and condition. Photograph it from all sides. Note anything unusual (damage, an inserted USB stick, an external drive).
  3. Open under seal discipline. Record the existing seal number, open the bag, and — for a drive you will remove — extract the SSD/HDD and photograph it with its own serial visible. (For some machines you image in place via the device's own interface; either way, document the method.)
  4. Connect through a hardware write-blocker. Attach the drive to a NIST-CFTT-tested blocker matched to its interface (NVMe via a PCIe blocker, SATA via a SATA blocker). Record the blocker's model, firmware, and serial. Validate it that morning if you have not already.
  5. Check for hidden regions. Query the drive for an HPA (hdparm -N /dev/sdb) and DCO (hdparm --dco-identify /dev/sdb). If the reported size is less than the native capacity, a hidden area exists; document it and configure the acquisition to capture the full native capacity so nothing is missed.
  6. Image to E01 with metadata. Acquire with Guymager or FTK Imager to a compressed E01, filling the case number, evidence number, examiner, and notes into the container's header. Compute MD5 and SHA-256.
  7. Verify. Let the tool re-read source and image and confirm H_img == H_src for both algorithms. Save the verification report.
  8. Record the hashes everywhere. Write both digests into your notes and onto the chain-of-custody record and the evidence label.
  9. Reseal and return. Reseal the original with a new numbered tamper-evident seal, log the new seal number, and return the original to locked storage — another chain entry.
  10. Make and verify a working copy. Copy the E01 to your analysis storage, verify its hash equals the acquisition value, and from this point forward analyze only the working copy. The original image and the original drive are not touched again except under documented custody.

The verification report from step 7 is the document that anchors everything downstream:

Acquisition verification — case 2026-0142, item 01
  Source:  internal SSD, S/N S3TPNX0M412345, 256,060,514,304 bytes
  Format:  E01 (compressed), acquired with Guymager 0.8.13
  Write-blocker: Tableau T7u (NVMe), fw 2.x, S/N ...   [validated 2026-06-25 07:40]
  MD5     (source)=9a1c0e6b4f7d2a83c5e10f9b6d4a72e8  (image)=9a1c…2e8  VERIFIED
  SHA-256 (source)=4e1d8b9a6c0f23e7d5a1b4c8f02e96d3a7b5c1e0f8d2a4b6c9e3f1a07d5b2c8e
                   (image)=4e1d…c8e                                   VERIFIED
  Working copy SHA-256 = 4e1d…c8e  VERIFIED against acquisition value

When the deleted-file recovery, EXIF analysis, browser history, and timeline that this case will require are produced later (Chapters 20, 21, 18, 16), every one of them will be performed on that working copy, and every finding will trace back to an image whose hash is recorded here. That is what lets the examiner answer, calmly, the most important question the defense will ask: "How do we know your tools, not the suspect, didn't put that there?" The answer is the chain that begins at this acquisition. Anchor #4 will return in Chapter 26 (the report), Chapter 27 (testimony), and Chapter 28 (the ethics, including mandatory reporting under 18 U.S.C. §2258A and the examiner's own well-being); the integrity established right here is what makes all of it stand.

Legal Note. Notice how much of acquisition is documentation, not keystrokes. The imaging took a couple of hours of unattended machine time; the defensibility came from the photographs, the serials, the write-blocker validation, the dual hashes, the seal numbers, and the chain entries. Examiners new to the field over-invest in tool mastery and under-invest in note-taking. In court, your notes are you.

Acquisitions that don't fit the textbook

Most of the cases above assume a healthy drive you can power off and image at leisure. Reality is messier, and technology changes while the principles do not — the book's fourth theme. Each of the following situations bends the method without breaking the cardinal rule; each gets a full chapter later, but you must recognize them at acquisition time.

  • Failing drives. Do not image a dying drive with plain dd; use ddrescue, which maps bad regions, retries them in optimized passes, and resumes from a saved map file: bash ddrescue -d -r3 /dev/sdb /mnt/evidence/item01.dd /mnt/evidence/item01.map Accept that a failing source may never produce two identical hashes; lean on piecewise hashing and the .map file as your integrity record, and document the drive's condition. (Chapter 8 covers physical-failure recovery and clean-room work.)
  • Encrypted drives. Image the raw, encrypted bits now; decryption is a later, separate problem. You can always image ciphertext through a write-blocker; whether you can ever read it depends on keys, credentials, or legal compulsion (Chapter 29). "Imaged but encrypted" is a valid acquisition state.
  • SSDs and TRIM. Image promptly and never write to the source. As Chapter 9 explains, the TRIM command plus the SSD's background garbage collection can physically erase the contents of deleted blocks on their own schedule, so the window to capture deleted data may be closing even as the drive sits powered.
  • Live systems you cannot power off. If a machine is running with full-disk encryption unlocked, or holds volatile evidence in RAM, pulling the plug destroys the decrypted state and the memory. Here acquisition order inverts: capture volatile data first per the order of volatility, then deal with the disk. This is the entire subject of Chapter 15 (live response) and Chapter 22 (memory). The FDE dilemma — power off for a clean image of unreadable ciphertext, or keep running to preserve a decryptable state — is a judgment call you make at the scene.
  • RAID arrays, NAS, and SAN. You may need to image each member disk and reconstruct, or acquire the assembled logical volume; either way the destination must hold the combined capacity (Chapter 10).
  • Cloud and remote data. There is often no physical drive to seize; acquisition becomes legal process and API-based collection (Chapter 31).

Recovery vs. Forensics. Failing-drive handling is the sharpest divergence between the two trades — and it is the heart of anchor #1, the deleted wedding photos. For that distraught client, with a decade of irreplaceable family photographs on a reformatted, ailing drive, the recovery priority is to get a stable image off the patient before it dies for good, even if that means accepting an imperfect, partially unreadable capture — some of the photos back is the whole point, and the human stakes are personal, not legal. The forensic priority on a failing evidence drive is the same ddrescue-style capture, but wrapped in documentation: every unreadable region logged, the drive's condition recorded, piecewise hashes preserved, so that the incompleteness itself is provable and defensible. Same tool, same urgency — different burden of proof, because one copy must restore a family's memories and the other must withstand cross-examination.

Common mistakes

  • Imaging without a write-blocker — or mounting the original read-write. The single most common fatal error. The OS writes to the source, the hash changes, the evidence is compromised. Hardware-block every source, every time.
  • Booting the suspect machine "just to look." Powering the evidence machine from its own OS modifies timestamps, journals, and dozens of system files — often the very artifacts the case depends on. Image first; look only at the copy.
  • Computing one hash, or none, or never re-verifying. A single hash is weaker than two; no hash is indefensible; and a hash computed at acquisition but never re-checked before analysis cannot prove the image stayed unaltered in your custody. Compute MD5 and SHA-256, and re-verify before every session.
  • Working on the original instead of a verified copy. Even with a perfect image, analyzing the original (or the only image) risks the irreplaceable. Make a working copy, verify it, and quarantine the master.
  • Doing a file copy instead of a physical image. Copying files discards unallocated space, slack, deleted data, and hidden regions — usually the most valuable evidence. Acquire the whole physical device.
  • Missing the HPA/DCO. Trusting the drive's reported size can leave a hidden region — and the data in it — entirely unexamined. Check for host-protected and device-configuration areas and capture native capacity.
  • Destination too small, not wiped, or auto-mounting. Verify the destination has room for the full source (raw needs the whole capacity), pre-wipe and verify destination media so old data cannot bleed in, and ensure the destination does not auto-index or write to your source.
  • Phones not bagged. A wireless device left out of a Faraday bag can be remotely wiped or locked before you image it. Isolate radios immediately.
  • Thin documentation. No photos, missing serials, unrecorded write-blocker model, gaps in the chain. The acquisition can be technically perfect and still fail in court for want of notes.
  • Trusting "succeeded" without reading the verification result. A tool reporting "done" is not the same as a tool reporting "verified." Open the report, read the words "verified" next to both hashes, and confirm the image exists at the expected size on disk. Reported success is not verified success.

Limitations: knowing when to stop

Acquisition is powerful, but it is not magic, and a mature examiner is precise about its boundaries — the book's fifth theme. Honesty about what you cannot acquire is as professional as skill at what you can.

  • You cannot acquire what the hardware will not read. A drive with a dead PCB, seized heads, or a failed controller returns nothing until it is physically repaired or its storage media is read by other means (clean-room head swap, chip-off of raw NAND). That is physical recovery, not imaging (Chapter 8, Chapter 9) — and a chip-off, by reading the NAND directly, is itself a different acquisition with its own integrity considerations.
  • A failing source may never yield a stable hash. If the drive returns different bytes on re-read, there is no single reproducible whole-disk hash to be had. The honest record is the ddrescue map, the list of unreadable regions, and per-region hashes of the stable parts. Document the limitation rather than papering over it.
  • You can image ciphertext you may never decrypt. A bit-perfect, fully verified image of a strongly encrypted volume is still unreadable without the key. "Acquired and verified, but encrypted and inaccessible" is a complete and valid finding (Chapter 29).
  • Some data is genuinely gone. TRIM-erased SSD blocks, securely overwritten regions, and physically destroyed media place data beyond recovery. This is the hard boundary of deleted ≠ destroyed: deletion alone leaves data behind, but deliberate overwriting and physical destruction can defeat acquisition entirely.
  • Scale and time impose limits. You cannot bit-image a multi-petabyte array or an entire cloud tenancy in a weekend. Targeted, logical, or sparse acquisition (AFF4) and legal process replace full physical imaging when the data is too large or not physically in your hands.

The professional move when you hit one of these walls is to state it plainly: "The device was acquired and verified; regions X were unreadable due to media failure; volume Y is encrypted and was not decrypted; analysis is therefore limited as follows." A clear statement of limitation is a finding, not a failure — and it is far stronger in court than an overreach that cross-examination can puncture.

Progressive project: acquire the case evidence

In Chapter 5 you received the assignment and opened your Forensic Case File. Now you perform the step the whole case rests on: acquire a verified forensic image and start the chain of custody. Use a practice image or a small disposable USB drive you have populated yourself (see Appendix J for sources of practice images and a lab build; never practice on real evidence or on data you do not own).

Do this:

  1. Isolate and document the source. Record its make/model/serial and capacity, and photograph it. Note its condition.
  2. Acquire through write protection. Attach the source via a hardware write-blocker if you have one, or — for practice — through a validated software read-only configuration on a forensic Linux distro. Record the method.
  3. Image to a forensic format with metadata. Use Guymager or FTK Imager to create a compressed E01 (or dcfldd to a raw .dd), entering a case number, evidence number, examiner, and notes. Compute MD5 and SHA-256.
  4. Verify. Confirm the source and image hashes match for both algorithms; save the verification report into your case file.
  5. Make and verify a working copy. Copy the image, confirm its hash equals the acquisition value, and resolve to analyze only the copy from here on.
  6. Start the chain-of-custody log. Using the template in Appendix F, create the evidence record (item identity, both hashes, your name, date/time) and the first transfer entries.

A raw acquisition plus hashing from the command line:

# 3a) Acquire to raw with on-the-fly dual hashing and piecewise hashes
sudo dcfldd if=/dev/sdb hash=md5,sha256 hashwindow=256M \
    md5log=case/CASE-2026-XX-item01.md5 \
    sha256log=case/CASE-2026-XX-item01.sha256 \
    conv=noerror,sync bs=4M \
    of=case/CASE-2026-XX-item01.dd

# 4) Verify the finished image
hashdeep -c md5,sha256 case/CASE-2026-XX-item01.dd

# 4 (Windows) Re-verify the image hash before analysis
Get-FileHash -Algorithm SHA256 'D:\case\CASE-2026-XX-item01.E01'

A small, reusable helper to hash an image in chunks (works on huge files without loading them into memory) and append a chain-of-custody line — the kind of script that grows into your personal toolkit (see Appendix B):

#!/usr/bin/env python3
"""Hash a forensic image (MD5 + SHA-256) and append a chain-of-custody record.
Illustrative: read-only on the image; never modifies evidence."""
import hashlib, datetime, sys

def hash_image(path, chunk=1 << 20):           # 1 MiB chunks
    md5, sha256 = hashlib.md5(), hashlib.sha256()
    with open(path, "rb") as f:                # read-only: never alters the image
        for block in iter(lambda: f.read(chunk), b""):
            md5.update(block); sha256.update(block)
    return md5.hexdigest(), sha256.hexdigest()

def coc_line(case, item, examiner, md5, sha256):
    ts = datetime.datetime.now().isoformat(timespec="seconds")
    return (f"{ts} | case={case} item={item} | examiner={examiner} | "
            f"action=hash-verify | MD5={md5} | SHA256={sha256}\n")

if __name__ == "__main__":
    image, case, item, examiner = sys.argv[1:5]
    md5, sha256 = hash_image(image)
    print(f"MD5   : {md5}\nSHA256: {sha256}")
    with open("chain_of_custody.log", "a", encoding="utf-8") as log:
        log.write(coc_line(case, item, examiner, md5, sha256))
    print("Recorded to chain_of_custody.log")

Add to your case file: the acquisition verification report, the dual-hash record (MD5 + SHA-256), the working-copy verification, and the started chain-of-custody log. Everything you do in Chapters 15 through 24 will be performed on the working copy you created here, and every finding will trace back to these hashes. You now hold a verified image and an open chain — the foundation of the investigation.

Summary

Forensic acquisition is the step you cannot redo, and this chapter taught you to do it right. You acquire a complete, sector-by-sector image of the device — not a copy of its files — so that unallocated space, slack, deleted data, and hidden regions all come with it, because that is where the evidence usually lives. You make that image through a write-blocker, preferably a hardware one, because an operating system writes to a disk the moment it sees it and a single stray write changes the hash and breaks your ability to prove the evidence is unaltered; hardware blocking is host-independent, NIST-CFTT-testable, and simple to defend, where software blocking is a useful supplement that depends on correct configuration. You choose a tool to match the job — dd as the universal model, dcfldd/dc3dd for scripted forensic captures with piecewise hashing, FTK Imager for trusted free Windows imaging, Guymager for fast Linux imaging with SHA-256 — and a format to match the purpose: raw for universal simplicity, E01 for embedded metadata, per-chunk integrity, compression, and self-verification, AFF4 for huge or partial captures. You prove integrity with cryptographic hashes, computing both MD5 and SHA-256, capturing the source hash during the single read, verifying the image against it, and re-verifying before every analysis session — and you know that a mismatch is never noise but a signal to stop, document, and investigate. Around all of it you maintain a chain of custody: labels, photographs, anti-static and Faraday bags, numbered tamper-evident seals, locked storage, and a gap-free transfer log, because the hash proves the bits are unchanged and the chain proves people controlled the item, and the court demands both. Through the court-case acquisition you saw how integrity established at this step is what later lets an examiner testify that what was found was present at seizure and untouched; through the wedding-photos contrast you saw the same techniques serve recovery's human urgency and forensics' burden of proof. And you learned the limits — failing drives that never hash the same, ciphertext you may never read, data that TRIM or destruction has genuinely erased — and that naming a limitation plainly is itself professional work. Above everything sits the cardinal rule, arrived at from both directions: the original is sacred; image first, verify, and work only on the copy.

You can now: - Explain why a forensic acquisition copies the entire device — unallocated space, slack, and hidden HPA/DCO regions included — rather than its files, and why an OS will silently alter an unprotected source. - Choose and justify hardware vs. software write-blocking, and validate a write-blocker before trusting it. - Acquire a drive with dd, dcfldd, FTK Imager, or Guymager, and choose among raw, E01, and AFF4 for the situation at hand. - Compute, record, and verify MD5 and SHA-256 hashes through the full acquisition chain, and respond correctly to a hash mismatch. - Maintain a defensible chain of custody — labels, bags, seals, storage, and a gap-free transfer log — and document an acquisition so it survives cross-examination. - Recognize the acquisitions that don't fit the textbook (failing, encrypted, SSD/TRIM, live, RAID, cloud) and state acquisition limitations honestly.

What's next. Chapter 15 — Live Response and Triage Forensics — confronts the case this chapter set aside: the machine you cannot simply power off. You will learn the order of volatility, how to capture RAM and running state before they vanish, and how to triage at speed when full imaging must wait.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.