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!

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.