I. VMware 10
VMware 10 is the latest release, and it will affect how we mount E01s if we want to boot them in VMware. In my first post about booting E01 images, I explained that we had to mount them as physical disks (logical, too, if wanted). The process involved the following steps:
- Mount the E01 image in FTK Imager (or similar tool).
- Create a VMware machine by selecting the mounted physical disk.
- Edit the vmx file to change rawDisk to Disk.
- Take a snapshot.
- Map the disk in VMware as writable.
- Edit the registry and strip passwords.
Well, Step 5 isn’t possible at this point. If you try to map the disk as writable, VMware will present the message in the following screenshot.
If you open the disk as read-only, it will map fine, but we will not be able to do any editing. All is not lost. Simply be sure to use FTK Imager to mount your disk as writable, so that it will cache edits. Moreover, as we want to effect edits on a logical volume, be sure to have FTK Imager mount both the physical disk and logical volume. Heretofore, we needed to mount only the physical disk. Then create your VM as usual, but omit mapping the disk in VMware. Although FTK Imager will discard the edits that you made to the mounted image when you unmount it, those changes will persist in your VMware snapshot.
Of course, you must remount the image whenever you want to access it in VMware. One thing to remember is that, if you remount your image in FTK Imager, be sure that your drive number remains the same as the original, or you must edit your vmdk file to match the new number, Drive 7 in the example below. Your vmdk file will include a line like this, based on the screenshot that follows:
RW 488397168 FLAT “\\.\PhysicalDrive7″ 0
Doing things this way was something that we always could have done. It just wasn’t my practice, and I almost never use an E01 as my working image file. Even with a split DD image, you may fine mounting preferable to creating a vmdk file with all of the extents.
VMware never officially supported mapping physical disks as writable, and evidently patched Version 10 to prevent us from doing so, until we figure out a hack. If I come up with one that allows writable physical disks, I’ll post back. According to the VMware tech with whom I spoke, the issue was that too many users were damaging real media, i.e., real disks. Actually, VMware also discourages users from snapshotting physical disks, and we get around that by editing the vmx file. However, there also is a command line tool named vmrun in your VMware\VMware Workstation folder, and you always could have used that to create a snapshot of a physical disk. As we have a simple method already, I won’t demonstrate vmrun.
II. Error Messages
Okay, if we’ve used mounted images for any length of time, we’ve probably been frustrated by an error messages that appear when we try to map a mounted image or boot it in VMware . This message can show up regardless of whether we try to mount read only or writable.
These errors presents when something “out there” has a hook into your mounted image. I don’t know what it could be or whether it can be several things. I’ve tried to replicate them, with only limited success. They seem to present when I do a lot of mapping/unmapping and mounting/unmounting. Sometimes, if I unmounted the image, closed VMware, mounted the image again, started VMware, and tried to run the VM, I received an error message that is similar to the first one shown above.
It appears that the easiest way to get around the errors and get back to work is, in the words of your favorite Help Desk tech, “reboot your computer.” That means your physical, host machine. If that doesn’t work, post a comment and I’ll dig deeper when time permits. Thanks for your time.