VMware 10 and Booting Through a Write-Blocker

In my last post, I pointed out an issue that affected the way we boot E01 and other non-dd image files.  The issue arose because VMware 10 does not allow us to map a physical disk, e.g., a mounted image, as writable.  We want to mount potential VM disks as writable to edit the registry and remove passwords.  Naturally, this change also affects how we boot a disk through a write blocker.  I posted on that method previously.  In this post, I’m running VMware 10.0.0 on a Win7x64 host.  My target disks run Win7x32 and Win7x64.

To get around the VMware 10 limitation with a mounted image, we mounted the image with FTK Imager or another tool that allowed write caching.  Write caching takes potential writes to a mounted image and stores them in a file instead of on-disk.  We then accessed the mounted image directly, edited the registry, and removed passwords. Next, we built a VMware VM from the edited mounted image, edited the vmx file to allow snapshots, took a snapshot, and away we went.  However, in this post, we’re working with a “real” physical disk, albeit through a write blocker. There’s nothing to mount.  Image mounters can’t “mount” a write blocked disk or any physical medium.  They’re not supposed to do that.  After all, why mount a disk when it’s already mounted?  Now, if you have a write blocker that allows write caching (Voom Shadow), you can simply follow the steps in my last post.

Note that we can create a VM directly from a (write protected) physical disk that came from a system disk that we receive for examination, but it’s apt to be unbootable, given a typical Windows 7 system on the disk.  Of course, the object is to make it bootable despite the fact that VMware 10 won’t allow us to write to the disk.  The first thing we’ll do is create a VM from the write-blocked disk.  When we power up our blocker, the disk will be mapped as a physical disk and Windows will present the logical volume(s).

Snap34

In the screenshot, my write-blocked disk is Disk 8, which happens to contain one logical volume, which Windows mapped as M.  Now, let’s create a VM.  We’ve done this before, but here’s a video to remind you of the process.

Next, we’ll edit our virtual machine configuration file (vmx) to allow snapshotting.  Take a snapshot when you reopen your VM.

We now have a VM that’s based on a write-protected disk, but has a snapshot that will serve as the target for writes.  We can try to boot it to Windows, but it will blue-screen.  Trust me.  So, let’s make another configuration change to our VM.

I chose to use an ISO of a Windows 7×64 installation DVD.  I’ll anticipate some questions by telling you that you can use your host’s physical CD drive with the Windows disc if you wish.  If you do, just leave the VM’s CD drive mapped to your host system’s physical CD drive.  Note that, if we intended to go through an actual Windows repair, we’d need the same version disc as was on our target system.  Here, we don’t.  Before I present the next video, I’ll tell you what we’re going to do.  We’ll boot to the DVD and go into Windows Repair.  There are a couple of ways to get VMware to boot to your DVD, but I usually just hit Escape after the VM starts.  You also can reset the boot order in the BIOS, VM\Power\Power On to BIOS from the menu.

I usually take a snapshot at this point.  We’ll close out of repair mode, which should reboot our VM to the guest system’s login screen. If the user has no password or has one that you know, you’re set to log on to the system.  Otherwise, we must remove the passwords.  Before you get this far, you could have opened your disk in your favorite tool and checked whether a password would be an issue.

There are a few ways in which we can reset the password.  I used an ISO of free, multi-tool application named Hiren’s Boot CD, available at http://www.hirensbootcd.org/download/.  The disc includes a number of free tools, including a mini-Windows XP PE platform.  However, at the moment, I want to use the password reset feature.

I went through the process somewhat quickly, so pay attention to the prompts and options.  Make sure that you select the proper partition, which is the partition contains the registry (#2 in my example).  The default is Partition 1, which often is the boot partition and not the system partition in Windows 7 and 8 (I haven’t tested 8 yet).  I usually unlock the target account and remove the password during the same operation.  Remember that when that when it comes time to reboot, we use Ctrl-Alt-Ins in VMware.  Ctrl-Alt-Del will take us to the options on our host system.

At this point, your write-blocked disk should boot to Windows 7, and you can log on as the user.  Note that this process can be a little buggy sometimes.  Before VMware 10, we edited our physical disk through our first snapshot, which we mounted as writable.  Although we’re doing almost the same thing here, I’ve found that the repaired system sometimes blue-screened, though not because of the standard driver issue.  To avoid that problem, take a snapshot of the system when it boots successfully for the first time.  Let’s call that snapshot our “Base System.”  Then, you simply can go to the Base System snapshot and start from where you last ended.

I would install VMware Tools at the first successful boot, but that depends on my mission.  I’ve found that installing VMware Tools can avoid a blue screen on reboot, though the installation requires a reboot, itself.  As I mentioned before, installing VMware Tools creates a restore point, which can overwrite others.  Take more snapshots along the way, so that you can develop the evidence that you desire.  Remember, too, the disk number of your write blocked drive.  As you mount or swap disks in you host, disk numbers may change.  If your original disk number changed, edit the <original>.vmdk file.

Frankly, I don’t consider booting a write blocked drive as practice that I will repeat more than once or twice on a given drive.  If the disk warrants that much attention, I’ll image it (dd) and go through more conventional exam procedures.  BTW, you can pick up a Voom Shadow device to boot an original drive.  Although my approach takes a little more work, it’s about $1,900 cheaper, considering that everyone already has a write blocker.

Anyway, you may have to try a few experiments to get a given system to boot reliably.  As an alternative to booting to a Windows install disc, you can use Hiren’s disc and load the “Mini XP” system.  From there, you can use Regedit to edit the registry, and use a Windows password stripper if you load it into the Hiren ISO or access it from a USB stick that you mount in the XP environment.  Good luck!

 

7 comments

  1. […] cool post on how to use Vmware to boot a suspect drive that is still hooked up to a write blocker, http://justaskweg.com/?p=1381. This is a great solution when you don’t have time to clone, virtualize and get it […]

  2. Brent Muir says:

    You could also use MountImagePro (www.mountimage.com) to re-mount the physical drive with write-caching enabled as well, instead of using a Voom.

    • jimmyweg says:

      With respect to an image file, certainly, as I indicated in my post. However, I don’t think so if we’re talking about an actual physical disk. For that, it seems a write blocker is required, and the Voom is one that affords write caching, albeit as considerable cost. According to MIPs site, an attached “Physical device (e.g. connected HDD)” cannot be mounted physically. The file system can be mounted, but that won’t do if we want to boot the drive.

      • Brent Muir says:

        No matter what their website stipulates, I have just confirmed that MountImagePro version 4.59 can in fact mount a Physical Drive with write caching enabled. I am happy to send a screen shot to you. In my opinion this is the only benefit over FTK Imager’s mounting abilities.

        • jimmyweg says:

          I don’t doubt your findings, but I do find it odd that the MIP web site contradicts them. Perhaps you can try to boot a write blocked drive in conjunction with MIP and post back with the results. MIP always could mount an E01 with write caching, well before FTKI mounted any image format. If MIP does so with physical disks, that’s great. I wouldn’t pay for a mounter just on that basis, as my approach is free and not more difficult. As I said, I don’t do this very often, if ever. Overall, with respect to whether MIP is worth $300 as opposed to the free FTKI, is a judgment call of the examiner. In any event, I don’t see an advantage in the Voom. I started out with the first release of MIP, and Michael Penhalurrick, the creator of VFC, is the “father of forensic virtualization” as far as I’m concerned.

  3. Rob P says:

    Great Stuff Jimmy!.. Thanks for all your research and work on this topic.

    Rob

Leave a Reply

Your email address will not be published. Required fields are marked *