Forensic Imaging: Creating and Verifying an Exact Copy

Prerequisites

• DFA-K001: Forensic Principles
• CIR-K002: Evidence Collection & Order of Volatility

Why This Lesson Matters

A forensic image is the foundation of every file system investigation. Get it wrong — wrong tool, no write-blocker, missing hash — and every finding built on top of it is suspect. Think of the image as the crime scene photograph: if the photographer accidentally moves a piece of evidence before shooting, the photo is useless as evidence.

1. What a Forensic Image Is

A forensic image is a bit-for-bit copy of a storage device — every sector, including empty sectors, deleted file remnants, and slack space. It is not a backup. A backup copies files. A forensic image copies raw sectors, preserving artefacts that file-level backup would miss.

Normal backup:   copies files the OS can see
                 → deleted files: MISSING
                 → slack space: MISSING
                 → MFT metadata: MISSING

Forensic image:  copies every sector 0 → last sector
                 → deleted files: PRESENT (until overwritten)
                 → slack space: PRESENT
                 → MFT metadata: PRESENT

2. Image Formats

For most practical work and CTF challenges, raw .img files are used.

3. Write Blockers

Analogy: A write-blocker is a one-way valve. Water (data) flows out freely for reading. Nothing flows back in. The original media cannot be modified.

WITHOUT write-blocker:
  [Suspect drive] ←→ [Workstation]
  OS mounts drive, updates last-access timestamps → EVIDENCE MODIFIED

WITH hardware write-blocker:
  [Suspect drive] → [Write-blocker] → [Workstation]
  Every write command intercepted and discarded → ORIGINAL UNCHANGED

Hardware write-blockers (Tableau, FRED, WiebeTech) are the professional standard. Software write-blockers (Linux mount -o ro, Windows registry flag) are acceptable for preliminary work but not for evidence that may go to court.

4. Creating a Forensic Image

4.1 dc3dd (Enhanced dd for Forensics)

# Basic forensic image with SHA-256 hash and log
dc3dd if=/dev/sdb 
      of=/cases/IR-001/sdb_image.img 
      hash=sha256 
      log=/cases/IR-001/sdb_image.log 
      bs=512

# Verify immediately after imaging
dc3dd if=/cases/IR-001/sdb_image.img 
      hash=sha256 
      log=/cases/IR-001/sdb_image_verify.log 
      hof=/dev/null

# The hash in the first log must match the hash in the second log

4.2 FTK Imager (Windows GUI)

Steps: 1. File → Create Disk Image 2. Source: Physical Drive → select the write-blocked drive 3. Destination: E01 (EnCase) format, set case number, examiner name 4. Enable "Verify images after they are created" 5. The tool auto-generates MD5 and SHA-1 hashes

4.3 Verifying Integrity at Any Time

# Verify a raw image against its recorded hash
sha256sum sdb_image.img
# Compare output to the hash in your chain of custody document

# For E01: FTK Imager can verify the image
# File → Verify Drive/Image → select the .E01

5. Mounting an Image Read-Only for Analysis

Never mount a forensic image with write access. Use read-only mounts.

# Linux: mount raw image read-only (identify partition offset first)
mmls sdb_image.img                    # list partitions and start sectors
# Example output: partition starts at sector 2048

sudo mount -o ro,loop,offset=$((2048*512)) sdb_image.img /mnt/evidence
# Now browse /mnt/evidence without modifying anything

# Unmount when done
sudo umount /mnt/evidence

Better practice: Use a forensic framework (Autopsy, Sleuth Kit) that handles mounting internally with read-only guarantees.

6. Imaging Special Cases

6.1 Live System (Acquired Running)

If the system cannot be powered off (production server, live memory needed), image while running:

# Linux live imaging (dd over network to avoid local writes)
dd if=/dev/sda bs=512 | ssh analyst@forensic-server "dd of=/cases/IR-001/sda.img"

# Hash on both ends must match

6.2 Virtual Machine

# Copy the VMDK/VHD directly (VM must be powered off, or use snapshot)
cp /vm_storage/suspect_vm.vmdk /cases/IR-001/
sha256sum /vm_storage/suspect_vm.vmdk   # before
sha256sum /cases/IR-001/suspect_vm.vmdk # after — must match

6.3 Cloud Storage (AWS S3)

# Create a legal hold on the bucket first (via management console or API)
# Then sync to local for analysis
aws s3 sync s3://target-bucket /cases/IR-001/s3_contents/ --no-sign-request
# Hash the downloaded directory
find /cases/IR-001/s3_contents/ -type f -exec sha256sum {} ; > s3_hashes.txt

7. Common Mistakes

Mistake 1: Imaging to a partition on the same physical disk. If you image /dev/sda (the suspect drive) and write the output to /dev/sda1 (a partition on the same drive), you are overwriting evidence while imaging it.

Mistake 2: Not recording the hash at imaging time. The hash must be recorded during acquisition. A hash computed days later cannot prove the image has not been modified since then.

Mistake 3: Only computing MD5. MD5 is cryptographically broken and can be forged. Always compute SHA-256 (or both MD5+SHA-1 for legacy legal systems that require both, plus SHA-256 for your own records).

Mistake 4: Ignoring errors during imaging. dc3dd and similar tools report read errors (bad sectors). These must be documented. An image with unread sectors is still valid evidence, but the gaps must be recorded.

8. Practice Exercises

1. You need to image a 2 TB hard drive. You have a USB 3.0 write-blocker and a 4 TB external SSD for the image. Estimate the imaging time at approximately 150 MB/s. Is the external SSD large enough?

2. Your dc3dd log shows: error reading block 4096: Input/output error. The image was otherwise completed successfully. Does this invalidate the image? What do you record in the chain of custody?

3. Describe the difference between imaging /dev/sda and /dev/sda1. Which do you image for a complete forensic acquisition, and why?

9. Lab

Assessment mode: quiz

5 questions on image format selection, write-blocker purpose, hash verification, and error handling during acquisition.

10. Framework Alignment

11. Further Reading

• dc3dd man page — man dc3dd; understanding every flag is essential
• Tableau Write Blocker FAQ — Explains hardware write-blocking mechanics
• NIST CFTT (Computer Forensics Tool Testing) — Validated tool results database; check your tools here

["Explain the difference between a forensic image and a file-level backup, and state two specific artefact types that exist in a forensic image but are absent from a backup", "Execute a forensic image of a block device using dc3dd with SHA-256 hashing and a log file, then verify the image integrity by comparing the recorded and recomputed hashes", "Identify three errors in a described imaging procedure (wrong output location, missing hash, software-only write-blocker for a court case) and explain the consequence of each"]

Prerequisites → Why this matters (crime scene photo analogy) → What a forensic image is (vs backup) → Image formats table → Write blockers (one-way valve analogy, hardware vs software) → Creating images with dc3dd and FTK Imager → Mounting read-only → Special cases (live, VM, cloud) → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading