As we created our VM with a LSI SCSI disk, we have to start the LSI SCSI driver at boot.  So, we change the Start value data to 0×00.  Just change the 0×03 to 0×00 (change the 3 to 0 in the edit box).

Assuming that we fixed any password issues, we should be good to boot.  But wait; we get the old BSOD.  How can this happen, you ask Weg, as you edited the LSI SCSI registry key?  Here’s one way that it could.

When we get to the point where we choose our disk controller, VMware defaults to the LSI SAS controller, and even recommends that we keep the LSI SAS.  If you simply click through this option box, your machine will contain the SAS, and not the SCSI, controller.  When we boot, the system will crash because the wrong driver will load.  If you catch this mistake, you need not start fresh.  SAS is fine, if you load the LSI SAS driver.  Just go back and reset the LSI SCSI to 3, and change the LSI SAS (the first one, if there are two) to 0×00.

In the upper screenshot, note that we edited LSI_SAS and not LSI_SAS2.  If everything else is okay, you resolved the issue and your VM will boot.

Concerning VMs created from dd images, some folks forgot that we use a different procedure for segmented images.  Each segment must be enumerated in our VMDK file.

Lastly, we need to mount E01 and other image formats as physical disks to build VMs from them.  We need not create the usual VMDK file for the physical disk, as VMware will create it for us when we elect to build a VM from a physical disk.  Just be sure to go to the folder in which you created the VM and edit the VMX file.

Delete the word raw.  Then, take a snapshot after closing and re-opening the VM to refresh VMware.  Next, edit the registry/passwords as you would in the case of a dd image VM.

So, let’s start with a picture of what a valid VMDK file presents for a single dd image file of a Windows Vista/7/8 drive.

First of all, a VMDK file must be plain text.  Don’t create it in WordPad, Word, WordPerfect, etc., unless you are sure to save the file as plain text.  Here is a plain text file that you can use as a template: VMDK file.  I’ll take the blame for this one, as I had posted a RTF in my first post without enough explanation.  It’s fixed now.

Another common oversight is to use commas in numbers.  The numbers of sectors and cylinders, which are the numbers that you will edit, must appear as in the screenshot.  They’re yellow-highlighted in the screenshot.

Next, be sure to name you image file correctly.  In the example, it’s “image.001″.  Case is not sensitive.  Typos will kill the process.  In addition, the above VMDK file is designed to reside in the same folder as your image file.  If you want to store it elsewhere, insert the path to the image file within the quotes, e.g., “D:\Cases\VMs\Image.001“  Notice that certain parameters are enclosed in quotes.  If you neglect to use a single quotation mark, you’re apt to get a failure.

That’s it for now.  I’ll post a similar troubleshooter concerning E01-based VMs at a later date.

Next, we have UEFI (Unified Extensible Firmware Interface), which is tied to GPT.  UEFI is the replacement for the BIOS and is required to create a bootable, GPT disk.  Windows 8 includes a few features that go hand in hand with GPT/UEFI.  One is the Secure Boot/Trusted Boot process, which is designed, in part, to protect the system from bootloader bugs and can prevent a system from booting or require some form of remediation, if any threats are discovered. The process also will recognize infections of critical system files and automatically boot into a repair mode, if it detects infections, and restore previous copies of the system files. Secure Boot is based upon UEFI, and many new systems will ship with UEFI systems and Secure Boot active.  It’s very important to note that you can’t boot such a machine to a non-UEFI system disk, unless you set the UEFI boot option to compatibly mode, a/k/a CSM (compatibility support module), in the UEFI setup (analogous to BIOS setup).

Here’s a screenshot of the UEFI setup on an HP system.

Above, you can see some of the options that I described.  This system happens to default to CSM if a UEFI/GPT disk is replaced by a MBR disk.  Here’s what the Legacy Support option presents (Disabled/Enabled):

Should you disable this option, you could not boot a EUFI/GPT disk.  If you seek to disable Legacy Support, a warning to that effect will present.  This system will default over to CSM if it finds an MBR disk. There may be any number of variations among system manufacturers.

Many of you know that, through Windows Disk Management, Diskpart, and other tools, we can change the partitioning of a disk to and from GPT/MBR.  However, we can’t do that with conventional tools if the disk contains partitions.

As you can see, the option to convert my GPT disk to MBR is unavailable.  If I right click on the partition, gpt-formatted (J:), I would have the option to Delete Volume…  Thereafter, I could create either a GPT or MBR disk.

There is some debate over whether VMware 9.x can boot a GPT disk without at least a tweak to the configuration (VMX) file.  From tests, I found that a simple edit could overcome a failure to boot a GPT image.  Note that the same principles apply to booting mounted images, which are the practice with E01 and other non-raw image files.  However, we will have to adjust how we work with E01/mounted images (stuff for a later post).  To complicate things, it seems that VMware does not support mounting VMDK files that represent GPT disks.

By now, you should be familiar with creating a VM from a dd image by preparing  a VMDK descriptor file.  That process remains unchanged.  Once you accomplish that task, you will have a number of VMware system files in your VM folder:

The file of note is Win8.vmx.  For the best explanation of VMware system and config files, please visit Ulli Hankeln’s site at http://sanbarrow.com/.  So, we’re at the point where we have a VM.  Next, we take a snapshot.  We can try to boot out Win 8 VM and see what happens.  If you receive a no operating system found message, I suggest that GPT/UEFI may be the culprit.  Of course, you probably visited the system settings earlier to document the setup.  There, you could have learned what might be in store concerning VMs.

Open your VMX file in a text editor and add the parameter firmware = “efi” to the file.  Below is a screenshot of a portion of my VMX file.

Now, your Win 8 image should boot, if at least the registry is set to boot to the LSI SCSI drive that’s in our standard VMDK file.  You should remember that, concerning Vista and Win 7 images, we took a snapshot and mounted our virtual disk with VMware as writable.  Then, we edited the registry so that the LSI SCSI service started at boot (0×00):

You also should recall that we stripped any essential passwords while our virtual disk was mounted.  The problem we have now is that VMware doesn’t support mounting GPT virtual disks.  You can go through the motions, and VMware will appear to mount the disk.  However, when you try to access it, you’ll see what follows.

Now, you may just get lucky and find that your target system already is set to load the LSI SCSI driver at boot and that the user had no password.  If that’s the case, you’re luckier than I am, and you’re good to go.  For the time being, we do have a workaround, which relies on our trusty SEAT Workstation.  While we can’t mount the virtual disk to our host system from VMware, we can add the virtual disk, from its snapshot, to our SEAT Workstation.  Watch.

When we use VMware to mount a virtual disk, VMware defaults to the most recent snapshot of the virtual disk.  If we mount a VMware disk otherwise, we have to navigate to the latest snapshot manually.  Below, we can see that VMware is about to mount a snapshot file, which is apparent from the 000002 identifier, which was appended to the name of our original vmdk file.

You may wonder why we elected to add the virtual disk in persistent mode.  Well, we want to edit the registry and strip passwords, just as we did when mounting a virtual disk as read-write with VMware.  Our Win 8 VM has been snapshotted, so our original image, which also is write-protected, remains unchanged.  Next, we’ll boot our SEAT Workstation.

Above, we see that our Win 8 virtual disk has been added to our Seat Workstation as Volume E:\.  Now, we’ll edit the registry of our virtual disk.

I’ve become accustomed to naming added hives in a manner that makes them stand out, just so I don’t edit my own system’s registry by mistake!  Note that you may find that your target’s System hive already may have the desired setting.  You can check that before you get this far, simply by examining the registry with your forensic tools.  The same thing applies for passwords.

NTPWedit, being a Windows too, can run within our SEAT Workstation.  Simply copy the executable to your SEAT Workstation.  You can try to boot your Win 8 VM with one of the password editing discs, though I have not tried that approach.  Again, the process of adding your Win 8 virtual disk to your SEAT Workstation may be unnecessary, if you find that you target system already includes the correct registry setting and included no passwords.  Nevertheless, you had a refresher on the process, which is, in substance, the same with respect to Win Vista/7.  Now, we shut down our SEAT Workstation and remove the Win 8 virtual disk.

Last, let’s see whether our Win 8 VM boots.  It does!

There a few more things related to GPT, Win 8, etc., and I’ll be back with more as I get caught up and as I learn more about overcoming some of the hurdles that I identified above.  There also are a few things to discuss about examining shadow volumes in Win 8 systems.  They still exist in Win 8, though the Previous Versions feature is gone.  You may want to start thinking about building a SEAT Workstation on a Win 8 platform!

As time goes by, we’re seeing more tools that can make a shadow volume exam more efficient and may make my method “obsolete.”  Much depends on how you work and your resources. I like my approach because it allows me to incorporate my findings into X-Ways Forensics almost seamlessly.  Shadow volumes aside, booting an image of a target system is, IMHO, an essential part of almost every exam.

I want to make mention of one new tool that’s worth a look: Reconnoitre, which Paul Sanderson produced, http://sandersonforensics.com/forum/content.php?168-Reconnoitre.  Paul let me do a little beta testing, and I was impressed with the power of his latest creation.  Many of you are familiar with Paul’s tools, so you know that they perform as represented and meet the demands of the forensic community.  That’s it for now.

I’ll go through some, but not all, of the stuff that we’ve done before because many folks don’t like going back and forth to reference information.  We’ll begin with a drive that I attached to my Tableau UltraBlock.

As you can see, I used the eSATA bus, but that’s irrelevant.  As long as Windows can see the disk, we’re in good shape.  

Note that our write-blocked is Disk 5.  Next, we’ll let VMware do the work of building our configuration files.  Here’s a quick refresher:

Next, we’ll navigate to the VM’s folder and open the VMX file in a text editor.  We’ll edit the VMX file with respect to the disk type parameter for our disk, SCSI Drive 0, as in the next video.

Natively, VMware will not allow us to snapshot a physical disk.  Editing the parameters allows us to trick VMware into thinking that we don’t have a raw disk.  Next, we have to refresh our VM to take a snapshot, so just close and reopen your VM in VMware, and take a snapshot.

The next step is to edit the registry.  Don’t worry, in addition to snapshot protection, our original drive is behind a physical write blocker.

After you’re finished, be sure to unmap the volume in VMware.  However, if you want to remove any logon passwords, be sure to do so before you unmap your volume.  I described that process in an earlier post, which suggested the NTPWEDIT tool.  To unmap the volume in VMware, you may have to close all Explorer windows, or simply tell VMware for force a disconnect if prompted.  Note that we could have used a SAS disk in our VM, but I think that the SCSI option is a little less confusing when it comes to editing the registry.  After the edits, you may want to take another snapshot.

Next, sit back and behold your powers!

We’re going to create a custom vmdk file for our mounted image file.  The first step is to mount our E01, and my example uses FTK Imager with write caching.

Note that my image is mounted as Drive 9.  An easy way to start is by creating a VM from another, <2TB mounted image file (not your target, >2TB image or any image that large).  Doing so will provide the vmdk and vmx files that we must edit.  Here’s a refresher:

When you create your “template” VM, it will be handy if you give it the same name as you intend for your >2TB VM.  Navigate to the folder in which you created your sample VM, and open the vmdk file in a text editor.  The next screenshot depicts the vmdk, as it will appear after we edit the file.  I’ll explain afterward.

Note the yellow highlighted portions, and let’s start with the lower one.  We know by now that we have to edit our vmdk file to match our disk’s geometry.  The math is Total Sectors/63/255=Cylinders.  In my example, 5860533168/63/255=364802, and you can see those numbers reflected in my geometry.

No, let’s move our attention to the upper portion.  Your original vmdk sample file will contain one extent, which looks like this (number of sectors will vary):

# Extent description
RW 625142448 FLAT “\\.\PhysicalDrive9″ 0

In our edited version, we had to “split” the disk to avoid extents that are >2TB.  Otherwise, VMware will reject the disk because it presents as >2TB.  Using the edited extents, we instruct VMware to read 2930266584 sectors beginning at Sector 0 and 2930266584 sectors starting at Sector 2930266584.  As we’re still using a flat (single) disk, we must tell VMware how to address the disk.  We could have split the disk into, for example, four extents.  If you have a 4TB disk, you may have to split a little further.  In simple terms, we tell VMware, “Start here and read X sectors, from that point read Y sectors, etc.”  The last extent instructs VMware to go from the indicated address and read the number of sectors to the end of the disk.  Also be sure to insert the disk number that corresponds with your target, >2TB mounted image, e.g., PhysicalDrive9.

Next, open your vmx file in a text editor.  This is a screenshot of the top portion of the config settings.  Note the highlighted line.

Change the highlighted setting to Disk by deleting the prepended word raw.  That will allow snapshotting in the GUI.

Next, open your VM.  You can double-click your vmx file.  I then create a snapshot.

I want to point out that my large disk was partitioned with one 2TB MBR partition, and the excess was unpartitioned.  To use an entire, >2TB disk in Windows, requires a GPT disk, which I touched on in my previous post.  Thus far, I have not seen a GPT disk with an operating system, though one can install Windows on such disks, with certain restrictions.  To illustrate my disk, check the next, two screenshots, which are from Disk Manager.

My disk  is an MBR disk.  The mechanics would be the same for a GPT disk; however, using GPT disks in VMware is something that I have to explore.  I’ll post after I do some testing,

As disks become even larger, we may find that imaging them is not always practical.  The procedures described above will work for a true physical disk, although I have not tested the method through a write-blocker.  If you want to create a VM from an actual physical disk, you must take the disk offline before you boot the VM.  In the previous screenshot, you can see the option, which can be accessed by right-clicking the disk in Disk Manager.

This is a work in progress.  There may be a better way, and I’m looking into alternatives and other ways to handle 2TB+ disks.  I am also going to avoid a discussion on GPT (GUID Partition Table) disks and UEFI (Unified Extensible Firmware Interface).  You can find plenty of discussions on those topics, and I suggest that you look them up if, for example, your system can’t recognize a 2TB+ disk.  I’m going to describe the procedure now, and try to address some anticipated questions later.

First, let’s go back and look at the vmdk file that we created for use with a typical split dd image. Note the parameter createType=”monolithicFlat” in the first section.  My friend, Ulli, has a great reference on vmdk file parameters at http://sanbarrow.com/vmdk-basics.html#what.  The createType relates to the type of disk, and monolithicFlat generally describes a single, whole disk.  However, we “cheated” a little bit in the previous, split dd image scenario, as it really didn’t matter that we chose a split image as a whole disk.  Each extent in the graphic describes a disk (image) segment and is expressed in number of sectors (512 bytes per sector here).  (I omitted a listing every segment for the sake of brevity.)

Before we create a vmdk file for our 2TB+ disk, we will create a segmented dd image of the medium.  You must keep your segments <2TB.   I used a 3TB disk, and here’s a screenshot of mine:  

You may note that I compressed my segments with NTFS compression.  Don’t use NTFS Sparse compression (another handy feature offered by X-Ways Forensics), as it won’t work and really helps only if the disk has many zero-bytes.  Note that each of my segments is 125GB.  We use Size and not Size on disk.  Let’s do the math.  134,217,728,000 / 512 = 262,144,000 sectors per segment.  So, we have the value for each extent in our vmdk file, except for the last segment (do the math).

You’ll note the createType right away by its highlighting.  This was the type that I was able to use for large disks.  This type also will work for our smaller split disks: twoGbMaxExtendFlat.  The disk that I used was not a system disk, so we won’t create a VM from our vmdk, but will add it to an existing VM.  Any by the way, Dana McNeil’s VMDK Creator makes vmdk creation a snap!

The disk that I added was not a system disk, nor was it associated with my VM’s system.  All of the 2TB+ drives that I’ve seen thus far were used to store stuff, typically videos and graphics.  Although I compressed my image segments substantially, I can’t hope to do so with the average, seasoned disk that I’ll find in the field.  I could achieve even better compression with an E01 image, given the proper compression method.  However, using an E01 requires that we mount the image as a physical disk.  That’s where the problem lies, for the moment.  I have yet to overcome the challenge of creating a VM or virtual disk from a physical disk that’s >2TB.  I’m studying that problem now, and I’ll post again if I find a solution.  Whether we even image such large drives may be questionable.  Perhaps we’ll do our exams on the original disk through a write blocker.  Thanks for tuning in, folks!

As you can see, we can have any number of segments to enumerate.  That’s where the basis of this post comes into play.

Dana McNeil is a seasoned detective with the Bozeman, MT, Police Department.  He’s certified as a computer forensics examiner and a member of our Internet Crimes Against Children Task Force.   On top of that, Dana’s a programmer.  He wrote a handy tool named WinVMDKCreator to automate building vmdk files from single or multiple dd image files.  Even with a single image, Dana’s tool removes a margin of error that exists when humans copy, paste, and do math.  In keeping with our philosophy of sharing with the forensics community, Dana kindly allowed me to share his latest beta with my readers.  So, here it is: WinVMDKCreator.  To make downloading less troublesome for some readers, the zipped application is in another zip file that’s encrypted with the password vmdk.  Simply unzip the application and its accompanying files to a location of your choice.  It’s a portable app, and no installation (or uninstallation) is required.

When you run the executable, the following screen presents.  I’ll demo the tool with a video later.

In sum, you point the WinVMDKCreator to your dd image file, choose some options, and create a vmdk descriptor file in a few seconds.  Dana also allows us to have WinVMDKCreator set our image files to read-only, in case we haven’t done so already.  A log file is created to document the operation.  I’ll demonstrate with a 75-piece dd image set.

WInVMDKCreator needs only the first segment of a mulit-part dd image and uses the image file to compute the disk geometry.  By default, it verifies its findings with the imaging verification file produced by X-Ways Forensics or FTK Imager.  WinVMDKCreator was designed to parse the formats of the text files produced by those applications.  You can choose a different file, though WinVMDKCreator may not understand its format.  Had we looked, we would have noted that every image segment’s attribute was set to read-only.  Presently, WinVMDKCreator allows us to choose an output version suitable to VMware 8 or 9.  Finally, WinVMDKCreator names the descriptor file after the name of the image.  You can choose a different name if you wish.

Let me go over a few points about VMware versions and vmdk file formats.  First, they’re not critical to any task that we’ll undertake in forensics.  However, if you’re versions don’t conform with your VMware version, you may find yourself perplexed over choices that present during VM creation.  I’ll demonstrate by beginning at the VMware 9 screen where we decide to create a VM from an existing virtual disk.

If we created a vmdk descriptor file based upon VMware 8, VMware asks whether we want to convert it to Version 9.  Let’s say we’re inclined to do so.  Well, the next box tells us that we can’t.  The reason for this is that our underlying image file is read only, and we can’t take a snapshot before our VM is created.  It’s a chicken-egg thing.  I can tell you that VMware doesn’t need to “edit” the image file for a conversion, but I like to keep my images read-only.  If you simply choose to keep the existing format, VMware will create your VM, and it will work fine.  There are other ways around this, but I’ll leave this issue alone as it’s really insignificant.

Remember that WinVMDKCreator is still a beta, thought it seems ready for full deployment.  Basically, if your VM works, WinVMDKCreator did its job.  If you like the tool, give a shout out to Dana or drop him a note.  His  email address is in the “good-bye” box that presents when you close the application.

In the first section of this post, I’m going to review another way to examine shadow volumes, by using a commercial tool named Shadow Scanner, which is produced by EKLsoftware.  One of our esteemed colleagues, Rob Erdely, is on the EKLsoftware team and is very well versed in Shadow Volumes.  The link above also guides the reader to a couple of videos that nicely explain Shadow Volume basics and the Shadow Scanner application.

Please keep in mind that I’m not going to present a tutorial on Shadow Scanner (SS), beyond a simple demonstration.  The guys at EKLsoftware already have done that through their videos and PDF documentation.  My aim is to show that you can avail yourself of SS’s powerful features right in your SEAT workstation.  You don’t need to restore the image (which is unnecessary with respect to almost any shadow volume exam).

As we’ve seen, accessing the Shadow Volumes from an image or mounted image (volume) directly on forensic workstation, through Windows, generally is not possible.  While we can do so by converting our image to VHD format, doing so requires editing our dd image file as I described in a previous post.

In a nutshell, SS allows an examiner to compare Shadow Volumes with the target’s current system to see whether files were changed, deleted, or added.  I’ll start with a video in which I set up a scenario.  Previously, I added the virtual disk (vmdk file), which I created from my image of the target system, to my SEAT workstation.  It’s Volume F:

As you saw, I added a file to, and deleted some files from, an arbitrarily chosen folder.  Next, we”’ run SS.

As we saw, SS compared the target folder with the current volume and noted files that had been deleted, i.e., not present in the current volume, but present in the selected shadow volume.  SS also noted the created file, i.e., present today, but not in the selected shadow volume.  Using your SEAT VM allows you to employ SS without restoring the image file or installing SS in a booted image of the target.

Again, there are all kinds of options that SS affords an examiner.  For one, you’re not limited to selecting only one shadow volume to scan and compare.  Visit the SS site and have a look.  The publishers also are kind enough to offer a trial version.

II. Another Approach

One last point on getting your image file into your SEAT workstation.  In an earlier post, I described how we add a custom-built, virtual disk to our SEAT workstation.  Generally, I create VMs from my target image files because I want to boot the target and kind of immerse (pun on Windows 8 intended) myself in the user’s system.  However, you don’t have to create a vmdk disk.  You can mount an image (any format) in your host and add the mounted image to your SEAT workstation.  Watch.

Note that, in FTK Imager, I selected the Block Device / Writable method.  This allow “writes” to the disk to be cached, as opposed to actually being written to the mounted image.  I also left the Mount Type as Physical & Logical, although I could have chosen Physical Only.

Next, we’ll add the mounted, physical disk to our SEAT workstation.

If we mount the image as Block Device / Read Only with FTK imager, we have to take a snapshot of the SEAT workstation before we boot it with the mounted disk attached.  When you boot your VM, you may see a couple of things that catch your attention.

Insofar as the SCSI disk warning is concerned, you may ignore it and click OK.  The second screenshot reveals that Windows wants to check one of our disks, which is the newly added physical disk, for consistency (CHKDSK).  You may just let it proceed, or canceling likely will have no effect.

Obviously, to run an application in a VM, the application must exist.  What about a case in which you know that the subject employed a particular application, but your exam of the acquired image reveals that the program no longer exists?  A VM will only afford access to those objects that exist, although we always can explore shadow volumes.  However, we can’t run most applications from a shadow volume folder or mounted shadow volume.  It’s analogous to trying to run an application from a mapped volume; it may work with some, but not all, applications.  I’m going to review a couple of approaches to “bring back the dead.”  I’ll say up front that these methods are somewhat experimental and don’t always work.  There also may be other approaches to this project, but mine assumes that you want to run the previously existing application in its native system.

Much depends on the complexity of the application that you want to restore and the method by which it was removed.  I’ve found that most users employ the application uninstaller to remove an unwanted program.  Some applications, particularly  P2Ps, remove the application folder from the Program Files directory, but leave behind the configuration files, which usually are in the user’s AppData tree.  The first approach is a simple copy and paste where we copy the application folder from the most recent shadow volume in which the program existed.  We can start by using the quick shadow volume exam approach that I outlined previously.

When I undertake a program resurrection, I usually start with a base VM of the target, before I install VMware Tools or do anything that may disrupt the system.  In my example, we know that the subject used a P2P program named LimeZilla.  However, a look at the image file revealed that the application’s program folder was not present in Program Folders (x86).

Here are a couple of screenshots of the target VM to illustrate the point.  The first shows the AppData\Roaming folder for the LimeZilla config files.

Next, here’s a look at the Program Files (x86) folder.  The LimeZilla folder is missing.

Next, we’ll navigate to our available shadow volumes and look for the previously existing LimeZilla program folder.  Here’s a video.

It’s always best to get as recent a copy of the application as possible.  Applications, particularly P2Ps, are fussy about matching the executable with the proper version of the configuration files.  Next, let’s see whether we are successful.

We now have access to the most recent version of the application.  At this point, we can install VMware tools depending upon our goals.

We’re apt to find cases in which a simple copy and paste won’t work.  In those instances, we resort again to the shadow volumes and try a system restore.  Before I present a few warnings, I’ll demo the process.

The process may take quite a bit longer than the video made it appear.  In case you didn’t notice, my desktop background reverted to what it was at the time of my selected restore point.  In my example, I had installed VMware tools, although I usually don’t if I want to restore a system.  By going back in time, I lost my VMware Tools as well as my installation of FTK Imager.

I did manage to recover my Skype installation. Frankly, this process isn’t successful very often, and the old BSOD presents regularly.  For one, by going back in time, we probably returned to a time before we edited the drivers through the registry services.  If that happens, you can try to fix the VM by returning the restored VM system’s registry to boot from the LSI SCSI drive.  Even so, I’ve had some failures in this approach.

I do have a couple of other approaches in the testing phase of my research.  When I make them a little more reliable, I’ll add a post.

With one, notable exception, the descriptor file is configured like the one that we used for Windows 7.  For XP, we use a standard IDE disk for our system.  Here’s a text file that you can edit, but change the extension back to vmdk.  It’s for use in VMware 9.  Use WordPad or an application that will respect the delimiters.  Remember, edit your file to identify the image name, number of physical sectors, and number of cylinders.

Next, I’ll go through the creation.

We chose the version of XP that’s on our target system.  If you come across Windows XP Media Center Edition, select XP Professional.  After the VM is created, take a snapshot.  If you want to strip passwords, use the procedure that I described earlier, and mount the disk as read-write and run a password stripper.

We don’t do shadow volume exams in XP, so we don’t need to mount the virtual disk in our SEAT workstation.  Nevertheless, as with any operating system, we probably have a need to run a VM of the target system for any number of reasons.  Our VM is ready to boot, or so we think.

Familiar sight?  I’ve found that the easiest and most effective fix for the BSOD is to do a Windows repair.  To do that, you need an installation disc of the same version of XP as your target.  Here, we need an XP Home CD or an ISO.

You can configure VMware to boot from your physical CD drive or an ISO image.

When you start your VM, make sure that it has focus (click your mouse in the VM).  When you see the POST screen, hit Escape once.

When you hit Escape, the screen should look like this:

Here, we’ll arrow down and elect to boot from the CD.  When you first try this, you may find that VMware doesn’t give you enough time to choose a boot option.  It can be quite frustrating, and a Glock is not the answer!  I’ll show you a more effective fix for this later.

After electing to boot from the CD, you’ll press a key when you see this message:

In the next video, we’ll follow along with the rest of the process.

The first decision screen is where we’re asked whether we want to install windows.  We’ll elect to do so, and then accept the license agreement.  Next, Windows finds an existing installation and offers choices.  We’ll choose  to repair the existing installation by pressing the R key.  Windows then proceeds through the setup.  During the installation, we’re offered some choices, which we can accept.  We also have to enter our license key.  After the reboot, we have a working VM.

Now that we’ve repaired our XP VM, it will boot just fine!  However, we may not be home free.  Often, the change in hardware will make Windows tell us that we must activate our XP installation.  There are a couple of options here.  If you’re in law enforcement, you can seek assistance through the Microsoft Law Enforcement Portal, which is a great resource.  If you’re not in law enforcement or want an alternative, there is a utility named WPA Kill, which you can find through a Google or a similar search engine.  I’m not advocating its use, but I do advocate complying with licensing requirements or otherwise being authorized to use a utility like this.

Many antivirus scanners will trap WPA Kill, so be sure to enter an exception so that you can download and save the file.  You can save a copy to a CD or include it in an ISO image.  If the activation requirement presents, you still can boot to Safe Mode, where you can run WPA Kill.  Sometimes, you may find that Windows offers you 30 days until you must activate your VM.  Of course, using snapshots can keep you “frozen” in time.

I’ll point out that XP can be difficult, and there are times when I’ve been unable to build a bootable VM.  Defects in the underlying operating system may be to blame.  There also can be troublesome driver issues.  In the latter cases, experimenting in Safe Mode may help.  There’s also a nasty issue that pops up now and then and which renders your keyboard and/or mouse unusable.  It’s a driver issue, and I haven’t figured out a fix, although Virtual Forensic Computing has.  If you want to start with an E01 image, you can mount the image and build your VM from a physical disk as I described in a previous post.  You also can use segmented images.

As promised, here’s a way to gain some time when you want to hit Escape to see the boot menu:  In Windows 7, go to \ProgramData\VMware\VMware Workstation.  Here, you’ll create or edit a file named settings.ini.  In the file, type the line Bios.bootDelay=”3000″.  That will force a three-second delay before your system boots.  If you want more time, enter the number of milliseconds, e.g., “5000″ is five seconds.  Use quotation marks around the number.