e01 files, get a copy of EnCase (without the dongle all you have is Acquisition Mode), and see what EnCase verifies the hash to be. I think maybe it's just not totally clear which files, folders, images, or drives you are hashing for each iteration.Īlso, just as a double check, have you considered hashing the entire drive with something other than FTK? After you create the. If you are hashing those files, or a separate folder of those files, you will not end up with the same hash (please don't take offense, just making sure we're on the same page).Įven though I'm very familiar with FTK Imager, I've never run into this problem with different hash values. e01 images incorporate metadata within each section of data, which includes the CRC32 checksum, as well as other information used to identify that specific section of the image. To elaborate - exactly which files are you hashing? The. Http// I'm not sure what you're seeing with different hashes.
#PRODISCOVER BASIC CHECKSUM HOW TO#
This is a pretty good run through of how to do it - it may change a little based on the windows version you are using (this example is XP) If you don't have a write block and are using USB, you can go into the registry and change the key to software-write-block your USB ports Without it the device makes changes almost every single time it is connected to something. So, I then deleted the entire compressed E01 images and re-ran the imager, and again, mismatchĬould this be a failure of the hardware somehow? This is entirely mysterious.Īre you using a write block device? This is imperative in getting the same hash every single time. I ran a command to simply hash the source evidence drive, to see if maybe it had changed for some reason. In this case, I'm not even sure if it re-computed the original hash of the source drive, since I didn't tell it to. So, I then ran a command to just re-verify the compressed E01 imagesĪgain, the "computed hash" is different. So, since the "image hash" matches the original hash that was successful – how could ftkimager write out a perfect image, yet "compute" the hash "incorrectly"? Image hash seems pretty self-explanatory. I'm not sure what the difference between "computed hash" and "report hash" is. Once it completed, ftkimager reported a mismatch So, I decided to run it again using compression to another target drive I formatted, that way I figure I could burn them to DVDs or something.
I imaged it initially with no compression to E01 images to a brand new 500GB drive with no problems – complete match on the hashes (SHA …66d22). Here's the situation evidence drive is a 250GB laptop HDD. Specifically with using AccessData's ftkimager Linux commandline tool for imaging drives.
0 kommentar(er)
