Disk & Memory Acquisition

Everything downstream — timelines, registry parsing, carving, memory analysis — is only as good as the image it runs on. Acquisition is the one phase you cannot redo: a live box changes every second and a powered-off box loses its RAM forever. This card is the order of operations, the exact dd / ewfacquire / FTK Imager invocations, the memory capture tools per OS, and how to hash, document and mount the result so the analysis sheets (EZ Tools, Linux forensics, Volatility) have something trustworthy to chew on.

[!warning] Two rules that never bend

1. Never write to the evidence. Hardware write blocker on the suspect drive, or software blocking (blockdev --setro, Windows diskpart read-only attribute, FTK Imager’s own protection) when you must go software-only.
2. Hash before, hash after, write it down. An image without a matching acquisition hash is a file, not evidence.

Order of volatility (RFC 3227)

Collect what disappears fastest first. Every step below the line you are on is destroying evidence above it.

[!tip] Pull the plug or shut down? Pull the plug (hard power-off) preserves the disk as-is, including hiberfil.sys/pagefile.sys, and defeats shutdown-triggered anti-forensics. Graceful shutdown flushes caches and may fire a wiper. Default to: capture RAM live → pull the plug → image the disk. Exceptions: encrypted volumes you can only read while unlocked (image them live, or capture the key from RAM first), and servers where downtime is not yours to decide.

Documentation & chain of custody

Start the log before the first command. Every image needs:

• Case ID, examiner, date/time (with timezone — record the suspect machine’s clock skew against a reference clock too)
• Device: make, model, serial, capacity, interface, physical condition, photos of labels
• Acquisition method, tool + version, write-blocker used
• Source hash, image hash, verification result
• Every hand-off: who, when, why, signed

# Capture the timestamp and clock skew at the very start
date -u; hwclock -r 2>/dev/null      # on the suspect box (Linux)
# Windows:
# w32tm /stripchart /computer:pool.ntp.org /samples:3 /dataonly

Live response (before you power off)

Only do this when the RAM capture is done (or you cannot capture RAM). Run tools from your own media, redirect output to your own media, and know that every command you run leaves artefacts — log what you ran so the analyst (probably you) can exclude them later.

# Linux — volatile state to an evidence mount
E=/mnt/evidence/$(hostname)-$(date -u +%Y%m%dT%H%MZ); mkdir -p "$E"
date -u                    > "$E/date.txt"
uptime                     > "$E/uptime.txt"
w; last -F                 > "$E/logins.txt"
ps auxwwf                  > "$E/ps.txt"
ss -tulpan                 > "$E/net.txt"
ip a; ip r; arp -an        > "$E/ip.txt"
lsof -nP                   > "$E/lsof.txt"
mount; df -h               > "$E/mounts.txt"
lsmod                      > "$E/lsmod.txt"
cat /proc/mounts /proc/partitions > "$E/proc.txt"

# Windows — same idea, PowerShell (run from your USB, output to it)
$E="E:\evidence\$env:COMPUTERNAME-$(Get-Date -f yyyyMMddTHHmm)"; mkdir $E | Out-Null
Get-Date -Format o                              > "$E\date.txt"
Get-Process -IncludeUserName | Sort StartTime   > "$E\ps.txt"
Get-CimInstance Win32_Process | Select ProcessId,ParentProcessId,CommandLine | Export-Csv "$E\cmdlines.csv"
Get-NetTCPConnection -State Established,Listen | Export-Csv "$E\net.csv"
Get-NetNeighbor; Get-NetIPAddress; Get-DnsClientCache | Out-File "$E\netcfg.txt"
query user; net session; net use               > "$E\sessions.txt"
Get-ScheduledTask | Export-Csv "$E\tasks.csv"
Get-Service | Export-Csv "$E\services.csv"
Get-SmbOpenFile; Get-SmbSession               > "$E\smb.txt"

Memory capture

Windows

# WinPmem, raw image, then hash it
.\winpmem_mini_x64_rc2.exe E:\evidence\mem.raw
Get-FileHash E:\evidence\mem.raw -Algorithm SHA256 | Tee-Object E:\evidence\mem.raw.sha256

# Also copy the swap/hibernation files for Volatility / Hibr2Bin
# (locked while running — use FTK Imager's "Obtain Protected Files" or KAPE MemoryFiles)

[!info] Size and time RAM image ≈ physical RAM (16 GB box → 16 GB file, 2–5 min over USB 3). Write to external media, never the suspect disk. If Volatility later fails to find symbols, capture C:\Windows\System32\ntoskrnl.exe too — Vol3 uses its PDB GUID to fetch the right symbol pack.

Linux

# AVML — compress on the fly to your evidence mount
./avml --compress /mnt/evidence/mem.lime.compressed
# or plain
./avml /mnt/evidence/mem.lime && sha256sum /mnt/evidence/mem.lime > /mnt/evidence/mem.lime.sha256

# LiME — build on a matching kernel, never on the suspect box if you can avoid it
git clone https://github.com/504ensicsLabs/LiME && cd LiME/src && make
sudo insmod ./lime-$(uname -r).ko "path=/mnt/evidence/mem.lime format=lime"
sudo rmmod lime

# For Volatility 3 you will need a symbol table for this kernel:
#   dwarf2json linux --elf /usr/lib/debug/boot/vmlinux-$(uname -r) > $(uname -r).json

[!tip] macOS Modern Apple silicon makes live RAM capture impractical without vendor tooling. Collect volatile state with sysdiagnose, ps, lsof, nettop, and unified logs (log collect --output case.logarchive), then image the disk from Recovery / target disk mode.

Disk imaging

Identify the device first (and do not mount it)

lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINT,FSTYPE
sudo fdisk -l /dev/sdb
sudo smartctl -i /dev/sdb              # serial, firmware, power-on hours — into the log
sudo hdparm -I /dev/sdb | head -20
sudo blockdev --setro /dev/sdb         # software write-block if no hardware blocker
sudo blockdev --getro /dev/sdb         # → 1
# Stop the desktop from auto-mounting removable media before you plug in:
# gsettings set org.gnome.desktop.media-handling automount false

# Windows — find the disk and make it read-only in diskpart (no hardware blocker)
Get-Disk | ft Number,FriendlyName,SerialNumber,Size,PartitionStyle
diskpart
# DISKPART> select disk 2
# DISKPART> attributes disk set readonly
# DISKPART> attributes disk   (verify "Read-only: Yes")

dd family (raw images)

# Baseline hash of the source (slow, but the gold standard)
sudo sha256sum /dev/sdb | tee /mnt/evidence/sdb.source.sha256

# Plain dd — works everywhere, no progress, no error handling
sudo dd if=/dev/sdb of=/mnt/evidence/sdb.dd bs=4M conv=noerror,sync status=progress

# dcfldd — hashes while imaging, splits, verifies
sudo dcfldd if=/dev/sdb of=/mnt/evidence/sdb.dd bs=4M \
     hash=sha256 hashlog=/mnt/evidence/sdb.dd.hash \
     conv=noerror,sync statusinterval=256

# dc3dd — the DoD successor to dcfldd, best error handling, logs everything
sudo dc3dd if=/dev/sdb of=/mnt/evidence/sdb.dd \
     hash=sha256 hash=md5 log=/mnt/evidence/sdb.dd.log \
     rec=on                       # keep going on bad sectors, zero-fill them

# Split raw image into 2 GB chunks (FAT32 evidence drive, or just manageability)
sudo dc3dd if=/dev/sdb ofs=/mnt/evidence/sdb.dd.000 ofsz=2G hash=sha256 log=sdb.log

# Verify: image hash must equal source hash
sha256sum /mnt/evidence/sdb.dd

[!warning] conv=noerror,sync matters Without noerror a single bad sector aborts the image. Without sync the bad block is skipped instead of zero-padded, and every offset after it shifts, breaking filesystem parsing. Use both, and record the bad-sector list from the log.

E01 / EWF (compressed, hashed, metadata-carrying)

The Expert Witness Format is what commercial suites (EnCase, FTK, X-Ways) expect, compresses well, embeds the case notes and checksums every chunk. Prefer it over raw when the image will be shared.

sudo apt install libewf-tools ewf-tools    # ewfacquire, ewfverify, ewfmount, ewfinfo

# Interactive (asks for case number, examiner, notes, compression, segment size)
sudo ewfacquire /dev/sdb

# Unattended
sudo ewfacquire -u -t /mnt/evidence/sdb -C CASE-042 -E 001 -e "DAEMON" \
     -D "Laptop SSD, Samsung 970, S/N ..." -N "Seized 2026-09-26 room 3" \
     -c best -S 4G -d sha256 -f encase6 /dev/sdb

ewfinfo   /mnt/evidence/sdb.E01           # metadata + stored hashes
ewfverify /mnt/evidence/sdb.E01           # recompute and compare
ewfexport -t /mnt/evidence/sdb.raw /mnt/evidence/sdb.E01   # back to raw when a tool needs it

Guymager (Linux GUI)

Pre-installed on SIFT/Kali/Tsurugi. Right-click the device → Acquire image → pick .dd or .E01, fill case fields, tick Calculate SHA-256 and Verify image after acquisition. It logs to a .info file next to the image. Fast, multithreaded, and the sanest option when a colleague has never used dd.

FTK Imager (Windows GUI + CLI)

The most common Windows imager. Free, runs from a USB (“FTK Imager Lite”), no install.

GUI: File → Create Disk Image → Physical Drive → select the suspect disk → Add destination → choose E01 (or Raw/dd) → fill Evidence Item Information → set fragment size (0 = single file) and compression (6 default) → tick Verify images after they are created → Start. The summary window at the end has the MD5/SHA1 — screenshot it and save the .txt log it writes next to the image.

Other jobs FTK Imager does that nothing else free does as easily:

:: FTK Imager CLI (ftkimager.exe, separate download) — image with verification
ftkimager.exe \\.\PhysicalDrive2 E:\evidence\pd2 --e01 --frag 4G --compress 6 ^
   --case-number CASE-042 --evidence-number 001 --examiner DAEMON ^
   --description "Dell laptop SSD" --verify

:: List physical drives
ftkimager.exe --list-drives

Live imaging (encrypted / cannot power off)

When BitLocker/LUKS/FileVault means a dead image is ciphertext, image the logical, unlocked volume while it is mounted, and accept that the image is not a perfect snapshot.

# Linux LUKS — image the mapped device, not the raw partition
sudo dc3dd if=/dev/mapper/luks-xxxx of=/mnt/evidence/root-decrypted.dd hash=sha256 log=root.log

:: Windows BitLocker — logical drive letter, plus grab the recovery key while you can
manage-bde -protectors -get C: > E:\evidence\bitlocker-keys.txt
ftkimager.exe C: E:\evidence\C-logical --e01 --verify

[!tip] Cloud and virtual machines VMs: snapshot, then copy the .vmdk/.vhdx/.qcow2 and the .vmem/.vmsn (that is the memory image). qemu-img convert -f vmdk -O raw disk.vmdk disk.raw gets you something every tool reads. Cloud: snapshot the volume (AWS create-snapshot, Azure az snapshot create), attach to a forensic instance in the same region, image from there — do not download 500 GB over the internet.

Hashing & verification

# Multiple algorithms in one pass (GNU coreutils 9+ or via hashdeep)
hashdeep -c md5,sha256 -e /mnt/evidence/sdb.dd > sdb.dd.hashes
# Verify later against that file
hashdeep -c md5,sha256 -a -k sdb.dd.hashes /mnt/evidence/sdb.dd

# Hash a split image as one stream
cat sdb.dd.0* | sha256sum

# Hash every file inside a mounted image (for a known-good/bad comparison later)
find /mnt/img -type f -exec sha256sum {} + > case-filehashes.txt

Get-FileHash E:\evidence\pd2.E01 -Algorithm SHA256
certutil -hashfile E:\evidence\pd2.E01 SHA256          # no PowerShell needed

[!info] MD5 is fine here MD5 collisions are a real cryptographic weakness but irrelevant to proving an image was not altered by accident. Courts and tools still use MD5+SHA1; adding SHA-256 costs nothing. Record all of them.

Mounting images for analysis (read-only, always)

# Raw image: find partition offsets, then mount one
sudo mmls sdb.dd                       # Sleuth Kit: sector offsets of each partition
sudo fdisk -l sdb.dd
sudo mount -o ro,loop,noexec,noload,offset=$((2048*512)) sdb.dd /mnt/img     # ext4 (noload = don't replay journal)
sudo mount -o ro,loop,noexec,show_sys_files,streams_interface=windows,offset=$((1050624*512)) sdb.dd /mnt/img   # NTFS via ntfs-3g, exposes $MFT and ADS
# Whole disk as block devices
sudo losetup -rfP --show sdb.dd        # → /dev/loop0, /dev/loop0p1, ... (-r read-only, -P scan partitions)
sudo mount -o ro,noexec /dev/loop0p2 /mnt/img
sudo losetup -d /dev/loop0

# E01: expose as raw first
sudo mkdir -p /mnt/ewf && sudo ewfmount sdb.E01 /mnt/ewf         # → /mnt/ewf/ewf1 (raw view)
sudo losetup -rfP --show /mnt/ewf/ewf1
# or xmount, which also fakes a writable overlay (cache file) so tools that insist on writing work
sudo xmount --in ewf sdb.E01 --out raw --cache /tmp/sdb.cache /mnt/xm

# LVM inside an image
sudo losetup -rfP --show sdb.dd && sudo vgscan && sudo vgchange -ay && lsblk
# Windows VSS shadow copies inside an NTFS image
sudo vshadowinfo /dev/loop0p2 && sudo vshadowmount /dev/loop0p2 /mnt/vss && ls /mnt/vss   # vss1, vss2 ...

# Windows: Arsenal Image Mounter (free, handles E01/raw/VHD, true disk-level mount so
# VSS and BitLocker-unlocked volumes behave). Mount → pick image → "Read only" → OK.
# FTK Imager: File → Image Mounting → Mount Type "Physical & Logical", Mount Method "Block Device / Read Only".
# Native for VHD/VHDX only:
Mount-DiskImage -ImagePath E:\evidence\disk.vhdx -Access ReadOnly

[!warning] ro is not a write blocker A read-only mount stops you writing; it does not stop a journaling filesystem replaying its journal on mount (hence noload on ext4), and it does not stop macOS Spotlight or Windows indexing from touching an image file you open in a GUI. Analyse copies of the image, keep the original hashed on a shelf.

Quick decision table

Next steps

• Windows image → EZ Tools & KAPE for parsing, Digital Forensics reference for what to look for, Registry (RECmd)
• Linux image → Linux forensics
• Memory image → Volatility 3
• Unknown files, unallocated space → strings & file triage
• Point-and-click review → GUI tools