I don’t plan to regularly post about tool updates, but I figured there’s enough in the most recent update to VSC Toolset that I might want to write a bit about it.  As indicated by the title of this post, the biggest change incorporates the ability to browse shadow copies using an Explorer-like interface.  Although you can easily write a batch file to list the directory contents of each shadow copy, it’s nice to be able to see the directory structure.  The “Browse Selected VSCs” button will open all selected linked VSCs.  This allows you to open a directory view of two (or more) shadow copies and view them side by side to visually see the differences between them.  If you find it easier to view the directory contents in another view mode other than “Details”, you can right-click on the list view pane and select a different view mode.

I’ve also tweaked how the VSCs are listed in the main interface.  For example, when you’re viewing a list of the shadow copies on a drive, you will no longer see “ShadowCopy1”, “ShadowCopy2”, etc..  Instead, you should see something like “VSC1: 4/24/2012”, “VSC2: 5/12/2012”, etc.. Including the date right beside the listing makes it quicker to determine which VSC(s) you may be interested in, based on the creation date.

Other minor updates include:

• Removed the “List Shadows” button – shadow copies are now automatically listed upon selecting the drive letter
• Logging is now in local time instead of UTC
• Added an “Open Output Folder” button that…well, opens the output folder
• Added another parameter input box, allowing for up to three additional parameters that can be specified at run time to execute against one or more shadow copies using a simple batch script
• As noted in the release notes of another recent update, jump lists and custom RegRipper plugin files now have built-in functionality with VSC Toolset (see here for more details).

I’ve updated VSC Toolset with a couple of new features, including integrating some new scripts with it.  You can now choose a specific RegRipper plugin to run against one or more VSCs (specifying either the NTUSER.DAT hive or one of the hives in the config directory).  I’ve also incorporated link file parsing (thanks for Corey for the batch file and script) and the ability to run diff.exe against two shadow copies to see only the differences between the two.  Running diff against VSCs was one of my favorite features that Corey covered in his VSC series and I wanted to make a point to incorporate it in the GUI.  It’s quite time consuming to do this, but it can be helpful if you’re interested in exactly which files have changed between VSCs.  If you decide to run diff using VSC Toolset, the GUI will appear unresponsive while its running.  I will eventually need to make the app multi-threaded to avoid this, but I have confirmed that this command does work with VSC Toolset (at least in the test runs that I’ve completed).

One change I’ve made that will affect those deciding to extend VSC Toolset by writing their own batch files is that I’ve specified a directory called “~LinkedVSC” that is created in the root of the “C:” drive to hold all symbolic links to VSCs.  The main reasoning for this is to enable a user to simply add this directory as evidence in another application such as FTK Imager if they are interested in taking a look at all linked VSCs.  I ran into the annoyance of having to add C:vsc1, C:vsc2, etc. to other applications individually instead of being able to add them all at the same time, so I created a directory to store all symbolic links to VSCs.  This doesn’t make a huge difference in writing batch files for VSC Toolset, you’ll just need to make sure you reference the symbolic link as “C:~LinkedVSCvsc%1” instead of “C:vsc%1”.

A couple of other minor improvements include not listing drive letters that do not make sense to list (non-local drives, etc.) and including the volume label beside the drive letter for easier identification.  Additionally, the second and third parameter text boxes and labels are only shown when applicable (and customized when shown).  For example, selecting “RegRipper-ntuser” from the command drop-down box displays a single text box labeled “User Name”.  Selecting “RegRipper-plugin(config_dir)” displays two text boxes labeled “Hive Name” and “Plugin Name”, respectively.  If a command does not require user-specified parameters, no text boxes are shown.  This will hopefully make it easier for those that may not be as familiar with running some of the commands that are integrated with VSC Toolset, but will likely just serve as a reminder for most.  Note that if a custom batch file is being used (one that is not currently integrated with VSC Toolset), both parameter text boxes will be displayed.

To take advantage of the LinkFiles.bat and Diff.bat scripts, you’ll need to download the respective Perl script and executable.  You can download lslnk-directory-parse2.pl from the Win4n6 Yahoo Group under FilesTools; you can download diff.exe from UnxUtils.  Both the Perl script and the executable will need to be in the same directory as the VSC Toolset executable.  Also, note that you will need ActiveState Perl or something similar to run the link file parsing command since it’s a Perl script.  As with the previous version, you can simply copy all RegRipper files into the “regripper” folder that is included with the VSC Toolset download.  You can download the latest version of VSC Toolset here.  

Volume shadow copies (VSCs) have become an important part of the forensic examination of a Windows machine, as they can provide details about user activity that was not possible in the past.  Being able to see how the system has changed over a period of time can be critical in many examinations, and VSCs can provide just that (and more).  The forensic aspects of VSCs, as well as their functionality, have been covered in detail in many other locations, so I’m not going to go over those facts in this post.  If you’re interested in some references though, check Harlan Carvey’s new book (or his blog posts here and here), Troy Larson’s presentation slides, Microsoft documentation, the QCC whitepaper, Lee Whitfield’s blog post, or Corey Harrell’s recent blog posts.

Corey Harrell’s series about VSCs provide a great way to access and examine VSCs through the use of batch scripts.  By adding a loop to the batch script, Corey displayed the ability to create symbolic links to all shadow copies (or only certain ones) on a disk quickly and efficiently. He also covered the use of adding programs like robocopy, RegRipper, and diff (available in UnxUtils for Windows, as noted by Corey) to batch files in order to target specific data or generate a specific report (such as the difference between shadow copies).  The series covered many other aspects and ideas in examining VSCs, so it’s best that you read the entire thing instead of taking my word for it.

After reading Corey’s series, I decided to explore the option of adding a GUI front-end to his batch scripts.  Although the scripts make it easy to access and rip data from VSCs, I was intrigued as to what a GUI might look like on top of those scripts.  So I decided to take a crack at writing one.  What I’ve come up with so far is a functioning GUI application that allows a user to enumerate VSCs, create and remove symbolic links to VSCs, and run a few specific RegRipper commands against them.  I’ve also built in a log pane and a results pane so that you can immediately see the results of what you’ve just done.

VSC Toolset UI

Since this app is just running batch scripts in the background, there’s a folder called “batch” that must be stored in the same directory as the VSC Toolset executable.  As you might have guessed, this is where the batch scripts will be stored.  Each file in this directory with the .bat extension will be listed in the drop down box beside  “Command” in the GUI.  The idea is that a user will be able to write their own batch file with a command to be carried out on a single volume shadow copy, store it in the “batch” folder, and the GUI app (I gave it the name “VSC Toolset”) will take care of the rest.  That is, VSC Toolset will list the batch file in the command drop down box and provide a means of inputting the parameters.  This command can then be executed against any number of linked VSCs, which are listed in the “Linked Shadows” check box list.With the current version, there is a limitation of only one additional input parameter, although I plan to expand this.  For example, VSC Toolset always passes the VSC number to the batch file as the first parameter. In some cases, this may be the only parameter we need (such as ripping data from the entire SOFTWARE hive using RegRipper).  However, in many cases additional parameters will be needed.  To account for this, VSC Toolset has a text box labeled “2nd Parameter” to hold another parameter to be passed to the batch file.  An example of passing a second parameter would be ripping a user’s NTUSER.DAT file using the VSC number and the user name.  To do this using VSC Toolset, you would simply select “RegRipper-ntuser” from the command drop down box and type the username of the NTUSER.DAT hive that you would like to rip.  From there, you can execute this command on any number of the linked shadow copies.

UPDATE: I’ve added an additional text box to the GUI to hold a third parameter to be passed to the batch file if needed.

There’s also a logging pane (the bottom of the two text panes) that keeps track of the batch files that have been executed, along with a timestamp.  This can be saved using the button below the pane, but it’s currently not saved by default.  The results pane (the upper pane) displays the results of the commands or batch files that were executed. The check box below this pane controls whether all results are saved or not.  The default is to save all results to individual text files, but this can easily be changed.  If the results are being saved, they are saved to the “output” folder that VSC Toolset creates within the working directory. The results are saved according to the batch file that created them and named by the shadow copy from which the information was gathered.  If a case name is specified using the text box in the VSC Toolset GUI, the results are divided by case name first, then batch file, etc..  Other than output directory organization, the case name value serves no purpose.