Skip to content
CSY204 Week 02 Intermediate

Practice evidence acquisition before moving to reading resources.

Security Operations

Track your progress through this week's content

Opening Framing: The First Critical Step

Evidence acquisition is where investigations succeed or fail. A forensic image must be a perfect, verifiable copy of the original media. Any modification to the source—even a single bit—can compromise the entire investigation.

This week covers the tools and techniques for creating forensically sound images of hard drives, SSDs, and other storage media. You'll learn to use write blockers, select appropriate imaging formats, verify integrity with hashing, and document the acquisition process properly.

The goal is simple: capture everything, change nothing, prove it. From an academic perspective, this adheres to the concept of **Forensic Soundness** as defined in **NIST SP 800-86** and **ISO/IEC 27037**. It is not merely about copying data, but about establishing a methodology that is reproducible, verifiable, and admissible under the **Daubert Standard**.

Key insight: You can repeat analysis infinitely, but you only get one chance at proper acquisition.

1) Write Blocking

Preventing any modification to source media:

Write Blocking Concept:

When a computer accesses storage:
- Operating system may write metadata
- File access times update
- System files may change
- Caching may occur

These changes = evidence contamination!

Write blockers prevent ALL writes
while allowing reads for imaging.

Theoretical Mechanism:
The blocker functions as a protocol bridge for the ATA/SCSI Command Sets.
It actively intercepts destructive opcodes (e.g., WRITE DMA, SECURITY ERASE)
at the firmware level, while permitting safe opcodes (e.g., READ DMA)
to pass through.

Hardware Write Blockers:

Hardware Write Blockers:

Preferred for legal cases
Physical device between drive and computer
No software dependencies
Tamper-evident

Popular Devices:
- Tableau (now OpenText)
- WiebeTech
- CRU
- Logicube

Interfaces:
- SATA to USB
- IDE to USB
- NVMe to USB
- Multi-interface units

Usage:
1. Connect write blocker to forensic workstation
2. Attach evidence drive to write blocker
3. Verify write-block LED indicators
4. Proceed with imaging

Advantages:
✓ Hardware-enforced protection
✓ Court-accepted standard
✓ Works with any OS
✓ Visible, verifiable

Disadvantages:
✗ Cost ($200-$2000+)
✗ Need different types for different interfaces
✗ Physical device required

Software Write Blockers:

Software Write Blocking:

Operating system level protection
Less expensive (often free)
Acceptable for some investigations

Linux (built-in):
# Mount read-only
mount -o ro /dev/sdb1 /mnt/evidence

# Block device write protection
blockdev --setro /dev/sdb

# Verify
blockdev --getro /dev/sdb
# Returns 1 = read-only

Windows:
- SAFE Block (free)
- Windows Registry method
- EnCase FastBloc SE

Verification:
# Attempt write (should fail)
touch /mnt/evidence/test
# touch: cannot touch '/mnt/evidence/test': Read-only file system

Limitations:
- Software can be bypassed
- OS may have already written
- Less defensible in court
- Depends on correct configuration

Write Block Verification:

Always verify write blocking!

Before Imaging:
1. Connect media through write blocker
2. Note hash of first sectors
3. Attempt test write
4. Confirm write fails
5. Document verification

Hash Verification:
# Hash first 1MB of disk
dd if=/dev/sdb bs=1M count=1 | md5sum

# After mounting/accessing
dd if=/dev/sdb bs=1M count=1 | md5sum

# Hashes should match = no writes occurred

Documentation:
- Write blocker make/model/serial
- Verification steps performed
- Test results
- Screenshots/photos

Key insight: Hardware write blockers are the gold standard. Use software methods only when hardware isn't available.

2) Forensic Image Formats

Choosing the right format for your images:

Common Forensic Image Formats:

RAW (dd):
- Bit-for-bit copy
- No compression
- Universal compatibility
- Large file sizes
- Extension: .raw, .dd, .img

E01 (EnCase):
- Industry standard
- Compression supported
- Metadata embedded
- Hash verification built-in
- Segmented files option
- Extension: .E01, .E02, ...

AFF (Advanced Forensic Format):
- Open source
- Compression and encryption
- Extensible metadata
- Less common now
- Extension: .aff

AFF4:
- Modern successor to AFF
- Container format
- Multiple evidence streams
- Extension: .aff4

Format Comparison:

┌─────────────┬───────┬───────┬───────┬───────┐
│ Feature     │ RAW   │ E01   │ AFF   │ AFF4  │
├─────────────┼───────┼───────┼───────┼───────┤
│ Compression │ No    │ Yes   │ Yes   │ Yes   │
│ Metadata    │ No    │ Yes   │ Yes   │ Yes   │
│ Hash embed  │ No    │ Yes   │ Yes   │ Yes   │
│ Encryption  │ No    │ Some  │ Yes   │ Yes   │
│ Segmented   │ Manual│ Yes   │ Yes   │ Yes   │
│ Compatibility│ Best │ Good  │ Fair  │ Fair  │
│ Open format │ Yes   │ No    │ Yes   │ Yes   │
└─────────────┴───────┴───────┴───────┴───────┘

Recommendation:
- E01 for most investigations (balance)
- RAW when maximum compatibility needed
- Split large images into segments

Image Segmentation:

# Why segment images?

- FAT32 has 4GB file size limit
- Easier to transfer large images
- Better error recovery
- Parallel processing possible

# E01 segmentation (automatic)
ewfacquire -S 2G /dev/sdb
# Creates: image.E01, image.E02, image.E03...

# RAW segmentation with split
dd if=/dev/sdb | split -b 2G - image.raw.

# Result: image.raw.aa, image.raw.ab, image.raw.ac...

# Reassemble if needed
cat image.raw.* > image.raw

Key insight: E01 format balances compression, metadata, and compatibility. Use RAW when interoperability is critical.

3) Imaging Tools and Techniques

Creating forensic images:

dd and dcfldd:

# dd - basic imaging (built into Linux)

# Basic image
dd if=/dev/sdb of=/cases/evidence/disk.raw bs=4M status=progress

# Parameters:
# if     = input file (source)
# of     = output file (destination)
# bs     = block size (4M is efficient)
# status = show progress

# With hash verification
dd if=/dev/sdb bs=4M | tee /cases/evidence/disk.raw | md5sum

# dcfldd - forensic enhanced dd

dcfldd if=/dev/sdb of=/cases/evidence/disk.raw \
  bs=4M \
  hash=md5,sha256 \
  hashlog=/cases/evidence/disk.hash \
  hashwindow=1G \
  status=on

# Features:
# - Multiple hash algorithms
# - Hashing during imaging
# - Progress status
# - Split output
# - Verification logging

FTK Imager:

FTK Imager (Windows, Free):

Popular GUI imaging tool
AccessData (now Exterro) product
Creates E01, RAW, SMART formats

Process:
1. File → Create Disk Image
2. Select Source (Physical Drive, etc.)
3. Choose Evidence Item
4. Add Image Destination
5. Select format (E01 recommended)
6. Enter case information:
   - Case number
   - Evidence number
   - Examiner name
   - Description
7. Set compression, segmentation
8. Image and verify

Advantages:
✓ Free
✓ GUI interface
✓ Automatic verification
✓ Previews evidence before imaging
✓ Memory capture capability
✓ Creates detailed log

Guymager:

# Guymager - Linux GUI imaging tool

# Install (included in SIFT)
sudo apt install guymager

# Launch
sudo guymager

# Features:
- GUI interface for Linux
- E01 and EWF support
- Multi-threaded (fast)
- Automatic hashing
- Detailed logging

# Process:
1. Right-click on source drive
2. Select "Acquire image"
3. Configure:
   - Output directory
   - File format
   - Segment size
   - Case information
4. Start acquisition
5. Review completion log

ewfacquire:

# ewfacquire - Command line E01 creation

# Basic acquisition
ewfacquire /dev/sdb

# With options
ewfacquire /dev/sdb \
  -t /cases/evidence/disk \
  -C "Case 2024-001" \
  -D "Suspect workstation HD" \
  -e "John Smith" \
  -E "Acme Corp Investigation" \
  -N "Primary evidence drive" \
  -c best \
  -S 2G

# Parameters:
# -t = target filename (no extension)
# -C = case number
# -D = description
# -e = examiner
# -E = evidence number
# -N = notes
# -c = compression (none, empty, fast, best)
# -S = segment size

# Verify image
ewfverify disk.E01

Key insight: Advanced acquisition must account for **Host Protected Areas (HPA)** and **Device Configuration Overlays (DCO)**—hidden drive regions that standard tools miss. Use the right tool for the situation—GUI for simplicity, command line for automation, and specialized parameters for hidden areas.

4) Hash Verification

Proving image integrity:

Why Hashing Matters:

Cryptographic hashes create "digital fingerprints"
Any change = completely different hash
Proves evidence hasn't been modified

Analogy & Theory:
Hash is like a unique serial number for every possible arrangement of data.
In Information Theory, this ensures **Collision Resistance**.
While the Pigeonhole Principle implies collisions are mathematically possible
(infinite input -> fixed output), secure algorithms make finding them
computationally infeasible.

Common Hash Algorithms:

MD5 (Message Digest 5):
- 128-bit hash
- Fast to compute
- Cryptographically broken
- Still used for integrity (not security)
- Example: d41d8cd98f00b204e9800998ecf8427e

SHA-1 (Secure Hash Algorithm 1):
- 160-bit hash
- Also cryptographically broken
- Legacy use
- Example: da39a3ee5e6b...

SHA-256:
- 256-bit hash
- Currently secure
- Modern standard
- Example: e3b0c44298fc1c149...

Forensic Practice:
- Calculate BOTH MD5 and SHA-256
- MD5 for quick comparison
- SHA-256 for legal defensibility
- Document both in reports

Hash Verification Process:

# During acquisition:

1. Hash source before imaging:
   md5sum /dev/sdb > source.md5
   sha256sum /dev/sdb > source.sha256

2. Image the drive:
   dcfldd if=/dev/sdb of=disk.raw hash=md5,sha256 hashlog=imaging.hash

3. Hash the image after creation:
   md5sum disk.raw > image.md5
   sha256sum disk.raw > image.sha256

4. Compare hashes:
   # Source hash should equal image hash
   cat source.md5 image.md5
   
   # Must match exactly!

# Verification documentation:

HASH VERIFICATION LOG
=====================
Source Device: /dev/sdb (Seagate ST1000)
Image File: disk.raw

Pre-Acquisition Hash:
MD5:    a1b2c3d4e5f6g7h8i9j0...
SHA256: 1234567890abcdef...

Post-Acquisition Hash:
MD5:    a1b2c3d4e5f6g7h8i9j0...
SHA256: 1234567890abcdef...

Verification: ✓ PASSED - Hashes match

Working Copy Verification:

# Never work on original evidence!

# Create working copy:
cp disk.E01 working/disk_working.E01

# Verify working copy matches:
md5sum disk.E01 working/disk_working.E01

# Expected output:
# a1b2c3d4... disk.E01
# a1b2c3d4... working/disk_working.E01

# Document in case notes:
Working copy created: [timestamp]
Hash verification: PASSED

# Re-verify periodically during analysis
# Any change = working copy compromised

Key insight: Hashing proves integrity mathematically. A matching hash means the data is identical to the bit level.

5) Acquisition Documentation

Recording the acquisition process:

Documentation Requirements:

BEFORE acquisition:
- Photograph evidence
- Record physical condition
- Note connections/configuration
- Document write-block setup

DURING acquisition:
- Start/end times
- Tool and version used
- Any errors or issues
- Progress observations

AFTER acquisition:
- Hash verification results
- File sizes
- Storage location
- Chain of custody update

Acquisition Report Template:

FORENSIC ACQUISITION REPORT
===========================

CASE INFORMATION
Case Number: 2024-001
Case Name: Acme Data Theft
Examiner: John Smith
Date: 2024-01-15

EVIDENCE ITEM
Evidence #: E001
Description: Dell Latitude 5520 Laptop HDD
Make/Model: Seagate ST500LM000
Serial Number: W7G123ABC
Capacity: 500GB
Interface: SATA

ACQUISITION DETAILS
Date/Time Start: 2024-01-15 09:00:00 UTC
Date/Time End: 2024-01-15 10:45:00 UTC
Duration: 1 hour 45 minutes

Write Blocker:
  Type: Hardware
  Make/Model: Tableau T35u
  Serial: T35-12345
  Verified: Yes

Acquisition Tool:
  Name: FTK Imager
  Version: 4.7.1.2
  
Image Information:
  Format: E01 (EnCase)
  Compression: Best
  Segment Size: 2GB
  Segments Created: 12
  Total Size: 23.5GB (compressed)

HASH VERIFICATION
Source Drive:
  MD5:    a1b2c3d4e5f6789...
  SHA256: 9f86d081884c7d6...

Image File:
  MD5:    a1b2c3d4e5f6789...
  SHA256: 9f86d081884c7d6...

Verification Result: ✓ MATCH

OBSERVATIONS/NOTES
- Drive showed minor physical wear
- No bad sectors encountered
- Imaging completed without errors

STORAGE LOCATION
Primary: Evidence Locker A, Shelf 3
Backup: Secure Server \\forensics\cases\2024-001\

________________________
Examiner Signature  Date

Photographic Documentation:

Photographs to capture:

1. Evidence in original location
   - Before touching anything
   - Shows context

2. Evidence item (multiple angles)
   - Front, back, sides
   - Labels and serial numbers

3. Physical condition
   - Any damage
   - Modifications
   - Seals

4. Connection points
   - How it was connected
   - Cables and ports

5. Write blocker setup
   - Device connected
   - Indicator lights

6. Screen captures
   - Imaging tool progress
   - Completion summary
   - Hash results

Photo requirements:
- Include evidence marker/scale
- Timestamp visible or documented
- High resolution
- Stored with case files

Key insight: Documentation proves you followed proper procedure. What isn't documented might as well not have happened.

Real-World Context: Acquisition Challenges

Practical acquisition scenarios:

SSD Challenges: SSDs complicate forensics. TRIM commands can instantly zero deleted data. Wear leveling means data location changes. Encryption may be hardware-based. Always acquire SSDs as quickly as possible—evidence degrades even when powered off.

Live Acquisition (RFC 3227): Sometimes you can't power down a system—critical servers, volatile evidence in RAM, encrypted drives that will lock. This introduces the **Order of Volatility** debate. Pulling the plug (Dead Box) preserves the disk state but destroys RAM (encryption keys, network connections), potentially rendering the "perfect" disk image useless. You must weigh data stability against data accessibility.

Remote Acquisition: Cloud environments, remote offices, and distributed systems require network-based acquisition. Tools like F-Response enable remote imaging, but network bandwidth becomes a limiting factor.

Encrypted Drives: Full disk encryption (BitLocker, FileVault, LUKS) presents challenges. If the system is running and unlocked, acquire immediately. If locked, you need the key—recovery keys, memory forensics, or legal compulsion may help.

Key insight: Every acquisition is different. Standard procedures adapt to real-world constraints while maintaining integrity.

Guided Lab: Forensic Imaging

Practice creating forensic images with verification.

Step 1: Prepare Test Media

# Create a small test disk image
dd if=/dev/zero of=test_source.raw bs=1M count=100

# Add some data
mkfs.ext4 test_source.raw
mkdir /tmp/mount_test
sudo mount test_source.raw /tmp/mount_test
sudo cp /etc/passwd /tmp/mount_test/
sudo cp /var/log/syslog /tmp/mount_test/
sudo umount /tmp/mount_test

Step 2: Hash Source

# Calculate source hashes
md5sum test_source.raw > source_hashes.txt
sha256sum test_source.raw >> source_hashes.txt

cat source_hashes.txt

Step 3: Create RAW Image

# Using dcfldd
dcfldd if=test_source.raw of=test_image.raw \
  hash=md5,sha256 \
  hashlog=imaging_hashes.txt

# Verify
cat imaging_hashes.txt

Step 4: Create E01 Image

# Using ewfacquire
ewfacquire test_source.raw \
  -t test_image_e01 \
  -C "Lab Exercise" \
  -D "Test disk image" \
  -e "Your Name" \
  -c best

# Verify
ewfverify test_image_e01.E01

Step 5: Compare and Document

# Compare all hashes
md5sum test_source.raw test_image.raw

# Create acquisition report
# Use template from lesson

Reflection (mandatory)

  1. Why did we hash before and after imaging?
  2. What's the difference between RAW and E01 image sizes?
  3. How would this process change with a physical drive?
  4. What would happen if hashes didn't match?

Week 02 Quiz

Test your understanding of Forensic Imaging, Write Blockers, and Evidence Integrity.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz

Week 2 Outcome Check

By the end of this week, you should be able to:

Next week: File System Forensics—understanding how data is stored and recovering deleted files.

🎯 Hands-On Labs (Free & Essential)

Practice evidence acquisition before moving to reading resources.

🎮 TryHackMe: Autopsy

What you'll do: Import disk images, verify hashes, and navigate evidence.
Why it matters: Acquisition and validation are the backbone of forensics.
Time estimate: 1.5-2 hours

Start TryHackMe Autopsy →

🎮 TryHackMe: Disk Forensics

What you'll do: Work with disk images, partitions, and file recovery basics.
Why it matters: Understanding image structure prevents evidence mishandling.
Time estimate: 1.5-2 hours

Start TryHackMe Disk Forensics →

📝 Lab Exercise: Imaging + Hash Verification

Task: Image a USB or test file, then verify with MD5 + SHA256.
Deliverable: Acquisition log with hashes and tool versions.
Why it matters: Hash verification proves evidence integrity.
Time estimate: 60-90 minutes

🛡️ Lab: Build a SOC Playbook

What you'll do: Draft a playbook for common alert types (phishing, malware, login anomalies).
Deliverable: One-page playbook with triage steps and escalation criteria.
Why it matters: Forensics depends on consistent triage and evidence intake.
Time estimate: 60-90 minutes

💡 Lab Tip: Always hash the source before imaging and the image after creation.

🛡️ Triage Playbooks & Evidence Intake

Forensic quality starts at intake. Playbooks define what gets collected, when, and how evidence is preserved.

Playbook essentials:
- Trigger conditions and severity
- Evidence sources to collect
- Order of volatility
- Escalation and notification steps

📚 Building on CSY201: SOC triage workflows and escalation criteria.

Resources

Complete the required resources to build your foundation.

Lab: Complete Acquisition Exercise

Goal: Perform end-to-end forensic acquisition with full documentation.

Part 1: Setup

  1. Obtain a USB drive (or create virtual disk)
  2. Populate with sample files
  3. Delete some files (for later recovery)
  4. Configure write blocking

Part 2: Pre-Acquisition

  1. Photograph the evidence
  2. Document physical characteristics
  3. Calculate source hashes
  4. Verify write blocking is active

Part 3: Image Creation

  1. Create E01 image with proper metadata
  2. Create RAW image for comparison
  3. Note start/end times and any issues

Part 4: Verification

  1. Verify E01 image with ewfverify
  2. Compare source and image hashes
  3. Document verification results

Part 5: Documentation

  1. Complete full acquisition report
  2. Include all required elements
  3. Add photographs and screenshots
  4. Update chain of custody

Deliverable (submit):

Checkpoint Questions

  1. Why are hardware write blockers preferred over software methods?
  2. What are the advantages of E01 format over RAW?
  3. What two hash algorithms should be calculated for forensic images?
  4. What does it mean if source and image hashes don't match?
  5. Why should forensic analysis never be performed on original evidence?
  6. What challenges do SSDs present for forensic acquisition?

Weekly Reflection

Reflection Prompt (200-300 words):

This week you learned evidence acquisition—the critical first step in any forensic investigation. You created forensic images and verified their integrity.

Reflect on these questions:

A strong reflection will connect technical procedures to their legal and practical implications.

Verified Resources & Videos

Evidence acquisition is the foundation of all forensic work. The skills you've developed—write blocking, imaging, hashing, documentation—will be used in every investigation. A perfect acquisition enables all subsequent analysis. A flawed acquisition can invalidate an entire case. Next week: file system forensics, where we examine how data is actually stored and recovered.

← Previous: Week 01 Next: Week 03 →