Tuesday, September 04, 2018

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 vss_carver.py.

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:\

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.

Addendum, 5 Sept
I've continued my testing, but before I kicked off the summary, I wanted to provide a link for vss.exe.  Thanks to Brian Maloney for tracking that down.

One thing that's been clear over the past day or so is that even providing clear documentation (above) as to what I did, and where I got the tools, there's been a significant disconnect with respect to those offering assistance.  It appears that the biggest one is that when we say "Arsenal Image Mounter", apparently, we're not all referring to the same thing.  I got a copy of Arsenal Image Mounter from Github, not from the from the main ArsenalRecon.com web site, and that appears to make a significant difference.  In particular, the option to mount a raw/dd image in "Write Temporary" mode is specifically NOT supported in this version of the tool.

So, to clarify, what I've been looking to do is get working processes for accessing VSCs within acquired images, using free and/or open source tools that run on Windows.

To get this version of Arsenal Image Mounter to work, I had to do a couple of things.  First, I had to download libewf.dll (My system is x64, so I used the DLLs from this location).  I then copied the libewf.dll from my Autopsy installation over to the same folder as the Arsenal Image Mount tool, overwriting the older version of libewf.dll (there was some speculation online that the older version of libewf.dll was causing problems).  Finally, I had to open the E01 files from the Lone Wolf scenario, rather than the raw/dd format image (I'd opened the E0x image files in FTK Imager and exported a raw/dd image, so I had both available).  Once I did that, I was able to use Shadow Explorer to successfully view and access the VSCs.

The process that appears to work for raw/dd images is to use the Arsenal Image Mounter to mount the image file in Read Only mode, and then use vssadmin (via an Admin-level command prompt) to list the VSCs, and then mount a VSC as X:\ (or whatever you choose) via vss.exe.  Once you've done that, you can open the now mounted VSC via FTK Imager,

I'm still trying to get vshadowmount to work, as well... I got the vshadowmount method working right after I published the updated post...essentially, once you run the vshadowmount command, you can access the individual VSCs via FTK Imager, by adding one of the VSCs as an image file evidence item, rather than logical drive.  That is, when adding an evidence item to FTK Imager (after running the vshadowmount command), you choose "Image File".  Boom.  Done.


Anonymous said...

ShadowExplorer should work with Arsenal, however images must be E01 and mounted write-temporary

Anonymous said...

If you don't have a recent Arsenal Image mounter, get it and install it (requires reboot for its driver to work).
Mount the .E01 image with Arsenal Image mounter, using the Write Temporary option.
Once mounted, open Windows's Disk Manager (diskmgmt.msc) and check the new volume if it has a drive letter. If not, assign one, otherwise ShadowExplorer will not see the mounted image.
Now open ShadowExplorer and select the drive :)

sv2hui said...

Jimmy Weg blog has been archived by Brett Shavers:

Minoru Kobayashi said...

Thank you for an interesting post.
I tried to confirm this problem, too.
However, I successed to mount VSS1 with extended-libvshadow + FTK Imager, but I tested it on Windows Server 2016.
Does the problem occur only on Windows 10 1803?

ERZ said...

I just rolled this application after reading your post based on some work i had some elsewhere. I hope it makes things easier.

please let me know if theres other stuff that could be added to make it even more useful.


Troy Larson said...

If you are using a server version of Windows for analysis work, you can use the command line tool diskshadow.exe to mount shadow copies as shares, drives, or mount points. Diskshadow gives you a bit more capability than vssadmin.exe.

See, https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/diskshadow

I look forward to reading your new book.