The Digital Chain of Custody: Write-Blocker Logs and Hash Discrepancies

In digital forensics, chain of custody is not a paper trail alone. The technical anchor is a pair of cryptographic hash values: one computed when the evidence is first acquired, and one computed when the working image is verified. If the two values are identical, the examiner can testify that the copy is bit-for-bit faithful to the source. If they diverge, you have an MD5 or SHA-256 hash mismatch, and the reason for that divergence becomes a threshold issue before the data ever reaches analysis.

For enterprise servers, the acquisition phase is where most defensible cases are won or lost. The custody documents (who held the drive, when, and under what seal) authenticate the physical handling. The hash authenticates the bytes. A perfect custody log cannot rescue an image whose verification hash does not match its acquisition hash, and a strong hash chain can survive gaps in the human narrative. Attorneys who conflate the two will misjudge both the strength of their own evidence and the vulnerability of the other side's.

A hardware write-blocker is not a setting. It is a physical device inserted between the source storage and the examiner's workstation. It intercepts the low-level command set the operating system sends to the drive (ATA, SATA, SAS, NVMe, or USB mass storage commands) and enforces a one-way rule: read and identify commands pass through, while any command that could modify the media is blocked or returns a benign response.

This matters because simply attaching a drive to a running computer is not passive. Modern operating systems write to any volume they recognize. They update file access timestamps, replay journal transactions, mount and index the volume, and can update drive-resident areas such as SMART attributes or the Host Protected Area. Any one of those writes alters the source and gives opposing counsel a concrete argument that the evidence was changed after seizure. The write-blocker removes that entire class of objection at the hardware level.

• Hardware write-blockers are preferred for removable media because the enforcement lives outside the examiner's operating system and is independently testable.
• Software write-blockers rely on the acquisition operating system honoring a read-only flag, which is defensible but places the control inside the same environment being trusted.
• The NIST Computer Forensics Tool Testing (CFTT) program publishes device specifications and test results for write-blockers, which is the independent validation an expert should be able to cite for the specific model used.

The clean textbook workflow (power down, remove the disk, attach it through a write-blocker, image it) frequently does not apply to enterprise infrastructure. Corporate attorneys and adjusters should expect the acquisition method to be dictated by the environment, and should ask why a given method was chosen.

• RAID arrays stripe or mirror data across multiple physical disks. A single disk pulled from a RAID 5 or RAID 10 set is not a readable file system on its own. The examiner must either image every member disk and reconstruct the array, or acquire the logical volume the controller presents.
• Live production systems cannot always be shut down. A running database or hypervisor holds relevant state in memory and in open files. Powering it off can destroy volatile evidence and cause business damage, so a forensically sound live acquisition may be the correct call.
• Full-disk encryption (BitLocker, LUKS, self-encrypting drives) means a powered-off image is an encrypted blob. If the system is live and unlocked, imaging the decrypted logical volume may be the only way to obtain usable data, and the keys or recovery credentials become part of the record.
• Virtualized and cloud servers have no physical disk to seize. Acquisition happens at the virtual disk, snapshot, or API layer, and the write-blocker concept is replaced by read-only export procedures.

The consequence for admissibility: in a live acquisition you get a one-time snapshot. You cannot later re-read the source to reproduce the identical state, because the running system has moved on. That is why the hash must be computed at the moment of collection, and why the order in which volatile data is captured (memory before disk, following the order-of-volatility guidance in RFC 3227) is itself a point an expert should be prepared to defend.

A forensic image is not a copy of the files. It is a copy of the storage, every sector, including regions a normal file copy ignores. That completeness is the point, because deleted and residual data frequently carry the decisive evidence.

• Allocated space holds live files.
• Unallocated space holds data from deleted files that has not yet been overwritten.
• File slack is the leftover area between the end of a file and the end of the last cluster it occupies, which can retain fragments of prior data.

Image formats carry different evidentiary weight. A raw image (often called dd) is a plain sector-for-sector dump with no embedded metadata. Forensic container formats such as EnCase Evidence File (E01) and AFF4 embed the acquisition hash, examiner notes, and per-block integrity checks inside the file itself, and store internal checksums that flag localized corruption within the container. For an enterprise matter, the format choice and whether the image was compressed or split should appear in the examiner's notes, because those decisions affect how the integrity data is interpreted later.

A cryptographic hash function reduces an input of any size to a fixed-length digest: 128 bits for MD5, 256 bits for SHA-256. The property that makes hashing useful for evidence is the avalanche effect. Change a single bit anywhere in the input, and roughly half of the output bits change. The new digest bears no visible relationship to the old one. There is no partial match and no near miss. Two digests are either identical or they are different, and a difference of one bit in a multi-terabyte image produces a completely different hash.

This is exactly the behavior evidence handling requires. If any bit of the image diverges from the source, whether from a failing sector, a marginal SATA cable, a memory error on a workstation without ECC, uncaught corruption during a network transfer, or slow media degradation, the verification hash will not match the acquisition hash. The hash cannot tell you where the divergence occurred or why. It only tells you, with near-certainty, that byte-level identity failed.

On MD5 specifically: it is cryptographically broken for collision resistance, meaning a motivated party can engineer two different inputs that share an MD5 digest. That is a real concern when the question is deliberate forgery. It is not a concern for detecting accidental corruption, which is the ordinary verification use. The mainstream practice is to record both MD5 and SHA-256. Computing two independent digests over the same data makes an engineered collision that satisfies both functions at once computationally infeasible, and it gives the expert two separate anchors to testify to.

A hash mismatch is a signal, not a verdict. The critical distinction is when the two hashes diverged, and the imaging log is what lets you tell the difference.

1. Verification mismatch after a clean acquisition. The source was read cleanly, an acquisition hash was recorded, and a later verification of the stored image does not match. This points to corruption of the image after it was made: bad storage, a faulty transfer, or, in the worst case, alteration. This is the scenario that should draw the most scrutiny.
2. Acquisition of a degrading source. If the source drive has unreadable sectors, a forensic imaging tool logs each read error and typically substitutes a fixed pattern (often zeros) for the sectors it cannot read. Two images of the same failing drive can legitimately produce different hashes because the drive returns different results on different reads. Here a hash difference is explainable, and the tool's error log is the explanation.

This is why the reflexive claim that a hash mismatch equals spoliation is often wrong, and why the opposite reflex, waving a mismatch away, is equally unsafe. The defensible answer lives in the logs: the write-blocker's report, the imaging tool's sector-error log, and the recorded acquisition and verification digests. Without those, a mismatch is unresolvable and the evidence is exposed. With them, an examiner can frequently show that a difference was caused by a documented, physically explained condition of the source rather than by any handling failure.

Federal Rule of Evidence 901 requires the proponent to show that an item is what it is claimed to be. For digital evidence, the acquisition and verification hashes are the mechanism that satisfies that authentication standard. Federal Rule of Evidence 902(14) goes further and allows electronic data copied from a device to be self-authenticating when a qualified person certifies that it was verified by hash or other reliable digital identification, which can remove the need for live foundation testimony if the certification is properly prepared.

The reliability of the method itself is tested under Federal Rule of Evidence 702 and the Daubert standard (or the Frye general-acceptance standard in jurisdictions that still apply it). Write-blocking, forensic imaging, and cryptographic hashing are well-established and independently validated techniques, which is a strong position, but the expert must still show the method was applied correctly in this matter. SWGDE best-practice guidance and NIST CFTT tool validation are the external references that support the general reliability prong.

Do not guarantee an outcome to a client on the strength of a matching hash. Admissibility turns on the whole foundation, the court, and the specific challenge raised. A clean hash chain is powerful, and it is not a promise.