./ftkimager hash mi...
 
Notifications
Clear all

./ftkimager hash mismatching

11 Posts
6 Users
0 Reactions
3,444 Views
Samuel1
(@samuel1)
Trusted Member
Joined: 14 years ago
Posts: 63
Topic starter  

Howdy everyone,

I am perplexed about something. Specifically with using AccessData's ftkimager Linux commandline tool for imaging drives.

Here's the situation evidence drive is a 250GB laptop HDD. 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). I archived the successful image.

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.

Once it completed, ftkimager reported a mismatch

Computed hash …c2263
Image hash …66d22
Report hash …66d22

I'm not sure what the difference between "computed hash" and "report hash" is. Image hash seems pretty self-explanatory. 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"?

So, I then ran a command to just re-verify the compressed E01 images

Computed hash …0cb20
Image hash …66d22
Report hash …66d22

Again, the "computed hash" is different. 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.

I ran a command to simply hash the source evidence drive, to see if maybe it had changed for some reason. It had not

Computed hash …66d22

So, I then deleted the entire compressed E01 images and re-ran the imager, and again, mismatch

Computed hash …0237a
Image hash …66d22
Report hash …66d22

Could this be a failure of the hardware somehow? This is entirely mysterious.

Thank you everyone!

arrow


   
Quote
mattdk
(@mattdk)
New Member
Joined: 13 years ago
Posts: 4
 

Sam,

Just a few thoughts and questions

Are you using a write block device? This is imperative in getting the same hash every single time. Without it the device makes changes almost every single time it is connected to something. 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

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)

http//www.google.com/url?url=http//accessdata.com/media/en_us/print/papers/wp.USB_Write_Protect.en_us.pdf&rct=j&sa=U&ei=JR89T6jIFKjL0QHEwIndBw&ved=0CD8QFjAE&q=usb+write-block+registry+location&usg=AFQjCNE8U1tndukhiH-Q037lzRjUumSwDw

I'm not sure what you're seeing with different hashes. To elaborate - exactly which files are you hashing? The .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. 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).

Even though I'm very familiar with FTK Imager, I've never run into this problem with different hash values. I think maybe it's just not totally clear which files, folders, images, or drives you are hashing for each iteration.

Also, just as a double check, have you considered hashing the entire drive with something other than FTK? After you create the .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. It may at least give you information about your original image to let you know whether it is a valid copy or not.

Keep me posted - I am interested in what you come up with.


   
ReplyQuote
Samuel1
(@samuel1)
Trusted Member
Joined: 14 years ago
Posts: 63
Topic starter  

Thanks for your response. I've discovered it is my hardware I cannot trust. And, this occurs in more than one of my external USB converters/enclosures. Do any of you recommend any specific brands that are more reliable?

I recorded and edited a quick video of me hashing a file, turning off and on the drive, then re-hashing and you can see it change

http//youtu.be/xoH0OvWTmWM

Any thoughts?

Thank you!


   
ReplyQuote
(@mscotgrove)
Prominent Member
Joined: 17 years ago
Posts: 940
 

You do not say if you are using a write blocker.

No write blocker and it is likely that the PC is updating a few bytes on the drive.

USB interfaces are normally very reliable.

Make two images (easiest if they are DD). Then do a binary compare and see which bytes are different


   
ReplyQuote
Samuel1
(@samuel1)
Trusted Member
Joined: 14 years ago
Posts: 63
Topic starter  

I am using software write-blocking, via the registry key. Regardless, the hashing software I am using with HashTab doesn't hash the metadata. Windows doesn't change the binary information of files on external devices unless you instruct it to do so. It certainly might change MAC times, but not the binary information.

Also, as I mentioned, it fails verification when used via any of my external devices – but not when I plug it directly into the motherboard of my trusted main system.

I think it's because all of my external devices were bought in China and don't have any decent QC to speak of.

Which is why I asked if there's any specific brands you guys trust for your forensic work. Thank you!


   
ReplyQuote
benfindlay
(@benfindlay)
Estimable Member
Joined: 16 years ago
Posts: 142
 

Have you rebooted after applying the Registry key write blocking? As I understand it, the Windows Vista & 7 registry keys do not work until the after system is restarted.

Ben


   
ReplyQuote
(@cults14)
Reputable Member
Joined: 17 years ago
Posts: 367
 

I've used USB_WriteBlock.exe on XP SP2 and W7 Enterprise SP1 and it appears to work on both without the need to re-boot.

If you enable write-blocking, and USB devices which were already connected will not be affected and will remain write-enabled. Similarly, if you have devices already attached with write-blocking enabled and then disable write-blocking, those devices will remain write-blocked.

FYI I haven't scientifically tested USB_WriteBlock.exe and don't use it for forensic work, only for ensuring that any fat-finger syndrome - or lack of concentration - doesn't wipe out a bunch of data I'd rather hang on to.

Cheers


   
ReplyQuote
ForensicRanger
(@forensicranger)
Estimable Member
Joined: 16 years ago
Posts: 122
 

Is there a reason you're not using a hardware write blocker rather than a software w/b?


   
ReplyQuote
(@cults14)
Reputable Member
Joined: 17 years ago
Posts: 367
 

Is there a reason you're not using a hardware write blocker rather than a software w/b?

If that was directed at me - convenience in non-critical scenarios

Cheers


   
ReplyQuote
Samuel1
(@samuel1)
Trusted Member
Joined: 14 years ago
Posts: 63
Topic starter  

Using a software write-blocker because there's no pressing need to pay $400+ for one presently when using Windows/Linux works okay if done properly after extensive testing.

Regardless, you guys are really getting off topic.

The issue is hashing a file. Assuming no metadata is hashed, the hash should be the same every single time, unless the hardware is faulty. I have determined definitively that it is indeed faulty hardware.

Under what circumstances have you ever seen Windows directly modify the data of a file on an external drive just by plugging it in?


   
ReplyQuote
Page 1 / 2
Share: