Tool Guide · acquisition

Acquisition: dd & dcfldd

Why imaging matters

Acquisition is where integrity is won or lost. The goal is a byte-for-byte, hash-verified copy of the evidence that you can analyze without ever touching the original. If the image doesn't hash-match, everything downstream is moot.

dd basics

dd is the classic low-level copy tool. Always use it on the device, never mounted filesystems, and always specify block size explicitly.

# image the whole disk to a raw file
dd if=/dev/sda of=/mnt/evidence/sda.dd bs=4M conv=noerror,sync status=progress

# conv=noerror   -> keep going past read errors
# conv=sync      -> pad bad sectors so offsets stay aligned

# image a single partition
dd if=/dev/sda1 of=/mnt/evidence/sda1.dd bs=4M conv=noerror,sync status=progress

# image over the network (evidence goes straight to your workstation)
dd if=/dev/sda bs=4M conv=noerror,sync | ssh forensic@192.168.1.10 "cat > /evidence/sda.dd"
Read errors noerror,sync is non-negotiable. Without it, dd aborts on the first bad sector and you silently lose everything after it. With it, bad blocks are zero-filled and offsets remain accurate — essential for carving and timelines.

dcfldd: hashing on the fly

dcfldd is a dd fork designed for forensics: it computes multiple hashes while copying and reports progress in bytes, not blocks.

# Debian/Ubuntu
apt install dcfldd

# image while hashing MD5 + SHA-256 simultaneously
dcfldd if=/dev/sda of=/mnt/evidence/sda.dd bs=4M \
    hash=md5,sha256 hashlog=/mnt/evidence/sda.dd.hashlog \
    status=on

# watch the progress / read the hashlog
cat /mnt/evidence/sda.dd.hashlog
  MD5 (input):    4b31a97b8d3a5e9c6f1d...
  SHA256 (input): d0f2c8a2e9b1...   # matches original if verified

# also send the same data to TWO files (redundancy)
dcfldd if=/dev/sda of=/mnt/ev1/sda.dd of=/mnt/ev2/sda.dd bs=4M hash=sha256 hashlog=ev.hashes

Write blockers & read-only discipline

A hardware write blocker physically prevents any write to the evidence drive. Software options also exist but only protect against kernel-level writes — the drive itself still sees your reads (which is unavoidable and acceptable).

# re-read-only a block device if you must connect it directly
blockdev --setro /dev/sdb
blockdev --getro /dev/sdb     # should print 1

# never mount it - mounting writes journal/metadata even 'ro'

Verifying images

# hash the original device (record this)
sha256sum /dev/sda > /mnt/evidence/original.sha256

# hash the image you made
sha256sum /mnt/evidence/sda.dd > /mnt/evidence/image.sha256

# compare - they must be identical
diff original.sha256 image.sha256
  0           # no output = match

# read-only verification afterwards, any time
sha256sum -c image.sha256

Imaging memory

Same discipline, different source. Memory capture always happens on the live system:

# LiME module writes a self-describing dump
insmod lime-$(uname -r).ko "path=/mnt/evidence/ram.lime format=lime"
sha256sum /mnt/evidence/ram.lime

# or raw via /dev/mem (often restricted; LiME preferred)
dd if=/dev/mem of=/mnt/evidence/ram.mem bs=1M status=progress

← Previous: Volatility  ·  Next: File Carving →