Write Blockers and Hardware Imaging Devices: How to Prevent Evidence Contamination

Every digital forensic investigation depends on one guarantee: that the evidence drive was not modified during acquisition. The mechanism that provides that guarantee is the write blocker. Use one correctly, and the integrity of every bit on the source media is provable in court. Skip it, misconfigure it, or use the wrong one for the interface type, and the OS silently modifies the drive before you have opened a single tool — altering hash values, updating timestamps, and potentially writing artifacts that did not exist before you touched the device.

This guide covers what write blockers do at the hardware and OS level, the exact differences between hardware and software approaches, how to select the right device for every storage interface type, the step-by-step function test that must be performed before connecting any evidence, HPA and DCO detection, standalone hardware imagers for field work, and the specific evidence contamination events that occur when write protection is missing or fails. Each section is written at the depth required to execute the procedure, not just describe it.

What Evidence Contamination Actually Looks Like

When a storage device is connected to a computer without write protection, the operating system does not wait for instructions. It immediately begins interacting with the device in ways that are invisible to the user but detectable by any competent forensic examiner hired by the opposing side.

What Windows Does Without a Write Blocker

Connecting an unprotected drive to a Windows workstation triggers a cascade of OS-initiated writes. Windows creates or updates the System Volume Information directory on any volume it can access. It updates Last Accessed timestamps on files it reads while populating the filesystem cache. It may write a dirty volume bit if the volume was not cleanly unmounted previously. If Windows Explorer auto-preview is enabled, thumbnail generation writes to hidden database files. Shell LNK files may be created or updated. If the drive is recognized as belonging to the same user profile, Windows may attempt to index it, creating or modifying search index artifacts.

Every one of these actions changes the data on the source drive. Every change alters the hash value. If the pre-connection hash of the drive and the post-connection hash differ — which they will — no mathematical proof of integrity can be established, and the chain of custody is damaged before the imaging tool has been opened.

What Linux Does Without a Write Blocker

Linux is not passive either. Many distributions, including commonly used forensic distributions when not properly configured, will auto-mount detected volumes. Auto-mounting triggers filesystem journal replay for dirty ext3 and ext4 volumes, which writes to the journal before the examiner is aware. The kernel may assign and write device labels. udev rules may execute scripts that interact with the device. Even when auto-mounting is disabled, connecting a drive and then running mount -o ro does not guarantee the underlying block device is write-protected: the ro mount option instructs the filesystem driver, but it does not prevent the kernel from writing at the block device level, as the Linux write-blocker research project explicitly documents.

The Hash Consequence

The forensic consequence of unprotected connection is not hypothetical. If the pre-acquisition hash of the evidence drive cannot be shown to match the hash of the forensic image, the examiner cannot prove that the image is an exact copy of what was on the drive before the investigation began. Defense counsel will ask: what changed between the time the drive was seized and the time it was imaged? Without write protection, there is no answer to that question that does not create reasonable doubt about the integrity of everything in the image.

How Write Blockers Work at the Hardware Level

A write blocker is fundamentally a command filter. It sits in the data path between the evidence drive and the forensic workstation and examines every command sent from the host to the drive. Read commands pass through. Write commands, format commands, and any other command that could modify data on the drive are intercepted and either discarded or returned to the host with an error response that indicates the operation failed.

The ATA and SCSI Command Layer

Most storage interfaces communicate using ATA (for SATA and IDE drives) or SCSI (for SAS, USB, and NVMe adapters that expose a SCSI command set) command sets. These command sets define what operations a host can request from a drive. Write operations correspond to specific command opcodes — for ATA these include WRITE SECTOR, WRITE DMA, WRITE MULTIPLE, and WRITE STREAM DMA, among others. A hardware write blocker contains firmware that recognizes these opcodes and blocks them before they are forwarded to the drive.

The write blocker allows through the full set of read commands (READ SECTOR, READ DMA, READ MULTIPLE, etc.) and status commands (IDENTIFY DEVICE, READ NATIVE MAX ADDRESS, etc.), which is what allows the forensic workstation to see the drive, query its geometry and serial number, and read every sector. What it never sends to the drive is any command that could change a bit.

Why Hardware Blocking Is More Robust Than Software

A hardware write blocker’s firmware runs on a dedicated controller chip inside the device. It is not affected by what software is running on the forensic workstation, what drivers are loaded, or what user permissions are in effect. If the forensic workstation crashes mid-acquisition and the OS generates a desperate flush-and-close sequence, the hardware write blocker intercepts those writes. If an investigator accidentally triggers a format dialog, the write blocker intercepts that. The OS has no direct path to the evidence drive — every command must go through the blocker.

Software write blockers, by contrast, are implemented as kernel-level drivers or OS registry settings. They are part of the OS they run on. If any other software on the workstation has a lower-level path to the drive — through a bypass driver, through the SG_IO interface on Linux, or through a direct device path that the software write blocker does not monitor — writes can reach the drive. Hardware write blockers eliminate this attack surface entirely.

Hardware vs. Software Write Blockers

Both approaches enforce the same fundamental requirement — no writes to the evidence drive during acquisition — but they differ significantly in how they achieve it, where they can be used, how they are tested, and how defensible they are in court.

Hardware Write Blockers

Hardware write blockers are standalone physical devices. They have their own power supply or draw power from the host USB connection, their own controller chip running dedicated firmware, and physical interface connectors on both the drive side and the host side. They operate identically regardless of the host OS. They are the preferred solution for all formal forensic investigations and for any case where the methodology will be examined in court.

The primary limitations of hardware write blockers are cost, the need to carry and maintain multiple devices to cover all interface types, and the need to update firmware periodically as new drive variants introduce new command sets or behaviors. A write blocker purchased in 2020 may not correctly handle features introduced in 2024 NVMe firmware variants unless it has been updated. Firmware update records should be maintained as part of the lab equipment log.

Software Write Blockers

Software write blockers are implemented at the OS level. On Windows, the most common approach is the registry-based USB write protection setting. On Linux, blockdev --setro marks a block device as read-only. Dedicated forensic distributions such as CAINE Linux include write blocking built into their boot configuration. Software write blockers are cost-effective or free, portable, and appropriate for cloud and virtual acquisitions where no physical hardware is involved.

Their critical limitation is reliability. They depend entirely on the OS they run on. As the Linux write-blocker research project documents, the Linux ro mount option does not prevent all kernel writes — certain filesystem journal operations can still reach the physical device. The SG_IO interface on Linux allows programs to send arbitrary SCSI commands to a device, bypassing software write protection entirely. On Windows, the registry setting applies only to USB storage devices and only if no other software has a lower-level path. In all cases, if the OS behaves unexpectedly or another program sends commands through an unmonitored interface, the protection fails silently.

Interface Types and Selecting the Right Device

The write blocker must be compatible with the physical interface of the evidence drive. Using the wrong write blocker — or using an adapter to connect a drive to a write blocker that does not natively support its interface — introduces compatibility risk. Adapters can introduce communication artifacts, reduce transfer speeds, and in some cases fail to correctly pass all commands, including the commands used to detect HPAs and DCOs. When a native-interface write blocker is available, use it. When an adapter is unavoidable, test the adapter and write blocker combination together on a sacrificial drive before using it on evidence.

Interface	Common Evidence Sources	Notes
SATA	Desktop and laptop HDDs and SSDs from roughly 2003 to present	Most common interface in current field work; all major write blockers support it natively
IDE / PATA	Older desktops and laptops, some consumer DVRs and embedded devices	40-pin and 44-pin variants; still encountered in legacy systems and corporate infrastructure
NVMe (M.2 or PCIe)	Modern laptops and desktops from roughly 2017 onward; increasingly common	Requires NVMe-specific write blocker; not all blockers support it; verify firmware version
USB (2.0 / 3.0 / 3.1)	Thumb drives, external HDDs and SSDs, memory card readers	USB write blockers intercept at the USB protocol level; must be connected before the drive
SD / microSD / CF	Cameras, drones, mobile devices, IoT devices	Requires card reader with write-block capability; validate on non-evidential card before use
SAS / SCSI	Enterprise server drives, older workstations	Less common in field work; Tableau TX1 and Logicube Falcon support SAS natively
eMMC	Tablets, phones, embedded systems, older Chromebooks	Requires chip-off or specialized hardware; conventional write blockers do not apply

Current Hardware Write Blockers: Capabilities and Specifications

The following devices represent the primary hardware write blockers in use as of 2025–2026 in professional and law enforcement forensic practice. All have NIST CFTT test results available publicly.

OpenText Tableau TX1 Forensic Imager / Bridge

The TX1 is the current flagship from OpenText (formerly Guidance Software / Tableau). It combines write-blocking and standalone imaging in a single device, making it one of the most versatile units in the field. It supports SATA, SAS, NVMe via M.2, USB 3.1, and IDE through adapters. The unit features an LCD touchscreen for configuration and status, HPA/DCO/AMA detection and removal, SMART data display, and simultaneous multi-drive imaging when used with a Tableau hub. It produces E01, raw, and AFF4 image formats and computes MD5 and SHA-256 hashes concurrently. The NIST CFTT test report for the Tableau Forensic Universal Bridge is publicly available at the NIST CFTT website. For field acquisitions, the TX1 can operate as a fully standalone imager without a separate workstation.

WiebeTech Forensic UltraDock FUDv6

The FUDv6 is a drive dock-style write blocker that supports SATA and IDE natively, with USB-C host connection. Its key design feature is that write-blocking mode is the default state every time the unit powers on — there is no configuration step required to engage write protection. This eliminates the risk of starting an acquisition in read/write mode because the operator forgot to set the mode. The FUDv6 includes an LCD menu for HPA/DCO/AMA detection and removal, SMART data access, and drive identification. The CRU NIST CFTT results for WiebeTech devices are current through 2025 (WiebeTech USB v3.1 was tested and published in May 2025).

WiebeTech NVMe WriteBlocker

A dedicated write blocker specifically for M.2 NVMe SSDs. The device presents an M.2 slot on the drive side and connects to the forensic workstation via USB-C or USB-A. LED indicators confirm write-block status. The LCD menu displays SMART data including hours used, power cycle count, and drive health, which can be relevant to establishing drive provenance. Compatible with any computer with a USB-C or USB-A port. This is the appropriate choice when a SATA write blocker with NVMe adapter would not provide full NVMe command coverage.

WiebeTech USB 3.1 WriteBlocker

A handheld USB write blocker for USB drives, external drives, and other USB storage devices. It connects inline between the USB drive and the forensic workstation’s USB port. Simple operation: plug the write blocker into the workstation, plug the evidence USB device into the write blocker. NIST CFTT tested. The May 2025 test results for WiebeTech USB v3.1 are publicly available from DHS/CISA and NIST, confirming that no sectors on the test drive were modified during any test operation.

OpenText Tableau TD4 Forensic Duplicator

A standalone duplicator capable of simultaneous 1-to-4 drive duplication or imaging without a host computer. Supports SATA, SAS, IDE, USB, and NVMe with adapters. Used primarily in multi-device seizure scenarios where multiple drives must be imaged simultaneously to reduce total acquisition time. Produces forensic images to attached destination drives or to network shares. Includes write-blocking on all source ports independently of the destination configuration.

Atola Insight Forensic

A professional forensic imager and write blocker with emphasis on difficult and damaged drives. Supports SATA, NVMe, USB, IDE, and SAS. Key features include automatic identification and handling of read errors, multi-pass imaging with escalating retry strategies for bad sectors, built-in power supply stabilization for failing drives, and a detailed acquisition log that records every read attempt and result. Particularly well suited for drives that show marginal behavior or read instability during standard acquisition.

Function Testing Before Every Evidence Connection

A write blocker that is not tested before use on evidence is not a documented write blocker — it is an assumed write blocker. The function test is what transforms the hardware into part of the documented forensic process. It must be performed before every acquisition involving a different evidence drive, and its results must be recorded. A function test performed last week does not validate the write blocker for today’s evidence.

What You Need for the Test

A sacrificial test drive that is not evidence. The drive should be of the same interface type as the evidence drive you intend to connect. It should have a known, documented state — ideally wiped and hashed so you have a baseline. The drive is not evidence and will not go into the case file, but it should be consistent enough to produce a clean test.

The Test Procedure

Step 1: Connect the sacrificial drive to the write blocker and connect the write blocker to the forensic workstation. Power on in the correct sequence: power the write blocker first, then connect to the workstation (for USB-connected blockers the workstation detects the write blocker before the drive is inserted). Confirm the LED indicators show write-block mode active. On LCD-equipped devices, confirm the status display shows read-only or write-protected state.

Step 2: Compute the hash of the sacrificial drive before testing. On Linux:

# Hash the test drive before the function test
sha256sum /dev/sdb | tee test_drive_prehash.txt
md5sum /dev/sdb | tee -a test_drive_prehash.txt

Step 3: Attempt to create a file on the drive from the forensic workstation. On Linux, this can be done by attempting to mount and write:

# Attempt to mount and write (should fail)
sudo mount /dev/sdb1 /mnt/test 2>&1
# If mount succeeds, attempt to create a file
sudo touch /mnt/test/write_test_file.txt 2>&1
# Expected: Permission denied or read-only filesystem error

On Windows, attempt to copy a file to the drive through File Explorer or from the command prompt. The operation must fail with a “The disk is write-protected” error or equivalent.

Step 4: Attempt to delete an existing file from the drive. This must also fail.

Step 5: Attempt to run a format operation against the drive or a partition on it. This must fail.

Step 6: Disconnect the drive and recompute its hash:

# Hash the test drive after the function test
sha256sum /dev/sdb | tee test_drive_posthash.txt

# Compare: values must be identical
diff test_drive_prehash.txt test_drive_posthash.txt
# No output = hashes match = write blocker passed

A passing function test requires that all three write operations failed and that the post-test hash of the drive exactly matches the pre-test hash. If any write operation succeeded, or if the hashes differ, the write blocker has failed the test. Do not use it on evidence. Remove it from service, investigate the cause, and either repair or replace the device before any further forensic use.

Documenting the Function Test

The function test record must be created contemporaneously and must include: the write blocker make, model, serial number, and firmware version; the test drive make, model, and serial number; the pre-test hash value and algorithm; the specific write operations attempted and their results; the post-test hash value; the comparison result; the date and time of the test; and the name and credential of the examiner who performed it. This record is retained in the case file and is the document that allows you to answer in court: “How do you know the write blocker was working when you connected the evidence drive?”

Setup and Connection Procedure

The order of operations when connecting evidence media to a write blocker matters. Connecting in the wrong sequence can allow the OS to detect the drive before the write blocker is in write-protect mode, creating a window during which writes could occur.

For Hardware Write Blockers

The correct sequence is: power on the write blocker first (confirm it initializes and displays write-protect mode), then connect the evidence drive to the write blocker’s evidence side, then connect the write blocker to the forensic workstation. For USB-connected write blockers, plug the write blocker into the workstation’s USB port before inserting the evidence media into the write blocker’s evidence port. This ensures the OS recognizes the write blocker as the device on the USB bus before it detects the drive through it.

After connection, verify:

• The write-protect LED is illuminated (green or amber depending on the device; consult the manual for the specific indicator behavior)
• The forensic workstation detects the drive correctly and reports its capacity, make, model, and serial number
• The reported capacity matches the expected capacity of the evidence drive
• No automatic mount or auto-play events occur (disable autorun in Windows before connecting any evidence; configure udev rules in Linux to suppress automounting)

If the reported capacity is lower than expected, the drive may have an HPA or DCO active that is hiding sectors. Do not begin imaging yet — investigate the hidden area configuration as described in the next section.

For the WiebeTech ComboDock and Similar Dual-Mode Devices

The WiebeTech ComboDock powers on in write-block mode automatically, but it also has a read/write mode accessible through the device menu. The transition from write-block to read/write mode is deliberately difficult — it cannot be done accidentally — but the examiner must confirm mode status before each acquisition. The LCD display shows the current mode. Verify it every time. Some versions of the ComboDock require pressing and holding a button combination to enter read/write mode, making accidental mode changes essentially impossible, but confirmation is still required documentation.

HPA, DCO, and AMA: Hidden Data Regions

Three ATA features allow hard drives to hide data from the operating system and from standard forensic tools. If these regions are not detected and addressed before imaging, the forensic image will not be complete — and the examiner will not know what was missed.

Host Protected Area (HPA)

The HPA is a section at the end of a drive that is hidden from the OS by the drive’s firmware. The drive reports a reduced sector count to the OS, making the OS believe the drive is smaller than it actually is. The hidden sectors are accessible through ATA commands that the OS does not normally issue. HPAs are legitimately used by manufacturers to store firmware recovery data or diagnostics, but they can also be used by sophisticated actors to hide evidence in a region that most analysis tools will never see.

The ATA command READ NATIVE MAX ADDRESS (or READ NATIVE MAX ADDRESS EXT for 48-bit LBA drives) returns the true maximum sector count reported by the drive’s native capacity, which will be larger than the sector count reported by IDENTIFY DEVICE if an HPA is active. The difference between the two values is the size of the HPA.

Most hardware write blockers with LCD interfaces can detect and temporarily remove the HPA by issuing the SET MAX ADDRESS command to restore the full native capacity for the duration of the acquisition. This operation is documented in the acquisition report. After the acquisition session ends and the drive is powered off, the HPA is automatically reinstated by the drive firmware.

Device Configuration Overlay (DCO)

The DCO is a firmware-level feature that allows the manufacturer or a system integrator to permanently configure the capabilities the drive reports to the host. Like the HPA, a DCO can hide sectors by making the drive report a lower capacity than it physically has. DCO modification requires ATA commands at a lower level than HPA manipulation, and removing it is a permanent or semi-permanent change depending on the drive. The DEVICE CONFIGURATION IDENTIFY command returns the drive’s true capability set, which can be compared against what the drive reports through normal IDENTIFY DEVICE to detect a DCO.

Hardware write blockers such as the WiebeTech FUDv6, the OpenText TX1, and Atola Insight can detect both HPA and DCO and provide options for handling them before acquisition. FTK Imager and EnCase also have built-in HPA/DCO detection features when used in conjunction with a compatible write blocker.

Accessible Max Address (AMA)

AMA is a newer feature on some drives, particularly those using Host Managed Drives and Zoned Storage specifications, that defines an access boundary similar to HPA but at the firmware controller level. The WiebeTech FUDv6 and ComboDock documentation explicitly references AMA detection alongside HPA and DCO as part of the device’s pre-acquisition workflow. AMA is less common than HPA in current evidence scenarios but becomes relevant when acquiring drives from newer NAS devices and enterprise storage systems.

What to Record About Hidden Regions

The acquisition report must document: whether HPA, DCO, or AMA detection was performed; the tool used to perform the detection; whether any hidden regions were found; the size of any hidden region detected; and whether the hidden region was temporarily removed before imaging (and the command used to do so). If hidden regions were found and removed, the image must cover the full native capacity including those regions. If they were not removed, the image must note the sectors that were not accessible and the reason.

Software Write Blocking: Platforms, Commands, and Limitations

Software write blocking is appropriate in specific circumstances where hardware blocking is not feasible: virtual machine acquisitions, cloud-based forensic workstations, remote triage scenarios, or field situations where the appropriate hardware write blocker was not available for the specific interface encountered. In all cases, the decision to use software rather than hardware write blocking must be documented with the reason, and the limitations of the software approach must be disclosed.

Windows: Registry-Based USB Write Protection

Windows includes a built-in USB write protection mechanism controlled through the registry. When enabled, it prevents the Windows USB storage driver from sending write commands to USB storage devices:

; Enable USB write protection via registry
; Run regedit.exe as Administrator

; Navigate to or create:
; HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies

; Create DWORD value:
; Name: WriteProtect
; Value: 1

; Disable:
; Set WriteProtect to 0 or delete the key

This setting applies only to USB storage devices. It does not protect SATA, NVMe, or other interface types. It also does not apply to processes that access storage devices through paths that bypass the USB storage driver. Restart the workstation after changing this registry value, and connect the evidence drive only after the restart has completed and the setting is confirmed active. Disable Windows autorun and auto-play before connecting any evidence device.

Linux: blockdev and hdparm

On Linux, the blockdev command marks a block device as read-only at the kernel’s block layer:

# Mark the entire device as read-only (must include the parent device, not just a partition)
sudo blockdev --setro /dev/sdb

# Verify the flag is set (must return 1)
sudo blockdev --getro /dev/sdb

# Alternative using hdparm
sudo hdparm -r1 /dev/sdb

# Confirm with lsblk
lsblk -o NAME,RO /dev/sdb

As the Linux write-blocker GitHub project documents, this protection is not absolute. The ro flag instructs filesystem drivers to refuse writes, but filesystem drivers that lack proper checks may still issue write commands that reach the physical device. The SG_IO interface allows programs to send arbitrary SCSI commands to a device, completely bypassing the ro flag. If you are using software write blocking on Linux, disable automounting systemwide before connecting evidence, and do not run any utility that uses the SG_IO interface (including hdparm in passthrough mode and tools from sg3_utils) against the evidence device while it is connected.

The correct procedure for mounting a filesystem read-only after setting blockdev --setro is to use the ro,noload mount options for ext3/ext4 filesystems, which prevents journal replay:

# Mount ext3/ext4 read-only without journal replay
sudo mount -o ro,noload /dev/sdb1 /mnt/evidence

# For NTFS (requires ntfs-3g)
sudo mount -o ro /dev/sdb1 /mnt/evidence

# Verify mount is read-only
mount | grep /mnt/evidence

CAINE Linux

CAINE (Computer Aided INvestigative Environment) is a Linux distribution designed for forensic work. Its kernel is patched to mark all block devices as read-only by default at boot, before any user interaction. This makes it a significantly more robust software write-blocking solution than manually configuring blockdev on a standard distribution, because the write protection is applied at the kernel level before any device-mounting scripts can run. CAINE is a legitimate choice for situations where a hardware write blocker is not available, provided the CAINE version used is documented and the examiner can explain the protection mechanism under cross-examination.

Standalone Hardware Imagers and Forensic Duplicators

Standalone hardware imagers combine write-blocking, imaging, and hashing in a single portable device that operates without a separate forensic workstation. They are the appropriate tool for field acquisitions at seizure locations, for multi-device seizures where speed matters, and for situations where minimizing the number of systems in the custody record is desirable.

OpenText Tableau TD4 Forensic Duplicator

The TD4 supports simultaneous 1-to-4 drive duplication with write-blocking on all source ports independently of the destination ports. This means the source drive is protected regardless of what is happening on the destination side. The TD4 supports SATA, SAS, USB, and IDE, with NVMe via adapter. It produces raw, E01, and AFF4 format images and computes MD5 and SHA-256 hashes concurrently. In duplication mode, it creates direct drive-to-drive forensic clones with hash verification. Field use is supported by a compact form factor and a front-panel LCD interface that does not require a host computer.

WiebeTech Ditto Forensic FieldStation

The Ditto is a handheld standalone imager designed for field use. It supports local, remote, and networked imaging without requiring a laptop or workstation. It can image to an attached drive, to a network share via Ethernet, or to a mounted forensic image file. The Ditto supports SATA, IDE, and USB natively. It includes write-blocking on the source port and produces raw and E01 images with MD5 and SHA-256 verification. Battery-powered operation is supported for field locations without power access.

Logicube Falcon Neo

The Falcon Neo is a high-speed standalone imager that supports simultaneous imaging from multiple source drives to multiple destinations. It supports SATA, SAS, NVMe, USB, and IDE. Acquisition speeds are among the highest in the field, with NVMe-to-NVMe transfers approaching the rated speeds of the drives themselves. The Falcon Neo includes write-blocking on all source connections, LCD touchscreen control, and network imaging capability. It is widely used in law enforcement agencies that conduct large-scale seizures involving multiple drives.

When to Use a Standalone Imager vs. a Write Blocker with a Workstation

A standalone imager is appropriate when a workstation is not available or not desirable at the acquisition location, when simultaneous imaging of multiple drives reduces total acquisition time significantly, or when the simplified custody chain (one device performing both write-blocking and imaging) is preferable. A write blocker paired with a forensic workstation is appropriate when the workstation provides capabilities the standalone imager does not — more flexible image format options, integration with case management software, or a larger display for monitoring complex acquisitions. Both approaches produce legally sound evidence when used correctly.

NIST CFTT Validation and Why It Matters in Court

The NIST Computer Forensics Tool Testing (CFTT) program tests forensic hardware and software against published specifications and makes the results publicly available. For write blockers, the CFTT tests verify that: no sectors on the evidence drive are modified during acquisition; the device correctly passes all read commands; and the device correctly reports drive capacity without HPA or DCO interference.

NIST CFTT test results are version-specific. The report for a Tableau Forensic Universal Bridge tested in 2023 applies to that specific firmware version of that specific hardware. Updated firmware or a new hardware version requires new testing. NIST lists the most recent test results on its CFTT hardware write block page, which was updated as recently as December 2025 with results for Kanguru devices, and May 2025 for the WiebeTech USB v3.1.

When testifying about an acquisition, being able to say “I used [device name], firmware version [X], and the NIST CFTT test report number [Y] confirms that this device and firmware version produced no writes to the evidence drive during testing” is substantially more defensible than saying you used a well-known brand. The CFTT report is a peer-reviewed, government-published technical record. It shifts the burden of proof on the write-blocker question squarely onto any expert who challenges it.

If you use a device that does not have a current NIST CFTT test report, or whose current firmware version has not been tested, your lab must have conducted its own validation testing on that specific firmware version and documented the results. Lab validation testing should follow the same methodology as NIST testing: attempt writes through multiple pathways, verify no sectors were modified by comparing pre- and post-hash values, and document the complete test procedure and results.

Documenting Write-Blocker Use for Chain of Custody

Write-blocker use documentation is part of the acquisition report and part of the chain of custody record. The documentation must allow an independent examiner, a court, or opposing counsel to understand exactly what hardware was used, that it was functioning correctly, and what the examiner did with it.

The write-blocker section of the acquisition report must include:

• Type: hardware or software
• Make and model (for hardware: the exact product name; for software: the name of the tool or OS mechanism and its version)
• Serial number (hardware only)
• Firmware version (hardware) or software version (software)
• NIST CFTT report number or lab validation report reference for this firmware/software version
• Function test result: pass or fail
• Function test date and time
• Function test performed by (name and credential)
• Interface type used to connect the evidence drive
• Mode confirmed active before evidence connection (write-protect LED status, LCD confirmation, or registry setting)
• Any anomalies observed during the acquisition session

When Write Blocking Is Not Possible

There are scenarios in which a hardware write blocker cannot be used: the drive interface is not supported by any available blocker, the drive is installed in a system that cannot be removed, or the acquisition must occur live on a running system. In each case the situation must be documented, the decision must be justified, and the methodology used in place of hardware write blocking must be disclosed.

Drive cannot be removed (laptop NVMe soldered to motherboard): If the NVMe drive is soldered or otherwise not removable without damaging the system, a live acquisition using a trusted tool (FTK Imager or Magnet ACQUIRE launched from a write-protected USB drive) is the alternative. The acquisition report documents that the drive was not removable, that live acquisition was performed, and that a write-protected boot medium was used for the acquisition tool. The limitation — that writes to other system components occurred during the live session — is explicitly noted.

Unsupported interface: If the interface is not supported by any available write blocker (an uncommon proprietary flash interface, for example), document the interface type, explain why no compatible write blocker was available, and describe the alternative protective measures taken. For some embedded systems, this means acquiring through the manufacturer’s diagnostic interface with documented commands and verified output hashes.

Live system acquisition: When a running system must be imaged without shutdown — because volatile memory is critical, because shutting down would destroy an encryption key, or because a critical server cannot be taken offline — write protection of the system drive is not possible. The acquisition report must explicitly identify this as a live acquisition, note that the source drive was not write-protected, and describe all steps taken to minimize the acquisition tool’s footprint on the running system. Hash verification is still performed on the acquired image and compared against the image hash from a second acquisition if possible.

In all three scenarios, the absence of write blocking does not automatically make the evidence inadmissible. It creates a documented limitation that must be explained in the acquisition report, addressed in examination testimony, and potentially reinforced by additional corroborating evidence. Undisclosed absence of write blocking is the problem — not the absence itself.

Sources and References

• NIST CFTT — Hardware Write Block Test Results (current through December 2025): nist.gov
• DHS / CISA — Test Results: WiebeTech USB v3.1 Hardware Write Block Device (May 2025): dhs.gov
• CRU / WiebeTech — Write Blockers Product Page: cru-inc.com
• OpenText — Tableau Forensic Equipment: opentext.com
• msuhanov — Linux Write-Blocker: Kernel Patch and Research: github.com/msuhanov
• Hawk Eye Forensic — Best Practices for Using Write Blockers in Forensic Imaging (2025): hawkeyeforensic.com
• Cyber Forensics Academy — How to Build Your Own Digital Forensics Toolkit (2025): cyberforensicacademy.com
• ScienceDirect — Hardware Write Blocker Overview: sciencedirect.com
• Digital Intelligence — Software for Forensic Imaging: digitalintelligence.com
• ForensicsWiki — Write Blockers: forensics.wiki