Forensic write blockers and disk imagers: a buyer's guide

Digital evidence is only useful if you can show it was not changed by the act of collecting it. A write blocker sits between the evidence drive and the examiner's computer and prevents any command that could modify the drive from reaching it. A forensic imager goes further and produces a verified copy without a computer at all.

This guide covers how these devices work, how to choose them, and, most importantly, how to validate the kit you rely on.

Why the operating system is the problem

Connect a drive to a normal workstation and the operating system will happily write to it: mounting updates journal and superblock fields, Windows may write volume metadata or offer to "repair" the file system, indexing services touch files, and some tools update access times. None of this is malicious; all of it can alter evidence and complicate its admissibility.

A write blocker intercepts the storage protocol (ATA, SCSI, NVMe or USB mass storage) and allows only read and identification commands through, while reporting success or failure in a way the host can live with.

Hardware write blockers

Hardware blockers are protocol bridges: evidence drive on one side, examiner workstation (usually over USB 3) on the other. They are sold by specialist forensic vendors and come in two broad types:

What to check:

• Supported interfaces for the media you actually see: SATA and NVMe SSDs dominate; M.2 SATA and M.2 NVMe are keyed differently; USB flash and SD cards need their own blockers or readers.
• Throughput. A USB 3.x host link and a bridge able to sustain it make the difference between hours and days on large drives.
• Detection and display of HPA and DCO hidden areas, and the ability to unlock or report them.
• Read-write mode switch. Some units can be switched to read-write for wiping destination drives. Make sure the mode is clearly visible and locked by default.
• Firmware update policy and release notes, since new drive types need firmware support.
• Independent test reports. The NIST Computer Forensics Tool Testing (CFTT) program publishes test reports for hardware write blockers and imaging tools, and the U.S. Department of Homeland Security has funded and published many of them. A report for your exact model and firmware is valuable evidence of reliability.

Software write blocking

Software write blocking is sometimes the only option (servers you cannot open, live systems, some cloud or virtual disks). Common approaches:

• Linux: set the block device read-only before anything touches it and never mount it read-write.

# Prevent automounting first (desktop environments), then:
sudo blockdev --setro /dev/sdb
sudo blockdev --getro /dev/sdb     # 1 = read-only

Note that --setro applies to the block device node and should be set on the whole disk and its partitions; some forensic Linux distributions ship udev rules that set new devices read-only automatically.

• Windows: a registry policy (StorageDevicePolicies\WriteProtect) can block writes to USB mass-storage devices. It only covers USB storage, requires validation on the exact Windows build, and does not protect internal SATA or NVMe disks.

Software methods depend on the host OS behaving correctly, so they need their own documented validation. Use them deliberately, not by default.

Standalone forensic imagers

A standalone imager copies a source drive to one or more destinations (drives or network shares) without a PC, computing hashes on the fly. Benefits:

• Speed: several drives can be imaged in parallel at full interface speed.
• Repeatability: the device logs source identification, hashes, errors and timestamps.
• Field use: no laptop, no OS, less that can go wrong.

Look for simultaneous image-to-multiple-destinations, E01 and raw output, SHA-256 and MD5 hashing, bad-sector handling with logging, HPA/DCO detection, network output, and audit logs you can export.

Imaging with open-source tools

Behind a hardware write blocker, open-source tools produce defensible images:

# Identify the device and record model/serial
sudo hdparm -I /dev/sdb | grep -E "Model|Serial"
lsblk -o NAME,SIZE,MODEL,SERIAL /dev/sdb

# Check for a Host Protected Area (native max vs current max sectors)
sudo hdparm -N /dev/sdb

# Raw image with built-in hashing and logging
sudo dc3dd if=/dev/sdb of=/cases/2026-041/disk01.dd hash=sha256 log=/cases/2026-041/disk01.log

# Or an E01 image with case metadata (interactive prompts for case details)
sudo ewfacquire /dev/sdb

Guymager provides a graphical front end with E01, AFF and raw output and parallel hashing, and is included in several forensic Linux distributions.

After acquisition, verify the image independently:

sha256sum /cases/2026-041/disk01.dd
ewfverify /cases/2026-041/disk01.E01

SSD, NVMe and modern media pitfalls

• TRIM and garbage collection. Once an SSD is powered, its controller may erase blocks that the OS previously marked as unused. A write blocker cannot stop this. Image as soon as possible and note that re-acquisition may produce a different hash.
• Self-encrypting drives and OPAL. A locked SED produces only ciphertext or refuses reads. Plan for credentials, recovery keys or live acquisition.
• Soldered storage. Many laptops and all phones have storage on the mainboard; acquisition moves to logical or live methods, or to specialised techniques.
• BitLocker, FileVault and LUKS. Capture recovery keys and memory where legally and technically possible before powering down a running system.
• USB bridge chips in external drives may hide the real drive geometry or apply their own encryption; consider removing the drive from its enclosure.

Faraday protection for mobile devices

Phones and tablets can be remotely wiped or keep syncing. Faraday bags or boxes isolate them from cellular, Wi-Fi and Bluetooth. Check attenuation claims across the frequency bands you care about, test each bag regularly with a known phone, and remember that a phone searching for signal drains its battery quickly, so bring a shielded power bank or a Faraday box with filtered power.

Validating your own kit

Vendor claims and third-party reports are a start. Your lab should still validate every write blocker and imager, and re-validate after firmware updates:

1. Prepare a test drive with known content, then compute and record its full-disk SHA-256.
2. Connect it through the write blocker; mount it, run a file manager, and attempt to create, modify and delete files and to write to raw sectors.
3. Disconnect, reconnect directly to a trusted reader and hash the full drive again.
4. The hashes must match. Record the device serial, firmware version, test date, tester and result.
5. Repeat for each interface (SATA, NVMe, USB) the device supports.

Keep these records with your quality documentation; they answer the question "how do you know your write blocker works?" before anyone asks it.

Selection checklist

• Interfaces that match the media you encounter, including NVMe.
• Public NIST CFTT or equivalent test reports for the model.
• Clear read-only default, visible mode indication and logged operations.
• Fast host link (USB 3.x or better) and parallel imaging if volume is high.
• HPA/DCO detection and bad-sector reporting.
• Firmware updates with release notes, and a vendor that supports the product for years.
• Budget for adapters, spare cables, destination drives and Faraday equipment, which are often forgotten.