Write Blocking, Imaging Formats and Verification That Holds Up

Acquisition is the part of an examination most often attacked and least often defended well, because the defence has to be built before the analysis starts. What survives challenge is not a tool choice but a record: a tested tool at a named version, a blocker whose function you can demonstrate, a documented reason for the scope you took, two digests computed in one pass, and every read error logged with its offset.

Does write blocking still mean what it used to?

A write blocker sits between the examination host and the evidence device and refuses commands that would modify it. The distinction between hardware and software blocking is real and worth stating precisely.

Hardware blockers are bridge devices that inspect the command stream and drop writes. They are interface-specific, they can be tested independently of the host operating system, and NIST's CFTT programme publishes specifications, test assertions and test reports for both hardware and software write blocking. If you use a blocker whose model appears in those reports, you have a citable basis for saying it works.

Software blocking is enforced by the examination host. On Linux this is blockdev --setro on the device, mounting read-only, and — for journalled filesystems — mount options that prevent journal replay, because replaying a dirty journal writes to the evidence. Automount, LVM and RAID metadata scanning, and filesystem probing on device attach must all be suppressed, which in practice means udev rules rather than good intentions. On Windows, the commonly cited registry approach scopes only to USB mass storage devices and is not a substitute for a tested blocker.

What write blocking does not cover is the more important half:

• Self-encrypting drives. The blocker stops host writes; it does nothing about the fact that the data is ciphertext without the key.
• Solid-state internal activity. An SSD controller performs wear levelling and garbage collection on its own schedule while powered. A blocker prevents your writes. It does not freeze the device, and it is the reason a whole-device SSD hash may not reproduce.
• Areas not presented to the host. Legacy ATA host-protected and device-configuration areas, and on NVMe, namespaces that are not attached, can hide capacity from an ordinary acquisition. Check reported capacity against the device's own stated geometry.
• Firmware that modifies on power-up. Some devices write on initialisation regardless of what the host asks.
• RAID members. An individual member disk imaged behind a blocker is correct and useless on its own; the array configuration is part of the evidence.

So the honest statement in a report is not "the evidence could not be modified". It is "host writes to the device were blocked by [device, model, firmware], which was verified before and after use, and the following classes of change remain possible for the following reasons".

What should you actually image?

The instruction to always take a full physical image no longer describes most real work. Full-disk-encrypted laptops, cloud-resident mail, live production servers, mobile devices where the vendor permits only a logical extraction, and multi-terabyte estates all defeat it. What is required is not a fixed answer but a documented, justified and reproducible choice — which is exactly what ISO/IEC 27041 means by assuring that an investigative method is suitable and adequate, and what ISO/IEC 27037 is getting at when it treats proportionality as part of identification and collection.

The realistic options, in descending completeness:

Physical image of the whole device. Every sector, including unallocated space and areas no filesystem claims. Necessary if deleted content, carving or file system metadata history matter. Impossible where the storage is encrypted at rest and you have no key, or where the device cannot be removed or powered down.

Logical image of a volume. Every sector of a partition. Loses whatever lies outside it, including some partition-level artifacts.

Targeted collection. A defined set of artifacts, collected live. KAPE does this on Windows with targets and modules, writing to a container you can mount; Velociraptor does it across an estate with a query language, which is the difference between examining one machine and triaging four hundred. Targeted collection is now the norm in incident response and increasingly in civil matters, and its defensibility rests entirely on being able to state what was collected, what was not, and why.

Live acquisition of volatile state. Memory, running process state, network state. Non-repeatable by definition, which changes what verification can mean.

Decide in that order and record the reason for stopping where you did. An examiner who took a targeted collection and can explain why is on firm ground. One who took a targeted collection because the tool defaulted to it is not.

Which imaging format, and why does it matter?

Format	Metadata	Compression	Internal integrity	Portability
Raw (dd, .001)	None	None	None	Universal
Expert Witness (E01 and later variants)	Case fields embedded	Yes	Per-chunk checksums plus stored acquisition hash	Very wide
AFF4	Yes	Yes	Yes	Growing; supports sparse and discontiguous images
VHD / VHDX	Limited	Yes	Limited	Mounts natively on Windows

Raw is universally readable and carries nothing. No case metadata, no compression, no integrity structure. That is not disqualifying — it is arguably the safest long-term archival choice — but it means the digest and the acquisition log are not optional extras, they are the only verification the artifact has.

The Expert Witness family is the workhorse. It embeds acquisition metadata, compresses, segments, and stores a checksum per data chunk alongside the acquisition hash, which means a corrupted region can be localised rather than invalidating the whole image. The open implementation is libewf and its ewfacquire, ewfverify, ewfinfo and ewfmount tools, and being able to verify and mount an image with open tooling — independently of the commercial product that produced it — is worth a great deal when the format itself is questioned. Later EnCase-era variants add stronger compression and optional encryption.

AFF4 matters where the image is sparse or discontiguous, which is the normal case for live and targeted acquisition.

VHDX is what several targeted-collection tools emit, because it mounts natively and reviewers can browse it.

The practical rule is the one nobody writes down: choose a format the other side can open. An image in a format opposing counsel's expert cannot read produces a discovery fight, not evidence. FTK Imager is free, ubiquitous, and reads all the common formats, which makes it the effective lowest common denominator whether or not it is your working tool.

Bruce Nikkel's Practical Forensic Imaging covers the whole chain with open tools and is the best single book on this specific subject; Practical Linux Forensics extends it where the subject system is not Windows.

What does verification that survives challenge consist of?

Eight elements. Missing any one of them is a question you will be asked.

1. Device identity read from the device. Make, model, serial and capacity in sectors, obtained by querying the device, not transcribed from the label — and recorded again after acquisition.
2. Blocker identity and a functional check. Model, firmware, and the fact that you verified it before and after this acquisition.
3. Tool and version, with a testing record. SWGDE's minimum requirements for testing tools states what to record about the tool, the test data and the outcome. Federated Testing makes this achievable for a small lab, and CFReDS provides images with known answers to test against. FSR-G-218 on method validation is the fuller treatment if you are building a validation programme rather than documenting one acquisition.
4. Two digests in one pass. Name the algorithms. Simultaneous MD5 and SHA-256 costs nothing and removes an entire line of attack.
5. A source-side digest where feasible, and an explicit statement where not. On a live system, failing media, or an SSD, source hashing may be impossible or non-reproducible. Record that before acquisition, not afterwards when the numbers fail to match.
6. Every read error, with offset and extent. Imagers substitute padding for unreadable sectors and different tools pad differently, so two correct images of the same failing drive can legitimately differ. An image with 137 documented bad sectors is a good image. An unexplained mismatch is not.
7. A contemporaneous log kept as evidence. Times, actions, people, in the order they happened. This becomes an exhibit; treat it as one from the first line.
8. Re-verification at every transfer, recorded each time.

Where the process is the whole argument, SWGDE's computer forensic acquisition best practices and digital evidence collection best practices are the documents to align to, with the ACPO good practice guide still the clearest short statement of the underlying principles for anyone working in a UK context.

What can an acquisition record not establish?

• A hash match does not prove the image is faithful to the device. It proves the image matches what the tool read. If the blocker failed, if capacity was hidden, if the controller returned inconsistent data, the digest matches a flawed read perfectly. Fidelity is carried by the tested tool, the working blocker and the log.
• Verification does not reach backwards. Coverage begins at the first digest. Anything that happened to the device before you touched it is chain of custody and other people's evidence.
• A mismatch is not proof of tampering. SSD internal activity, mounted volumes, live systems and failing media all produce legitimate mismatches. What is not legitimate is a mismatch you did not anticipate and cannot explain.
• Nothing about the acquisition speaks to content. A perfectly acquired image of a fabricated document is a perfect image of a fabricated document.
• A physical image is not a complete account of the data. Cloud-resident, server-side and ephemeral data was never on the device. Saying "we imaged the laptop" answers a narrower question than most parties believe.

How does this get litigated?

Authentication of the copy runs through Rule 902(14), which allows data copied from a device or storage medium to be self-authenticated by certification where the copy is authenticated by a process of digital identification, and through Rule 901(b)(9) for output of a process or system generally. Reliability of the method itself is the Daubert inquiry, extended to technical and experience-based expertise by Kumho Tire, and it is answered with testing records rather than assurances. United States v. Durham states the standard that actually applies to an image: where evidence is not readily identifiable and is susceptible to alteration, the foundation must be a chain of custody complete enough to make exchange, contamination or tampering improbable — and in that case the court also upheld the government producing a mirror image rather than the device itself.

Two civil realities deserve equal attention. First, you will frequently not get the device at all. In In re Shipman the Texas Supreme Court conditionally granted mandamus and ordered the trial court to vacate an order requiring a party to turn over his devices for forensic examination, holding that a suspicion the responding party had not searched diligently did not justify it; in Motorola Solutions v. Hytera the court refused a renewed motion to compel forensic inspection of an opponent's machines, noting that such examination is not routine even domestically and that the request was disproportionate and late. Plan acquisition around what you are likely to be permitted, and preserve the argument for more.

Second, holding images too long is its own exposure. United States v. Ganias reached the Second Circuit en banc over the government's retention of forensic mirrors for years after the original warrant's scope was exhausted; the conviction was affirmed on good faith and the court expressly declined to decide whether the retention itself violated the Fourth Amendment. The question is open, and a retention schedule you can point to is cheaper than litigating it.

For training that covers acquisition as an examined competency rather than a lecture, IACIS BCFE and the CFCE process both test it hands-on, and the SANS FOR series with GCFA is the other well-trodden route. Either way, test against CFReDS and CFTT material yourself — a validation you performed is worth more in testimony than one you cite.