Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Forensic Downloads
· Forensics Feedback
· Forums
· Members List
· Statistics
· Surveys
· Top 10
· Topics
· Training Reviews
· Web Links
· Your Account

Our Membership

Latest: Sergioramos
New Today: 1
New Yesterday: 0
Overall: 29353

Computer Forensics
This is a free and open peer to peer medium for digital and computer forensics professionals and students. Please help us maintain it by contributing and perhaps linking to us from your own website.

Recent Posts

 A question for students and newbies
 E-DISCOVERY & DATA RECOVERY? WHICH ONE IS BETTER?
 Computer Forensic in e-commerce
 Computer Forensic as component in Information Security
 Small Business - Do You Prepared?

Computer Forensics World Forums


Pages Served
We received
51193797
page views since August 2004

Security Sources

FTC
OnGuard Online
ISO 17799 ISO 27001
ISO 27000 Toolkit
ISO 27001 & 27000
Cryptography
Security Policies

Computer Forensics World: Forums

Computer Forensics World :: View topic - VMDK hash value abnormality
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

VMDK hash value abnormality

 
Post new topic   Reply to topic    Computer Forensics World Forum Index -> General Computer Forensic Issues
View previous topic :: View next topic  
Author Message
GPewitt
Newbie
Newbie


Joined: Nov 16, 2016
Posts: 2

PostPosted: Thu Nov 17, 2016 6:34 am    Post subject: VMDK hash value abnormality Reply with quote

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.
Back to top
View user's profile
PreferredUser
Newbie
Newbie


Joined: Jan 01, 2007
Posts: 1130
Location: USA

PostPosted: Mon Nov 21, 2016 1:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile
GPewitt
Newbie
Newbie


Joined: Nov 16, 2016
Posts: 2

PostPosted: Wed Nov 23, 2016 11:48 am    Post subject: Reply with quote

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.
Back to top
View user's profile
SgtJackie
Newbie
Newbie


Joined: Dec 01, 2015
Posts: 19
Location: Aberdeen, Scotland

PostPosted: Fri Nov 25, 2016 12:30 am    Post subject: Reply with quote

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!
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    Computer Forensics World Forum Index -> General Computer Forensic Issues All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.10 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

TMs property of their respective owner. Comments property of posters. 2007 Computer Forensics Science World.
Digital forensic computing news syndication: Computer Forensics Training News or UM Text
Software is copyrighted phpnuke.org (c)2003, and is free under licence agreement. All Rights Are Reserved.