Archive for August 2012

Working With Segmented DD Images

I’ve received a few requests to present a method for creating VMware VMs from segmented images.  This post applies to dd images, as E01s still require the physical mounting method that I presented earlier.  I’ll add that you can use the same approch with a segmented dd image.  However, there are some advantages in going to a VM directly from an image.

We start with same approach as we did with building a VM from a single dd image.  That is, we create a vmdk descriptor file.  However, a little more labor is involved.  As a refresher, here’s a screenshot of the vmdk file that we created for our single dd image.

An editable copy is here.  Remember to change the extension to vmdk.  If we study the above vmdk, we’ll recall that we edited the file to reflect our physical geometry: numbers of sectors, cylinders, heads, and sectors per track.  We left everything else as supplied.  Now, we have a split image.  I’m going to assume that we’re working with 2GB segments.  That seems to be the custom or default with most imagers or examiners.  Even though it’s split, we’ll leave our vmdk type as monolithicFlat.  We start with a split image of 75 segments.

There are two important things to note from the start.  First, we’re dealing with sectors in our vmdk file, while our segments are expressed in bytes.  Next, bytes means number of bytes in the literal sense, and you should determine exactly how many bytes are in each of your segments.  Each, but the last, will be identical in size.  Open the first segment and check.

Here, we have 2,146,435,072 bytes.  That equates to 4,192,256 sectors (2146435072/512).  Our last segment, however, is 1,205,690,368 bytes, or 2,354,864sectors:

Now that we’ve done the math, we simply can substitiute our image segments for the single image file that was in our first vmdk file.

In the interest of space, I cut a bunch of segments from the screenshot.  Just place the vmdk file in the same directory as your image segments.  I’ll bet that there are a few of you who want to JustAskWeg, “Do I really have to type 75 lines in my descriptor file?”  Well, not really.  There are a few shortcuts that I can suggest.  I’m sure that there are others or better approaches, but this works for me.  First, from the command prompt at your image directory, run dir /b >[path to output]images.txt.  You’ll get a text file with contents that looks like this:

Next, copy the list into one field in Excel.  Notice that the format of our list ultimately must look the this:

In Excel, Record A1 is MyImage.001.  In B1, use the following function, but with your own number of sectors instead of 4192256:

=CONCATENATE(“RW 4192256 FLAT”,CHAR(32),CHAR(34),A1,CHAR(34),CHAR(32),0)

Hit enter, and then copy the formula down B1 to the last record in Field A.  Next copy Field B and paste it as a value in Field C.  Watch:

Next, copy Field C into Notepad.  This will remove any special formatting that Excel inserts and which will mess up your vmdk file.  Be sure to edit the size (in sectors) of your last segment.

Then, copy the list from Notepad and paste it into your vmdk file. Thereafter, it should look like the example above.  Lastly, create your VM as though it were being built from a single image.  Take a snapshot, edit the registry, remove the password if required, and sit back in awe of your power!

I want to add a note to express my gratitude to the author of, a/k/a Continuum on the VMware Forums.  His web site, as well as his forum posts, comprise the greatest wealth of knowledge about VMware that I have seen.  I’ve learned a lot from our dialog over a number of years.

“Weg, I’m afraid that I don’t have VMware. How do I Examime Shadow Volumes?”

First, you have my sympathy.  However, I’m glad that you Just Asked Weg. I’ll present one approach, knowing that there are others that also happen to be free.  To do this, were going to employ Microsoft’s Virtual Hard Drive (VHD) format.  We need a dd image, which we’ll convert to VHD format.  The converter is a command line program, VHD Tool (VHDT), that’s available freely from Microsoft.

Before we start, I want to point out that converting your image with VHDT changes your image file.  First, it adds a footer of 512 bytes.  If your image doesn’t end on a sector boundary, VHDT pads the original image with 0x00 to end on a sector.  (I think that you’re images typically will end with a complete sector.)  So, you have a couple of options.  You can create an extra image and use VHDT with the spare.  Nothing that VHDT does will affect the shadow volume data.

An alternative is to use the original and then edit the VHDT-converted image to return it to its former state when you’re done.  If you choose this approach, I’d hash the image after editing to be sure that you returned it to its original condition.  Whether you even consider this method depends on your view of actually making changes to your original image.  Remember, we started with the premise that you don’t have VMware (or some virtualization tool that uses the VMware formats).

So, let’s run VHDT against an image file, which is in the folder with our image.  First, I’ll show the screen with all of the VHDT options.

It’s pretty straightforward.  We’ll run VHDT with the /Convert option.  As in the screenshot, be sure to use the forward slash.  Note the size of the image file in the picture above the command box.  Next, we run vhdtool /convert myimage.001.

Note that the file is about 1KB larger than the original.  If we open our converted image and navigate to its end, we’ll find that the additional sector looks like this:

For those who want to produce only one image, discarding this last sector should restore your image to its original condition.  Hash it to be sure.  To show what a VHDT-converted, non-sector-ending image looks like, I present the following screenshot:

I’m sure that some will recognize that I used a “custom” image, so it was easy for me to determine positively where my original ended.  Of course, it would be just as easy to make note of where your original ends before you convert the image.

Okay, we now have a VHD file, so let’s append an extension: MyImage.001.vhd.  Next, we’ll mount our VHD file directly in Windows 7.  I begin with the Disk Management feature of Windows Computer Management.

As we mounted VHD as read-only, we won’t bother with setting that attribute with Diskpart as I demonstrated in an earlier post.  I should point out that, even if you don’t bother with Diskpart in your SEAT workstation, Windows doesn’t let you alter shadow volumes or their contents.  I seem to recall, however, that Windows may create a new restore point on your virtual disk and may delete an old one, although I haven’t tested that possibility.  Still, you could make other alterations otherwise, if you don’t use Diskpart.

At this point, we can examine our mounted disk as we would in the VMware method that I presented over the course of my posts.  As the next screenshot demonstrates, vssadmin can enumerate the shadow volumes on the system partition (K:) of our mounted disk.

When you’re done with your VHD disk, you can detach it as in the next screenshot.  That, too, is done in Disk Management, but by right-clicking on the Disk.

Note that other mounting tools, including FTK Imager and Mount Image Pro, will not mount an image in manner that allows you to access (allows you to mount) shadow volumes.  Mounting a VMware vmdk file with VMware also will not work.  Third party tools, e.g., WinMount, which can mount VHD files also produce a volume on which we can’t access shadow volumes. It seems that, if you can’t see your mounted image in Windows Disk Management, you won’t be able to access the shadow volumes.

Once your VHD is mounted, you can proceed with a shadow volume exam as though you were working in VMware.  Dan Mares’ vss will work splendidly, as will X-Ways Forensics.  I’ll also point out that you can probably boot your VHD image in Windows 7 with Windows VHD Boot or Microsoft’s Virtual PC, though I’m not conversant in their use.

If you have only an E01 image and don’t have VMware, you’ll have to convert it to a dd and then convert the dd to VHD.  One topic that’s on my agenda is doing a shadow volume on a mounted E01.

Incorporating Shadow Volume Evidence Into Our Case

In my last post, I reviewed how we gather evidence from shadow volumes and copy the evidence into X-Ways Forensics (XWF) Containers, which are akin to image files.  I promised to present a method for incorporating the XWF containers into our primary case, but then I segued a bit and got into building VMs from e01 image files.  I’ll get back on track in this post, but there are a few things that I want to cover first, to bring my audience up to date.

We used XWF to identify relevant files and then we copied them, and their metadata, into XWF Containers that we created for each shadow volume.  Well, Stefan Fleischmann, XWF’s creator, has issued yet another enhancement to XWF, which makes the Container process easier.  Now, we need only create one Container that will hold files from any number of shadow volumes and their objects.  Watch.

We added all evidentiary files to a single container.  This can be a real time saver if you have many shadow volumes in your case.  We’ll see the end results later, but remember that our report table names identify the shadow volume from which each file derived.

I also want to point out another XWF feature, which is creating custom names for evidence objects.  Again, XWF offers “X” ways of doing things.  The choice is yours.

My esteemed colleague and “personal programmer” Dan Mares has again enhanced vss.  In brief, vss now can mount all, or any consecutive number, of shadow volumes with one simple command and without being concerned about the beginning drive letter.

VSS will find the first available drive letter and go forth.  It will warn you if you run out of letters, and you can see that I received a warning after the program completed.  In my case, I had reached Volume Z:, which was okay as all of my shadow volumes had mounted.  As Z: is the last letter, VSS told me to double check to be sure.  VSS even will skip used drive letters automatically.

VSS now offers a couple of handy ways to dismount all shadow volumes at one time.

We can simply run the batch file, unmount_log or use the command vss mounted_log.txt.  The text file is a simple string that identifies all mounted volumes.  You still can mount or unmount selected, individual volumes.  be sure to get the Help file at Dan’s site.

Now, we’re ready to add our shadow volume evidence to our main case.  If you close XWF in your SEAT VM, the Container will close, too.  However, you have a few options within XWF.

By creating an E01 image, you can share the evidence with those who prefer that format.  The other options are self-explanatory.

Lastly, just copy the XWF Container from your SEAT workstation to your host system.  I usually copy it to the location of my image file.  We’ll start with our main case open in XWF.

As you can see, all of the evidence from our shadow volume exam now is in our main case.  The shadow volume evidence will be included seamlessly in our XWF report, and our clients will see quite clearly, where every file of interest has been found.



Creating a VM from E01 Images

My first post described how to build a VMware VM from a single dd image.  A few folks “just asked Weg” to demonstrate how to do that from E01 images.  Note that it doesn’t matter whether we start with a single or segmented E01 image (or whether we use a single or split dd image).  Why?  Because we’re going to build a VM from a physical disk, which really is a virtual disk that was mounted from an image.  With regard to E01 images, we have to create a physical disk because VMware can’t translate an E01 image as it can a dd.

I’ll mention again a tool named Virtual Forensic Computing (VFC), which can automatically build a VM from either a dd or E01 image.  It, too, requires that you first mount your E01 as a physical disk.  VFC’s creator, Michael Penhallurick is a brilliant fellow to whom I owe a debt of gratitude for helping me get started in virtualization.

In case some of you don’t mount images very often, I’ll provide a video on the process.  There are several free or cost-based tools through which you can mount an image.  I’ll use AccessData’s FTK Imager, which is freely offered at

We’re going to do things in somewhat of a reverse order from where we built a VM from a dd image.  The first step is to create a VM in VMware from our mounted image.  After you watch the video, I’ll explain a few things.

First, note that VMware must be opened after you mount your image. When VMware is opened, it enumerates disks on the system.  Unless you re-open VMware, it will not see your newly mounted disk.  I’ll also point out now that your image must be mounted whenever you want to access the VM or the virtual disk.  We basically created a VM as we did in my first post, and used most of the same options.  We ignored the warning about the need for “expertise” when using creating a VM from a physical disk.  If I were creating a VM from a “real” disk, I may be more concerned.

VMware does not allow snapshots of physical disks inherently.  We have to make VMware think that the disk really isn’t a physical disk.  To do so, we’ll edit the VMware configuration file, which is the VMX file that VMware created when we built our VM.  That file is in the folder to which we pointed VMware when we created the VM.  Below is a screenshot of the relevant portion of the VMX file, which is a text file.

We can see the highlighted line, which tells VMware that we’re using a physical disk.  We’ll edit that line as follows:

We removed the string “raw,” which changed “rawDisk” to “Disk.”  You also may notice that VMware created a vmdk file in the same path.  Usually, we don’t need to edit this file.  If you haven’t done so, either close VMware or close your new VM.  Then, re-open the VMware or the VM.  Navigate to VM\Snapshot:

Now, snapshots are available!  Take a snapshot.  If you go back to your VM’s folder, you just may see 150 snapshot files.  Don’t be alarmed.  VMware will split snapshots in this situation, but it has no effect on our mission.  I will say that VFC has figured out a way to avoid splitting snapshots.

At this point, you can go back to my first post  and see how to edit the registry and remove passwords.  After mounting our disk as writable, we’ll make sure that the LSI_SCSI service Start value=0, and we’ll strip any passwords (remembering EFS issues).

We now have a bootable VM of our E01 image.  It really doesn’t take any time at all to get to this point.  However, we’ll approach our shadow volume exam a little differently in this case.  We’ll do it from within out running VM, and I’ll go into that in my next post.