In the previous posts we have looked at the ability to run test and validation workstations as well as a forensic examination workstations within VMWare Workstation. The ability to map a drive from within the virtual forensic examination system to directly access the VMDK files of the test workstations was also discussed previously.
During past tests of the direct access to the VMDK files I had only added them directly to Autopsy 4.1.1 and not attempted to create a clone or verify the hash values for the VMDK files. In doing some testing utilizing FTK imager it was quickly discovered that FTK Imager does not show the mapped drive as an option when adding evidence. The screen shots below show the shared folder containing the VMDK files for the other virtual workstations mapped as drive Z: in windows explorer but missing from the FTK Imager drive listing.
A quick Google search provided an article published by Access Data with two options to allow FTK Imager to access these mapped drive locations. One being a link to a Microsoft article on how to modify the registry to allow mapped drives to be seen in other applications and the second option being to manually type in the UNC path to the destination rather than using the mapped drive.
I completed the steps in the Microsoft article to modify the registry of my examination workstation and after completing the required reboot was still unable to see the Z: drive within FTK imager. However, the other work around of utilizing the UNC path allowed successful access to the shared folder from within FTK Imager.
The UNC path utilized to access the shared folders in VMWare Workstation is \\vmware-host
In the screenshot below you can see the Shared Folder displayed after browsing to the \\vmware-host UNC path.
Entering this UNC path into FTK Imager after clicking Browse when adding evidence as an image file worked successfully and allowed me to utilize the Verify Drive/Image function within FTK Imager to compute the MD5 and SHA1 hash values of the VMDK file.
Additional investigation needs to be completed to determine why the modification of the registry did not resolve this issue, however, utilizing the UNC path to access the shared folders is easy enough and provides access to the VMDK files of the test and verification workstations.
Stay tuned for a post within the next few days outlining the results of the hash analysis of the VMDK files when accessing them directly through VMWare Workstation.