Volume Shadow Copy Forensics - the Robocopy method Part 2

Without further ado this post will build upon Volume Shadow Copy Forensics - the Robocopy method Part 1. In part one we looked at using Robocopy to extract data from a single shadow copy at a time. We will now look at a method to extract data from a range of shadow copies in one go. I will also cover some slightly more advanced options.

What are we going to need?
For what follows we will need a Windows 7 box (real or a VM), Encase with the PDE module and some storage space formatted NTFS. Robocopy is pre-installed within Windows 7.

Method
You will already have an Encase image of the drive you wish to investigate. When this is loaded up into an Encase case you need to gather some information in respect to the shadow copies you wish to investigate further. You will need to note the File Creation dates and if you wish to be more precise establish the Shadow Copy IDs stored at File Offset 144 for 16 bytes - bookmark as a GUID in Encase. Next you will have to mount the volume containing the shadow copies as an emulated disk using the Encase PDE module with caching enabled. On my box the mounted volume was allocated the drive letter J. I am using a Windows 7 box - if you are using a Windows 7 VM add the PDE mounted disk to the VM as an additional hard disk. Then on your box or in the VM:

Run a Command Prompt as Administrator and type the command (substituting J for the drive letter allocated to your mounted volume and G:\Shadows with the path of your export directory):

vssadmin list shadows /for=J: > G:\Shadows\list_of_shadow_copies.txt

This will create a text file containing a list of available shadow copies. From the list we can identify a range of shadow copies that we wish to investigate further. We now need to create symbolic links to them using the command:

for /l %i in (22,1,24) do mklink /d c:\Users\Richard\Desktop\Symbolic\SC%i \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy%i\

note: there is not a space after the ?

This command will create symbolic links for all shadow copy IDs starting at 22 up to 24. Obviously vary the (22,1,24) part to suit - 22 is the start, 1 increments by 1 and 24 is the end value. The symbolic links in this example are being created in a folder C:\Users\Richard\Desktop\Symbolic that I have allocated for this purpose. Many walk throughs, including ones I have prepared, often create the symbolic links at the root of C. Vista and Windows 7 do not like files being stored there so I think it is better practise to create the symbolic links in a user area.

OR
If you do not wish to process a range of shadow copies but need to process more than one or two you can instead use the command:

for %i in (18 20 22) do mklink /d c:\Users\Richard\Desktop\Symbolic\SC%i \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy%i\

note: there is not a space after the ?

In this example the command process only shadow copy IDs 18, 20 and 22.

Next we will run robocopy over the range of shadow copies we have selected:

for /l %i in (22,1,24) do robocopy c:\Users\Richard\Desktop\Symbolic\SC%i\Users G:\Shadows\SC%i *.jpg *.txt /S /COPY:DAT /XJ /w:0 /r:0 /LOG:G:\Shadows\Robocopy_log_SC%i.txt

OR
for %i in (18 20 22) do robocopy c:\Users\Richard\Desktop\Symbolic\SC%i\Users G:\Shadows\SC%i *.jpg *.txt /S /COPY:DAT /XJ /w:0 /r:0 /LOG:G:\Shadows\Robocopy_log_SC%i.txt

where you are interested in just specific shadow copies.

This command will create output folders named after each selected shadow copy along with a log of what has been copied. These items are being stored within an export folder prepared for the purpose. In this example I have drilled down to just the Users folder and copied out only jpg and txt files. Please see Part 1 for a detailed explanation of the options used in the command. The output folders can be dragged into Encase as single files. All paths and timestamps have been preserved.

Network Shares instead of Symbolic Links alternative
In part 1 I touched upon possible permission and copying errors. Troy Larson from Microsoft commented that creating shares instead of symbolic links may overcome some issues. So as an alternative the command:

for /l %i in (22,1,24) do net share SC%i=\\.\HarddiskVolumeShadowCopy%i\

will create network shares entitled SC22, SC23 and SC24 for the shadow copy IDs 22-24. We can now use robocopy to copy data out of these shares:

for /l %i in (22,1,24) do robocopy \\localhost\SC%i\Users G:\Shadows\SC%i *jpg *.txt /S /COPY:DAT /XJ /w:0 /r:0 /LOG:G:\Shadows\Robocopy_log_SC%i.txt

In this example I am accessing the shares on the same box hence localhost but of course you can run this across a network. The resulting data is as before.

Incorrect Function
You may run into what I think is a permission related error - clicking on the symbolic link results in

or you see

2010/04/12 15:25:28 ERROR 1 (0x00000001) Accessing Source Directory c:\Users\Richard\Desktop\Symbolic\SC22\Users\Incorrect function.

in your log file.

I have tried myriad ways to overcome this - trying to take ownership of the Shadow Copies using cacls, icacls and everything else but the kitchen sink. However I did eventually find a workaround. In Volume Shadow Copy Forensics.. cannot see the wood for the trees? I discussed imaging shadow copies using George Garner's Forensic Acquisition Utility. This utility appears not to have this issue so the command

for /l %i in (22,1,24) do dd if=\\.\HarddiskVolumeShadowCopy%i of=G:\Shadows\%i.img bs=512 count=1 --localwrt

will image just one sector of each shadow copy in our range. This takes just a few seconds. Then after imaging make your symbolic links or network shares. The Incorrect Function issue is overcome. Don't ask me why.

Cleaning Up
At the conclusion of your investigations you will want to remove the symbolic links or network shares you have created.

To remove the symbolic links

for /l %i in (22,1,24) do rd c:\Users\Richard\Desktop\Symbolic\SC%i

To remove the shares

for /l %i in (22,1,24) do net share SC%i /delete

Dealing with the storage issues
If you want to copy substantial amounts out of a large number of shadow copies you are faced with the problem of where you can store it. In Volume Shadow Copy Forensics.. cannot see the wood for the trees? I observed that there is considerable duplication of files in each shadow copy. I have found that a utility like Duplicate and Same Files Searcher can be useful. This utility can search across your export folders and identify duplicates. You can then opt to retain the first file and then create hard links for all the duplicate files. This utility can also move duplicate files, thus allowing you to focus on just the unique files.

References
Windows 7: Current Events in the World of Windows Forensics Harlen Carvey, Troy Larson
Reliably recovering evidential data from Volume Shadow Copies in Windows Vista and Windows 7 QCC

Volume Shadow Copy Forensics - the Robocopy method Part 1

There is always more than one way to skin a cat and so I make no apologies for discussing another approach to processing volume shadow copies. This approach - I'll call it the Robocopy method - has been researched and developed by the chaps over at QCC, John Douglas, Gary Evans and James Crabtree and they have kindly let me crib from their notes. This post is Part 1 - I have simplified QCC's approach but have also removed some functionality. In Part 2 I will expand on the simplified approach and add back in some functionality.

Robocopy is a robust file copying utility developed by Microsoft. This method allows us to copy out folders and files of interest from any notable shadow copies. The process will preserve folder and file paths and timestamps. The key advantages are that it is efficient -both in storage and speed.

This blog post complements my previous posts Vista Volume Shadow Copy issues and Volume Shadow Copy Forensics.. cannot see the wood for the trees? and the method documented below is similar in the early stages.

What are we going to need?
For what follows we will need a Windows 7 box (real or a VM), Encase with the PDE module and some storage space formatted NTFS. Robocopy is pre-installed within Windows 7.

Method
You will already have an Encase image of the drive you wish to investigate. When this is loaded up into an Encase case you need to gather some information in respect to the shadow copies you wish to investigate further. You will need to note the File Creation date and if you wish to be more precise establish the Shadow Copy ID stored at File Offset 144 for 16 bytes - bookmark as a GUID in Encase. Next you will have to mount the volume containing the shadow copies as an emulated disk using the Encase PDE module with caching enabled. On my box the mounted volume was allocated the drive letter I. I am using a Windows 7 box - if you are using a Windows 7 VM add the PDE mounted disk to the VM as an additional hard disk. Then on your box or in the VM:

Run a Command Prompt as Administrator and type the command (substituting I for the drive letter allocated to your mounted volume)

vssadmin list shadows /for=I:

This will result in a list of all available shadow copies on the selected volume

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Contents of shadow copy set ID: {2202d8a9-1326-4254-9818-252ece858b17}
Contained 1 shadow copies at creation time: 10/12/2009 14:41:25
Shadow Copy ID: {ad2e71d0-48d6-44b9-9715-f5ff6b5a5643}
Original Volume: (I:)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered

Contents of shadow copy set ID: {e13bb9d9-c522-422b-b92a-37f6d12363d9}
Contained 1 shadow copies at creation time: 15/12/2009 12:17:37
Shadow Copy ID: {d0e1c613-7892-47e1-9b7e-f638adac9d16}
Original Volume: (I:)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered

Marry up your bookmarked GUID to the Shadow Copy ID number to identify the Shadow Copy Volume you wish to process. The next step is to create a symbolic link to the selected shadow copy (ShadowCopy6 in this example) by typing the command

mklink /d C:\shadow_copy6 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6\

which results in the output

symbolic link created for C:\shadow_copy6 <<===>> \\?\GLOBALROOT\Device\Harddisk
VolumeShadowCopy6\

We are now going to use robocopy to copy out data from the mounted shadow copy - for this example I have created a folder called SC6 on my export volume. The command I used for this example is

robocopy C:\shadow_copy6\Users\Richard G:\SC6 /S /XJ /COPY:DAT /NFL /NDL /w:0 /r:0

This results in robocopy outputting a Job Header to the console

---------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows
---------------------------------------------------------------------------
Started : Mon Apr 05 11:23:18 2010
Source : C:\shadow_copy6\Users\Richard\
Dest : G:\SC6\
Files : *.*
Options : *.* /NDL /NFL /S /COPY:DAT /XJ /R:0 /W:0
---------------------------------------------------------------------------

The header usefully sums up what I have asked robocopy to do.

• I am copying only the Richard user profile (Users\Richard) to my export folder SC6
• *.* indicates that I am copying all files
• /NDL suppresses directory listings to the console
• /NFL suppresses file listings to the console
• /S copies the source folder and all sub folders and files
• /COPY:DAT copies data, attributes and timestamps
• /XJ exclude junction points
• /R:0 number of retries on failed copies (in other words -do not re try)
• /W:0 wait between retries

Nothing much happens at the command prompt now unless a failed file copy is encountered when you will receive output to the console similar to

2010/04/06 11:24:48 ERROR 5 (0x00000005) Copying File C:\shadow_copy6\Users\Rich
ard\AppData\Local\Temp\~DFA2ED.tmp
Access is denied.

When the copying is completed a summary is outputted to the console

It can be seen that 17 directories have been skipped. This means they have not been copied -probably because of permission issues. Also notable is the copying speed which is much quicker than imaging.

The output folder now contains a copy of the Richard users profile. Drag the contents of the export folder into Encase which processes the contents as single files. You may wish to create a logical evidence file of these single files.

Alternative Robocopy Configuration
As inferred from the Job Header above it is possible to take a fairly granular approach to what is copied out of your shadow copy. For example the command

robocopy C:\shadow_copy6\Users G:\SC6 *.jpg *.bmp *.png /S /XJ /COPY:DAT /NFL /NDL /w:0 /r:0

will copy out all jpg, bmp and png files from all User profiles. With reference to the two examples in this post and the robocopy manual it is possible to configure the copy operation in many different ways. For example you could just copy files that have timestamps in a particular range or files that are greater than a particular size.

Incorrect Function
If you play with VSCs often you will run into this rather helpful Microsoft error message. Tips to overcome it in Part 2.

References
Windows Vista/7 Recovering evidential data from Volume Shadow Copies John Douglas
http://technet.microsoft.com/en-gb/library/cc733145(WS.10).aspx
http://blogs.sans.org/computer-forensics/2009/01/08/robocopy-–-a-computer-forensics-tool/
http://42llc.net/index.php?option=com_myblog&task=tag&category=robocopy&Itemid=39

Internet History Examination Tools - you generally get what you pay for

My digital Life of Grime case and another ongoing case have caused me to look more closely at the tools we use to analyse internet history. Life of Grime's suspect had a penchant for the Flock browser and the other ongoing case involves Firefox 3.0.1 running on an Apple iBook. The version of Flock in use is built on Firefox 3 also. It seems to me that I am seeing Firefox as the browser of choice in the majority of my cases. I know that most available statistics still put Internet Explorer in top spot but I still maintain Firefox has overtaken IE in my cases. Certainly Firefox is (worryingly?) by far the most popular browser used to read this blog.

Now as far as the data we think of as internet history is concerned, Firefox 3.x.x stores this data in a Sqlite database, places.sqlite and sometimes additionally places.sqlite-journal. However in the wider sense internet history can also be determined from the Firefox cache because the page elements stored there contain each elements URL and associated times and dates. Firefox stores it's cache in a folder entitled Cache within the xxxxxxxx.default folder (it is possible for a user to have more than one profile -so there may be other profile names not having the word default appended). Cached items may be stored in a file by itself (albeit renamed without a file extension) or more often within cache block files (e.g. _CACHE_001_). These cache block files can contain many cached items and therefore an index file is needed to record where an item is stored in the cache. This index is called a cache map and is the file _CACHE_MAP_.

Many of us have made use of a number of free utilities to examine Firefox 3 internet history. These tools have become popular due to our mainstream, paid for, tools falling a little behind the curve and not supporting Firefox 3. These free utilities include:

• http://www.firefoxforensics.com/
• http://forensic-software.co.uk/foxanalysis.aspx
• http://www.machor-software.com/firefox_forensics
• http://www.nirsoft.net/web_browser_tools.html
• http://www.woany.co.uk/firefoxforensics/
• http://manuel.santander.name/wbf.html
  

All bar the Nirsoft tool can not parse any data out of Firefox cache. Now for me that is a problem -not necessarily with the tools, but with the methodology I am going to use in a production line forensics environment. I know there are other approaches -substituting the suspects profile into a test installation of Firefox for example but ideally I would prefer a one stop shop approach.

Regular readers will know that I work in an Encase shop and the Encase 6.15 comprehensive internet search will parse out live Firefox records from cache. However in both the cases I am working on now, the cache map file is zeroed out. In this situation Encase does not parse records still recorded within the cache block files (and for that matter neither does the Nirsoft utility).

Which brings me to NetAnalysis. As our more experienced readers will know NetAnalysis is the industry standard, tried and tested tool for the analysis of browser history and cache, particularly Internet Explorer history and cache. NetAnalysis has always supported other browser artefacts but until now not Firefox version 3. NetAnalysis 1.50 and the associated program HstEx 3 now support Firefox 3 and then some.

In both my cases I have copied out the profile folders and quickly added them to a NetAnalysis workspace using the Open all history from folder option. Because the cache map file is empty the cache is effectively deleted which is where HstEx 3 comes in. HstEx 3 is a deleted history record extractor which can locate deleted records from physical disks, raw images and new to this version, directly from Encase evidence files. In both my cases HstEx 3 was able to parse records from the cache block files that none of my other tools, including Encase 6.15, could do. The advantage of being able to run HstEx 3 directly over Encase evidence files can not be over stated. By running multiple sessions of Hstex 3, productivity can be considerably enhanced and at the same time freeing up image mounting tools for other uses.

NetAnalysis 1.50 also introduces many other new features -probably the headline one being the significantly enhanced cached web page rebuilding feature. This is very cool. Simply load in your suspects browser cache, press F6 and the workspace filters cached webpages that can be rebuilt. Double clicking on them displays the page in a viewer and within an export folder the underlying html and associated page elements can be found. Each rebuilt page folder can be copied for use in an html report for example. I can't do this feature justice here but a Digital Detective knowledge base article covers it in more detail. Other enhancements include the provision of an extensive audit log. I think this facility is anticipating the tightening of regulation here in the UK with the advent of the Forensic Science Regulator. More immediately it allows the creation of cracking contemp notes. Another notable addition is the ability to provide more information about redirect and referral URLs.

As a final thought, we all love free tools, many of them written by Harlan Carvey, Mark Woan, Tim Coakley, John Douglas and others we know and respect. But we do need to be careful - one or two of the free tools I have referred to above have been written by people who, for whatever reason, have had to obfuscate their identity. I do not doubt any of these tools, but what if a new tool was released that extracted data that none of our current tools could. If we do not know who is behind it how do we know that the said tool was not on a certain date in the future going to scour our forensic network and modify all the Encase evidence files it came across? As I said at the start you generally get what you pay for. Till next time.

Flock shepherds in a Life of Grime

After writing that title I am wondering if I wouldn't be better employed writing crossword clues. Back at the sausage factory I am bogged down investigating a digital Life of Grime. You probably have done a case like it - there are several hard drives in the suspect's box all with multiple partitions. Every nook and cranny is stuffed with IPoC and IVoC in a semi organised way. Almost as if all the material was neatly stored at one time until my suspect got lazy and started storing stuff on the floor, in the hall, under the table, that sort of thing. There are new folders after new folders -you don't see a New Folder (13) everyday. Not content with filling up his hard drives my suspect had also felt the need to back his stuff up to CD-R or DVD. Repeatedly.

The sheer quantity of files and folders in this case presents many problems and I thought I would share a few of them with you. Most of the problems are linked to pictures, that is the vast quantity of pictures, all of which have to be categorised and counted.

As many of my readers will know in a case like this C4P is an essential tool (going off at a tangent -googling C4P led to the discovery that c4p dot com is an online community for swingers - and now having said that we better watch out for some dodgy google ads appearing to the right ->> but hey they might improve my minuscule return from them ;-) ). C4P stores the results of categorisation, whilst the case is being worked on, in an Access database that has a 2GB file size limit. Now depending on how deeply your MDP folder is buried within your case folder structure this equates to about 1.9 million picture files. A long standing problem has been that if the c4p graphics extractor enscript carves out more than about 1.9 million picture files C4P itself would fail to create a case, due to the underlying Access database maxing out. In this case well over 2.1 million images were carved from the optical media alone and I was pleased to discover that C4P version 4.01 at least dealt with the maxing out issue fairly gracefully by creating a .c4p4 file and then a second .c4p4 file for the overspill. Case creation failed but I was subsequently able to create a new case by opening the double clicking on the first c4p4 file, which is associated with C4P. Doing this gave me a case with exactly 1,900,000 pictures which when viewed pragmatically is better than starting again. It is clear that the Access database problem will become more of a problem as main stream hard disks become bigger and bigger and I was pleased to discover that a beta version (4.03) of C4P is available that utilises an SQLite database (and whilst at it, runs happily on 64 bit boxes). This version does not limit the number of pictures you can have in one case.

In a case like this another C4P bugbear also rears its ugly head. The latest C4P graphics extractor enscript (4.03) carves out embedded thumbnails within jpgs, so for every picture file potentially you may have three carved images- the original, a thumbnail and a preview image. I am not sure why the latest script does this as a feature of earlier scripts was that it didn't carve embedded images to avoid duplication. It is that word -duplication- that is the problem. C4P will allow you to create a report directly from the program but if you need to compile statistics (how many Level 1s, 2s etc.) the report will be inaccurate. I do not use C4P for reporting and instead use the C4P Import enscript to bring back the C4P results into my Encase case. Once in Encase, sorting the C4P bookmarks by file offset provides a good indicator of how many embedded images there are. Luckily it is a fairly simple exercise to remove the duplicate bookmarking -simply selecting (blue checking) each category folder in turn and tagging selected files, and then from Entries view rebookmarking the files concerned will effectively sort out most duplication. Obviously different considerations will apply to pictures embedded into files for other reasons.

Moving away from C4P another issue in this case is establishing where the pictures came from. Obviously establishing which browsers are being used is a job that need doing and an Enscript that does just that has been written by Mark Woan over at Woanware. The WebBrowserInformationFinder enscript outputs to the console enabling you to copy and paste into your contemporaneous notes -very neat. Talking of contemp notes I use John Douglas's Case Notes - another very neat program. Looking at the problem a little wider it is worth considering some other angles to this problem, the registry contains a few pointers too, Harlan Carvey's post Browser Stuff covers this in more detail.

As it turned out my suspect used Flock as his default browser. This browser is built upon Firefox 3 and stores internet history and cache in a profile in the same way as Firefox. In the XP box I was looking at the profile folder was stored at the path C:\Documents and Settings\USER_NAME\Application Data\Flock\Browser\Profiles\xxxxxxxx.default. I have analysed this with NetAnalysis 1.50. More on NetAnalysis, Firefox 3 and the tools available to analyse this browser's artefacts in my next post.

Volume Shadow Copy Forensics.. cannot see the wood for the trees?

There has been a great deal written about volume shadow copy forensics lately, much of it very technical. The purpose of this post is to provide some of this information in an abridged form and to document a methodology to investigate them that works for me. I work in an Encase shop so much of what follows is tailored for Encase users. It is a followup to my earlier post.

What is a Volume Shadow Copy?
It is a snapshot of a NTFS formatted volume. Typically they are created every day or two in Vista and on a weekly basis in Windows 7. Both operating systems will also create volume shadow copies prior to the installation of new software (including Windows updates). The Volume Shadow Copy Service (VSS) monitors all the changes made to a volume from the time that a shadow copy was created until the creation of the next one. For the purpose of monitoring a volume is divided into 16 kilobyte blocks. When a block is about to be overwritten it is backed up in the shadow copy. Only changed blocks are backed up. If there is a requirement to revert to a snapshot the original blocks are restored, replacing the changed ones, in a sense reconstituting the volume back to its state when the snapshot was taken. Certain versions of Vista and Windows 7 allow users to revert to previous versions of files and folders, not just at the volume level.

Where are Volume Shadow Copies stored?
In the System Volume Information folder stored at the root of each protected volume.

Why might I need to investigate the contents of a Volume Shadow Copy?
You might not, but I am seeing many cases now where the Shadow Copies contain relevant evidence. For instance, during your IPOC cases the file finder or the C4P graphics extractor enscript or Blade have identified pictures within the shadow copy file which do not exist on the live volume. At that stage you simply do not know for example, whether these pictures were part of a web page accidentally viewed and then immediately closed down, embedded within an unsolicited email message, or there as a result of the intended actions of your suspect. Or you may have experienced cases where Encase lists many files as deleted and overwritten but that have very very dodgyfile names.

The following screenshot is from an Encase case which contains a live volume and images of two shadow copies of the same volume. Four deleted and overwritten files are listed, the metadata of which has been recovered by Encase from the MFT on the live volume. It can be seen that these files are intact within the shadow copies which allows your file carver of choice to recover them.

There are of course many other scenarios and examples I could give but the long and the short of it is that if deleted data from the live volume could be relevant to your case, you may need to investigate the shadow copies.

Which shadow copies should I look at further?
It has been suggested that, because each shadow copy is effectively a volume in it's own right which mirrors the size of the source volume, that if you have twenty shadow copies you will have to investigate twenty times as much data. In Production Line forensics this simply is not going to happen. Therefore we need to make some educated guesses as to which shadow copies to look at. Have our file carvers flagged any as meriting further investigation? Do keyword searches point to any? Were any shadow copies created just before or just after a particular event we are looking at? Are there a rash of shadow copies created within a short time of each other by software installation or windows updates which we can exclude? Once we have made our choices we can proceed further but it is not the case that the amount of data to be investigated is a multiplied by the number of shadow copies you chose to investigate. This is because the majority of data within each shadow copy is exactly the same as the data on the live volume. We are really only interested in the differences and I will discuss a method to do this later in this blog post.

What are we going to need?
For what follows we will need a Windows 7 box, Encase with the PDE module and some storage space formatted NTFS and ideally with File and Folder compression enabled. We will also need George Garner's Forensic Acquisition Utility.

Method
You will already have an Encase image of the drive you wish to investigate. When this is loaded up into an Encase case you need to gather some information in respect to the shadow copies you wish to investigate further. You will need to note the File Creation date and if you wish to be more precise establish the Shadow Copy ID stored at File Offset 144 for 16 bytes - bookmark as a GUID in Encase.

Next you will have to mount the volume containing the shadow copies as an emulated disk using the Encase PDE module. On my box the mounted volume was allocated the drive letter I.

I am using Windows 7 - every thing that follows should work in Vista and has worked for many people. However for me, in testing using Vista it did not always work as expected -generating various permissions related errors -so far - touch wood- Windows 7 just works.

Run a Command Prompt as Administrator and type the command (substituting I for the drive letter allocated to your mounted volume)

vssadmin list shadows /for=I:

This will result in a list of all available shadow copies on the selected volume

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Contents of shadow copy set ID: {2202d8a9-1326-4254-9818-252ece858b17}
Contained 1 shadow copies at creation time: 10/12/2009 13:41:25
Shadow Copy ID: {ad2e71d0-48d6-44b9-9715-f5ff6b5a5643}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered

Contents of shadow copy set ID: {e13bb9d9-c522-422b-b92a-37f6d12363d9}
Contained 1 shadow copies at creation time: 15/12/2009 11:17:37
Shadow Copy ID: {d0e1c613-7892-47e1-9b7e-f638adac9d16}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered

Contents of shadow copy set ID: {4db5347c-214a-4e5c-b785-0fd993f1dc33}
Contained 1 shadow copies at creation time: 15/12/2009 11:18:25
Shadow Copy ID: {b7621ae2-5efb-4929-aa35-39af3d6e39ac}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered

Contents of shadow copy set ID: {2445d9b6-58fd-4ac6-b73e-7bd0ebbec6cc}
Contained 1 shadow copies at creation time: 15/12/2009 12:14:44
Shadow Copy ID: {709f74d5-ded2-4294-a292-c7cc4db0e67b}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered

Contents of shadow copy set ID: {c9e7850a-87db-4dbc-9d72-40749665d80d}
Contained 1 shadow copies at creation time: 09/02/2010 07:26:39
Shadow Copy ID: {2a871fe5-21f7-4fb6-b8e9-65e194a62901}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered

It can be seen that the Shadow Copy ID number I bookmarked as a GUID is identified by VSSAdmin as HarddiskVolumeShadowCopy5. The next step is to image this shadow copy using the Forensic Acquisition Utility (a version of dd that works in Windows). At the command prompt navigate to the path of the utility and type the command

C:\FAU.x64>dd if=\\.\HarddiskVolumeShadowCopy5 of=G:\shadow5.img --localwrt

It can be seen that the input file is referenced as \\.\HarddiskVolumeShadowCopy5 and the output file which I chose to name shadow5.img is located on G:. This volume is an NTFS formatted volume with file and folder compression enabled. --localwrt is a switch required to allow the utility to write to the G drive. The response at the command prompt will be similar to

The VistaFirewall Firewall is active with exceptions.
Copying \\.\HarddiskVolumeShadowCopy5 to G:\shadow5.img
Output: G:\shadow5.img
44048285696/57868808192 bytes (compressed/uncompressed)
55187+1 records in
55187+1 records out
57868808192 bytes written

Succeeded!

Enabling file and folder compression reduced the dd image from about 59GB to 44GB. Whilst imaging make sure that you have carried out an hash analysis in Encase of your source volume and create a hash set from it. Add only this hash set to your library.

Once imaging completes add the image to Encase (via the add raw image option) and carry out a hash analysis. Create a condition which filters out files that match a hash set.

The following screen shot shows that there are 237024 files contained within the image of HarddiskVolumeShadowCopy5 (broadly the same as the source volume)

Apply the condition which filters out files that have the same hash value as those in the original image and it can be seen that the amount of new or different files is considerably reduced to 7864 files (with the caveat that some of the original files may have been moved -which may or may not be relevant in your case).

I think it can be seen therefore that it is possible to reduce the number of files you need to consider by filtering out the duplication between the original volume and the shadow copy.

A Note of Caution about the Shadow Copy Images
When you image a Shadow Copy and add it into an Encase case as described above it is easy to think of the image as a point in time snapshot of the entire volume including the areas of the volume we refer to as unallocated clusters. Unfortunately it does not appear to be. However your forensic tool (Encase in my case) is likely to process it as if it was the entire volume. In my test case used to illustrate this blog post I imaged at 14:47hrs on 9th February 2010 two shadow copies -one created at 15/12/2009 11:17:37 and one created at 09/02/2010 07:26:39. At 15/12/2009 11:35 I copied a folder entitled Sony from an external device to the desktop of my user account on this Vista box. It can be seen in the screen shot below. It is a live folder containing files and has not been deleted.

It can also be seen within the shadow copy created on 9th February 2010 as expected.

And as expected it cannot be seen in the earlier shadow copy created prior to the folder being copied.

However unexpectedly when I ran the Encase Recover Folders feature across the HarddiskShadowcopy5 volume it found traces of the Sony folder and in fact many other files post dating the creation of the shadow copy.

The Encase Recover Folders feature parses unallocated clusters looking for folder metadata. It seems that it found data in unallocated clusters relating to the current volume. Therefore I believe that any deleted but recoverable data within the shadow copies needs to be treated with caution.

Other Methods
So far in this post I have discussed imaging the shadow copy pseudo-device. It is possible to mount the shadow copy as a symbolic link. There are various methods discussed using VMs etc. The most streamlined approach seems to me to be:

• Mount shadow copy with Encase PDE
• create a symbolic link (in this example at the root of C) using the command

mklink /d c:\shadow_copy5 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5\

• drag the created symbolic link into a separate instance of Encase (for me using the same instance as the one running PDE blue screened my box) which causes Encase to treat the files and folders accessed via the symbolic link as Single files
• Create a logical evidence file of these Single files (you may encounter some permissions issues along the way)

Methods involving accessing the shadow copies via Symbolic links will only provide access to the logical contents. It may be that the object you are seeking is deleted but recoverable (but note warning above).

References

http://blogs.sans.org/computer-forensics/2008/10/10/shadow-forensics/
http://www.digital-detective.co.uk/cgi-bin/digitalboard/YaBB.pl?num=1251461771
http://blog.szynalski.com/2009/11/23/volume-shadow-copy-system-restore/
http://windowsir.blogspot.com/2009/11/working-with-volume-shadow-copies.html
http://blogs.technet.com/filecab/archive/2006/09/01/452845.aspx
http://en.wikipedia.org/wiki/Shadow_Copy

TIM released - first test

Tableau have released their Tableau high performance software imaging product today.

To install it you first must have installed the latest Tableau firmware updater. Once installed the interface is fairly simple to use. I found some of the terminology in the GUI a bit odd. For example the types of compression selectable for Encase e.01 files are No Compression, Fast Compression or Good Compression whilst Encase provides the options none, good or best. It seems that fast maps to good and good maps to best. There also does not seem to be the ability to actually name the created e.01 files- just their containing folders, again a little strange.

Now as far as performance is concerned in our environment it is slightly faster. We image to a mapped network drive on a san across a gigabit ethernet network. I imaged a Hitachi 80GB sata laptop hard disk via a Tableau T35i write blocker using FTK Imager 2.5.5 using the Encase e.01 format - imaging completed in 51 minutes. Using TIM to image the same drive took 44 minutes. In both cases maximum compression was selected. Obviously at this stage this testing is far from scientific but TIM seems to be between 10 to 15% faster. I will report how it goes on with larger 3.5 inch sata hard drives later.

C4P, MySQL and Windows 7

I can just about remember the thrill of upgrading to a new OS. When I was the new kid on the block I couldn't wait to upgrade from Windows 98SE to XP Pro (somehow we missed out Windows ME). Anyhow the newer kids on the block have migrated to Windows 7 (it is prettier, more stable, blah blah). Now I am a dinosaur with XP Pro 64 bit!

Anyway I had a call today about getting various aspects of C4P to play nicely with MySQL on a Vista 64 bit box. In our office we don't actually use Vista on any of our forensic boxes so I thought I'd check out the issues on one of Windows 7 64 bit boxes. As you know (because if you are still reading this you probably use C4P along with a MySQL DB) C4P interacts with the MySQL database in two areas:

1. within Encase at Enscript level if the pre categorization option is selected
   
2. or via Data Migration/ Special/ Update Case Direct from C4P Hash Database within the Categorizer for Pictures program itself.
   

Both of these connections require an MySQL ODBC connector driver to communicate with the running MYSQL C4P hash database using a suitable database connection string. Essentially in this scenario we have a choice of four MySQL ODBC drivers:

1. MySQL ODBC 5.1 64 bit
2. MySQL ODBC 5.1 32bit
3. MySQL ODBC 3.51 64 bit
4. My SQL ODBC 3.51 32 bit
   

All bar the 3.51 64 bit driver are installed via a Windows installer. The 3.51 64 bit driver is slightly trickier to install - you need to unpack the zip, run a command prompt as administrator, navigate the command prompt to your unpacked zip folder and then run the command

Install 0

Enscript level communication

At Enscript level it is possible to modify the database connection string which allows you to specify which ODBC connector driver to use. In testing on a Windows 7 64 bit box I have found that both the 3.51 and 5.1 64 bit drivers work (if the drivers fail you generally get a long unintelligible error message). The C4P 4.02 enscript allows the user to configure their own database connection string. The string that works for me is:

Provider=MSDASQL;DRIVER={MySQL ODBC 3.51 Driver};SERVER=Your_server_name_or_IP_address;DATABASE=c4p_hash;UID=c4p_user;PASSWORD=password;OPTION=3

Simply change 3.51 to 5.1 if you are using the later driver.

Categorizer for Pictures communication

The database connection string used by this program is hard coded and not user configurable. The program requires the 3.51 driver. However I could not get the Data Migration/ Special/ Update Case Direct from C4P Hash Database option to work on the Windows 7 64 bit box using the 3.51 64 bit driver. I suspect this is due to a permissions issue and tried to run C4P as administrator but I still failed to connect to the MySQL C4P hash db. However I was able to get the Data Migration/ Special/ Update Case Direct from C4P Hash Database option to work using the MySQL ODBC 3.51 32 bit driver.

Conclusion

Other combinations may work but on a Windows 7 64 bit box I recommend installing the MySQL ODBC 5.1 64 bit driver and the MySQL ODBC 3.51 32 bit driver to get C4P and the C4P graphics extractor enscript to play nicely with the MySQL C4P hash database.

Web Browser Session Restore Forensics

As this is the first post of the year I would like to wish you a happy new year.

The posting title is the title of an excellent paper written by Harry Parsonage relating to Session Restore files created by the latest Mozilla (Firefox) and Internet Explorer 8 browsers. These files may contain enough information to allow the browser to display a users workspace exactly as it was prior to a forced restart. Obviously these files may contain significant evidence. I am not going to steal Harry's thunder so download his paper from http://computerforensics.parsonage.co.uk/other/other.htm

I know that Harry is not keen on blogs simply regurgitating information found elsewhere so I will try and add a little value.

Safari v4
Session Restore functionality is now a must have in modern browsers. Another browser to have similar functionality is Safari v4. The last session information is contained in a file entitled LastSession.plist

In Mac OSX 10.6 this file is stored at /Users/<user name>/Library/Safari

In XP this file is stored at C:\Documents and Settings\<User name>\Application Data\Apple Computer\Safari

I use the mac application - property list editor to review plists, there are windows applications to do this as well.

Firefox v3.5.6 running in Mac OSX 10.6
Harry's paper applies here in the main.

The sessionstore.js file is stored at /Users/<User Name>/Library/Application Support/Firefox/Profiles/XXXXXXX.default

Navman S30 Satnav device

I have seen a number of different Navman models now. All of them have subtle variations on how to process them. Although the underlying OS is Microsoft WinCE.NET 5.0 Core Version I did not have to access this device via Mobile Device Centre. After applying some write blocking to my USB port this device was accessible as a mass storage device allowing me to image it with Encase. I ended up with 114,759 sectors being imaged.

The next step I took was to track down and consult a manual for the device in order to establish its capabilities. I expect all devices to have saved Home, Favourites and Recent destinations and this device was no exception.

In addition however this device can save trip logs, pre-planned itineraries, pictures and be paired with a mobile phone.

Almost all the relevant data is stored within xml formatted files. Microsoft Excel 2007 is an excellent tool for examining these files and subsequently reporting on them. I use the Get External Data / From Other Sources / From XML Data Import option via the data tab and allow Excel to sort out the formatting.

A good place to start is the file paths.xml stored at the root of the partition. This file details the location of some of the relevant files.

This is a more definitive list:

• MyFavouriteLocations.xml - used to store the home location and favourites
• MyRecentLocations.xml - used to store Recents and also Journey Starts
  
• MyMultiStopLocations.xml - used to store saved multi stop journeys
• MyRoute.xml - used to store the current journey which is in effect the last journey -on the device I examined this file was deleted but recoverable
  
• UserSettings.xml – used to store device settings including where the unit was turned off
  

When a user enters a new address the menu shows previously entered towns or cities, road names and postcodes. This data is stored in the following files:

• DWRecentPocode.xml – Previously entered postcodes, most recent first
  
• DWRecentRoad.xml – Previously entered road names, most recent first
  
• DWRecentPlace.xml – Previously entered towns or cities, most recent first
  

There are a number of presumably back up files also containing the same (as far as I could see) xml formatted data:

• MyFavouriteLocations_bak.xml
• MyRecentLocations_bak.xml
  
• MyMultiStopLocations_bak.xml
  

There are also two files that appear to be temporary files which were deleted but recoverable, containing xml formatted data:

• MyRecentLocations_New.xml
  
• MyMultiStopLocations_New.xml
  

All of the above mentioned xml files are parsed very tidily using Microsoft Excel 2007. I use the same program to create an html version of the worksheet after a little tidying up. The longitude and latitude values need to be divided by 100,000. I populate a new column using the formula:

=HYPERLINK("http://maps.google.co.uk/maps?q="&(K3/100000)&"+"&(L3/100000)&"","Click here to view in Google Maps")
The cell K3 contains the Latitude and L3 the Longitude. The formula creates a clickable hyperlink to the Lat/Long in google maps.

There are one or two other files of interest:

• destdata.dat - which contains the address used for the last navigated journey
  
• gpslog.ini - detailing the location of trip log data
  
• default_settings.xml -which in the FAVOURITES/ RECENTS/ MULTI-STOP section appears to detail the maximum number of favourites and recents
  
• .pcd - on the unit I examined I could not locate a .pcd file however I understand from Andy Sayers that this file if it exists contains the phonebook from a paired mobile phone
  
• Log001.log - again I did not see this file but if it exists it contains GPS track logs
  

Because we have physical access there is also a possibility of recovering relevant data from unallocated clusters. I located records in unallocated using the keyword <lat> .

References
Sat Nav Examination Guidance Notes (Andy Sayers)
Navman S-Series (S30, S50, S70 & S90i) User Manual

Binatone X350 UK&ROI 2nd edition GPS

This device can be purchased very cheaply now from places like Asda and ebuyer. It runs Astrob Turbodog4 satellite navigation software within a Microsoft WinCE.NET 5.0 Core Version OS. Although I have not examined one I believe a number of Navigo devices run similar software. It has an SD card slot which was unpopulated in the one I looked at. The internal memory can be accessed like many similar devices via Mobile Device Centre in Vista which makes available a volume entitled ResidentFlash. I disable writing to USB devices by modifying the registry (there are many utilities about to do this). Simply paste the text below into a text file, give it a .reg file extension and then execute it and then reboot.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000001

After copying and creating a logical evidence file of ResidentFlash I found three notable files within the MobileNavigator folder:

• RecentDest.dat
  
• FAV.DAT
  
• SystemSet.dat
  

RecentDest.dat stores up to fifty of the recently navigated to locations. These locations are stored in records of 104 bytes in length. The first record starts at the first byte of RecentDest.dat, so by viewing the file in Encase with the view pane set to hex and dragging the view to show 104 bytes per line (assuming you have twin monitors), it is possible to see all the relevant data. Each location record stores Longitude and Latitude as 8 byte doubles which unfortunately Encase does not natively decode. The data interpreter in Winhex can do this. The hex editor 0xED on a mac can also do this but rounds up to fewer decimal places than Winhex. So given a fully populated RecentDest.dat file you have one hundred doubles to decode. I turned to my friend Oliver Smith over at Cy4or who wrote me an enscript which parses out the records to a csv file. Email me with a brief note about who you are for a copy

Recent Destinations also log the time entered, so very unusually some meaningful time and date information may be extracted. Providing these times have been recorded whilst the device can see satellites they are accurate and stored at the configured time zone. If a destination is entered when the unit can not see the sky and if the battery had been previously discharged it appears that the recorded time and date would be soon after 00:00 hours 1st January 2007.

I have decoded each 104 byte record as shown in figure 1

Figure 1 (click on image for larger version)

FAV.DAT contains user configured Favourites stored in 536 byte records. Once again the Longitude/Latitude are stored as eight byte doubles in the first sixteen bytes of each record.

SystemSet.dat appears to store the users Home location and again the Longitude/Latitude are stored as eight byte doubles.

Within the MobileNavigator folder there is a folder entitled Trace. This was empty in the one I looked out however the manual states:

The unit is capable of logging all positioning information received from the GPS satellites during navigation. It then uses this information to draw a track of the route on the map. This enables you to review the route information at a later time.

I imagine that should this feature be enabled a file of some sort will be stored in this folder.

References

http://binatonegps.com/gps/download/manual/X350II%20User%20Guide%20(Turbo%20Dog)%20-%2020080910.pdf
http://en.wikipedia.org/wiki/Double_precision_floating-point_format