Tuesday, January 04, 2011

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?

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
ImDisk 1.3.1
Mount Image Pro (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.


Troy said...

Beautiful. I am doing a more in depth presentation about VSS. There are so many details, and I want to get them right.

I will send it out when it is done. Of course it will be public and available to all.

Thanks for pointing out diskpart. This is a very useful tool for forenics and data recovery. Anyone working on or with Windows should master it.


DC1743 said...


Thanks for the info.

Over and above what I blogged about in Forensics from the Sausage Factory and pertinent to the scenario detailed above in your post, I think you could add the vmdk you have as an additional drive to another Windows 7 VM in VMWare.

This additional drive will then get a drive letter and from then on the robocopy method may be carried out from within this additional VM.

Best wishes

Richard Drinkwater

H. Carvey said...


Thanks, I tried that...added the vmdk file to my Windows 7 VM as an additional disk and clicked "Power on this virtual machine". I immediately got an error message about being unable to open the vmdk file due to "insufficient permission to access file". I'm an admin on the system I'm using, and should have full access to vmdk file, as well as the raw/dd file it points to, per the permissions I see.

H. Carvey said...


I went back and added the vmdk file as a nonpersistent disk.

When I added the disk file, under "Mode", I selected Independent, and Nonpersistent. That allowed me to boot the VM. I'll need to run the VM from a system with more RAM after I upgrade VMWare Workstation, but it appears to work.

I would still recommend using FTK Imager to make a raw/dd image of the vmdk file, as that would serve as your "working copy", leaving your original "evidence" untouched. Further, using vhdtool provides for a completely free solution, where you would need to purchase VMWare Workstation, or somehow obtain a valid Windows 7 VM to use in VMPlayer.


Jimmy_W said...

Disks mounted with vmware-mount also will not allow access to the shadow volumes with vssadmin. Only Encase/PDE. You also could take a snaphot of your vmdk and boot i, as an alternative to the change in persistence.

As I've suggested before, absent EnCase, it's easiest to access the shadows in a VM made from an image. Just make your image R/O, create a vmdk file in WordPad, snapshoot the machine, and boot. Your image will remain untouched. Shadow Explorer works well in an image, but mklink is handier. Shadow Explorer is painfully slow, too. Robobcopy probably works well, but you also can use FTK Imager to create image files from folders of interest, and that's probably a better approach insofar as maintaining evidence is concerned.

You could also run a command to mount all of the shadows at once. Otherwise, just arrow-up in your mklink command box and edit the shadow number to increment it upward to the next (I delete the finished shadow in explorer beforehand).

It's handy to run a tool like XWF in your VM to do a quick exam of a mounted shadow. For that matter, you can add objects to an XWF Container as an alternative to FTK Imager. Of course, you can image the shadow if neccessry, though you'll get a lot of unnecessary stuff.

H. Carvey said...


Thanks for all of the comments.

What about not using VMWare at all? I'm not saying that you can't, but when you look at all of the steps required, if you have a Windows 7 system already, simply using vhdtool would seem to be much easier...I'm just sayin'...

Corey Harrell said...

As it relates to the registry, something I found useful was to make comparisons between ntuser.dat files in order to see what activity occurred on a certain day. I extract the ntuser.dat files from the VSS before and after the day of interest. I compare the files using the program you suggested in the Win4n6 group which was regdiff.pl in the Parse::Win32Registry module. This is just another option to help see what occurred on a certain day.

Jimmy_W said...

Perhaps, but I build a VM in almost every one of my cases. For one, it's a relatively quick and foolproof way to check config settings on current applications. It also give me a "feel" for the user that I just don't get from an image.

Jimmy_w said...

Oddly enough, the G:\ drive is NOT a visible option in ShadowExplorer.
Shadow Explorer only will address shadow volumes from within the same volume as it is invoked. So, if you boot to C:\, that's where it will access the shadows.

Antoher option is to restore the image to a disk. Then, attach the disk to Vista/7, and go about the vssadmin/mklink process. (Or boot the original system with a VOOM.)

Gary Evans said...

We have updated the procedure outlined in the QCC Whitepaper. Creating the hard links using the 'mklink' command was based on the shadow copy number shown in the vssadmin output i.e. VolumeShadowCopy1 (rp1). This is all very well but if you, or someone else, needs to repeat the analysis or provevance a particular file that you have extracted, knowing that it was from 'rp1' doesn't help. This is because when you remount the image in the same or another workstation it does not have the same shadow copy number.
We now use a small script to name the hard link in accordance with the date that the shadow copy was created. This makes provenancing extracted files much easier.

Gary Evans said...

It's been a while but I seem to remember finding little cross tool support for FTK Imager logical evidence files (particularly for EnCase users...). I haven't used FTK logical evidence files for a while so this may have changed. I would otherwise agree that it would in some ways be better than using robocopy. The method we have developed though is very good at quickly targeting particular file types, pictures, movies etc, albeit by extension. Of course, one of the limitations of this approach is the potential to miss files through the lack of signature analysis. Using wildcards to extract all folder files is one way to overcome this but I guess there is a trade off to be made between the time and space you have available and what sort of data you are looking for.

Jimmy_W said...

...I seem to remember finding little cross tool support for FTK Imager logical evidence files

True. If you have FTK (I do, but use it rarely), it'll work fine. The other approach with using XWF and creating evidence containers also works, but you need XWF (perhaps only the Investigator version) thereafter. My exams of shadows volumes typically are quite focused, requiring information from select folders.

Jimmy_W said...

My last comment (in response to Gary's) hasn't posted yet, but I'll add another nonetheless. One other benefit of using a VM to access shadow volumes is the ability to repair the VSS when it's corrupt and you cannot access the volumes. Usually, the repair requires the editing of the system registry or registering DLLs that might have been missing.

If you add an image of a disk through PDE, or through a cloned drive, to your system, you still can't access the shadow volumes on the damaged target. I've had only a couple of cases like this, but the repairs seem to be required on the live system that contains the shadow volumes. Perhaps a far greater talent like Troy can explain this further.

H. Carvey said...


Could you explain what you mean by "repair"? I don't know if anyone has seen anything like that mentioned before.

Also, why can't you do the same thing if you mount the image as a VHD, as opposed to a VMDK?

Jimmy_W said...

Well, let's say that you're in a VM and run vssadmin list shadows /for=x: and you're presented with something like "Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance. hr = ." The fix probably requires either edits to the registry and/or re-registering certain DLLs. Trolling through listserves and MS Tech can yield the answers. In my last case, the fix came from simply deleting a key and restarting the services.

I believe that you're going to have to do this type of repair on a live (VM) system. The VSS on your target is damaged; not on your host. From a test or two, I found that I could not access the shadows on a mounted drive (clone of original) when I attached it to a good system. I'll liken it to trying to run a typical program from an attached drive; it doesn't work. I suppose that you could test this by corrupting the registry on an image and going forth with the VHD approach.

H. Carvey said...

...the fix came from simply deleting a key and restarting the services.

Can you share which key that was?

Also, you refer to a repair...can you elaborate?

Jimmy_W said...

Certainly. HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions

By repair, I mean fixing the system so that VSS works. You can start by registering the DLLs and if that fails (and I haven't had much luck with that approach), I delete the above key. The DLL fix is as follows (run from %systemroot% after making sure that the services are stopped):
regsvr32 ole32.dll
regsvr32 vss_ps.dll
vssvc /Register
regsvr32 /i swprv.dll
regsvr32 /i eventcls.dll
regsvr32 es.dll
regsvr32 stdprov.dll
regsvr32 vssui.dll
regsvr32 msxml.dll
regsvr32 msxml3.dll
regsvr32 msxml4.dll

MS has a hotfix for Server 2003, and it doesn't work on Vista/7.

Jimmy_W said...

One more thing about working in a VM. You must take care that you don't lose the earliest shadow volume when the machine boots. That can happen if allowed disk space is near max and it's time to create a restore point. Just make sure that you study your image to be sure that they're all there in the VM.

I usually examine the earliest shadow before I install VMware Tools, as the install will create a restore point. Installing Shadow Explorer may do so, too. Plus, just lingering too long will have the same effect.

H. Carvey said...


Is that a result of booting the acquired image, and would it also affect the image if you booted your VM with the image/vmdk added as a disk?

Jimmy_W said...

I wouldn't say that it's a "result" of booting the image. It's just going to happen at a certain time or upon a certain event. I'm not really sure what you mean, however. The image is added as a virtual disk. You're booting the virtual disk, which really is the image.

Travis said...

"I want to access files within the VSCs in an acquired image, and I don't have EnCase/PDE."

The iSCSI solution...

1) Expose the disk image as an iSCSI target on your host or a VM.
2) Connect to the iSCSI target using iSCSI initiator from a Windows host or VM and access the VSC.

As an example:
Setup an iSCSI target using a SIFT Workstation VM. Get the image setup as a linear file (e.g. "mount_ewf.py IMG.E01 /mnt/raw" or "affuse IMG.001 /mnt/raw"). So the file /mnt/raw/IMG appears as a dd/raw of the whole disk. Modify the iSCSI enterprise target daemon configuration (/etc/ietd.conf) as below and restart the daemon (service iscsitarget restart).

# ietd configuration
Target iqn.2011-04.sift:storage.disk
Lun 0 Path=/mnt/raw/IMG,Type=fileio,IOMode=ro

Start iSCSI Initiator on a Windows 7 VM, type in the IP of the SIFT VM and connect.

H. Carvey said...

In WFAT3e, I cover how to do this remotely using F-Response...

Anonymous said...

Hi Harlan,

Sorry to raise and old thread but it was the best method I had for contacting you.

What i'd like to know is whether or not I could use FTKImager via psexec. ie copy ftkimager files, get shell, execute ftkimager to copy only registry and user hives and create dir listing.

I can see ways to image the complete physical drive but not just specific areas? The reason is that many of the machines i deal with a remote and we are unable to connect drives to the machine for imaging. So i need to limit to just what i need to create a solid timeline.

Any help appreciated

H. Carvey said...

While FTK Imager does have command line options, it doesn't appear that you can specify just certain files to acquire.

As such, you may want to look at dd, or F-Response. In fact, I have used F-Response to do exactly what you're asking about...

Another option is to, rather than "imaging" the Registry hives, use WMI and other remote means to acquire the data that you're looking for.

Anonymous said...

thanks for the reply harlan. Since speaking with you last I've found a number of tools that assist me to copy the required items.
Firstly hobocopy
"It uses the Volume Shadow Service (VSS) to "snapshot" the disk before copying. It then copies from the snapshot rather than the "live" disk."

Secondly the reg tool within windows to dump registry hives
- for example reg save HKLM\SAM SAM

Do you see any issues with the above for gathering copies of the hives?

I noticed that FTKImager Lite has command line options for /CreateDirListing however i haven't had any success with this. Do you know if command works only on already taken images or does it work against live systems too? If so do you have an example of the command line you'd use for a physical drive.

Thanks in advance and i hope you find some of it useful too.

H. Carvey said...


Unknown said...

I know I'm way late on this, but I a) wanted to say thanks, and b) wanted to add that I have managed to mount VSCs using Paraben's P2 Explorer (which is free).

Also, Corey Harrell's blog (Journey Into Incident Response) has a good guide on using the SIFT workstation and iSCSI to do this.

Thanks again!

H. Carvey said...



I've seen what Corey says about using iSCSI...I'm glad he posted it, but it does seem like a lot of work, and a lot of moving parts...

Unknown said...

Ha ha, yeah, it is slightly more work to get it running (even though his guide was spot-on, which is great for a still-fairly-n00b Linux user like me), however I like to have a few ways of doing the same things, especially since I've had a few occasions when P2 Explorer didn't want to mount the evidence.

H. Carvey said...

Agreed...sometimes, the VHD Method is just too easy, and hard to accept...because it's so easy...

Sometimes, if I need to, I'll use FTK Imager to export the entire directory structure. That can work very well.

Unknown said...

Possibly about to expose my lack of knowledge, but...

Besides using mount_ewf.py, is there another way of mounting an .e01 image as a dd image? I want to go through the process you've described in this post, but all my evidence is in e01 format. Which brings me to a second question: do you have a preferred format to acquire to? Sorry to bombard you.

H. Carvey said...


Send me an email at keydet89 at yahoo dot com...this is not the best way to go about this exchange...