I have a laptop hard drive for which Encase and FTK produces different hashes. I hashed it with Encase first, and then hashed it with FTK to check. The results are different. No hardware changed during two different hashing process. I repeated the whole process from the beginning again and again, however hashes are different.
2 bad sectors reported during the hashing in FTK and Encase
FTK says
The following sector(s) on the source drive could not be read
21824412
21952827
The contents of these sectors were replaced with zeros in the image.
—————–
Encase reports it as follows
Status Completed
Start 07/01/11 093044
Stop 07/01/11 095003
Time 01919
Start Sector 0
Stop Sector 39.070.079
Hash Value F7C2436A927E2BFDC24C6E5C6DEE941D
Read errors 2
Comment The hash value may not be accurate
————————————————————-
So, which one is correct ?
And if both Encase and FTK can not read the same bad sectors, why do they produce different hash values?
Sorry to ask something so basic, but are they both configured to create the same kind of hash? I believe FTK can do MD5 or SHA1 hashes - I'm not sure about Encase.
If they are both configured to generate the same kind of hash as output, then it appears that the error handling routines in each are different. FTK tells you explicitly that it has replaced bad sectors with zeros but Encase has only reported read errors, not what it has actually done in response to those errors.
Also, is EnCase set to Error Granularity 1? If it is not, the default value is 64 - meaning it has zero'd 2 x 64 sectors. This may account for the discrepancy.
Furthermore, which sectors does EnCase say are the unreadable ones?
So, which one is correct ?
For what purpose? What are you expecting? Particularly since the drive is faulty – that means that the error handling of both tools must be identical. And there's really no good reason for it to be.
If you want to double-check tool A against tool B, create a drive image with both tools, get it into a neutral format, like DD, hash both, and then compare sector by sector.
And if both Encase and FTK can not read the same bad sectors, why do they produce different hash values?
Because they behave differently in the presence of errors?
FTK clearly says that two identified sectors were replaced with zero.
What sectors did EnCase find faulty, and how did it react to them? The only EnCase reaction I can recall off the top of my head is the 'skip 64 sectors, zero out the corresponding data, and continue', but that's what is done on imaging. Is that what happened in your case?
Just in the unlikely case there may be some bugs involved, you probably want to ask tech support for each of the products.
Both Hashes are correct (but both tools are computing hash for different data), try to check “error granularity” in Encase.. is it the same as in FTK? (in EnCase it’s default set to wipe 64 sectors in case of read error found. In FTK this value can be different that is why you have different input data and different hashes)
Hope it help
Try both tools on a (small) drive without errors.
Also, if you know where the failed sectors are, can you see what data each tool has written to these sectors. I expect the 'padded' sectors may be different, and with hahsing, any single bit change will result in a completely different hash.