A write blocker is hardware or software that sits between an examiner's machine and a piece of evidence, permitting reads and refusing every write. It exists because connecting a drive to a running computer causes that computer to modify it automatically, which would alter the evidence before anyone deliberately did anything to it.
The problem it solves
Operating systems are not passive when you attach storage. Windows will index the volume, may create hidden system folders on it, and updates access metadata as it inspects what is there. macOS writes its own metadata directories. None of this requires a user to open a single file — plugging the drive in is enough.
Each of those writes changes the evidence. Most are trivial in substance and none are trivial in effect, because the examiner can no longer say the drive is in the state it was seized in, and the hash taken afterwards will not match one taken before.
Hardware and software blocking
A hardware write blocker is a physical bridge the drive connects through. It intercepts the command set at the interface level and returns an error for anything that would modify the device. It works regardless of the examiner's operating system, and it is what is normally used when the evidence is a physical drive.
A software write blocker sets the operating system to mount devices read-only. It is cheaper and adequate in many situations, but it protects only as well as the configuration holds — a wrong setting, an OS update that resets it, or a second tool that bypasses the mount layer can each defeat it silently.
The practical difference is failure mode. Hardware blocking fails loudly, by refusing to work. Software blocking can fail quietly, and quiet failure is the kind you discover in a deposition.
Where it does not apply
Write blocking assumes a storage device you can disconnect and attach. A growing share of forensic work involves neither:
- Live acquisition. A running server that cannot be shut down, or an encrypted volume that would become unreadable if powered off, must be captured while running. The acquisition itself changes system state, and the correct response is not a write blocker but rigorous documentation of exactly what was run and when.
- Mobile devices. Phones are acquired through the vendor's own protocols; there is no bare interface to interpose on. Protection comes from the extraction method, not from a bridge.
- Cloud data. There is no device. Integrity comes from documented API collection and hashing the collected output.
Why counsel should care about a piece of hardware
Because its absence is a straightforward question on cross-examination, and there is no good answer that begins "we didn't." "Was the source device write-protected during acquisition?" is asked precisely because the answer is binary and verifiable against the acquisition log.
It is also the clearest available marker of whether a collection was forensic at all. When a client says IT already made a copy, the useful follow-up is not whether they were careful — it is what they connected the drive to, and whether anything stood between the two.
From our work
Dealing with write blocker in a live matter?
Our examiners and testifying experts work these questions for a living. Tell us what you're facing.
Reviewed by Law & Forensics. See our editorial standards.