Digital Forensics 101: Why dd and a Hash Beat cp When Imaging a Drive

Someone hands you a drive pulled from a machine that matters: a compromised server, a device relevant to an internal investigation, something that might end up in front of a tribunal. The instinct of most engineers is to plug it in and run cp -a /media/evidence /somewhere/safe or rsync -a. It feels thorough. It is also the wrong tool, and understanding exactly why teaches you most of what "forensically sound" actually means.

What a filesystem copy actually sees

cp, rsync, robocopy, all of them operate through the filesystem layer. They ask the kernel "give me the files that exist", and the kernel hands back whatever the filesystem's metadata currently points to. That's a narrower view of the disk than you might think:

• Deleted files whose data blocks haven't been overwritten yet are invisible. The directory entry is gone; the bytes are still sitting there.
• Slack space, the unused tail of a block allocated to a file that doesn't fill it, is never copied. That slack can contain fragments of a previous file's contents.
• Unallocated space between partitions or after the last partition is entirely outside the filesystem's view.
• Copying resets or rewrites metadata. Depending on the tool and flags, you can end up with new access times, altered permissions, or a completely different inode layout on the destination.

None of that is a flaw in cp. It's doing exactly what it's supposed to do: give you the current, live view of a filesystem. The problem is that "the current, live view" is not the same object as "the drive", and forensic work usually needs the drive, deleted data, slack space and all.

dd copies the device, not the filesystem

dd (and its more forensics-friendly cousins dcfldd and dc3dd) reads from a block device rather than a mounted filesystem. Point it at /dev/sdb instead of /mnt/sdb1 and it doesn't care what filesystem, or how many partitions, live on the disk. It reads every sector in order and writes them out identically, which is what "bit-for-bit" actually means: not "same files", but "same bytes, in the same positions, including the ones nothing currently claims".

sudo dd if=/dev/sdb of=/evidence/case042.img bs=4M conv=noerror,sync status=progress

A few flags matter more than they look:

• bs=4M sets a sensible block size. The dd default of 512 bytes is fine for correctness but glacial for throughput; something in the low megabytes balances speed against memory use.
• conv=noerror,sync is the one people forget and then regret. Without it, dd stops (or silently skips ahead) the moment it hits a bad sector. With it, a failed read is replaced with a block of zero bytes of the same length, so every byte after the fault stays at its correct offset in the output. Getting the offsets wrong turns your image into a plausible-looking pile of nothing.
• status=progress is just so you know it hasn't hung, on a 4TB drive this can run for hours.

If the drive is actually failing rather than just having a handful of bad sectors, reach for ddrescue instead. It reads the easy parts first, keeps a log of what it's recovered, and retries the damaged regions with shrinking read sizes rather than dd's fixed block size, which matters a lot when a drive is dying mid-image and you don't get a second attempt.

A write blocker, or the equivalent

None of the above helps if the act of imaging modifies the source. Mounting a filesystem read-write, even briefly, can update journal metadata or access times, which is itself a form of evidence contamination. A hardware write blocker sits between the drive and your machine and physically refuses write commands. If you don't have one, the software equivalent is mounting nothing at all (you don't need to mount the source to dd it) and, where you must interact with it, mounting read-only:

sudo mount -o ro,noload /dev/sdb1 /mnt/check

noload stops an ext journal replay from writing to the disk on mount, which is exactly the kind of "harmless" write that quietly changes the source before you've imaged it.

Hashing is the proof, not a formality

Copying bit-for-bit is the goal; a hash is how you demonstrate you hit it. Hash the source device and the resulting image and compare:

sudo sha256sum /dev/sdb
sha256sum /evidence/case042.img

Matching digests mean, to a probability so close to certain it isn't worth arguing about, that the image is an exact copy of the source at the moment of acquisition. This is the artefact that actually gets challenged later: if a defence expert or opposing party can show the hash of your working copy doesn't match the hash recorded at acquisition, the integrity of everything downstream is in question, regardless of how good your analysis was. MD5 is still common in forensic tooling for historical reasons, but there's no reason to choose it over SHA-256 for new work; both are adequate for detecting accidental corruption, and SHA-256 costs you nothing extra in practice.

Hash before you touch the image with any analysis tool, and hash again afterwards if you ever need to justify that your working copy stayed untouched. Some examiners also hash at the sector level in chunks, so that a single damaged sector doesn't invalidate the identification of everything else on the disk. dc3dd and dcfldd will compute the hash inline as they image, which saves a second full read of a large drive.

Raw images versus container formats

A raw dd image is just the bytes: portable, readable by anything, but it carries no metadata about the acquisition itself. Tools like EnCase's E01/Ex01 or the open AFF4 format wrap the raw data with case metadata, built-in hashing, and often compression. For casual internal work a raw image plus a separate hash file and a written log is usually enough; for anything that might go in front of a court, a format that bakes the chain-of-custody metadata into the evidence file itself is worth the extra tooling.

The paperwork is part of the process

None of the technical rigour above matters if you can't account for what happened to the drive between seizure and analysis. In England and Wales, forensic science providers (including digital forensics units) operate under a statutory Code of Practice from the Forensic Science Regulator, put on a legal footing by the Forensic Science Regulator Act 2021, which sets quality standards for exactly this kind of evidential handling. Whether or not you're operating under that specific regime, the underlying discipline is the same one it codifies: record who had physical possession of the drive and when, log the exact commands and hash values used to acquire the image, and never analyse the original media directly, work from a verified copy and keep the source untouched as your fallback if anything is ever disputed.

cp will get the job done if all you want is a backup. It's the wrong tool the moment "the job" is proving, later, to someone who wasn't in the room, that what you're looking at is exactly what was on the drive.