"mscotgrove" posted a very helpful link (http//
I was imaging a 30GB drive from a older Dell laptop. Being new to forensics, and having essentially no budget to work with, I elected to use Guymager on the DEFT Linux live CD. But before doing the acquisition, I performed a quick MD5/SHA1 hash of the drive using a utility called "DHash2" which comes on the DEFT CD. I took note of the MD5/SHA and proceeded to acquire using Guymager.
When I returned, to my surprise, it had a red indicator which informed me that there was an MD5 mismatch. I ran another MD5/SHA using DHash2, and it returned a different result!
Confused, I attempted to run another Guymager acquisition. Then I ran an MD5 on the resulting *.dd file. The MD5 was different from ALL of the previous MD5's I had run before!
At this point, I became paranoid that I was somehow altering the original drive. So, I spent the next several hours testing and re-testing my methods using a ~162MB hard drive that I had scanned with SpinRite (level 5!) and was in perfect condition. As it turns out, my methods were perfectly sound. My MD5's matched every time using all of my previous methods.
So, how could the MD5 change every time I re-hashed the drive? Could it be that bad sectors can cause the drive to hash to change? If so, then how can anyone say for certain what the original hash of the drive is? And, if I use a utility like dd_rescue or dd_rhelp which can skip over certain sectors and zero them out – then which has becomes the "original" hash? It must be the hash of the *.dd file, because it would be impossible to actually acquire a hash from the original source. Right?
Given the above, how could I then explain in court that my MD5 is worth anything, since it can never match the "original"?
How do you guys work around these issues?
With this 30GB Dell drive, I used the Windows write-block reg flip and imaged it using Macrium Reflect…which was able to make a successful image. Unfortunately, the hash checksum it generates is not viewable as it is a proprietary file. I figure that's fine, because, it won't match the original drive anyway!
Thoughts?
–
Another drive I began imaging – after a few seconds it began making three "click" sounds in succession, followed by a pause, then three clicks again. dd_rescue and dd_rhelp did absolutely no good. This clicking issue would lock up the entire OS and would only let up if I unplugged the drive completely. With a drive like this, it would seem that the only way to acquire it is to do so partially.
In the end, with this drive, I ended up simply copying crucial data folders off of it in Windows (using the write block regkey). Again, I figure it doesn't matter since I can't make a forensically sound image of it that will have matching hash values.
I would be very curious as to how you folks deal with these kinds of issues and explain them to a jury.
Thank you very much!
-Samuel
Old drives can fail, and produce different results with different reads. As you say, some programs (as mine does too) will skip bad sectors and pad the data.
A single bit different anywhere in a disk image will produce a completely different hash value. If you want to know what is different you will have to compare the two files. You may find that it is just one byte, or one sector that is different. This can be noted. The main idea of a Hash value is to say tha two files are indentical, and it is all or nothing. You may find that saying that sectors are degrading, and you have some that are different will be fine - ideally you will try and indicate what errors that may produce. Also location of sectors, and which files they are in.
For your second disk, a clicking disk does indicate a physical problem. This is where sometimes the incremental imaging can be used to select certain areas of the disk to copy, and skip sectors that are causing the PC to crash. Other tips that may help is to use a different USB / eSata adapter. Be warned that the disk could die totally at any time and if important should be given to a hardware specialist for possible head replacement/repair.
The point were a hash value is most important is when the final image has been created and passed on for further investigation. This image should be hashed as that is the evidence you are producing. Your logs will say how you got there, and the hash will make sure nobody changes it later (without being detected).
Thanks for reading my wall-of-text! I really appreciate your insights tremendously.
A few more questions…
- What software are you using?
- What program would you recommend for finding the differences between two files?
- How could I identify what files are affected by what bad sectors?
- What program do you use for incremental imaging? (the one from the link?)
You say that the hash is most important when the final image has been created and passed on for investigation. So, then, I shouldn't be too concerned about acquiring a hash of the source drive if it is entirely impossible (as it was with the two situations I provided)?
I ask because I imagine someone in court asking the question "If there is no hash of the original drive, how can we be certain that you haven't omitted some data on purpose?" – or something to that effect. It would seem that without having a hash of the original drive, that any evidence uncovered during the examination is weakened.
Perhaps I should make a habit of recording a video of my acquisitions as a form of "insurance"? Or maybe I am being too paranoid.
One final thing – I like the EnCase file format, however, I don't want to be "married" to EnCase. Is it possible to open an EnCase evidence file in many different forensic programs?
Thanks! =)
To your first question, all my work is with my own software.
I think there is a lot of missunderstanding about Hashing in certain circles. I get the impression that 'if you have a hash value, the data is correct'. All the hash value means is that the data has not changed since last hashed. It does not mean that the original image was correct or complete.
The most important aspect of any imaging is to log each process, som ideally someone else could repeat the process nd get the same results. However, with a failing disk, this may not happen. However, this is were a disk/file compare function can help highlight the area of change.
For simple compares I use the DOS fc command with the /b (binary option)
eg
c\fc /b <file1> <file2> | more
I am sure there are many Windows / Linux programs to do it better.
For which files use which sectors, again I can only talk about my own software. I have a function in the log to search for a sector and it will say which file(s) it is found in. Multiple files when a file has been deleted, and space overwritten. Alternatively sort a log based on sector start - but you do need to allow for fragmented files.
I would not be too worried about Encase E01 format. It is well enough established to be around in many years time. Other programs also read .E01 files. I do know that if it can be used to create an incremental image as I often do with badly damaged disks .
Michael, thank you very much for pointing out the "fc" command! That's exactly what I needed, some kind of differencing utility in DOS. Wonderful.
As for misunderstandings about hashing – my only concern is that if the MD5 changes on the original, then I am unable to tell the jury what the original is. In all of the books I've read, it seems that nobody has explained how to deal with a damaged original drive with a shifting MD5. They seem to take for granted that every drive is going to somehow hash perfectly.
So, as long as I clearly document, essentially, "the MD5 changed numerous times, therefore, re-acquiring/hashing may result in slightly different bits/sectors" – I should be OK?
I'd imagine so, since, there's not much anyone can do about a failing drive.