I am a student studying computer forensics, I ran a file in RAW format through FTK and created a MD5 hash, I then used the original file to created files with with SMART and 0E1 extensions, and created an MD5 hash for those files, as well. The MD5 hash for all three files were the same when I used FTK. When I used Chaos to create the MD5 hash, of course these hash values were unique. My question is why is FTK giving the same hash value to all three files. Undoubtedly, the files contents were the same in all three files, but shouldn't they have a distinct hash value, as well.
I don't know if I understood it properly, but I think it is easy to explain it for the case of just raw vs encase.if you calculate the hash for the physical files themselves,the hash will be different because the e01 is somehow packed with headers and stuff.
On the other hand if you calculate the hashes on the open or parsed files,since the ACTUAL contents will be the same,the hashes will also be the same.
Was it the question?
I apologize for not making the question clearer. Yes, that does help answer the question. I think specifically, I am looking to answer the question of "why does FTK not generate a different MD5 hash for the three different file types, RAW, SMART, E01… when the copies of one file are saved in the three different formats? I looked at the FTK manual and I think the program is designed to create the MD5 prior to converting the file to a specific file type. I am not sure of this, but that might explain why FTK gives the same hash for the three different file types created from one file. Thank you for answering my post and giving your input.
Greetings,
I believe the answer is that FTK is calculating the hash on the file each time and, correctly, coming up with the same value. How it stores the resulting image shouldn't matter - RAW, SMART, and E01 are just different containers for the image.
-David
I don't know if I understood it properly, but I think it is easy to explain it for the case of just raw vs encase.if you calculate the hash for the physical files themselves,the hash will be different because the e01 is somehow packed with headers and stuff.
E01 files do not include the Acquisition header in their MD5 hash. The hash is done on the evidence only.
"why does FTK not generate a different MD5 hash for the three different file types, RAW, SMART, E01… when the copies of one file are saved in the three different formats?
You just answered your own question, to be honest.
Remember, MD5 hashes a computation that takes a variable length input and returns a fixed-length cryptographic "hash". Take an arbitrary file, generate a hash, and then file a single bit in the file from a 1 to a 0 and you'll get a different hash.
I'm not sure about the SMART format, but I do know that there is extra data added to an .E0x format image beyond just the raw format; if memory serves, there's some CRC information, etc. So you're not actually hashing the *same* file if you hash the raw format file and then the EWF/.E01 format file.
HTH
I think everyone else has answered it, but just to phrase it a different way.
FTK understands (or correctly interprets) the .E01 format, despite there being CRC information throughout the file it hashes only the 'evidence', or data between those CRC bands. By design it is a robust format for storing an image with error checking capabilities embedded. Therefore when you hash in EnCase or FTK you are not hasing the evidence file, rather a hash of the acquired image contained within that file.
Think of it as putting the bloody gloves in an evidence bag and writing on it. That bag and what you write are now associated with the gloves at all stages of the investigation from then on. This is what you are doing when you create an .E01 file, it is slightly more than just an image, but the extra stuff is ignored when you need to prove continuity (ie Hashing).