VMDK hash value abnormality


GPewitt

New Member
Nov 15, 2016
6
0
#1
I have run across some odd behavior when calculating the hash value of VMDK files that I am hoping someone can help me understand.

I have calculated the MD5 and SHA1 hash values of the VMDK file from the host system with the following programs, FTK Imager, DCFLDD, WinHex, Microsoft FCIV, NirSoft HashMyFiles. All programs report the same MD5 and SHA1 hash values with the exception of FTK Imager. FTK reports a completely different hash.

I then calculated the hash value again from a different virtual machine using the same programs and got the same results. All programs with the exception of FTK imager reported the same hash values. Please note that the hash values for all programs matched what the respective program returned when the hashes were calculated on the host workstation.

The only way that I can get FTK to return the same hash value as the other listed programs is to copy the VMDK file to a folder and then add the contents of the folder to FTK imager and then export the File Hash List from within FTK of the VMDK file.

I think this is telling me that FTK does something with the vmdk file when it is added as an image that the other programs are not. I have compared sector counts, partitions, etc. between what FTK shows and what is in the results file of DCFLDD and have not been able to detect any difference.

Can anyone shed any light on how FTK is handling the VMDK image differently or what I may be missing?

Thank you all for your time and any insight you may be willing to offer.
 
Dec 31, 2006
3,405
0
#2
You are describing the expected behavior of Imager. The hash of the image file, in your example VMDK, is different than the hash of the contents of the image file.

If you open Imager, select add evidence item, select Image File, and add your VMDK, you are adding the contents of the VMDK no different than adding an EWF or any other image file. When you select Verify Image you are calculating the hash of the "drive" within the image not the hash of the image file itself.

Your testing quite correctly showed this. When you added the contents of a folder and added the VMDK you calculated the hash value of the image file not the contents of the VMDK. I would imaging that you saw a marked speed difference as well with Imager appearing to be slower verifying the image than the other programs calculating the hash of just the VMDK.

You can perform the same test with any image file and see similar.
 

GPewitt

New Member
Nov 15, 2016
6
0
#3
Thank you for the reply. The point you made makes perfect sense and seem so simple now. It never occurred to me that FTK Imager was looking at the contents of the image file vs the other programs looking at the image file itself. I do appreciate the comment and will definitely sleep better understanding what I was seeing.
 

SgtJackie

New Member
Nov 30, 2015
58
0
#4
Ah! I have been following this thread in case somebody had a good explanation, and now I see that somebody has. It seems so obvious now that somebody has pointed it out. TY!
 

About us

  • Our community began in 2004. Since this time, we have grown to have over 29,000+ members within the DFIR & Cyber Security community.

    We are happy to announce that this forum is now under new ownership with the goal to once again become the main Digital Forensics Forum on the internet for DFIR, OSINT and Cyber Security.

    If you can think of ways to help us improve, please let us know.

    We pride ourselves on offering unbiased, critical discussion among people of all different backgrounds.

    We are working every day to make sure our community is one of the best.

Quick Navigation

User Menu