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.