Accessing Volume Shadows, Revisited

Almost 3 yrs ago, I published this blog post regarding accessing VSCs, via several different means.  I recently did some testing, revisiting the methods, and oddly enough, I couldn’t get the several of them to work.  I posted to Twitter, but due to the nature of the medium, things started to get out of hand.  As such, I thought I’d post what I’d done, so that others could try the same methods, and see if maybe they could get the processes to work.

My analysis system is Windows 10; when I open a command prompt, I get “Microsoft Windows [Version 10.0.17134.228]”.

I downloaded the *.e01 images files from the LoneWolf scenario that is available via the Digital Corpora site.  The image is of a physical Windows 10 system.  I then used FTK Imager to convert the split *.e0x images files into a unified raw/dd-style image, and I used that file (i.e., lonewolf_dd.001) in all of my testing. 

Vhd Method
This method is defunct, in part because it no longer seems to work.

I did try vhdxtool, as well, but that didn’t work at all…I’m not working with a .vhd file that needs to be converted to a .vhdx file, I’m using a raw/dd-style image.

This method requires Dokan 0.7.4 and pretty much follows along from the Libvshadow section of my previous post.  For this attempt, I used the extended libvshadow tools provided with

First, I used mmls (from the TSK tools) to determine the offset to the partition of interest:

mmls -i raw -t gpt g:\lonewolf\lonewolf_dd.001

From that, I saw:

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Safety Table
01:  -----     0000000000   0000002047   0000002048   Unallocated
02:  Meta    0000000001   0000000001   0000000001   GPT Header
03:  Meta    0000000002   0000000033   0000000032   Partition Table
04:  00       0000002048   0001023999   0001021952   Basic data partition
05:  01       0001024000   0001226751   0000202752   EFI system partition
06:  02       0001226752   0001259519   0000032768   Microsoft reserved partition
07:  03      0001259520   1000214527   0998955008   Basic data partition
08:  -----   1000214528   1000215216   0000000689   Unallocated

The partition we’re interested in is the one in bold, and the offset is 1259520 sectors, or 644874240 bytes.  Using that information, I can run vshadowinfo (I don’t have to, but I can):

vshadowinfo -o 644874240 g:\lonewolf\lonewolf_dd.001

From the output of the above command, I can see two VSCs, which is what I expected.  Now, for vshadowmount:

vshadowmount -o 644874240 g:\lonewolf\lonewolf_dd.001 x:<br />
After running this command, do not expect the command to exit…it won’t, until you hit Control-C.  I minimized the command prompt (which was running with Admin privileges) and could see “VSS1” and “VSS2” in the X:\ volume via Windows Explorer.

Next, I opened FTK Imager, and added the X:\ volume as an logical drive evidence item, or I tried to.  I got an error dialog that said simply “Incorrect function. (1)”.   

I then opened Autopsy 4.8.0, and tried to add the volume as a local disk data source to a case.  Unfortunately, unlike FTK Imager, Autopsy did not ‘see’ the X:\ volume.

Arsenal Image Mounter
I downloaded Arsenal Image Mounter, and used it to mount the image file.  When mounting, I chose the “Read Only” option (the “Write Temporary” option was grayed out, and reportedly not available for raw/dd-style images).  The image was mounted as “F:”, and I could easily browse the volume via Windows Explorer. 

I had also downloaded ShadowExplorer 0.9, and when I opened it, it did not recognize the F:\ volume.  I could see C:, D:, and G:\ (ext HDD where the image was stored). 

Vss Method
Finally, I tried vss.exe, mentioned in my previous post; however, I should note that Jimmy Weg seems to no longer maintain his “justaskweg” domain, or the site(s) referenced in my original blog post.  Further, the copy of vss.exe that I have has no identifying information (file version info), nor any syntax info. 

I mounted the image via Arsenal Image Mounter (just like I did above), and got identifiers for both VSCs:

vssadmin list shadows /for=f:

I copied the ID for one of the VSCs to the clipboard, and then pasted it into the following command:

vss x: Shadow Copy Volume: \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy47

The response I got back was:

Drive X:  —> \Device\HarddiskVolumeShadowCopy47

Okay…that’s a start.  I then opened FTK Imager and added the X:\ volume as a logical drive evidence item, and was easily able to traverse through the image, just as I normally would.

Of all of the methods tested, only vss.exe in conjunction with Arsenal Image Mounter was the one method that worked. 

Article Link: