Different Calculate...
 
Notifications
Clear all

Different Calculated Hash in EnCase/FTK

8 Posts
7 Users
0 Likes
3,782 Views
one234
(@one234)
Posts: 16
Active Member
Topic starter
 

Hi everyone, again

Here is another bizarre problem I encountered with another case I got; I was provided with a disk image by my opposition team, which was transported to me in an encrypted hard disk. The person who copied the disk image ran a file integrity verification using EnCase 7 after the image is copied onto the disk and the calculated hash matched the stored hash.

Here comes a series of problems

1 - after I received the encrypted disk, I decrypted it and ran the image through a file integrity verification using EnCase 6. The calculated hash is different to the stored hash.

2 - I ran the image through another file integrity verification using FTK Imager 3.2, the calculated hash is different to the stored hash AND different to what's calculated by EnCase 6.

3 - I ran the image through another file integrity verification using EnCase 7, the calculated hash is different to the stored hash AND the same as what's calculated by EnCase 6.

I swear I did not make any changes to the disk image after I received them! If the three tools all came up with the same hash I'd think something gone wrong in the transportation process, but the fact that EnCase and FTK calculate different hash value is the awkward part… which indicates problems with the tool itself?

I wonder if anybody has come across similar situation or could suggestion an explanation as to what might be happening to this disk image!?

Thank you so much….

 
Posted : 04/03/2015 3:01 am
(@mkel2000)
Posts: 24
Eminent Member
 

It's possible that the encryption/decryption process (or the act of copying from the encrypted drive to a local drive) somehow effected one of the files that make up the image. I would suggest hashing each individual file that makes up the image and then asking the other side to do the same and provide you with the results from their copy of the image. Then I'd compare the two and see if one (or more) of the files on your end is different.

 
Posted : 05/03/2015 9:22 pm
(@wookieshaver)
Posts: 27
Eminent Member
 

As user mkel2000 suggests a hash/sig analysis from the opposing teams reports (prior to copying to the drive for encryption) may provide good results. However, I would be interested in how the original image was acquired (encase, encase portable, ftk imager, etc) and what steps were taken to write-block the original media and to write-block the media they used to store the image in processing the e01.

 
Posted : 17/03/2015 9:21 pm
jhup
 jhup
(@jhup)
Posts: 1442
Noble Member
 

What kind of encryption was used?

What was the image format (without the encryption - raw, E01, AFF, etc)?

 
Posted : 17/03/2015 10:59 pm
(@ccalderwood)
Posts: 2
New Member
 

We had this happen as well. Our colleagues in another country copied a DD to a hard drive, and then ran BitLocker over the hard drive. When hashing the DD file, the hash was no longer the same as the acquistion hash.

However, when they Bitlocked the drive first, and then copied the DD the hashes matched.

I'm still not entirely sure why the first method produced those results.

 
Posted : 18/03/2015 1:25 am
zoltandfw
(@zoltandfw)
Posts: 27
Eminent Member
 

Hash values are in general useless to find out where things have changed.

I would decrypt the drive image twice and verify the hash values like you have done before for both images. If they result in different values then you'll know the decryption process made changes. Then open both of the images in a hex editor, most editors provide a tool to compare the files and show you where the images do not match. Based on the results, you might find your answers and see if you can rely on the image after all.

The best case scenario would be to have access to the original image that verifies correctly and do the hex comparison or the decrypted image to the original image to locate the areas of discrepancies.

To further test the exact changes, you can also convert the decrypted images to raw image and compare them that way to see the clear data changes and you might find out that changes were not made in the relevant data area of the image.

Let us know how it goes.

Forensicate responsively …

 
Posted : 18/03/2015 6:10 pm
one234
(@one234)
Posts: 16
Active Member
Topic starter
 

Hello all. Firstly thank you all SO much for replying to my question. The deadline of this case was pressing so I had to halt my investigation with this and just asked for another copy of the whole disk image. Now I'm away from the office and away from my evidence disk image so hopefully when I return to the office in a month I can try all your suggestions out ))

This hash mismatch problem actually happened twice; the disk was encrypted with TrueCrypt and BitLocker, respectively.

The first disk contained the disk images for 4 drives. Two of them had hash mismatch issue and the rest didn't. The second disk contained only the disk image for 1 drive (one of the two faulty drives in the first disk) and some other files.

The disk image in question is roughly 12GB and has been broken down into 6 files, e01-e06.

The verification results of EnCase showed that the failure occurred on the 'e06' file (i.e. the last file of the series) both of the times, at different sectors though.

According to the opposition acquisition report, they used an EnCase hardware duplicator to perform the acquisition, and had the same acquisition and verification hash, which is the same value my disk image has as acquisition hash.

 
Posted : 20/03/2015 1:20 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

OT 😯 , but not much, the idea of adding a more granular (simpler) hashing function has been thought about, and I personally find it a very good idea, with the every day growing of disk sizes.
See here
http//www.forensicfocus.com/Forums/viewtopic/t=11739/

Or we could think of something similar to .par files. ?

Even if we do not believe too much to the kind of calculations made in the (maybe a tadbit too alarmist) articles here
http//www.zdnet.com/article/why-raid-5-stops-working-in-2009/
http//www.zdnet.com/article/has-raid5-stopped-working/
it seems like the growth of disk size is incrementing hash mismatching (or however transfer/storage errors).

@mkel2000
Hashing the single files is of little help (besides most probably taking ages to be performed) as each of the "segment" is anyway very large, it is good to find which of the files composing the image has gone bad, but nothing more, if there was a more granular kind of check one could replace - say - 1000 sectors of the image, something that can be sent via e-mail or similar.

jaclaz

 
Posted : 20/03/2015 3:24 pm
Share: