/analyzing-disk-images

name: analyzing-disk-images
description: Perform dead-disk forensics on an acquired disk image using The Sleuth Kit, Plaso, and bulk_extractor — verify integrity and mount read-only, map partitions, recover deleted files, build a file-system and super-timeline, carve unallocated space, mine registry hives and OS artifacts, and detect anti-forensics. Use when handed a .E01/.dd/.raw/.vmdk/.vhdx disk image or forensic acquisition to examine, recovering deleted files, building a file-system timeline, or carving artifacts from unallocated space.
verified: 2026-07-26

Analyzing Disk Images

A disk image is a frozen crime scene, and the whole discipline is preserving that. Work only from a verified, read-only copy, prove nothing changed with hashes at every step, and remember that the deleted and the unallocated often say more than the live file system — because that is exactly what someone tried to remove.

When to Use

• You have an acquired disk image (`.E01`, `.dd`/`.raw`, `.aff4`, `.vmdk`, `.vhdx`) to examine
• Recovering deleted files, or reconstructing what was on a wiped or reformatted volume
• Building a file-system timeline or a full super-timeline across the whole image
• Carving files and artifacts out of unallocated space, slack, and free clusters
• Mining registry hives, browser data, logs, or other artifacts offline from a mounted image
• Confirming or refuting anti-forensics — timestomping, wiping, hidden or encrypted containers

When NOT to Use

• **You have a RAM capture, not a disk image** — use `analyzing-memory-images`
• **You have a live or triage Windows host and want the artifact-by-artifact

investigation, not raw image handling** — use `investigating-windows-endpoints`

• **You are sweeping a live Linux host for persistence** — use `analyzing-linux-persistence`
• **You need the wider incident-response process — scoping, containment,

eradication** — use `responding-to-incidents`

• **You recovered a specific sample and want to detonate it** — use `analyzing-malware`

Acquisition and Integrity

Everything downstream is worthless if the image is not provably the disk. Never touch the original media without a write blocker, and never analyze the original image — work on a copy.

# Acquire to E01 (EWF) with built-in compression and hashing — preferred format
sudo ewfacquire -t /evidence/host01 -f encase6 -c deflate:fast \
     -C "IR-2026-014" -E "1" -D "Dell OptiPlex sda" /dev/sda

# Raw acquisition alternative — dd with error handling, hash inline
sudo dd if=/dev/sda bs=4M conv=noerror,sync status=progress \
     | tee /evidence/host01.dd | sha256sum

# Verify an existing E01 against its stored hashes
ewfverify /evidence/host01.E01

# Hash the working copy and record it — MD5 and SHA-256 both, for legacy tooling
md5sum   /evidence/host01.dd
sha256sum /evidence/host01.dd

**Record at acquisition time, not later:**

Evidence ID | Source host/serial | Collected by | UTC timestamp | Tool + version
Write blocker used (Y/N + model) | MD5 + SHA-256 at acquisition
SHA-256 verified after each copy | Custodian at each handoff | Storage location

Verify the hash after every copy or transfer. A mismatch means stop — you no longer have the evidence you think you have. If the case may reach litigation or a regulator, involve legal before acquisition.

**Expose the image as a raw device without altering it.** E01 and AFF4 are containers; most TSK and mount operations want a raw block device or file.

# Mount an E01 as a raw device (read-only, FUSE) — exposes ./ewf1
ewfmount /evidence/host01.E01 /mnt/ewf
# /mnt/ewf/ewf1 is now a raw image you can feed to mmls, fls, mount -o loop, etc.

# xmount can also convert on the fly (E01 -> raw or VDI) without a second copy
xmount --in ewf /evidence/host01.E01 --out raw /mnt/xmount

Mounting and Partition Layout

Understand the geometry before you mount anything. The offsets matter — mount at the wrong one and you see nothing or you see garbage.

# Sleuth Kit partition table — gives you the starting SECTOR of each volume
mmls /mnt/ewf/ewf1
#   Slot   Start        End          Length       Description
#   002    0000002048   0000206847   0000204800   NTFS / exFAT (0x07)
#   003    0000206848   0976771071   0976564224   NTFS / exFAT (0x07)

# Cross-check with fdisk
fdisk -l /mnt/ewf/ewf1

# Loopback-mount a partition read-only. Offset = start_sector * 512.
# 206848 * 512 = 105906176
sudo mount -o ro,noexec,norecover,loop,offset=105906176 \
     /mnt/ewf/ewf1 /mnt/evidence

`ro,noexec` prevents writes and accidental execution; `norecover` stops ntfs-3g replaying the NTFS journal (a write) on mount. For ext4 use `ro,noload`; the journal replay is the classic way an examiner silently modifies evidence.

**Layered and encrypted volumes:**

# LVM — scan and activate, then mount the logical volume read-only
sudo losetup -r -f -P /mnt/ewf/ewf1
sudo pvscan && sudo vgchange -ay
sudo mount -o ro /dev/mapper/vg0-root /mnt/evidence

# LUKS — needs the passphrase or a recovered key file
sudo cryptsetup --readonly luksOpen /dev/loop0p2 evd_crypt
sudo mount -o ro /dev/mapper/evd_crypt /mnt/evidence

# BitLocker — dislocker with a recovery key, clear key, or FVEK
sudo dislocker -r -V /dev/loop0p2 -p<48-digit-recovery-key> -- /mnt/bde
sudo mount -o ro,loop /mnt/bde/dislocker-file /mnt/evidence

# macOS APFS / HFS+ — apfs-fuse for APFS containers, read-only
apfs-fuse -o ro /dev/loop0p2 /mnt/evidence      # APFS
sudo mount -t hfsplus -o ro,loop /dev/loop0p2 /mnt/evidence   # HFS+

Without the BitLocker recovery key or LUKS passphrase you have an encrypted brick — pursue the key (escrow, AD, MDM, a memory image, a sticky note) rather than attacking the crypto.

The Sleuth Kit Workflow

TSK reads the file system directly from the image — no mount, no OS interpretation, and it sees deleted entries the live view hides. Give every TSK command the offset (`-o` in sectors) so it targets the righ