CH2: Forensic Imaging and Validation

Introduction

A forensic image is the foundation of every digital evidence examination. It is a bit-for-bit copy of a suspect device, acquired in a manner that preserves evidentiary integrity and creates an auditable record of the acquisition process. Once a valid image is created, the original device can be sealed and stored, and all examination work occurs on the image instead. This separation protects the original evidence and provides a definitive record of its state at the moment of seizure.

This chapter takes you from the theoretical framework of Chapter 1 into the practical hands-on work of imaging. You will learn how cryptographic hashing functions work at a mathematical level, why different hash algorithms are chosen for different purposes, and how hash sets filter known files during examination. You will configure forensically sterile destination media, create images in multiple formats, and perform the critical validation steps that prove an image is a faithful copy of the original. By the end of this chapter, you will be able to conduct forensically sound imaging workflows and defend your methodology in court.

Learning Objectives

By the end of this chapter, you will be able to:

Explain the role of cryptographic hashing in forensic integrity and describe the differences between MD5, SHA-1, and SHA-256, including their appropriate and inappropriate uses in modern practice.
Generate and validate forensically sterile destination media using multiple tools and document the sanitization process.
Create forensic images in DD/Raw, E01, and AFF4 formats and articulate the trade-offs of each in terms of compression, metadata, tool support, and typical use cases.
Perform image verification through hash comparison and explain its courtroom significance and limitations.
Use NSRL hash sets and custom hash sets to filter known files during examination and reduce the scope of analysis.

2.1 Cryptographic Hashing in Forensic Practice

Hash Functions as Digital Fingerprints

A cryptographic hash function takes any input (a file, a disk image, a message) and produces a fixed-length output called a hash value or digest. The output is deterministic: the same input always produces the same hash. The hash value acts as a digital fingerprint for the input.

The mathematical properties of a good hash function are:

Deterministic: The same input always produces the same output. This allows you to verify that data has not changed by recomputing the hash.
Fixed Length: Regardless of input size, the output is always the same length. A 1-byte input and a 10-gigabyte input both produce a hash of the same size.
Avalanche Effect: A tiny change in the input produces a completely different hash. This means that even a single bit of modification is detectable.
Collision Resistance: It should be computationally infeasible to find two different inputs that produce the same hash. (We will revisit this assumption.)
One-Way Function: You cannot reverse-engineer the original input from the hash. The hash is a one-way function.

These properties make hashing ideal for forensic integrity verification. If the hash of an image matches the hash computed at the time of creation, you can assert with high confidence that the image has not been modified.

MD5 (128-bit Hash)

MD5 was developed in 1992 and was widely used in forensic practice for decades. It produces a 128-bit hash (32 hexadecimal characters).

Advantages:

Fast to compute even on large files.
Universal tool support across forensic software and operating systems.
Sufficient for detecting accidental modifications.

Disadvantages:

Known collision vulnerabilities. In 2004, researchers demonstrated practical MD5 collisions. By 2009, deliberate collision attacks were feasible.
No longer recommended for security-critical applications.

In forensic practice, MD5 collisions are not a practical concern for imaging because an attacker would need to control the contents of both the original device and the forensic image to create a collision. However, best practice in 2026 is to transition away from MD5 for new examinations.

Warning

You may encounter forensic labs still using MD5 as the sole hash algorithm for imaging. This is a legacy practice and should be updated. A competent defense attorney will note that MD5 has known collision vulnerabilities and will challenge the use of MD5 without supplementary hashing. Always pair MD5 with SHA-256.

SHA-1 (160-bit Hash)

SHA-1 was developed by the NSA in 1995 and was the recommended successor to MD5. It produces a 160-bit hash (40 hexadecimal characters).

Advantages:

Stronger theoretical collision resistance than MD5.
Widely supported across forensic tools.
Reasonable performance on large files.

Disadvantages:

Collision vulnerabilities have been demonstrated. In 2017, researchers published the first practical SHA-1 collision.
Deprecated by NIST for most applications as of 2019.
Should not be used as the sole hash algorithm in new forensic work.

SHA-1 is phasing out of forensic practice. You will encounter it in legacy case files and older forensic reports, but new examinations should not rely on it.

SHA-256 (256-bit Hash)

SHA-256 is part of the SHA-2 family of hash functions developed by the NSA and published by NIST in 2001. It produces a 256-bit hash (64 hexadecimal characters).

Advantages:

No known practical collision attacks.
Recommended by NIST and the National Security Agency.
Part of compliance frameworks (FIPS 180-4).
Growing universal support across forensic tools.

Disadvantages:

Slightly slower to compute than MD5, but performance is acceptable even on multi-terabyte images.
Larger hash output requires more storage, but this is negligible.

SHA-256 is the current forensic standard for imaging. All new forensic work should compute and document SHA-256 hashes.

Dual Hashing and Legacy Practice

Current forensic best practice is to compute two hash values for every forensic image:

SHA-256 (current standard): The primary hash for validation and courtroom defense.
MD5 (legacy compatibility): A secondary hash for compatibility with older systems and case files.

This approach provides redundancy and allows you to verify images even if tool support for one algorithm lags. In case reports, you document both hash values and explain that SHA-256 is the primary validation mechanism.

Fuzzy Hashing for Similarity and Known-Bad Sets

Fuzzy hashing (also called context-triggered piecewise hashing or CTPH) is a different approach to hashing. Instead of producing a single fixed-length hash, fuzzy hashing breaks the input into chunks and produces a hash for each chunk. Two files with similar content produce similar fuzzy hashes, even if they differ in length or structure.

Common fuzzy hash tools include:

ssdeep: Produces context-triggered piecewise hashes suitable for comparing files with minor variations.
TLSH (Trend Micro Locality Sensitive Hash): Another fuzzy hashing algorithm with similar properties.

Fuzzy hashing is used to identify files that are similar to known malware or known-bad files, even if they have been repackaged or modified. It is less precise than cryptographic hashing but useful for detecting variants and near-duplicates.

Analyst Perspective

You recover an executable file from a suspect device. You compute its SHA-256 and do not find a match in any known-bad hash sets. However, you compute a fuzzy hash and find a close match to a known ransomware variant. This similarity is evidence that warrants deeper analysis rather than proof of malicious intent. You would then manually examine the executable for suspicious strings, behaviors, and code patterns.

2.2 Hash Sets and Known File Filtering

NSRL and the Concept of Known-Good and Known-Bad Files

The National Software Reference Library (NSRL) is maintained by NIST and the U.S. Department of Justice. It contains cryptographic hashes of millions of common software packages, operating system files, libraries, and legitimate applications. The NSRL hash set is freely available and is used by examiners worldwide.

The purpose of the NSRL is to reduce the scope of analysis. When you acquire an image of a Windows 10 workstation, thousands of files are part of the standard operating system and installed software. The NSRL allows you to filter out these known-good files and focus on the files that are unique to the suspect device or are unknown to the reference library.

Known-Good Hashes: Files that are verified as legitimate and unmodified. The NSRL is a known-good set. When you identify a file by its SHA-256 hash in the NSRL, you can be confident that the file is a standard operating system or software component.

Known-Bad Hashes: Hashes of known malware, exploits, or other malicious files. Law enforcement agencies maintain known-bad hash sets, and some are publicly available through organizations like the Cyber Threat Coalition.

During an examination, you compare file hashes against both known-good and known-bad sets. Files matching known-bad hashes are flagged for investigation. Files matching known-good hashes may be deprioritized, depending on the investigation's focus.

De-NISTing

De-NISTing is the practice of removing NSRL-matched files from analysis. When a file matches a known-good NSRL hash, you note it but do not perform detailed analysis on it. This reduces the volume of data to review and allows analysts to focus on suspicious or unknown files.

Warning

De-NISTing is appropriate when the investigation is focused on unknown or suspicious files. However, if the investigation involves checking for unauthorized installation of legitimate software (e.g., verifying compliance with software licensing), you cannot de-NIST. Every instance of the software is material. Always clarify the investigation's scope before deciding whether de-NISTing is appropriate.

Custom Hash Sets

Beyond NSRL, you can create custom hash sets for specific investigations:

Case-Specific Known-Good: Hashes of files known to be legitimate in the context of a specific investigation. For example, in a corporate investigation, hashes of the company's custom applications.
Known-Bad: Hashes of files known to be malicious in the context of the investigation. For example, variants of malware found on other suspect devices.
Exclude Sets: Files or patterns to exclude from detailed analysis (e.g., temporary files, cache files, encrypted archives).

Custom hash sets are created by importing hashes from other tools, generating hashes from files, or manually collecting hashes from reference materials.

Hash Set Formats and Tools

Different forensic tools use different hash set formats. Common formats include:

NSRL RDS Format: The official NIST format for the NSRL database. Large file (gigabytes), requires specialized tools for importing.
Autopsy Hash Set Format: Autopsy-specific format for importing hashes into the Autopsy platform.
X-Ways Forensics Format: X-Ways-specific format with metadata about each hash.
CSV/TSV: Simple comma-separated or tab-separated values with hash, filename, and metadata. Supported by most tools.

Most forensic tools can import and export hashes in multiple formats, allowing you to move hash sets between tools as needed.

2.3 Forensically Sterile Media

Definition and Purpose

Forensically sterile media is destination storage that has been verified to be empty and unmodified before receiving a forensic image. The destination drive must be:

Fully erased of all data.
Verified to be empty through cryptographic hashing.
Documented as sterile before the imaging process begins.

Sterile media is essential because forensic images are authoritative. If you copy a suspect image to a destination drive that contains residual data from previous examinations, that residual data contaminates the new image. By verifying sterility, you ensure that every byte of the image comes from the suspect device, not from previous work.

Sanitization Methods

To sanitize a destination drive, you write a known pattern (zeros, random data, or a secure erase command) to every addressable location on the drive. Common methods include:

Zero-Fill Sanitization:

Write zeros (binary 00000000) to every sector.
Fast and simple.
Effective for magnetic media (HDDs).
May not be effective for SSDs, which have internal wear-leveling and may not actually overwrite NAND flash cells.

Random-Fill Sanitization:

Write random data to every sector.
Slightly slower than zero-fill.
More secure for SSDs because random data provides no pattern that optimization algorithms can detect.

ATA Secure Erase:

Issue an ATA SECURE ERASE command to the drive.
The drive firmware handles the sanitization, typically by overwriting NAND cells or resetting encryption keys.
Most effective for SSDs; may not work on all older drives.

Tools for sanitization include:

dc3dd (Linux CLI): Sanitizes drives with zero-fill, random-fill, or ATA secure erase. Provides logging and verification.
shred (Linux CLI): Overwrites files with random data. Less suitable for entire drive sanitization.
hdparm (Linux CLI): Executes ATA commands including secure erase. Low-level access; requires care to avoid data loss.
DBAN (Darik's Boot Negator): Bootable tool that securely wipes entire drives with multiple passes. Effective but slow.

Verification of Sterile Media

After sanitization, verify that the drive is sterile:

Compute the hash of the entire drive (using dd and a hash tool).
For a zero-filled drive, the hash should be consistent with all zeros (e.g., the SHA-256 of a billion zeros).
For a random-filled drive, recompute the hash multiple times and verify consistency (should be identical on each recompute).
Document the sanitization method, timestamp, and hash value in the case notes.

Analyst Perspective

You sanitize a 2TB external drive with dc3dd using zero-fill. dc3dd logs the process and computes SHA-256. You note the SHA-256 in your case file. Before imaging the suspect device, you re-hash the sterile drive to verify it has not been modified. The hashes match, confirming sterility. After imaging the suspect device, you compute a final hash of the image for the case report.

SSD-Specific Considerations

SSDs present additional complexity in sanitization. Unlike HDDs, which physically overwrite platters, SSDs use NAND flash cells and controllers that manage wear-leveling and garbage collection.

Wear-Leveling: SSDs internally remap logical addresses to physical flash cells to distribute write load evenly. A zero-fill command may not actually overwrite all physical cells.

TRIM: The TRIM command signals to the SSD that certain logical addresses are no longer in use, allowing the SSD to optimize its internal structure. However, TRIM data is volatile and may be overwritten.

ATA Secure Erase: The most reliable method for SSDs. The SSD firmware executes a full cell erase, typically at the controller level.

For SSDs, the recommended sanitization process is:

Issue an ATA SECURE ERASE command using hdparm or similar.
Verify sanitization by attempting to read the drive. A secure-erased SSD should return zeros or random data.
Document the sanitization method and timestamp.

2.4 Forensic Image Formats

Raw/DD Format: Bit-for-Bit Simplicity

The raw (or DD) format is the simplest forensic image format. It is a contiguous stream of bytes representing every sector of the source device, from sector 0 to the last sector. No metadata, no compression, no error correction.

Advantages:

Universal compatibility. Every forensic tool can read raw images.
Simple structure. A raw image is just a file containing every byte of the original device.
Transparent to verification. You can compute a hash of the image file and be confident it represents the original device.

Disadvantages:

Large file size. A 1TB drive becomes a 1TB image file with no compression.
No metadata. The image file contains no information about when it was acquired, by whom, or using what tool.
No error correction. If a read error occurs during imaging, the image is incomplete.
Single stream. The entire image is one file, which can be cumbersome to manage and transport.

Raw images are often segmented into multiple files (e.g., image.001, image.002, etc.) to fit on media with file size limitations or to improve portability.

E01 Format: Compression, Metadata, and Verification

E01 (Encase Image Format) was developed by Guidance Software and is now an open standard. E01 images are compressed, include metadata, and contain built-in verification.

Advantages:

Compression reduces image file size by 50-80% depending on content (highly compressible data like text compresses more; media files compress less).
Metadata includes acquisition date, tool information, examiner name, and case number.
CRC-32 blocks provide block-level verification. Each data block is accompanied by a CRC checksum, allowing verification of specific blocks without re-hashing the entire image.
Segmentation support. Large images are automatically segmented into multiple files.
Wide tool support. Most commercial forensic tools (EnCase, FTK, X-Ways, etc.) support E01.

Disadvantages:

Proprietary origins. Although open standards documentation exists, EnCase remains the reference implementation.
Slower read performance compared to raw, due to decompression.
Dependency on tool implementation. Different tools may implement E01 differently, and compatibility issues occasionally arise.

E01 is the industry standard for law enforcement and corporate forensics. Most digital forensics labs use E01 as the primary image format.

AFF4 Format: Open Standard and Multiple Streams

AFF4 (Advanced Forensic Format version 4) is a relatively newer format, based on the Zip archive format. AFF4 is open-source and designed for transparency and long-term archival.

Advantages:

Open standard. AFF4 specification is published and not controlled by any vendor.
ZIP-based structure. AFF4 images are essentially Zip archives, readable with standard tools if needed.
Multiple streams. AFF4 can contain multiple versions of the image (e.g., a raw stream and a compressed stream) and multiple metadata streams.
Suitable for long-term archival. The open format and ZIP basis make AFF4 more future-proof than proprietary formats.
Transparency. You can inspect the contents of an AFF4 image using standard tools without specialized forensic software.

Disadvantages:

Newer format with less universal tool support compared to E01 or raw.
Steeper learning curve for tool implementation.
Growing adoption, but not yet universal in law enforcement.

AFF4 is gaining adoption in academia and progressive law enforcement agencies. It is particularly suitable for long-term evidence archival.

Reference Table: Image Format Comparison

Format	Compression	Metadata	Verification	Tool Support	Typical Use Case	File Size (1TB drive)
Raw/DD	None	None	Hash only	Universal	Legacy cases, tool-agnostic scenarios	1000+ GB (uncompressed)
E01	Yes (50-80%)	Yes (date, examiner, tool)	CRC-32 blocks + hash	Broad (commercial tools)	Standard law enforcement, corporate investigations	200-400 GB (varies by content)
AFF4	Optional (multiple streams)	Yes (comprehensive)	Hash + multiple verification options	Growing (open-source tools, some commercial)	Long-term archival, academic research, progressive agencies	200-400 GB (depends on stream selection)

Logical vs. Physical Images

A physical image captures every byte of the storage device, including unallocated space, file system structures, and boot sectors. This is the standard forensic approach.

A logical image captures only the files within a file system, excluding unallocated space and deleted file fragments. Logical images are smaller but lose forensic detail. They are not suitable for comprehensive forensic examinations.

In CFS258, all imaging work focuses on physical images. Logical imaging is not a forensic technique.

2.5 Forensic Image Creation

Pre-Imaging Checklist

Before connecting a suspect device to the forensic workstation, verify:

Write-Blocker Validation: Test the write-blocker with a test drive and verify that modification is blocked.
Destination Media Sterility: Hash the destination drive and verify it is clean.
Workstation Baseline: Take a screenshot or hash of the forensic workstation to document its state before imaging.
Tool Version and Hash: Verify the forensic imaging tool version and compute its SHA-256 hash. Document both.
Case Metadata: Prepare case information (case number, examiner name, case description, device details).
Network Isolation: Verify that the forensic workstation is disconnected from all networks or connected only to an isolated lab network.

dc3dd: Linux Command-Line Imaging with Hashing and Logging

dc3dd is a Linux command-line tool developed by the U.S. Department of Defense Computer Forensics Lab (DCFL). It is similar to the standard dd tool but includes cryptographic hashing, error logging, and detailed output.

Basic syntax:

dc3dd if=/dev/sda of=/path/to/image.dd hash=md5 hash=sha256 log=/path/to/imaging.log

Parameters:

if (input file): The suspect device (e.g., /dev/sda for the first SATA drive).
of (output file): The destination image file.
hash: Compute specified hash algorithms (md5, sha256, or both).
log: Write detailed log to a file (timestamps, blocks processed, hashes, errors).

dc3dd logs every step of the imaging process, including:

Start and end timestamps
Total bytes imaged
Hash values (MD5 and SHA-256)
Any read errors encountered and their sector locations
Transfer rate

The dc3dd log is part of the case documentation and is retained as evidence.

Warning

dc3dd requires root privileges to read from most storage devices. Always verify that you are running the command with appropriate privileges and with the correct input device. Using the wrong /dev/sdX designation can result in overwriting the wrong drive. Double-check before executing.

FTK Imager: GUI-Based Imaging with E01 Support

FTK Imager is a commercial tool from AccessData. It provides a graphical interface for imaging and supports E01 format natively.

FTK Imager workflow:

Create New Case: Enter case metadata (case name, case number, evidence description, examiner name).
Add Evidence: Connect the suspect device (with write-blocker) and select it from the list of available drives.
Select Destination: Choose output format (Raw, E01, or AFF4), destination path, and segment size for large images.
Configure Hashing: Select which hash algorithms to compute (MD5, SHA-1, SHA-256).
Start Imaging: FTK Imager begins reading from the source device and writing to the destination.
Verification: After imaging completes, FTK Imager automatically verifies the image by recomputing hashes and comparing them to the acquisition-time values.

FTK Imager automatically logs the imaging process and stores metadata in the image file (for E01) or in a separate log file (for raw).

Guymager: Linux GUI-Based Imaging with Multithreading

Guymager is an open-source Linux tool with a graphical interface. It is designed for high-speed imaging and supports E01 format.

Guymager features:

Multi-threaded imaging for faster performance on modern hardware.
Real-time progress display with transfer rate.
Integrated hashing (MD5, SHA-1, SHA-256).
Support for E01 format with compression options.
Segment size configuration for large images.

Guymager is lighter-weight than FTK Imager and is commonly used in forensic labs running Linux workstations.

Handling Errors and Read Failures

During imaging, the source device may encounter read errors. These errors occur when the read head cannot reliably access a sector (on HDDs due to mechanical issues, on SSDs due to NAND cell degradation).

Most forensic tools handle read errors by:

Retry Logic: Attempt to read the sector multiple times with increasing wait times.
Error Logging: Document the sector address and number of failed attempts.
Placeholder Bytes: Write a known pattern (zeros or error markers) to the image for unreadable sectors.
Continued Imaging: Proceed to the next sector without stopping.

The imaging log documents all read errors, their sector locations, and the number of retries. If a sector is unreadable, the image contains a placeholder, and the case report notes the error and its impact on the examination.

Analyst Perspective

You are imaging a hard drive with mechanical failure (click of death). The drive has bad sectors near the end. dc3dd encounters read errors on sectors 1,842,000 and 1,843,000 and logs them. The imaging completes with those sectors marked as error. In your case report, you note that the image is complete except for two sectors, which contain read errors. You explain that the sectors could not be recovered due to hardware failure and that the rest of the image is complete and verified.

Partial and Targeted Acquisition

In some investigations, you do not need to image the entire drive. For example:

USB Flash Drive: Only the allocated file system needs imaging; the remainder may be unallocated space.
Partition-Level Imaging: Image only a specific partition (e.g., the C: drive on Windows) instead of the entire disk.
File System Imaging: Image only the file system structures, excluding unallocated space.

Partial acquisition is faster and produces smaller images but loses forensic completeness. Use partial acquisition only when the investigation's scope explicitly calls for it.

2.6 Image Verification and Integrity

Post-Imaging Hash Verification

Immediately after imaging completes, verify that the image matches the original device:

Compare Hashes: The imaging tool computes hash values (MD5 and SHA-256) of the source device during acquisition. After imaging, re-hash the destination image file and compare the values.
Manual Verification: Using dc3dd or a hash tool (sha256sum on Linux, certutil on Windows), compute the hash of the entire image file. Compare to the acquisition-time hash logged by the imaging tool.
Documentation: Document the hash values, the date and time of verification, and the examiner who performed the verification in the case notes.

Hash matching proves that the image is a faithful bit-for-bit copy of the original device. Hash mismatch indicates corruption or modification and requires re-imaging.

Warning

If hashes do not match, do not proceed with the examination. Return to step 1: investigate the cause of the mismatch. Possible causes include: - Faulty destination drive causing write errors. - Network transmission error if the image was transferred over a network. - Tool malfunction or misconfiguration. - The source device was modified between acquisition and verification (unlikely if write-blocked, but possible if write-blocker failed). Re-image the source device using a different destination drive and forensic tool if available.

Ongoing Integrity Checks Before Each Examination Session

Before opening an image for detailed examination, verify its integrity:

Compute Current Hash: Recompute the hash of the image file (using sha256sum or your forensic tool).
Compare to Acquisition Hash: Compare the current hash to the hash documented at the time of acquisition.
Match Verification: If the hashes match, the image has not been modified since acquisition. Proceed with examination.
Mismatch Investigation: If the hashes do not match, do not proceed. Investigate the cause.

This ongoing verification ensures that the image remains unmodified throughout its storage and handling. For images stored on servers or external drives, perform verification before each use, not just once.

Evidence Drives, Master Images, and Working Copies

Best practice distinguishes three separate artifacts in the forensic workflow: the original evidence drive, the first forensic image taken from it, and a working copy used for analysis.

This master-and-working-copy technique follows the guidance in NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response:

"During data collection, the analyst should make multiple copies of the relevant files or filesystems—typically a master copy and a working copy. The analyst can then use the working copy without affecting the original files or the master copy."

Original Evidence Drive (Source):

The physical drive or device collected as evidence.
Preserved in its original state and connected only through a validated write-blocker during acquisition.
Never used directly for examination or analysis.
Its identifying information and acquisition hash are documented in the case record.

Master Image (Read-Only):

The first complete forensic image acquired from the original evidence drive.
Stored in a secure, locked location (evidence storage, encrypted server).
Accessed only for verification and creation of working copies; it is not used for routine analysis.
Hash verified before each access.
Write-protected at the file system level (chmod 444 on Linux, read-only attribute on Windows).
Kept in perpetuity as the authoritative evidence record.

Working Copy:

A hash-verified copy of the master image.
Used for detailed examination and analysis.
Stored on the forensic workstation or examination server.
Can be modified with temporary files, indexes, and analysis artifacts.
Deleted after examination is complete, or archived as case materials.

This three-level separation protects the original evidence drive and master image from accidental modification while allowing the examiner to work freely on the working copy.

Documenting Image Integrity for Court

In case reports and testimony, explain the integrity verification process:

Acquisition Documentation: State the tool used (dc3dd, FTK Imager, etc.), the source device, and the destination image. Provide acquisition timestamp and examiner name.
Hash Values: Document both MD5 and SHA-256 hash values computed at the time of acquisition. Explain that SHA-256 is the current forensic standard and is used as the primary integrity verification mechanism.
Post-Acquisition Verification: Explain that the image was re-hashed after acquisition and that the hash values matched, confirming the integrity of the image.
Chain of Custody: Document everyone who accessed the image, when, and for what purpose. Include hashes computed at each access point if practical.
Forensic Methodology: Explain that forensic imaging is a standard, well-established methodology accepted by courts. Reference the Daubert standard and peer-reviewed literature supporting the methodology.

Hash Verification Limitations and Caveats

While cryptographic hashing is powerful, it has limitations:

Detection vs. Prevention: Hashing detects modification, but does not prevent it. If someone modifies an image and recomputes the hash, the new hash will match the image. Hashing detects modification only if the verifier has the original hash value.
Hardware Failure: Hashing assumes the storage medium is reliable. If the destination drive is failing, write errors may corrupt the image. The hash may compute, but the image may be incomplete or corrupt.
Tool Bugs: A tool bug in the imaging process could produce an image that is different from the original, but the tool's internal hash may not detect the bug. This is why external verification (re-hashing with a different tool) is valuable.
Proof of Integrity, Not Authenticity: A matching hash proves that an image has not been modified since acquisition, but does not prove that the original device's data is correct. The device could contain corrupted files or data errors that were present when the device was seized.

Hash verification is a powerful and widely accepted mechanism, but it is part of a broader chain of custody and documentation process. Hashing alone does not establish legal admissibility; the entire methodology must be sound.

Putting It Together: A Complete Imaging Workflow

You have seized a suspect laptop and have brought it to the forensic lab. The device is a Dell XPS 13 with a 512GB SSD. Walk through the complete imaging workflow:

Pre-Imaging Preparation:

Write-Blocker Setup: Connect a USB-based IDE/SATA write-blocker to your forensic workstation. Test the write-blocker with a test drive to verify it is functioning (attempt to write to the test drive; verify that the write is blocked by re-reading the drive and confirming the test data is not present).
Destination Media: Connect a 1TB external USB drive. Zero-fill sanitize it using dc3dd:
```
dc3dd if=/dev/zero of=/dev/sdc hash=sha256 log=sanitize.log
```
Verify sanitization by re-hashing:
```
sha256sum /dev/sdc
```
Document the hash: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 (hash of all zeros).
Workstation Baseline: Take a screenshot of the forensic workstation and hash all forensic tools. Verify network isolation (no Ethernet cable, Wi-Fi disabled).

Imaging: 4. Extract and Prepare Source Drive: Remove the SSD from the Dell laptop. Connect the SSD to the USB write-blocker's source/input port using the appropriate adapter or cable. Connect the write-blocker's host/output port to the forensic workstation.

Identify the Device: On Linux, use lsblk to identify the device:
```
lsblk
```
The write-blocked SSD appears as /dev/sdb.
Create Forensic Image: Use dc3dd to image the drive:
```
dc3dd if=/dev/sdb of=/media/external/dell_xps_image.dd hash=md5 hash=sha256 log=/media/external/dell_xps_imaging.log
```
dc3dd processes every sector, logs progress, and computes hashes. Imaging completes in approximately 30 minutes (depending on transfer rate).
Document Imaging: dc3dd automatically logs:
Start time: 2026-04-04 10:15:23
End time: 2026-04-04 10:47:42
Total bytes: 512,110,190,592
MD5: 3d4f3b5a7c1e9e2d6a8f3c4e7b9d1a2c
SHA-256: 7a2f8c3e1b4d9a6c2e5f8b1d4a7c9e3f2a8d5c1b4e9f7c3a6d2e8b1f4a7c9e
Read errors: 0
Transfer rate: 256.5 MB/s

Post-Imaging Verification:

Hash Verification: Compute the hash of the destination image file:
```
sha256sum /media/external/dell_xps_image.dd
```
Output: 7a2f8c3e1b4d9a6c2e5f8b1d4a7c9e3f2a8d5c1b4e9f7c3a6d2e8b1f4a7c9e

The hash matches the acquisition-time hash. Image integrity confirmed.

Create Working Copy: Copy the image to the forensic workstation's examination partition:
```
cp /media/external/dell_xps_image.dd /data/cases/2026-04-04_dell_xps/working_image.dd
```
Verify the working copy:
```
sha256sum /data/cases/2026-04-04_dell_xps/working_image.dd
```
Hash matches. Working copy is verified.

Secure Master Image: Move the original image to evidence storage and set it read-only:

mv /media/external/dell_xps_image.dd /evidence/2026-04-04_dell_xps/master_image.dd
chmod 444 /evidence/2026-04-04_dell_xps/master_image.dd

Case Documentation:

Write Case Notes: Document the entire imaging process:
- Device: Dell XPS 13 (serial number XXXX), 512GB SSD
- Seizure date: 2026-04-03
- Imaging date: 2026-04-04
- Examiner: [Your name]
- Acquisition tool: dc3dd version 7.1.657
- Source device: /dev/sdb (write-blocked via USB)
- Destination: Dell 1TB external USB drive (sanitized and verified)
- Acquisition hash (SHA-256): 7a2f8c3e1b4d9a6c2e5f8b1d4a7c9e3f2a8d5c1b4e9f7c3a6d2e8b1f4a7c9e
- Acquisition hash (MD5): 3d4f3b5a7c1e9e2d6a8f3c4e7b9d1a2c
- Verification completed: 2026-04-04 10:50:15
- Verification hash (SHA-256): 7a2f8c3e1b4d9a6c2e5f8b1d4a7c9e3f2a8d5c1b4e9f7c3a6d2e8b1f4a7c9e
- Status: Image verified and integrity confirmed. Ready for examination.

You have now completed a forensically sound imaging workflow and produced a validated image ready for detailed examination in subsequent chapters.

Chapter Summary

This chapter covered the practical tools and procedures for creating and validating forensic images:

Cryptographic Hashing: MD5 (128-bit, fast, collision-vulnerable) was the forensic standard for decades. SHA-1 (160-bit) is deprecated. SHA-256 (256-bit) is the current standard. Best practice pairs SHA-256 with MD5 for legacy compatibility. Fuzzy hashing (ssdeep, TLSH) detects similar files for known-bad set comparisons.
Hash Sets and Filtering: NSRL provides hashes of millions of legitimate files. De-NISTing removes known-good files from analysis. Custom hash sets track known-bad malware and case-specific files. Multiple formats (NSRL RDS, Autopsy, X-Ways, CSV) allow flexibility in tool choice.
Sterile Media: Destination drives must be sanitized (zero-fill, random-fill, or ATA secure erase) and verified as sterile before use. Verification involves hashing the sanitized drive to confirm emptiness. SSDs require ATA secure erase for reliable sanitization.
Image Formats: Raw/DD is universal but large. E01 (Encase format) compresses and includes metadata, and is the industry standard. AFF4 is open-source and archival-friendly, with growing adoption. Physical images capture all bytes; logical images capture only allocated files.
Imaging Tools: dc3dd (Linux CLI) with logging and hashing. FTK Imager (commercial GUI) with E01 support. Guymager (Linux GUI) with multithreading. Each tool has documented procedures and handles read errors gracefully.
Verification and Chain of Custody: Post-acquisition hash verification ensures integrity. Master images are read-only and stored securely. Working copies are used for examination and can be deleted after case completion. Ongoing verification before each session confirms images remain unmodified. Documentation for court explains the methodology and Daubert reliability.

These procedures establish the integrity of forensic images, the foundation of all subsequent examination work. Chapter 3 builds on this foundation by examining the file systems within the image.