Accessing Volume Shadow Copies

Over the past months, I've had some work that involved Windows systems beyond XP...specifically, one Windows 7 system, and I had some work involving a Vista system. Now, most of what I looked at had to do with timelines, but that got me to thinking...with the number of systems now available with Windows 7 pre-installed (which is pretty much everything that comes with Windows pre-installed), how much do we really know about accessing Volume Shadow Copies (VSCs)?

Troy Larson, the senior forensic-y dude from Microsoft, has been talking about Volume Shadow Copies for quite some time. In his presentations, Troy has talked about accessing and acquiring VSCs on live systems, using George M. Garner, Jr's FAU dd.exe; however, this requires considerable available disk space.

Troy's SANS Forensic Summit 2010 presentation can be found here. In his presentation, Troy demonstrates (among other things) how to access VSCs remotely on live systems, using freely available tools.

ProDiscover - Chris Brown has a presentation available online (from TechnoSecurity 2010) in which he discusses using ProDiscover to access and mount Volume Shadow Copies on live systems...remotely. Pretty cool.

I ran across a QCCIS whitepaper recently that discusses mounting an acquired image using EnCase with the PDE module, accessing the VSCs using the same method Troy pointed out, and then copying files from the VSCs using robocopy. There are also a number of posts over at the Forensics from the sausage factory blog that address VSCs, and a couple that include the use of robocopy. As I often work with acquired images, being able to access VSCs within those images is something I'm very interested in being able to do. However, most of my online research points to folks using EnCase with the PDE module to mount their acquired images when demonstrating how to access VSCs within those images...and I don't have EnCase.

So...what if you don't have access to EnCase or the PDE module? How could you then access Volume Shadow Copies within an acquired image?

Testing
I started out with a host system that is a fresh install of Windows 7 Professional, 64-bit. The acquired image I started with is of a physical disk of from a 32-bit Vista system; as it's an image from the physical disk, it has several partitions, including a maintenance partition. The acquired image is called "disk0.001". I also extracted the active Vista partition as a separate raw/dd image, calling it "system.001". I verified the file systems of both of these images using FTK Imager to ensure that I could 'see' the files.

So here are the tools I installed/used:
FTK Imager 3.0.0.1443
ImDisk 1.3.1
Mount Image Pro 4.4.8.813 (14 day trial)
Shadow Explorer 0.8.430.0

So the first thing I did was mount the image using FTK Imager 3.0, and noted the drive letter for the third partition...in this case, I:\. I opened a command prompt and used the 'dir' command to verify that I could access the volume. I then typed the following command:

vssadmin list shadows /for=i:

This got me an error message:

Error: Either the specified volume was not found or it is not a local volume.

Okay. I fired up ShadowExplorer, but the I:\ drive was not one of the options available for viewing.

I tried mounting the system.001 file, and then tried both image files again using ImDisk, and each time got the same result...running the vssadmin command I got the above error message. I also tried using the "Logical Only" option in FTK Imager 3.0's "Mount Type" option, and that didn't work, either. So, at this point, I was failing to even identify the VSCs, so I could forget accessing them.

I reached out the QCCIS guys and John responded that FTK Imager 3.0 seems to mount images so that they appear as remote/network drives to the host OS; as such, vssadmin doesn't 'see' VSCs on these drives. This also explains why ShadowExplorer doesn't 'see' the volumes, and why I get the same error message when using ImDisk. I also got in touch with Olof, the creator of ImDisk, and he said that ImDisk was written using the method for creating drive letters available in NT 4.0, prior to the Volume Mount Manger being included in Windows; as such, getting ImDisk to mount the volumes as local disks would require a re-write. Thanks to Olof for ImDisk, and thanks to Olof and the QCCIS guys for responding!

I then installed the VMWare VDDK 1.2 in order to get a version of vmware-mount that would run on Windows 7. I had booted the acquired image using LiveView, so I had a .vmdk file on my drive for this image. After installing the VDDK, I ran "vmware-mount /p", and clearly saw the 4 volumes within the image...I knew that I wanted to access volume 3. I then ran the following command:

vmware-mount /v:3 x: f:\vista\disk0.001.vmdk

This resulted in an error message stating that vmware-mount could not mount the virtual disk. Checking the log file that was produced, the first message I see is that the image file, disk0.001, "failed to open (38): AIOMgr_Open failed." I'm still researching this one...

Getting It To Work
So, at this point, I'm stuck...I want to access files within the VSCs in an acquired image, and I don't have EnCase/PDE. So far, my attempts to just see the VSCs have failed. So, I grabbed a copy of vhdtool.exe, which is available from MSDN (it is described as "unmanaged code"). Originally, I wanted to get a copy of this as I have XPMode installed on my Windows 7 Professional system, which means I have Virtual PC...but I don't want to boot the vhd file at this point, so that's not a required component. So I made a copy of system.001 to another storage location and ran the vhdtool.exe with the "/convert" switch. This apparently adds a footer to the file...which I'd read about during my research and is the reason I made a copy of system.001 to work with (don't want to muck up my original in case all of this doesn't work...know what I mean?). I should note here that running the tool adds the VHD footer to the file without changing the file name...so even though I apparently now have a VHD file, I can still see only "system.001".

Next, I opened the Computer Management interface in Windows 7 and fired up the Disk Manager. I then chose Action -> Attach VHD, and browsed to my new VHD file. Before clicking "OK", I made sure to check the "Read-only" box. I then had Disk2 added to Disk Manager, and the Volume listing included a new G:\ volume. In both instances, the drive icon was light blue, as opposed to the grey drive icon for the other drives on my system. When I ran the vssadmin command against the G:\ drive, I could see the VSCs! Oddly enough, the G:\ drive is NOT a visible option in ShadowExplorer.

Next, I ran the mklink command against the last VSC identified on the G:\ drive. To do this, I selected everything on the line following "Shadow Copy Name:"...the stuff that says "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy40".

mklink /d c:\vista \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy40\

Note: The final trailing "\" is EXTREMELY important!

From here, I could now access the files within the VSC. Several folks have mentioned using robocopy to get copies of files from within the VSCs, using something as simple as a batch file. See the QCCIS whitepaper for some good examples of the batch file. This is a great way to achieve data reduction...rather than acquiring an image of the VSC, simply mount it and access the files you need. Another idea would be to use RegRipper (include RegRipper's rip.exe in a batch file) or a forensic scanner to access and retrieve only the data you want. For example, when you access a user's UserAssist key and parse the information, if they've taken an action before (launched an application, etc.), you only see the date/time that they last took that action, and how many times they've done this. By accessing VSCs and running RegRipper, you could get historical information including the previous dates that they took those actions. Let's say that you use something similar to the batch file outlined in the QCCIS whitepaper, and include a command similar to the following (you may need to modify this to meet your environment):

rip.exe -p userassist -r D:\vsc%n\ > user_ua%n.txt

Now, this assumes that your VSCs are mounted with mklink under D:\vsc; %n refers to the VSC number.

Something similar would also be true with respect to MRU lists within the Registry...we know that the LastWrite time for the key tells us when the most recently accessed file (for example) was accessed; accessing VSCs, we can see when the other files in the MRU list were accessed.

When you're done accessing the mounted VSC, simply remove the directory using rd or rmdir. Then go back to your Disk Manager, right-click the box to the left in the lower right pane, and select "Detach VHD".

If you need a command line method for doing this, take a look at diskpart...you can even include the list of commands you want to run in a script file (similar to ftp.exe) and run the script using:

diskpart /s

This, of course, leads to other questions. For example, we've seen how, if you have a full image, you can use vhdtool to convert the image file to a vhd file, or extract the pertinent partition (using FTK Imager) and convert that raw/dd image to a vhd file. But, what if you have a vmdk file from a virtual environment? One option would be to use FTK Imager to re-acquire the file to raw/dd format; FTK Imager opens vmdk files, as well as EnCase format images, just fine.

There's a tool available from the VMToolkit (produced by the VMWare folks) that will reportedly convert vmdk files to vhd format. Apparently, Starwind has a free converter, and some have mentioned that WinImage should work, as well. I haven't tried any of these, so YMMV.