Why use a write blocker when hashing an evidence disk would reveal any change anyway?

## Two different kinds of control A **write blocker** is a *preventive* control: it stops the change happening. A **hash** is a *detective* control: it tells you afterwards that something changed. Interviewers ask this question because a candidate who thinks the detective control subsumes the preventive one has not thought about what a baseline is. ## Why the hash cannot cover the gap Detection requires two digests to compare. On a suspect drive pulled from an ageing file server, there is no pre-existing trusted digest — nobody hashed that disk last Tuesday. The acquisition hash *is* the first one. Whatever state the drive is in at the instant that digest is computed becomes, by definition, the reference state. So the sequence matters absolutely: - Blocker first, then hash: the reference state is the drive as the intruder left it. - Attach unprotected, then hash: the reference state is the drive as *your operating system* left it, and the hash will verify happily forever afterwards. You have produced a mathematically perfect record of contaminated evidence, and no later comparison can tell you which sectors you disturbed and which the intruder did. ## Attaching a disk is not passive The naive assumption is that reading is harmless and only deliberate writes matter. A general-purpose operating system does not behave that way when a volume is presented to it. Depending on platform and configuration it may replay a filesystem journal to bring the volume to a consistent state, update volume-level metadata or access times, index content in the background, create automatic snapshots or restore points, or write housekeeping structures when it assigns a drive letter and mounts. None of these require the examiner to touch a file. Several of them modify exactly the metadata a case turns on: timestamps. ## What the blocker actually does Hardware blockers sit inline on the interface between the examiner's machine and the drive: read commands pass through, write commands are dropped or answered with an error, so the host's optimism about mounting never reaches the platters. Software blocking achieves a similar result by policy on the examining host, refusing writes to the attached device. The principle is what matters more than the mechanism — the source device must be physically or logically incapable of accepting a write for the whole time it is connected, including the later re-read when you verify. Two properties follow: 1. The first digest describes an untouched source. 2. Verification can safely re-read the source, because reading through the blocker cannot itself alter what you are re-reading. ## What the blocker does not do - It does not protect your image; the image is a file on your evidence store and needs its own handling. - It does not protect your workstation from anything hostile stored on the drive. That is a separate concern and a common confusion. - It does not guarantee a matching verification hash. A drive with failing sectors can return different bits on two consecutive reads with no write involved at all — the physical medium changed nothing, but the data returned differed. - It cannot help with evidence that was never a block device you could interpose on, such as records held by a third-party service. ## If you already contaminated the source This happens, usually under time pressure. The wrong answers are to hide it or to declare the evidence worthless. The right sequence is: stop, record precisely what was connected, for how long, and with what mounting behaviour; acquire properly from that point; then scope every claim to what could not plausibly have been affected. Content-level findings — a binary's own hash, the bytes of a registered service entry — are robust to a mount that touched volume metadata. Claims that turn on last-access times on the very files you touched are not, and should be withdrawn rather than defended. A contamination you documented at the time is a manageable weakness; the same contamination discovered by the other side is a credibility problem. ## The line to remember The write blocker protects the **source**. The hash proves the **copy** matches it. They are not substitutes, and the order in which they are applied is the whole point.