md5 hash problem on acquiring a hard disk

1) check the output of 'dmesg' after/during the run and check that there are no errors coming from either drive

2) If there are no errors, try a different ide/usb cable or hook your drive to be imaged directly to the motherboard.

We don't use ddrescue unless we known a drive is damaged. otherwise we use dcfldd as it can hash while imaging and has a progress bar

good, thank you.

I tried dcfldd but only got one hash as a result, in the log file. The obtained hash is still different from a "md5sum /dev/sdc" though -/

I note you initially used ddrescue, is this a standard acquisition or is the disc actually damaged or failing?

Does rehashing /dev/sdc produce the same hash repeatedly, or is it different every time?

Also, does the hash that results from ddrescue match the hash that results from dcfldd?

Ben

Hi Ben,

I used ddrescue by default because I wanted to gain some time, the hard drive seems to be good (no error reported by ddrescue). (standard acquisition)

The hash of the image done with dcfldd I get is different than the hash of the drive (calculated by md5sum)

I will try to rehash the disk drive again, to check that the result is the same every time.

Thank you.

The returned MD5 hashes are different. My question is, is that a normal behaviour ?

You should inquire into the reason for the discrepancy, and if it is due to a faulty source drive, do the best you can. Otherwise, replace the faulty component. You need to have some hardware and software troubleshooting skills for this you need to know what you are doing.

How would you acquire a disk in a way to be sure the hash will be the same ?

Trusted acquiry software, trusted write blocker, trusted acquiry platform, etc. If that setup produces an acquiry problem, make sure the problem is with the source drive. Anything else is your responsibility to fix.

You don't say what parts of the acquiry you are confident about the source disk is probably out of the question, but what about the disk interface(s), the power supply, primary memory, the devices drivers, and the acquiry software. And the md5sum software. Do you know that it does the job correctly from previous tests? And what about the target drive – if that's faulty, you can look for errors elsewhere until you're blue in the face.

I assume you verified that there were no platform errors in the system logs before you started the acquiry or during? Errors from drivers, for example?

I would have guessed that if ddrescue returns 0 errors, the destination should be exactly the same ?

In theory. In real life, there are glitches, minor or major. For example, faulty memory can give you problems. On a trusted platform, you know when you last tested that primary memory was working. Faulty power supplies or power feeds are other occasionally non-obvious sources of problems.

Did you read the ddrescue documentation? What command line options did you use? What does the logfile say?

Should I maybe use "dd" instead of "ddrescue"?

Do you think that would have improved things? Don't make modifications to your setup without reason if things still fail, you should at least have made some kind of progress, for example by eliminiating a possible source of error.

In the case of a damaged disk (bad sectors/blocks) how do you proceed when you need to confirm that the destination is the same as the source ?

You can't. If the source drive is bad, you must deal with it. My first concern would be the IDE/USB thingy – if you don't know that it is working OK from previous experience, test it on another drive (of the same size) to verify that it is working as you expect.

Apart from that, and other 'trusted platform problems', I'd do two separate images, and then compare them bit by bit. If the mismatches are limited to a few sectors, it's likely to be a disk error those sectors should be treated carefully in the analysis. I might do a third acquiry splitting the drive into smaller sections, recomparing against the previous two, and verifying checksums for each such part.

If the errors repeat over and over in each sector or group of sectors, it's a different type of error – I'd have a chat with a hard drive expert. Might need to change drive electronics.

Actually, there are methods to hash and verify even damaged drives.

Look into 3-dimension hashing for entertainment purposes. It is in the same line as fuzzy hashing…

For real-life use, hash each sector individually and compare those against the image sectors. Damaged sectors are abandoned.

What you will get is not just the list of matching sectors, but also a clearer picture where the original drive is damaged.

presumption you imaged the evidence several times, and the resulting image is always producing the same hash. If this is not the case then there is borderline sectors, or flaky link from sector to your machine (controller, cable, write blocker, rodent infestation, etc.)

Also consider faulty RAM if your source hash isn't the same every time.

Fortunately, faulty RAM is very easy to test for. If you're consistently getting DD problem, just DD the image file to a second image file and see if they're different. (Sure, sure, you could also run Memtest…)

Unless it is overheating controller(s), a flaky cable, a borderline faulty write blocker, or that stink bug stuck behind the eSATA port… even worse - two or more of these…

That is, much of these faults are introduced at an intermittent and unpredictable way. mrgreen

Fortunately, faulty RAM is very easy to test for. If you're consistently getting DD problem, just DD the image file to a second image file and see if they're different. (Sure, sure, you could also run Memtest…)