What You'll Learn
- Explain the difference between a forensic image and a file-level copy, and why bit-for-bit imaging is essential for preserving deleted data and slack space
- Compare E01 (Expert Witness) and DD (raw) image formats and identify when each is appropriate
- Describe the FTK Imager workflow for creating a verified forensic image with hash validation
- Use dd and dcfldd from the Linux command line to create forensic images with built-in hashing
- Explain how KAPE performs targeted triage collection and why it complements full imaging
- Describe how Velociraptor enables remote forensic acquisition without physical access to the endpoint
- Connect imaging concepts to the disk artifact analysis you will perform in Lab 9.2
What a Forensic Image Actually Is
A forensic image is not a backup. It is not a file copy. It is a bit-for-bit, sector-by-sector duplicate of a storage device — every allocated file, every deleted file fragment, every byte of slack space, every sector of unallocated space, every partition table entry.
When you copy files using cp, robocopy, or drag-and-drop, you get the logical contents — the files the operating system knows about. You miss:
| What File Copy Misses | Why It Matters |
|---|---|
| Deleted files | Attackers delete tools, logs, and malware after use — remnants persist in unallocated space until overwritten |
| Slack space | The gap between the end of a file and the end of its allocated cluster can contain fragments of previous files |
| Alternate data streams | NTFS ADS can hide data inside legitimate files — only visible at the raw level |
| MFT entries for deleted files | The Master File Table retains metadata about deleted files (name, timestamps, size) even after the file data is freed |
| Partition gaps | Space between partitions may contain hidden data or remnants of previous partition schemes |
| Boot sector and MBR/GPT | Contains bootloader code that may be modified by rootkits or bootkits |
A forensic image captures all of this. That is why it is the gold standard for evidence preservation — and why Lesson 9.1 spent so much time on handling it properly.
Image Formats: E01 vs DD
Two formats dominate forensic imaging. Each has trade-offs.
E01 (Expert Witness Format / EnCase Format)
E01 is a proprietary format created by Guidance Software (now OpenText) for EnCase. Despite its proprietary origin, it has become an industry standard supported by virtually every forensic tool.
| Feature | E01 Behavior |
|---|---|
| Compression | Built-in (typically 30–50% reduction) |
| Hashing | Embedded MD5/SHA1 per segment and for the entire image — integrity verification is automatic |
| Metadata | Case number, examiner name, evidence number, notes stored inside the image file |
| Segmentation | Automatically splits into 2GB chunks (E01, E02, E03...) for FAT32 compatibility |
| Tool support | FTK Imager, EnCase, Autopsy, X-Ways, Magnet AXIOM, Sleuth Kit |
DD (Raw Format)
DD is the simplest possible image — a byte-for-byte copy of the device with no wrapper, no metadata, and no compression. It is named after the Unix dd command.
| Feature | DD Behavior |
|---|---|
| Compression | None (image equals source size). Can pipe through gzip manually |
| Hashing | External — you must compute and record hashes separately |
| Metadata | None — you must maintain case notes separately |
| Segmentation | None by default. split or dcfldd can segment |
| Tool support | Universal — every tool on every platform reads raw images |
When to Use Which
| Scenario | Recommended Format |
|---|---|
| Law enforcement case with court proceedings | E01 (embedded metadata and hashing provide built-in integrity proof) |
| Internal corporate investigation | Either (E01 preferred for auditability) |
| Linux-only toolchain | DD (simpler, no dependency on E01 libraries) |
| Need maximum compatibility across tools | DD (universally readable) |
| Limited storage | E01 (compression saves 30–50%) |
| Passing image to another examiner | E01 (metadata travels with the image) |
In practice, most examiners create E01 images for casework and DD images for quick internal analysis. The choice rarely matters for the analysis itself — FTK, Autopsy, and Sleuth Kit all read both formats. The choice matters for chain of custody documentation: E01 embeds it, DD requires external records.
FTK Imager: GUI-Based Forensic Imaging
FTK Imager (by Exterro, formerly AccessData) is the most widely used free forensic imaging tool on Windows. It provides a GUI workflow for creating verified forensic images.
The FTK Imager Workflow
Step 1: Connect the evidence drive through a write blocker. FTK Imager cannot replace a write blocker — it reads whatever the OS presents, and the OS will write to unprotected drives.
Step 2: Select "Create Disk Image" from the File menu. Choose the source type:
- Physical Drive — images the entire disk (recommended)
- Logical Drive — images a single partition (C:, D:, etc.)
- Image File — converts between formats (E01 → DD or vice versa)
Step 3: Choose the output format. E01 is the default and recommended choice. Fill in the evidence metadata fields: case number, evidence number, examiner name, description, and notes.
Step 4: Set the destination path and filename. FTK Imager will create segmented E01 files (filename.E01, filename.E02, etc.). Ensure the destination has enough free space — at minimum, 70% of the source drive size for E01 (with compression) or 100% for DD.
Step 5: Click "Start" and wait. FTK Imager reads every sector from the source drive, compresses it (for E01), and writes it to the destination. A progress bar shows estimated time remaining.
Step 6: Verify. FTK Imager automatically computes MD5 and SHA1 hashes during imaging and verifies them against a second pass. The verification result appears in the summary — "Verify Result: Match" is what you need.
FTK Imager also captures RAM. Under File → Capture Memory, it creates a memory dump (.mem file) — useful for volatile evidence collection (Lesson 9.1). In triage situations, use FTK Imager for both memory capture and disk imaging from a single tool.
dd and dcfldd: Command-Line Imaging on Linux
The dd command creates raw forensic images on Linux and macOS. It is pre-installed on every Unix-like system, requires no additional software, and produces universally readable output.
Basic dd Imaging
dd if=/dev/sdb of=/evidence/case-2026-0142/disk.dd bs=4M status=progress
| Parameter | Meaning |
|---|---|
if= | Input file — the evidence device (/dev/sdb, NOT a partition like /dev/sdb1) |
of= | Output file — the destination image path |
bs=4M | Block size — 4MB is optimal for modern drives (balances speed and reliability) |
status=progress | Shows transfer progress (GNU dd only) |
Hashing with dd
dd does not compute hashes internally. You must hash separately:
md5sum /dev/sdb > /evidence/case-2026-0142/source.md5
dd if=/dev/sdb of=/evidence/case-2026-0142/disk.dd bs=4M status=progress
md5sum /evidence/case-2026-0142/disk.dd > /evidence/case-2026-0142/image.md5
diff /evidence/case-2026-0142/source.md5 /evidence/case-2026-0142/image.md5
dcfldd: The Forensic dd
dcfldd (DoD Computer Forensics Lab version of dd) adds forensic features that dd lacks:
dcfldd if=/dev/sdb of=/evidence/case-2026-0142/disk.dd bs=4M hash=md5,sha256 hashwindow=1G hashlog=/evidence/case-2026-0142/hash.log statusinterval=32
| dcfldd Advantage | Description |
|---|---|
| Built-in hashing | Computes MD5, SHA1, SHA256 (or all three) during imaging — no separate step |
| Hash windows | Hashes every N bytes (e.g., every 1GB segment) for granular verification |
| Split output | split=2G creates 2GB segments automatically |
| Status output | Progress display with block count and speed |
| Verification | dcfldd if=source of=dest vf=dest verifies in a single command |
The most dangerous dd mistake: swapping if= and of=. Writing to the evidence device instead of reading from it is catastrophic and irreversible. Always triple-check your command. The mnemonic: if = in-file (source), of = out-file (destination). Some examiners write the command first without executing, have a colleague verify it, then press Enter.
KAPE: Triage Imaging at Speed
KAPE (Kroll Artifact Parser and Extractor) does not create full disk images. Instead, it collects specific forensic artifacts — the files and registry keys that contain the most investigative value — in a fraction of the time.
KAPE uses two types of configuration files:
| Component | What It Does |
|---|---|
| Targets (.tkape) | Define which files to collect (event logs, registry hives, prefetch, MFT, browser data, etc.) |
| Modules (.mkape) | Define which processing tools to run on collected artifacts (RegRipper, PECmd, MFTECmd, etc.) |
Example KAPE Collection
kape.exe --tsource C: --tdest D:\Evidence\Case-0142 --target KapeTriage
The KapeTriage compound target collects:
- Windows Event Logs (
*.evtx) - Registry hives (SAM, SYSTEM, SOFTWARE, NTUSER.DAT, UsrClass.dat)
- Prefetch files (
C:\Windows\Prefetch\*.pf) - MFT (
$MFT) - Amcache.hve
- SRUM database
- Scheduled tasks
- Browser artifacts (Chrome, Firefox, Edge)
- Recent files and Jump Lists
- PowerShell console history and transcription logs
A full KapeTriage collection from a 500GB drive typically completes in 5–15 minutes and produces 1–5 GB of output — compared to hours for a full image.
KAPE + full image = the triage-first workflow. Start KAPE on the evidence drive to get actionable artifacts within minutes. Simultaneously start a full dd or FTK Imager acquisition. Analysts begin investigating KAPE output while the full image runs in the background. By the time the image finishes, you already have initial findings.
Remote Acquisition with Velociraptor
In a cloud-first, distributed environment, you often cannot physically access the endpoint. The server might be in AWS. The laptop might be in another country. Velociraptor solves this with remote forensic acquisition — collecting artifacts over the network using its pre-installed endpoint agent.
What Velociraptor Can Collect Remotely
| Artifact Category | Examples |
|---|---|
| Memory | Full memory dump, specific process memory |
| File system | MFT, specific files by path or hash, recursive directory listings |
| Registry | Full hive export, specific key queries |
| Event logs | All .evtx files, parsed event data |
| Process data | Running processes, loaded DLLs, network connections, handles |
| Browser | History, downloads, cookies, cache (Chrome, Firefox, Edge) |
| Triage packages | KapeFiles-equivalent collection bundles |
Remote Acquisition Workflow
1. Velociraptor Server → selects target endpoint from client list
2. Server creates a "Collection Flow" — specifies which artifacts to collect
3. Agent on target receives the collection request
4. Agent collects artifacts locally, compresses them, and uploads to server
5. Server stores collected data + generates hash of the upload
6. Examiner downloads the collection for analysis
The key advantage: the Velociraptor agent is already running on the endpoint. It does not require a new login session, does not install new software, and its forensic footprint is minimal compared to RDP/SSH access.
In Lab 9.2, you will use both methods. First, you will use Velociraptor to remotely collect Windows forensic artifacts (event logs, registry hives, prefetch, MFT). Then, you will analyze a pre-built disk image using forensic tools. This mirrors the real-world workflow: remote triage first, full image analysis second.
Hash Verification: The Math of Trust
Every imaging method — FTK Imager, dd, dcfldd, KAPE, Velociraptor — must end with hash verification. The hash proves the image is an exact copy of the source.
| Algorithm | Output Length | Speed | Forensic Use |
|---|---|---|---|
| MD5 | 128-bit (32 hex chars) | Fastest | Legacy standard, still widely used. Collision-vulnerable but acceptable for integrity checking |
| SHA1 | 160-bit (40 hex chars) | Fast | FTK Imager default. Collision-demonstrated (SHAttered, 2017) but still used |
| SHA256 | 256-bit (64 hex chars) | Moderate | Current best practice. No known collision attacks. Recommended for all new cases |
Best practice: compute both MD5 and SHA256. MD5 for backward compatibility with older case management systems, SHA256 for actual integrity assurance.
md5sum disk.dd
sha256sum disk.dd
If the source hash and image hash match, the image is forensically sound. If they do not match, the image must be discarded and recreation attempted — after investigating what went wrong (bad sectors, failing drive, interrupted write).
Imaging Best Practices and Common Pitfalls
| Best Practice | Why |
|---|---|
| Always use a write blocker for physical access | Prevents OS from modifying the evidence drive |
| Hash both source and image immediately | Establishes integrity baseline before analysis begins |
| Use E01 for case work, DD for quick analysis | E01 embeds metadata; DD is simpler and universally compatible |
| Image the physical disk, not individual partitions | Captures unallocated space, partition gaps, and boot sectors |
| Run KAPE triage in parallel with full imaging | Provides actionable intelligence within minutes |
| Store images on a dedicated forensic workstation | Prevents accidental modification or deletion |
| Record imaging start time, end time, and any errors | Part of chain of custody documentation |
| Keep at least two copies of every image | One for analysis, one for archive/legal hold |
Never image to the same physical disk as the source. If you are imaging /dev/sdb, never write to a partition on /dev/sdb. This seems obvious, but in multi-disk systems with generic labels, mistakes happen. Always verify device identifiers with lsblk or fdisk -l before running dd.
Key Takeaways
- A forensic image is a bit-for-bit sector copy that preserves deleted files, slack space, and unallocated data — unlike a file-level copy
- E01 format embeds metadata, compression, and hashing; DD format is raw, universal, and simple — choose based on case requirements
- FTK Imager provides GUI-based imaging with automatic hash verification; dd/dcfldd provides CLI-based imaging with full scripting control
- KAPE collects specific high-value artifacts in minutes — use it alongside full imaging for a triage-first workflow
- Velociraptor enables remote forensic acquisition without physical access — critical for cloud and distributed environments
- Hash verification (MD5 + SHA256) at the end of every imaging session is mandatory — a mismatch means the image cannot be trusted
- The triage-first workflow (KAPE/Velociraptor for quick artifacts + full image in background) gives you speed without sacrificing completeness
What's Next
With evidence properly collected and imaged, Lesson 9.3 dives into Windows Forensic Artifacts — the specific files, registry keys, and system databases that reveal what happened on a Windows endpoint. You will learn to read Prefetch, Amcache, ShimCache, UserAssist, Shellbags, Jump Lists, LNK files, browser artifacts, USB history, and Recycle Bin contents — the breadcrumbs attackers leave behind.
Knowledge Check: Disk Imaging & Acquisition
10 questions · 70% to pass
What is the fundamental difference between a forensic image and a standard file copy?
Which image format embeds case metadata, compression, and hash verification within the image file itself?
What is the most dangerous mistake when using the dd command for forensic imaging?
What advantage does dcfldd provide over standard dd for forensic imaging?
In Lab 9.2, you will use Velociraptor for remote artifact collection. What is the primary forensic advantage of remote collection over logging into the endpoint?
A KAPE triage collection from a 500GB drive typically produces how much output and completes in what time frame?
Why should a forensic examiner image the entire physical disk rather than individual partitions?
Which hash algorithm is recommended as current best practice for forensic integrity verification?
What does the 'triage-first workflow' mean in practical forensic operations?
KAPE uses two types of configuration files. What are 'Targets' (.tkape) and 'Modules' (.mkape)?
0/10 answered