Archive for September 2012

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!


Getting a Quick Look at Shadow Volumes

We’ve come to the point where we can conduct a rather complete exam of shadow volumes using dd and E01 image files.  Let’s say that we don’t need to do such a complete exam.  For example, we’re confident that one, particular folder may contain previous, unrecovered copies of a small number relevant files.  Maybe we’re looking for one file in particular.  In those instances, we may not need to mount the shadow volumes.

We can accomplish this task in either our SEAT workstation, in which we added a virtual disk of the target system, or in a running VM of the target.  The latter approach is required for E01 images and optional for dd image files.  You also can accomplish this with the VHD method that I presented earlier.  The approach is the same regardless of which method you choose.  Remember, however, that using a “live” VM of a system runs the risk that the system will delete old shadow volumes.  The risk can be overcome, but keep it in mind.

To demonstrate the procedure, I’m going to use my SEAT workstation, in which I added a virtual disk.

It’s that easy!  Note, too, that you can invoke Windows Previous Versions on almost any file or folder.

In my example, no previous versions existed.  If they had, we would have seen a list of earlier versions by date.  We then could open and examine any available version of the file.  Should you find files of value in the approach that I presented, you can copy the files from the VM to your host system.  Copying is seamless if you install VMware Tools in your VM.  Otherwise, you can enable a shared folder with your host.  Any such copy operation, however, is not a forensic recovery, so consider whether it suits your needs.

Now that we have a quick and easy approach to a limited review of shadow volumes, don’t become too accustomed to using it into the future.  Windows 8 seems to have done away with the Previous Versions aspect of the Volume Shadow Service.  In my tests of the latest Windows 8 Enterprise edition, it’s gone, and I believe that this has been confirmed on MSDN or similar forums.  We can take heart, however, in the fact that shadow volumes remain; at least for the time being.

Examining Shadow Volumes Through an E01-Based VM With X-Ways Forensics

Now that we created a VMware VM from an E01, I should explain how we get to the shadow volumes.  The procedure is different from the one that we used with a single or segmented dd image.  With an E01, we began by mounting the E01 as a physical disk with the tool of our choice.  As a refresher, here’s a screenshot.

Note that I have a single E01, but a segmented one works as well.  Also remember that, if you have a segmented dd and don’t want to go to the trouble to create a vmdk descriptor as I outlined, you can mount the segmented dd image as a physical disk just like an E01.

Because we began with a physical disk, we can’t add it to our SEAT workstation as we did a VMware virtual disk, if we’re after shadow volumes.  Doing so would be the same as if we just mounted an image in our host workstation; we can access the volume, but not the shadow volumes.  However, don’t forget the VHD approach.

First, we have to mount our E01 as we did when we created the VM. An important point to remember is the physical drive number of your original VM.  VMware will not budge if the number changes, unless you edit the vmdk file.  To change the disk number, edit the string PhysicalDrive#, where # is the drive number.  Set it to the original and then open VMware so that it can enumerate the drives in your system.  The next step is to take an extra snapshot, and I’ll assume that we’re starting with our original, ready-to-go VM.

We’re going to approach this task by booting our VM and working in the live system.  Before we begin, remember what I said a long time ago about ensuring the integrity of your shadow volumes, with respect to numbers.  Before you launch a VM, note the number and dates of shadow volumes by studying the System Volume Information folder in the image within your exam tool:

I have 19 shadow volumes, and the first was created on December 31, 2011.  When we boot an image, we have a dynamic system.  Depending on drive size, timing, events, etc., the system will create new restore points, which may overwrite the earliest shadow volume(s).  We can deal with that, but you have to bear this in mind.  That’s why I created an extra snapshot.

Before we boot, we should prepare a thumb drive with the essential exam tools, e.g., X-Ways Forensics (XWF) and Maresware’s VSS.  Put anything on it that you want.  There aren’t however, many full-fledged Windows forensics tools that can be run from a thumb drive, and it’s best to avoid installing things in the VM.  I find it handy to place a shortcut to XWF in the root of my thumb.  Once you copy XWF to your thumb, run it in your host and set your options.

If it’s not clear in the screenshot, my XWF application is in the X-Ways Forensics folder, which is in the root of my thumb.  I used relative (..\) paths to direct the yellow-highlighted locations to the configuration folders, which also are in the root.  Also check the box to always run XWF as administrator.  Your thumb is now completely portable among different VMs.

Next, boot your VM and log on to the desktop.  If you succeed, you followed the instructions quite well!  First, I connect my dongles and my exam thumb to the VM.  If you find that you go back and forth to XWF between host and guess, another dongle is great!  XWF will let you assign a specific dongle to the host and guest, respectively.

In the screenshot, the Voyager GT is my exam thumb.  Just follow the arrow and click connect.  Do the same for your dongle(s).  Now, we can navigate to our exam thumb.

The first thing that I do is check my shadow volumes.  Enjoy the movie!

Remember to press Ctrl-Shift-Enter after typing cmd.  You must run vssadmin as Administrator.  We can see that we have all of our shadow volumes (there’s a time zone difference).

We’re now set to examine shadow volumes just as we did before.  Run Dan Mares’ VSS and map all or any of the shadow volumes.  Dan has made VSS quite intuitive.  Before  you go forth and mount all shadow volumes, I’ll offer a suggestion.  Start with only the first (earliest), and maybe the second.  You’ll find that navigating your VM will be a lot easier if you install VMware Tools in the VM.  Doing so, however, will create a restore point and risk deleting one or more shadow volumes.

Of course, you always can go forth, install VMware Tools right away, and re-check your shadow volumes.  After all, snapshots are your friend.  If you work in your VM long enough, new restore points will be created regardless of whether you install anything.  If you just want to do a quick check of the earliest shadow volume, or have just a very focused exam in mind, tune in next time for a quick tip on shadow volume “instant gratification”!