Forensic imaging with dd, dc3dd and dcfldd

Update (October 2026): fixed the dc3dd example. Current dc3dd releases (7.x) don’t accept dd’s bs= and progress= options: the hash log is set with hlog=, the sector size with ssz=, and the progress meter is shown by default. Thanks to Matthew Fleek for pointing it out in the comments.

This is a quick reference for creating a raw, bit-for-bit image of a drive with three command-line tools: the classic dd and two forks built for forensics, dc3dd and dcfldd. For a step-by-step walkthrough with dc3dd, see Drive acquisition with dc3dd.

In all the examples /dev/sdb is the source drive and /evidence/image.dd is the image file. Image the whole device (/dev/sdb) rather than a single partition (/dev/sdb1), so that you also capture the partition table and unallocated space. Always double-check the device name with lsblk or sudo fdisk -l, and use a write blocker on the source whenever you can.

dd

dd is the standard Unix utility to convert and copy files. It has no forensic features — no hashing, no logging — so you have to hash the source and the image yourself.

sudo dd if=/dev/sdb of=/evidence/image.dd bs=4096 conv=sync,noerror status=progress

• if=/dev/sdb — the source drive
• of=/evidence/image.dd — the output file
• bs=4096 — the block size. The default is 512 bytes; a larger block makes the copy much faster
• conv=sync,noerror — keep going on read errors and pad unreadable blocks with zeros, so that offsets in the image stay aligned with the source
• status=progress — show a progress meter (GNU dd)

Then compute the hashes of the source and of the image and check that they match:

sudo sha256sum /dev/sdb /evidence/image.dd

With conv=sync,noerror, a single bad sector zeroes out the whole block, so on a failing drive use a small block size or, better, a tool designed for damaged media such as ddrescue.

dc3dd

dc3dd is a patched version of GNU dd developed at the U.S. Department of Defense Cyber Crime Center (DC3) for forensic acquisition. It adds on-the-fly hashing, logging, split output, pattern wiping, a progress meter and verification.

sudo dc3dd if=/dev/sdb of=/evidence/image.dd hash=sha256 log=image.log hlog=hash.log

• if=/dev/sdb — the source drive
• of=/evidence/image.dd — the output file
• hash=sha256 — hash the data while copying. md5, sha1, sha256 and sha512 are supported; repeat the option to compute more than one
• log=image.log — log I/O statistics, diagnostics and hashes
• hlog=hash.log — also write the hashes to a separate file

Unlike dd, dc3dd shows a progress meter by default and, when reading from a device, writes zeros in place of bad sectors (use rec=off to stop at the first bad sector instead). There is no bs= option: if you need to force the sector size, use ssz=.

dcfldd

dcfldd, originally developed at the U.S. DoD Computer Forensics Laboratory, is another enhanced version of GNU dd. Compared with dd it adds:

• On-the-fly hashing of the data being copied, to ensure its integrity
• Status output with the amount of data transferred and the estimated time left
• Disk wipes, fast and with a known pattern
• Verification that a target drive is a bit-for-bit match of an input file or pattern
• Multiple outputs to several files or disks at the same time
• Split output, more configurable than the split command
• Piped output and logs, to send data and logs to other commands

sudo dcfldd if=/dev/sdb of=/evidence/image.dd bs=4096 conv=sync,noerror hash=sha256 hashconv=after hashlog=hash.log

• if=/dev/sdb — the source drive
• of=/evidence/image.dd — the output file
• bs=4096 — the block size. With bad sectors, the default (32 KiB) can produce an image with shifted data
• conv=sync,noerror — keep going on read errors, padding unreadable blocks with zeros
• hash=sha256 — on-the-fly hashing algorithm
• hashconv=after — hash the data as written to the image, including the zeros added for bad sectors
• hashlog=hash.log — save the hash to a file instead of printing it to stderr

For more dcfldd examples, with hashlog, split and verification, see this post: dcfldd command examples: hash, hashlog, split and verify.

Which one should you use?

Plain dd is fine for a quick copy on a system where nothing else is available, but hashing and documentation are up to you. For evidence acquisition prefer dc3dd or dcfldd: hashing and logging happen in the same pass, which saves time and gives you a record to attach to your report. For failing drives, start with ddrescue, which is designed to recover as much data as possible from damaged media.

Want numbers? In this post I measured the speed of the three tools and what happens to the image with bad sectors: dd vs dc3dd vs dcfldd: speed and reliability test.