Hi,
I have a strange situation where I am acquiring an external hard disk image using dcfldd. I set dcfldd to compute the md5 hash (hash A) on the fly. I then confirm this md5 by running md5deep on the generated image file and they match. However, when I then run md5deep directly against the external hard disk (/dev/sdb), it gives me a different value (hash B). This new value (has B) is also the same as the one that I get when I run md5sum on the external hard disk. The device is an external hard disk connected via a USB / SATA / PATA bridge and is never mounted. I'm currently using the CAINE linux distribution. Any ideas? Thanks.
If the hash is different, then there has been a change - or you were not hashing the same area of the disk.
At this stage I would do a binary compare between the disk and the original image file. You will then need to work out why the change has occurred. A few bytes that are different, or a completely blank sector indicates a failing disk. A changed sector implies that the disk has been mounted.
Don't forget, a single bit change will result in a completely different MD5
Does the drive have HPA and/or DCO?
Greetings,
What sort of bridge are you using?
If you run dcfldd again, what hash do you get?
If you image the drive with some other tool, what happens?
Did dcfldd report any errors during the imaging?
*If* dcfldd had problems reading part of the drive, its error correction would account for the "hash A" values matching. md5sum would have handled the error differently, resulting in a different hash value.
-David
Many imaging tools, when they encounter a bad sector, will pad that bad sector with zeroes in the output, and that will be reflected in the hash. What is md5deep's behaviour on encountering a bad sector?
This is why I always use the same methodology for generating a hash as I use for reading data for acquisition to avoid differing behaviours between apps.
Thanks a lot for your replies. I figured out the problem (more details below).
The problem was a little tricky to figure out. I wanted to to mirror the hard drive and only had an NTFS partition to write to (couldn't format it to anything else because it had other data I needed as well). So I mounted the target partition using ntfs-3g and proceeded to use dcfldd to acquire the source hard disk drive. I wrote the image twice to a file on the NTFS partition and both times it gave me different MD5s. The md5 of the source never changed regardless of the tool used (md5sum, md5deep, etc.) When I was able to finally dcfldd the source hard disk drive to an ext3 partition, it gave me the same md5 as the original drive gave me. I'm therefore 99% confident that the source of the issue either in the FUSE stack or the ntfs-3g driver. Anyway, my problem's been solved. Thanks for your help )
Greetings,
Well done, and thank you for the follow up so we're all better educated.
As a gentle reminder, if you'd told us more about the environment you were working in initially rather than in the summary, we might have been able to help you a bit more quickly and efficiently.
-David
Thanks David. I'll be sure to include more details in my original post in future posts. By the way, is the FUSE / NTFS-3G issue a known issue? Thanks.
Greetings,
I don't know exactly what issue you ran into with FUSE/NTFS-3G but they've only recently gone "prime time" and I'd not have tried using them without validating them first, or at least suspecting that there might be an issue with them.
I am sure that many people would appreciate it if you could do more research and pin down the exact problem.
-David