Forensic images and write blocking

This lesson covers how a drive is actually imaged: the image formats in use, the write blockers that keep the source unchanged, how tools are tested, a step-by-step workflow and the most common problems. Storing images safely is covered in Module 5.

Image formats

A forensic image is a file, or set of files, holding a bit-stream copy of a source.

Raw (dd)

A raw image, often called a dd image after the Unix dd command commonly used to create it, contains the exact bytes of the source and nothing else. Almost every tool can read it, and it can be split into numbered segments (.001, .002). With no header, case details and hash values are kept separately, in logs and notes.

Expert Witness Format (E01)

The Expert Witness Format (EWF), known by its file extension E01, came from a commercial forensic tool and is now supported by most forensic software. An E01 image stores the source data, optionally compressed, together with case metadata such as the case number, examiner and description, checksums for each block of data to locate corruption, and a hash of the acquired data. Large images are split into segments named .E01, .E02 and so on.

The hash stored in an E01 is the hash of the source data, not of the .E01 file. Hashing the .E01 file itself with a general utility gives a different value, which is expected and is not a sign of tampering. Tools verify an E01 by reading the data out of the container and comparing its hash with the stored value.

AFF4

AFF4 (Advanced Forensic Format 4) is an open format designed for very large images, which can hold several data streams, such as a disk image and a memory image, together with their metadata in one container.

Write blockers

A write blocker lets an examiner read a storage device while preventing any writes to it. Without one, simply connecting a drive to a computer can change it: operating systems may mount its volumes, replay file system journals or create system files on it.

• Hardware write blockers sit physically between the source drive and the forensic workstation. They pass read commands to the drive and stop write commands, independently of the workstation's operating system. Models exist for common interfaces such as SATA, SAS, NVMe and USB.
• Software write blockers work inside the operating system, as a driver or setting that refuses writes to selected devices, or as a forensic boot environment that never mounts drives for writing. They cost little but depend on the operating system and its configuration behaving exactly as expected.

A write blocker controls the commands that come from the computer. It does not control what happens inside the drive: an SSD's controller can keep erasing blocks marked by TRIM (Module 1) while it has power, and drives update internal counters such as power-on hours. A write blocker also protects only the device connected through it, and a plain USB-to-SATA adapter is not a write blocker, however similar it looks.

Testing tools and validating your setup

Examiners must be able to show that their write blocker and imaging tool behave as claimed. Two kinds of evidence support this.

• Independent testing: NIST's Computer Forensics Tool Testing (CFTT) program publishes specifications for categories of tools, including hardware and software write blockers and disk imaging, and test reports for specific products and versions, including any anomalies found.
• Your own validation: ISO/IEC 27041 expects methods and tools to be validated for their intended use. A simple check: hash a test drive, connect it through the blocker, try to mount it and write to it, then hash it again; the values must match. Repeat after firmware or software updates and keep the records. SWGDE also publishes guidance on validation testing.

A CFTT report on a different firmware version, or a validation done years ago on other hardware, is weaker support than a recent check of the exact setup used.

The imaging workflow

1. Document the source. Photograph the drive and its label; record make, model, serial number, capacity, interface and the device it came from.
2. Prepare the destination. Use new or forensically wiped media with enough space, checked before use, so that old data cannot be mistaken for evidence. Record its identity too.
3. Connect through the write blocker. Source to blocker, blocker to workstation, following the blocker's instructions for powering the drive.
4. Verify blocking. Confirm that the blocker shows write protection and that the workstation sees the drive as read-only; check that the reported capacity is what you expect.
5. Image. Choose the format, segment size, compression and hash algorithms, enter the case details and image the whole device.
6. Hash and verify. Record the acquisition hash, then verify the image and compare the values.
7. Record. Keep the tool's log; note the tool and version, start and end times, errors and final hash values; update the chain of custody (Module 5).

Tools as examples

The method matters more than the product. Free examples include FTK Imager (a free Windows tool from a commercial vendor), Guymager (an open-source Linux tool with a graphical interface), ewfacquire (part of the open-source libewf library, which creates E01 images) and dc3dd (a version of dd adapted for forensic use, which hashes while it copies and logs errors). Record the tool's name and version.

Common problems

• Bad sectors. Imaging tools retry damaged areas, then usually fill unreadable sectors with zeros and log their location. A later hash of the source may differ. Report how many sectors could not be read.
• Hidden areas. The Host Protected Area (HPA) and Device Configuration Overlay (DCO) are features of ATA drives that can make part of the disk invisible to the operating system. Compare the drive's native capacity with the reported capacity; accessing a hidden area may require changing the drive's configuration, which must be documented.
• Encrypted drives. A physical image of an encrypted drive is valid but unreadable without the password or recovery key. Look for keys before shutdown (Lesson 4.1), record any recovery keys provided under authorization, and consider a logical image of the unlocked volume on a running system. Self-encrypting drives encrypt in hardware; when a password is set, they lock themselves on power loss and give no readable user data without it.
• Storage that cannot be removed. In many current laptops the storage is soldered to the main board and encrypted by the hardware, so removing the drive for a dead-box image is impossible. Examiners then rely on the device's own interfaces, special start-up modes, or live and logical acquisition.

Exam focus: Know the differences between raw (dd), E01 and AFF4 images, and that the hash stored in an E01 covers the acquired data, not the container file. Tell hardware from software write blockers and know their limits, especially SSD garbage collection. Know the role of NIST CFTT and of your own validation under ISO/IEC 27041, the steps of the imaging workflow in order, and how to handle bad sectors, HPA and DCO, and encrypted drives.