Can You Trust a Forensic Image from a Failing Disk?

A forensic image can hash perfectly and still be missing the evidence you care about. The hash proves that your image file has not changed since it was created, but it does not prove that every byte on a failing disk was read correctly, or read at all.

That sounds obvious when written down. It is surprisingly easy to lose sight of it when a tool prints "finished" and produces a reassuring SHA-256 value.

The hash answers a smaller question than you think

An image hash proves the image's current bytes. If you calculate SHA-256 over evidence.img, you can later show that the file is the same file. That is useful for chain of custody, repeatable analysis and detecting accidental modification.

It does not prove that evidence.img matches the original medium. For a healthy disk, a complete read followed by verification may give you that confidence. For a failing disk, unreadable sectors, controller errors, unstable heads or a disappearing USB bridge make the comparison less straightforward.

There is a second wrinkle. A damaged device may return an error today and readable data tomorrow, or return different data after repeated attempts. A single successful read is not automatically the true value. It is merely the value the device supplied during that read.

Why ordinary dd is the wrong first move

Do not make the failing disk endure a full, linear retry battle. A simple command such as dd if=/dev/sdX of=evidence.img is fine for copying a healthy device. It is a poor recovery strategy when one bad region can stop progress for a long time or cause the kernel to retry the same request repeatedly.

Adding conv=noerror,sync tells GNU dd to continue and pad failed input blocks. That may produce an image-shaped file, but it gives you much less useful recovery state. You need to know which areas failed, whether the output contains padding, and which parts can be revisited later.

Quick detour: dd is not a forensic magic word. The name comes from an old Unix utility convention, not from "disk duplication". The important property here is controlled, documented acquisition, not the choice of a command with two letters.

Use a mapfile to preserve what happened

GNU ddrescue is designed for this situation. Its mapfile records the state of regions as it works, so you can stop, resume, change tactics and retain a record of the areas that remain unreadable. The GNU manual explicitly recommends using a mapfile because without one a new run has to start again.

A cautious first pass usually prioritises readable data and avoids spending all the drive's remaining life on difficult sectors:

sudo ddrescue --no-scrape -n /dev/sdX evidence.img evidence.map

After that pass, you can decide whether more retries are justified. A later pass might use direct reads and a bounded number of retries:

sudo ddrescue --direct --retry-passes=3 /dev/sdX evidence.img evidence.map

Check the tool's output and manual for your installed version. Recovery work is not the place to paste a command blindly, particularly when the output argument is a device rather than a regular file.

The mapfile is part of the acquisition record. Keep it beside the image, preserve its timestamps, hash it, and record the ddrescue version, source identifier, destination filesystem and command lines. The image without its recovery map tells only half the story.

A missing sector is not the same as a zero sector

If ddrescue creates a new regular image file, areas that remain marked as bad are normally represented by zeros. That is convenient for analysis, but zeros are still data in the image. They are not proof that the source contained zeros.

The distinction matters for filesystems, partition tables and allocated records. A zero-filled unreadable sector can make a structure look clean, remove part of a deleted file, or turn an unknown value into something an examiner accidentally treats as intentional.

There is a particularly nasty variant: if the destination file already exists, ddrescue can leave failed areas containing whatever was already there. Never confuse padding with recovered content. Use a fresh destination, or document exactly how pre-existing bytes were handled.

Record completeness separately from integrity

Two properties are often collapsed into the word "verified":

• Integrity: the image has not changed since acquisition.
• Completeness: the image represents every source byte needed for the question being asked.
• Consistency: repeated reads of difficult regions produced compatible results.

A SHA-256 digest is excellent evidence for the first property. The mapfile, error count and acquisition notes speak to the second. Repeated targeted reads, tool logs and independent acquisition attempts may help with the third.

Hash the finished artefacts:

sha256sum evidence.img evidence.map > evidence.sha256
sha256sum --check evidence.sha256

Do not write "the original disk was verified" unless you actually had a way to read and compare the original completely. A more accurate statement is: "The acquired image was hashed after acquisition; 12 MiB remained unreadable according to the mapfile." That sentence is less dramatic and much more useful.

Can you hash the source before imaging?

In an ideal acquisition, you might calculate a digest of the original medium and compare it with the image. NIST guidance discusses recording a message digest of the original media during bit-stream imaging, alongside write protection and acquisition records.

A failing disk may make that ideal procedure impossible. Reading the entire source once to calculate a hash is another complete pass over the device. It can waste time, trigger more failures and still produce no trustworthy baseline if the device returns errors or changes between reads.

For a disk that is already degrading, the defensible approach is usually to acquire the best image you can first, using a write blocker where appropriate, then hash the resulting image and preserve the rescue metadata. If the source can later be read again without unacceptable risk, compare selected regions or perform a second acquisition, but treat discrepancies as evidence to investigate, not as a reason to pick the nicer-looking copy.

Analyse the copy, not the patient

Once the first image exists, stop using the failing disk for ordinary analysis. Mount the image read-only, work from a verified duplicate, and keep the original image and mapfile untouched.

It is tempting to run filesystem repair because the image will not mount. Resist that until you have preserved a pristine copy. Repair tools can alter metadata, and a damaged image may contain gaps that make repair results misleading anyway.

Quick detour: an image that will not mount is not necessarily a failed acquisition. The source filesystem may have been corrupt before the failure, the partition offset may be wrong, or the missing region may contain exactly the metadata needed for mounting. File carving and filesystem-aware tools can still extract useful material from a partial image.

What a credible report should say

Report the limits as prominently as the hash. Include the source device identity, acquisition date and time, write-blocking method, imaging tool and version, command options, image size, image hash, mapfile hash, unreadable ranges, retry policy and any power or connection interruptions.

Then state what those gaps mean for the actual finding. A missing region in unused space may not affect a search for a particular log file. A missing region in an encrypted volume, filesystem journal or partition metadata may make much broader conclusions unsafe.

The honest answer to "can this forensic image be trusted?" is therefore not yes or no. You can trust its hash as an integrity check. You can trust the documented bytes as the result of the acquisition process. You can trust conclusions only to the extent that the unreadable and unstable parts do not undermine the particular conclusion being made.

A failing disk does not offer certainty. It offers a shrinking window in which to collect evidence, plus a map of what the hardware refused to tell you. Keep both.