Disk Image Integrity and Chain of Custody Mechanics

Acquisition is the step that fixes the evidentiary ceiling for everything after it. A disk image is not a copy of what happened; it is a copy of the storage as it existed at one instant, produced by a procedure whose details determine what questions the image can still answer. Two acquisitions of the same machine can differ in whether a deleted file is recoverable, whether an unallocated region is intact, and whether the image can be shown to correspond to the machine at all.

The procedure has three separable properties: whether the source was modified during acquisition, whether the copy is verifiably identical to the source, and whether the source can be shown to be the machine in question. Confusing them is the standard mistake.

Integrity is a claim about two byte streams

A cryptographic hash over an image proves that the image bytes have not changed since the hash was computed. It does not prove the image matches the device. That second claim requires a hash computed on the source and compared with the same hash computed on the copy. The comparison is meaningful only if both hashes cover the same byte range and the source did not change between the two reads.

MD5 remains in wide use for this purpose because legacy tooling emits it and because the property needed here is not collision resistance, since nobody is constructing a chosen-prefix collision against a disk image, but it is a defensible choice only when paired with a stronger digest. SHA-256 is the practical default; the storage cost is 64 hex characters per image rather than 32, which is irrelevant next to the image itself.

The failure mode this protects against is quiet corruption during transfer rather than adversarial tampering: a USB bridge with a faulty cable, a truncated write, an out-of-space condition reported incorrectly. Hashes catch all three. What they cannot catch is a consistent error: a tool that misreads the same sector identically on both source and destination, for example by silently skipping an HPA or DCO region on both reads. That is why the acquisition log records the device geometry as the kernel reported it, so the expected size can be compared against the size actually read.

Write blocking changes what the image can support

Opening a block device read-write gives the operating system the opportunity to touch the medium: journal replay, mount-count updates, file-system cache flushes, and the atime updates described in filesystem timestamps and timestomping all write. Every such write destroys the distinction between the state at the moment of seizure and the state after handling.

Two mechanisms prevent it. A hardware bridge that presents the device as read-only enforces the property below the operating system, so neither the kernel nor a userspace tool can write. A software blocker such as the blockdev --setro ioctl on Linux, or a mount option such as ro, enforces it in the kernel’s block layer or file-system layer, which is weaker but sufficient against accident. Mounting a file system read-only is the weakest of the three, because the ro mount flag governs the file-system driver, not the device, and because a dirty journal may be replayed in memory and written back by some drivers regardless.

The distinction between blockdev --setro and a ro mount also explains an acquisition-ordering rule. When the source is a live system that must keep running, memory must be captured before the disk is copied, because copying the disk changes the disk and cannot change memory; the reverse order loses the pages that were live during acquisition. That ordering interacts directly with live memory acquisition, where the perturbation cost runs the other way.

Sparse acquisition and what it discards

Full-device imaging reads used blocks and unused blocks alike. For a multi-terabyte array that is impractical, so tools support sparse or logical acquisition: copy only the regions the file system marks as allocated, leaving the rest as zeros in the output.

The trade is exact and should be stated in the acquisition record. Sparse acquisition preserves allocated file content and the metadata needed to interpret it. It discards unallocated space, which is where deleted content, prior versions of files, and the residue of previous file systems live. A case that hinges on recovering a deleted file cannot be answered from a sparse image. Conversely, a case that hinges on whether a specific file existed is answered equally well from either, and the sparse image is a fraction of the size.

Sparse images also break naive hashing: the zeros written for unread regions do not match the source, so a source-versus-copy hash comparison is only valid over the same, equally sparse ranges. Tools that support this record a per-segment map, and the hash is computed over the concatenation of read segments in a defined order.

Physical order is not logical order

Block devices are not always addressable linearly. A modern drive presents 512-byte logical sectors over a 4096-byte physical sector size, and the layer between them may remap writes for wear levelling or for thin provisioning. Reading via the device interface therefore recovers the current logical content, not the physical placement of that content on the medium. Regions the controller has deemed bad and remapped are invisible at the device interface.

This sets a hard limit. Anything that can only be recovered by reading the medium directly: fragments in controller-managed spare areas, previous content of blocks the controller reclaimed, is not in the image and cannot be argued from it. Where that level of recovery is genuinely required, it is a specialized service performed with vendor tooling, not something a dd variant can reach, and the resulting artifact is a separate item in the custody record with its own hash.

The custody record as a state machine

The documentary side of acquisition is a sequence of transfers, each with a time, a place, a custodian, and a hash. Its purpose is to bound who could have altered the artifact between the hash computed at acquisition and the hash recomputed before analysis.

Field	Recorded at	Why it matters
Item identifier	Seizure	Ties the artifact to the device, not the hostname
Blocker	Before the first read	Distinguishes enforced read-only from asserted
Reported size	Before the first read	Baseline for detecting a truncated image
Bytes read	End of acquisition	Must equal reported size for a full image
Source digest	End of source read	Provenance; without it the image has integrity only
Image digest	End of write	Compared against the source digest
Custodian and seal	Each handover	Bounds who could have altered the artifact

The record is only useful if it is written as the steps occur. Reconstructed afterwards, it documents what someone remembers rather than what happened, and a custody record with a gap is treated as weak regardless of how careful the handling actually was.

Where the procedure fails quietly

Four failures recur. Imaging a device while the machine is still mounted read-write, then documenting the device as “not modified”, misstates the source condition rather than corrupting the image. Omitting the source hash, so the image has integrity but no provenance. Acquiring over a USB bridge that silently remaps sectors, producing a consistent but incorrect read on both sides. And storing the image on media whose capacity is exceeded mid-write, producing a truncated but well-formed file that only the size comparison catches.

Each is detectable from records that cost nothing to keep: the kernel’s reported device size, the byte count actually read, two hashes rather than one, and the blocker’s identity. The earlier article on process start records makes the same argument for different evidence: what the system recorded at the time is the only thing that survives the reconstruction, and the reconstruction is always someone’s inference.