Hash Verification in Digital Evidence

A cryptographic hash function takes any input, from a 2 KB text file to a 4 TB disk image, and produces a fixed-length value. Change one bit of the input and the value changes completely. The function runs one way, so the value cannot be turned back into the data. In digital forensics this gives us a fingerprint: compute it on the original at the moment of acquisition, compute it again on any copy, and if the two values match the copy is the same, bit for bit.

That is the whole idea. The practice is where cases are won or lost: which algorithm, computed when, by whom, recorded where and compared against what. This tutorial takes each in turn and ends with a worked example using invented values.

Everything in this example is made up, including the hash values, which are not the hashes of anything. An examiner receives a 2 TB external hard drive, serial number recorded as EXT-2TB-0001 in the seizure memo. She connects it through a write blocker and images it to E01 with SHA-256 verification enabled. The tool reports the source SHA-256 as 7c1e4a0b9d2f6e8a3b5c7d9e1f2a4b6c8d0e2f4a6b8c0d2e4f6a8b0c2d4e6f8a (example value) and, after re-reading the image, the same value. She records the algorithm, both values, the tool name and version, the start and end time and her name in the acquisition log and on the chain-of-custody form.

Three days later the image is copied to the analysis workstation. The analyst recomputes SHA-256 and gets the same example value. He signs the transfer line. Two weeks later the client asks for a copy on a new drive. The lab copies the E01 segments, recomputes the hash on the copy, gets the same value and writes it on the transfer letter alongside the original. The client's own examiner can now confirm, without trusting anyone, that what arrived is what was seized.

Now the awkward case. Suppose the verification read of the source had returned a different value, say a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f60718293a4b5c6d7e8f90 (example value). The correct response is not to image again until two runs agree and quietly keep the matching pair. It is to find the cause, usually unreadable sectors that the tool zero-filled on one pass and read on another, or a drive that changed its own contents between reads, as SSDs can. Record both values, the tool's error log and the explanation. A report that shows a mismatch and explains it is stronger than one that hides it.