9.3 Forensic Image Formats (RAW/DD, E01, AFF) & Cryptographic Hashing Verification (MD5, SHA-256)

9.3 Forensic Image Formats (RAW/DD, E01, AFF) & Cryptographic Hashing Verification (MD5, SHA-256)

Quick Answer: Forensic images store acquired bit-stream data in standardized container formats. The RAW/DD format provides a flat, uncompressed sector dump with universal tool compatibility, but lacks embedded metadata or internal integrity checks. The Expert Witness Format (E01) encapsulates sector data with a 13-byte magic header (45 56 46 09 0D 0A FF 00), case metadata, zlib compression, internal CRC-32 checksums per 64-sector chunk (32 KB), and MD5/SHA-1 acquisition hashes in the footer. Evidence integrity is established when the pre-acquisition hash of the physical source drive matches the verification hash computed from the uncompressed image data stream.

---

Deep Architectural Comparison of Forensic Image Formats

Forensic disk images must preserve raw sector data while ideally documenting chain-of-custody metadata, resisting accidental file corruption, and minimizing storage footprint through non-destructive compression.

+-------------------------------------------------------------------------+
|                   E01 (EXPERT WITNESS FORMAT) ANATOMY                   |
+-------------------------------------------------------------------------+
| 1. Header Signature: 13 Bytes [ 45 56 46 09 0D 0A FF 00 ]               |
|    (ASCII: EVF followed by 0x09, 0x0D, 0x0A, 0xFF, 0x00)                |
|-------------------------------------------------------------------------|
| 2. Case Metadata Section: (Case #, Evidence #, Examiner, Notes, Dates)  |
|-------------------------------------------------------------------------|
| 3. Data Chunks (Repeated throughout file):                              |
|    +-----------------------------------------------+                    |
|    | Compressed Chunk (64 Sectors = 32 KB raw data)|                    |
|    | [zlib / deflate compression]                  |                    |
|    +-----------------------------------------------+                    |
|    | 32-bit CRC Checksum (4 Bytes)                 |                    |
|    +-----------------------------------------------+                    |
|-------------------------------------------------------------------------|
| 4. Table of Offsets: 64-bit pointers for rapid seeking into chunks      |
|-------------------------------------------------------------------------|
| 5. Footer Section: Stored MD5 (16 Bytes) & SHA-1 (20 Bytes)             |
|    Acquisition Hashes computed over the uncompressed raw byte stream    |
+-------------------------------------------------------------------------+

1. RAW / DD Format

The RAW format (commonly with file extensions .raw, .dd, .img, or split extensions .001, .002, .raw.aa, .raw.ab) is an uncompressed, direct sector-by-sector dump of the physical drive.

• Universal Compatibility: Can be opened by any forensic suite (Autopsy, Sleuth Kit, FTK, EnCase, X-Ways), mounted directly in Linux via loop devices (mount -o loop,ro image.raw /mnt/evidence), or analyzed with standard Unix string/grep utilities.
• Architectural Deficiencies:
  • Zero Embedded Metadata: Case details, examiner identity, drive serial numbers, and acquisition timestamps cannot be stored inside the image. They must be maintained in external text logs.
  • Zero Native Compression: A 2 TB drive requires a 2 TB .raw file, even if 1.9 TB consists of unallocated empty sectors.
  • No Internal Integrity Protection: If a storage medium hosting a .raw file experiences bit decay (silent bit rot) affecting a single sector, the global hash changes completely. The examiner has no internal checksums to prove which specific sector was damaged or demonstrate that the remaining sectors remain authentic.

2. Expert Witness Format (E01 / EnCase)

Originally developed by Guidance Software (now OpenText EnCase) and reverse-engineered into the open-source libewf library, E01 is the de facto standard format across corporate and law enforcement investigations.

• 13-Byte Magic Signature: Offset 0x00000000 starts with 45 56 46 09 0D 0A FF 00 (ASCII representation EVF followed by control characters 0x09 0x0D 0x0A 0xFF 0x00).
• Chunk-Based Integrity (CRC-32): Data is processed in discrete blocks of 64 sectors (32,768 bytes = 32 KB). Each chunk is compressed using zlib and appended with a 4-byte CRC-32 checksum. If a single chunk is corrupted on storage media, forensic software flags that specific 32 KB block while preserving the integrity of all other blocks.
• Embedded Metadata: Contains case number, evidence number, description, examiner notes, hardware serial numbers, and system time offsets directly within the header.
• Footer Verification Hash: The footer stores the cryptographic MD5 and/or SHA-1 hash computed over the uncompressed bit-stream during acquisition.
• Volume Splitting: Automatically splits large images into user-defined segments (e.g., .E01, .E02, ..., .EAA, .EAB) to facilitate storage across portable media.

3. Advanced Forensic Format (AFF / AFF4)

Developed by Dr. Simson Garfinkel and Basis Technology to provide an open, non-proprietary extensible format free from patent restrictions:

• AFF (Version 1): Stores disk images and extensible XML-based metadata in a single file (.aff), dual-file structure (.afm metadata accompanied by .raw data), or split directory structure (.afd).
• AFF4 (Next-Generation Multi-Stream Format): Standardized under an open RFC draft. Supports multi-stream storage (e.g., storing physical RAM dumps, multiple physical drives, and logical file extractions within a single unified container). Uses ZIP64 containerization, snappy or deflate compression, and SHA-256 block hashing.

4. SMART Format

Developed by ASR Data for the SMART Linux forensic suite. A proprietary compressed format that includes embedded metadata, volume segmenting, and CRC block protection similar to E01.

---

Forensic Image Formats Comparison Matrix

---

Cryptographic Hashing Algorithms in Digital Forensics

A cryptographic hash function is an irreversible, deterministic mathematical algorithm that converts an arbitrary stream of input bytes into a fixed-length string of hexadecimal characters (the hash digest). In digital forensics, hashes serve as mathematical fingerprints that authenticate evidence under FRE 901.

Core Properties of Forensic Hashing

1. Deterministic: The exact same input stream will always generate the identical hash digest.
2. Fixed Output Length: The digest length is independent of the input size (a 1-byte file and a 10 TB storage array produce identical digest bit-lengths).
3. Avalanche Effect: A modification of a single bit on a physical disk alters approximately 50% of the bits in the resulting hash digest, immediately exposing tampering or data corruption.
4. Pre-image Resistance: It is mathematically infeasible to reverse-engineer or reconstruct the original raw sector data from the hash digest.

Original Physical Disk (1 TB):
[ LBA 0 .................................................... LBA max ]
      |                                                          |
      +==================== SHA-256 Hash ========================+
                                   |
                                   v
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Suspect Disk with a SINGLE BIT MODIFIED (1 -> 0 at LBA 4096):
[ LBA 0 ........................[Bit Flip].................. LBA max ]
      |                                                          |
      +==================== SHA-256 Hash ========================+
                                   |
                                   v
7d22cf535520a60f466e42ba4d3495901389ecc30fb86d7aa83e01490804505a

Result: 128 of 256 bits changed completely! Tampering instantly detected.

Primary Algorithms Tested on the CHFI Exam

[!TIP] On the CHFI exam, remember digest character lengths:

• MD5: 128 bits / 4 bits per hex character = 32 hexadecimal characters.
• SHA-1: 160 bits / 4 bits per hex character = 40 hexadecimal characters.
• SHA-256: 256 bits / 4 bits per hex character = 64 hexadecimal characters.

---

Acquisition Hash vs. Verification Hash: Verification Matching Rules

Digital forensics enforces strict verification rules throughout the evidence lifecycle:

+-------------------------------------------------------------------------+
|                   FORENSIC VERIFICATION HASH PIPELINE                   |
+-------------------------------------------------------------------------+
|                                                                         |
|  PHASE 1: ACQUISITION HASH (Source Drive)                               |
|  Drive connected to write-blocker -> Bytes streamed to imaging tool.    |
|  Hash computed in RAM as raw bytes are read from physical disk.         |
|  Stored in acquisition log and/or E01 footer:                           |
|  Acquisition Hash: 4a2b9e81...                                          |
|                                                                         |
|  PHASE 2: VERIFICATION HASH (Forensic Image)                            |
|  Imaging tool re-reads the completed image file (.raw or .E01).         |
|  Decompresses chunks (if E01) to reproduce the raw bit-stream.          |
|  Computes cryptographic digest over the uncompressed data:              |
|  Verification Hash: 4a2b9e81...                                         |
|                                                                         |
|  PHASE 3: INTEGRITY COMPARISON                                          |
|  IF Acquisition Hash == Verification Hash:                              |
|     ==> EVIDENCE IS AUTHENTIC & UNALTERED (FRE 901 SATISFIED)           |
|  IF Acquisition Hash != Verification Hash:                              |
|     ==> EVIDENCE IS COMPROMISED & INADMISSIBLE                          |
+-------------------------------------------------------------------------+

The Working Copy Rule

1. Master Image Preservation: Once acquired and verified, the primary forensic image (Master Copy) is write-protected and stored in a secure evidence repository.
2. Working Copy Generation: The examiner creates a bit-for-bit duplicate of the master image file (the Working Copy).
3. Working Copy Validation: The examiner verifies that Hash(Master Image) == Hash(Working Copy) before conducting forensic analysis. Forensic tools (such as Autopsy or FTK) perform all indexing, parsing, and carving exclusively against the Working Copy, ensuring the Master Copy remains pristine.

---

Dual Hashing Pipelines & Concrete Command Operations

To withstand rigorous judicial scrutiny, examiners employ dual hashing, computing two distinct cryptographic algorithms (e.g., MD5 and SHA-256) simultaneously during image acquisition. If an adversary attempts to challenge MD5 due to theoretical cryptographic collisions, the independent SHA-256 hash completely refutes the challenge.

Operational Dual-Hashing with dcfldd

# Dual hashing on-the-fly during bit-stream physical imaging
sudo dcfldd if=/dev/sdb of=/evidence/suspect_drive.raw \
  hash=md5,sha256 \
  md5log=/evidence/acquisition_md5.log \
  sha256log=/evidence/acquisition_sha256.log \
  status=on conv=noerror,sync

# Independent verification pass on the resulting RAW image file
md5sum /evidence/suspect_drive.raw > /evidence/verify_md5.log
sha256sum /evidence/suspect_drive.raw > /evidence/verify_sha256.log

# Verifying exact matching via diff
diff /evidence/acquisition_sha256.log /evidence/verify_sha256.log
# Returns zero output when hashes are 100% identical

Inspecting and Verifying E01 Images with libewf Utilities

The open-source libewf suite provides command-line tools to interrogate and verify E01 containers:

# 1. ewfinfo: Displays internal header metadata, chunk size, and stored hashes
ewfinfo /evidence/suspect_disk.E01

# Sample ewfinfo Output:
# Case number:        2026-CHFI-903
# Evidence number:    Item-02
# Examiner name:      Lead Analyst
# Media size:         500 GB (500107862016 bytes)
# Chunk size:         64 sectors (32768 bytes)
# MD5 hash stored:    c4ca4238a0b923820dcc509a6f75849b
# SHA1 hash stored:   356a192b7913b04c54574d18c28d46e6395428ab

# 2. ewfverify: Reads all chunks, verifies internal CRC32s, and checks footer hashes
ewfverify /evidence/suspect_disk.E01

# Sample ewfverify Output:
# MD5 hash calculated:     c4ca4238a0b923820dcc509a6f75849b
# MD5 hash stored:         c4ca4238a0b923820dcc509a6f75849b
# MD5 hash verification:   SUCCESS
# SHA1 hash calculated:    356a192b7913b04c54574d18c28d46e6395428ab
# SHA1 hash stored:        356a192b7913b04c54574d18c28d46e6395428ab
# SHA1 hash verification:  SUCCESS
# ewfverify: SUCCESS

---

Real-World Case Scenario: The Contested Murder Trial Hash Mismatch

The Incident

In a high-profile homicide prosecution, law enforcement seized a 2 TB laptop hard drive belonging to the defendant. The field detective acquired the drive to a RAW (.dd) file format, recorded an acquisition MD5 hash in their handwritten notes, and placed the target external drive on an evidence shelf.

The Forensic Challenge in Court

Six months later, during pre-trial discovery, defense counsel requested an independent verification hash of the .dd image. When the prosecution's forensic analyst computed the SHA-256 and MD5 hashes of the .dd file, the MD5 hash did not match the detective's original notes.

• The prosecution argued that the discrepancy was merely a clerical error in the detective's handwritten notes.
• The defense retained a digital forensics expert who analyzed the .dd file against the physical drive. The expert proved that the .dd file on the evidence drive had suffered silent magnetic bit degradation (bit rot) at LBA 8,192, modifying 4 bytes.
• Because the detective utilized the RAW/DD format, which lacks internal block-level checksums, the prosecution could not scientifically prove which specific sectors had been altered or whether the detective had inadvertently connected the drive without a write-blocker.
• Had the detective acquired the drive in Expert Witness Format (E01), the embedded CRC-32 checksum per 64-sector chunk would have pinpointed the exact damaged 32 KB block, proving mathematically that the remaining 1,999,999,968 bytes of the drive remained 100% unaltered.

The Judicial Outcome

The trial judge ruled that the integrity of the disk image could not be verified under FRE 901. The disk image and all carved chat records recovered from it were excluded from evidence, resulting in a directed verdict of acquittal.