Windows 8, GPT, UEFI, and Virtualization

Well, it’s here!  Moreover, if you’ve encountered one, you may think that GPT stands for “giant pain in the tush”  It can be, especially if you don’t know a little about how these disks work in the newer machines.  I mentioned GPT in past blogs, here and here.  I won’t go into much detail about it, but I will present a few particulars so we can see why this topic is relevant to virtualizing Win 8 systems.  GPT (really) stands for GUID Partition Table and replaces the Master Boot Record (MBR) that we’re accustomed to seeing.  In Windows, GPT allows for 128 partitions, whereas MBR, in simple terms, limits us to 26 (one for each letter of the alphabet).  As you saw from my earlier posts, GPT also supports disks >2TB, whereas MBR does not.

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.

BIOS-1

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):

Legacy Boot

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.

Convert

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:

VM Folder-1

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.

VMX

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):

reg

 

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.

Error

 

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.

Snapshot

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.

Boot SEAT

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!

Win 8 Boot

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.

 

Booting a Write-Blocked Drive in VMware

The other day, my colleague, Huey Nguyen, just asked Weg whether he could create a VM from a physically write-blocked disk.  That was a great question, particularly as drives get bigger and imaging takes longer.  Conceptually, it seemed possible, so I gave it a whirl and will demonstrate the process.  First, readers should recall my post about creating VMs from mounted images (E01s).  The process basically is the same.  However, please recall my latest post, in which I discussed drives that are >2TB.

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.

UltraBlock1

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.  DiskMgt

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!

 

Mounted Images – Breaking the 2TB Barrier

In my last post, I described how to create a VM from a dd image file of a >2TB disk.  VMware does not support >2TB disks, so we had to implement a workaround.  You may recall that I stored my dd image as NTFS-compressed.  However, we can achieve better compression with E01 imaging.  The issue, however, is that we have to mount an E01 as a physical disk to create a VM from the E01 image.  I explained how to do this in an earlier post.  That approach applies to any mounted image, regardless of whether it is an E01.  We have to proceed differently if we have a mounted image that is >2TB.  In my example, I use a 3TB disk.  As the process is somewhat experimental and not supported natively by VMware, make sure that your results are accurate.  I’d like to thank Darius and the other talented folks at the VMware Community for their guidance.

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.

ftk-1

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.

vmdk

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.

vmx

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

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

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.

volume1

volume2

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.

How Do I Handle Really Big Disks?

I’ll begin by saying, “differently.”  At this time, VMware does not handle disks that are larger than 2TB.  You can’t create a VM with such disks, nor can you add them to an existing VM.  There is, however, a workaround, and I want to give a shout out to Ulli Hankeln (see blog roll) for his help.  In an earlier post, I demonstrated how we could build a VM from a split dd image.  To overcome the 2TB limitation, we’re going to use that approach, but with a slight difference in our vmdk file.

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.)

Split vmdk

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:  Split image file

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).

 

BigDisk vmdk file

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!

Automating VMDK File Creation

In my first post, I described how to create a vmdk descriptor file from a single, dd image.  Later, I posted on creating vmdk files from split, dd images.  Creating a vmdk descriptor file from a single, dd image is a relatively simple task, especially if you keep a handy template.  Segmented dd images, however, can make vmdk file creation laborious.  To illustrate, here’s an screenshot of a vmdk file that references a segmented image:

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.

Other Tools & Approaches to Access Shadow Volumes

I. Shadow Scanner

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.

Virtual Resurrection

I think most of us agree that, in addition to shadow volume exams, one of the most useful features of building a VM from an image is to determine the configurations of various programs.  Although details of configuration files are available for a number of frequently encountered applications, it’s often easier to simply run the program in a VM and determine the setup of the program.  For example, I found this approach to be especially useful in peer-to-peer (P2P) exams, with respect to programs like LimeWire, FrostWire, etc.  More specifically, while config files can tell us which individual files are shared, parsing through them is quite an undertaking.  Anytime we start parsing complex files, the chances  of error also increase.  If we run the application in a VM, we can review the configuration in a virtually (no pun intended) fail-safe environment.

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.

What About an XP VM?

From the start, my presentations concerned Windows 7 (and Vista).  When someone raised a question about XP, I thought it might be helpful to issue a post about building VMs from XP.  We go about it differently, and I’m going to presume we’re starting with a single, dd image.  First, we begin with a different vmdk descriptor file.  Here’s a screenshot:

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.

 

More on RAIDs and X-Ways Forensics

As I’ve said before, there often are a number of ways to accomplish a task in X-Ways Forensics (XWF), and a colleague at XWF pointed out an easier way to rebuild RAIDs.  When we just want to build and boot a VM from an E01 image, we must go through the process of mounting it as a physical disk.  Not so when we have a RAID and want to get to that point with XWF.  XWF can rebuild the RAID directly from the E01 (or any supported) image files.  The process begins by simply opening your image files from within XWF and choosing the option to include All Types of Images.  Watch:

Next, we can elect to rebuild the RAID directly from the image files.

So, we don’t need to mount images as disks to rebuild a RAID in XWF.  Should we proceed as I mentioned in my last post and create a DD image from the physical RAID with XWF, we will be able to create a VM directly from that image.

 

RAIDs & Virtual Machines

After a colleague posed a question about building VMs from RAIDs, I thought it might be a good topic for a post.  I won’t go into RAID basics, as you probably have a good grasp of that topic already if you’re visiting my site.  The RAID systems that I see most often are RAID 0s, insofar as the system disk is concerned.  We’re not concerned about a box that contains a system disk plus any variety of RAID.

In addition to being RAID 0s, the systems that are most common in my shop contain two disks.  Frankly, I’d be a little hesitant about building a system on a RAID 0 with more disks because of the lack of fault tolerance.  For our purpose, it really doesn’t matter.  In fact, we can build our VM from a RAID 5 or even some versions of RAID 6, if we use the world’s leading forensics tool, X-Ways Forensics (XWF).  For this demo, I’m going to use a two-disk RAID 0.  The first step is to create an image of each disk.  For the original images, the format is irrelevant.  I say “original” because we’re going to create another image later.

As in most cases with XWF, there are a few (X) ways to approach a task.  Let’s say that you don’t know whether you have a RAID, so you simply add your images to your case, as in the following video.

We now have two raw disks in our case.  XWF also advised us that disk structure implies that a RAID may be present (the MFT message indicates the possibility of an implausible file record and likely is of no consequence).  A little exploration will confirm that a RAID is present, so we can proceed to reconstruct the RAID.

When we add disk images to our case, XWF intuitively offers them as physical and/or logical disks in further tasks, as in the Select Disk box that we saw in the video.  We see that our original disk images remain in our case, but it’s really not necessary to keep them.  In fact, we didn’t have to add them when we created our case.  For example, during the original imaging process, we could take a look at the original disks through our write blocker and determine that we have a RAID 0.  After imaging, we can mount each image as a physical disk with FTK Imager or the tool of our choice.

Note that our image files are mounted as PhysicalDrive9 and PhysicalDrive10.  We can now create a case in XWF and reconstruct a RAID right from the start, without adding images or media.

We begin by reconstructing a RAID, just as we did before.  We’ll see that Disks 9 and 10 are offered as candidates for RAID reconstruction.  After reconstructing the RAID, we’ll add it to our case through the context menu, as before.  Note, however, that we must have our images mounted as disks to access our XWF case in the future.  In the previous method, our image files usually are always in place.

You may recall that I mentioned stripe size in terms of sectors.  Many of us are accustomed to referring to stripe sizes in terms of kilobytes, e.g., 128KB, which is a common stripe size for RAID 0s. XWF requires stripe size to be expressed as a number of sectors.  It’s easy math to determine sectors by dividing the number of bytes by sector size, which usually is 512 bytes (but could be 4,096 bytes these days).  Also, “bytes” mean the exact number: 128KB=131,072 bytes, so 131,072/512=256 sectors.  Determining the correct stripe size may take a little research or trial and error.

We now can work our case in XWF as we would with a typical single-disk case.  If we want to build a VM from our image files, we should create a new image from the physical, reconstructed RAID.  From the XWF File menu, we select Create Disk Image, and XWF will present the following option box:

In the case tree, our RAID 0 is highlighted, and the viewer window is in Disk mode.  My Create Disk Image options box is set to create a Raw (DD) image of the physical disk, which is our RAID 0.  Once the image is created, we can create a VM from the image as we would with any image of a single disk system.  Is that’s easy!