Into The Shadows

This is going to be the first of a couple of articles about Volume Shadow Copies. I was going to put everything in one

Since their arrival in recent versions of the Windows operating system, volume shadow copies have troubled computer forensic investigators. Many investigations place less value on, or even ignore items found in these files due to their complexity. The only known way of fully accessing the contents of volume shadow copies consumes a great deal of both time and storage. This can prove costly for investigator and client alike.

First of all, what are Volume Shadow Copies?

The volume shadow service (vss) runs on the following operating systems:

• Windows Server 2003
• Windows Vista (all versions)
• Windows Server 2008
• Windows 7 (all versions)

The VSS monitors all changes made to a VSS enabled volume.  These changes are monitored in 16kb ‘blocks’. If a change is made to any data inside a 16kb block the entire block is copied to a volume shadow copy file.  This happens regardless of the file system settings.  All volume shadow copy files are stored in the ‘System Volume Information’ folder on the root of the volume and are recognisable by their names.  The file names for volume shadow copies look something like this:

{802c6ba4-300b-11df-a523-005056c00008}{3808876b-c176-4e48-b7ae-04046e6cc752}

You can tell that this is a volume shadow copy because the second set of braces contains the number 3808876b-c176-4e48-b7ae-04046e6cc752 which is a unique identifier specific to the volume shadow service.

There are several ways to create a new volume shadow copy:

• System Snapshot
• Software Installation
• Manual Snapshot

On Windows Vista the system snapshot is scheduled to take place every 24 hours. On Windows 7 it is scheduled to take place every 7 days.  You may notice that this is not exact. Windows Vista will not take volume snapshots exactly every 24 hours, there may be some time changes day to day. This is because the VSS will only create new shadow copies once the computer has been idle for a certain amount of time, or the computer is being turned off or rebooted, and so on.

A VSS enabled volume will always have a ‘live’ volume shadow copy. This file saves all of the 16kb block changes and then, once a new volume shadow copy is created, these changes are committed to the current VSC and the shadow copy is archived. From this point the contents of that volume shadow copy remains unchanged until it is deleted.

Now we know what volume shadow copies are, how do we examine them?

There are currently three main methods for dealing with Volume Shadow Copies:

1. Ignore them
2. Link them
3. Image them

Each of these have their own benefits and downfalls.

The first method is probably named somewhat unfairly. I don’t mean that the evidence contained in the volume shadow copies is completely ignored, what I mean is that a file carver is run over the shadow copies and anything found is reported as ‘system files’.  This is good because it is quick and simple, it is bad because you don’t get anything like the full picture.

Linking requires booting the computer, whether it be virtually or via a disk clone, and creating a hard link to the volume shadow copy so that all files and folders can be accessed. This is good but any analysis performed using this method must be conducted from with the virtual machine/cloned drive. There is limited flexibility using this method but allows quick access to the contents of the volume shadow copies.

Imaging will produce the best evidence but there are a couple of drawbacks. Imaging each volume shadow copy can take a great deal of time and storage space. On a 500GB hard drive, an investigator could end up with 20 disk images from a single volume. That could mean 10TB worth of data. It would take a long time to image this much data and you’d need to think about your storage needs.  The other problem here is that you won’t even know if imaging has been worthwhile until you have analysed the images. All of the promised data may still be in unallocated clusters. This method also requires the investigator to boot the computer either virtually or via a cloned drive.

Rob Lee recently wrote an article on the SANS Forensic Blog giving guidelines on retrieving timeline data from volume shadow copies. This seems to have the best of all three methods, speed, results, and something to take away for analysis. At the time I joked with him that this was bordering on making my research obsolete and, while he has made VSCs more accessible to investigators this method still requires booting the computer.

So, three distinct methods for analysing volume shadow copies and a hybrid method. I have used each of these methods on several occasions and seen, first hand, the good and the bad that each method can bring. Because of this I have remained unsatisfied. I waited patiently for someone else to find a better way of conducting analysis but my patience ran out. About a year ago I decided that I was going to do something about it myself.

Allow me to introduce a fourth method.

I have (mostly) determined the structure of a volume shadow copy. This means that it is now possible to traverse volume shadow copies, extracting meaningful data, and all without having to boot the computer or create extra data to analyse.

Volume shadow copies themselves are divided into 16kb blocks. These blocks are divided into one of two categories:

• Index Blocks
• Data Blocks

As the name suggests the index blocks are pointers to the 16kb data blocks that have been saved by the volume shadow service. The index blocks all start with the same string: 6B 87 08 38 76 C1 48 4E B7 AE 04 04 6E 6C C7 52 01 00.

Then there is a block of 6 bytes (which unfortunately I haven’t yet figured out its purpose). Next there are three 8-byte values. These are the index block’s own file offset, then the index block’s own logical volume offset, then the logical volume offset for the next index block.  This essentially forms a linked list for all index blocks in the volume shadow copy. You may be wondering why use a logical volume offset rather than a file offset, as you continue reading you will see that this is a consistent theme through shadow file technology but it is a question that, as of the time of writing, I’m unable to fully answer.

At offset 128 in each index block the data block index begins. Each record here is 32 bytes in length.  The first 8 bytes reference the original logical location of the referenced 16kb block. The second 8 bytes gives the file offset, in the current shadow file, for the original data. The third 8 bytes gives the logical volume address for the original data. I will discuss the fourth 8-byte value later.

All addresses in these index blocks are given in bytes, not sectors, not clusters, but bytes. This means that the theoretical maximum sized volume for the Volume Shadow Service would be 18,446,744,073,709,551,615 bytes (approximately 18 exabytes). This also means that the 4kb sector drives will not affect the workings of the volume shadow service.

The only thing I have to say is that I don’t know if this is universal across 32bit and 64bit machines. Anyone willing to help me with some testing feel free to volunteer.

I’m sure that you’re finding this all very interesting but would like to know about the practical application of this information. For this example I formatted a drive s NTFS.  The volume has 8 sectors per cluster making each cluster 4kb. I installed Windows Vista, making sure that system restore was active, I’ve then taken the Forensic 4cast logo (file size of 12KB) and copied it to that volume. The logo was found at cluster 109779 (0x1ACD3). As volume shadow copies do not work in clusters we convert it to bytes making it a logical offset of 449654784. Divide this by 16KB (16384) and we’re left with 27444.75. If we ignore the decimals we’re left with 27444 (6B34) which is the VSC block number that contains the start of this file. It should be noted, however, that this file does not start at the start of that block.  The block contains 4 clusters and the picture starts in the last of them. Also, as this file is over a cluster in size the logo is spread over two 16kb blocks. In this case the blocks are contiguous.

I created a volume shadow copy using the ‘System Protection’ dialogue on Windows Vista, deleted this file and performed some menial tasks. I then created another volume shadow copy.

Upon inspecting the volume I found that the beginning of the file had now been overwritten. When performing a file carve over the newer VSC I found a fragment of the Forensic 4cast logo:

If you’ve ever run a file carve over a volume shadow copy you’ve probably seen pictures like this before. This kind of thing can be VERY problematic in cases involving child abuse as you may see a fragment of the picture. You may even recognise the picture from the fragment but, without the rest of that picture, you have to exclude it from your investigation. So the question is how to we turn this fragment into the full picture?

If we ignore the numbers used above (as we wouldn’t have them in a real world situation) we need to recreate them from looking at the data stored inside the volume shadow copy.

Looking at the results of the file carving we see that this picture has a VSC file offset of 454656 (0x6F000).  When we divide this by 16384 we find that this file is not at the start of a VSC block, the file header for the picture starts 3/4 of the way into the block.  With this knowledge we can now take the 16384 byte block and multiply it by 3/4 which comes to 12288. We need to remember this for later.

Finding the beginning of that block we see that the file offset is 442368 (0x0006C000). If we now search for this hex value in little endian we find it appears in an index block with the recorded logical offset of 449642496. If we now add the 12288 bytes from before we have the logical offset for the original starting point of the file, 449654784.  So we know that the first 4096 bytes of this picture were located here, where is the rest of the picture? Ordinarily we’d need to find the original MFT entry for the file and follow the cluster runs from there, but we’re going to cheat and gamble that the picture was stored in contiguous clusters. So we copy the 4096 bytes of the picture from the VSC and then jump that same distance again from the original location. We look in the following sectors for the JPEG footer. We find it near the end of the next cluster. Copying this cluster and adding it to the data copied from the VSC we open the file as a JPEG and find that our picture now looks like this:

We have now successfully carved our first file from a volume shadow copy. If we wanted to find the metadata related to this picture we could traverse the live MFT and the MFT entries saved in the VSCs. This is not a simple task when done manually, but help is on the way. Mark McKinnon of Red Wolf Computer Forensics and I have been working on some software that will allow a forensic investigator to view the contents of volume shadow copies (including all metadata) quickly, without having to clone the volume or run it inside a virtual machine. We’re hoping that this will persuade examiners to spend more time investigating volume shadow copies as it will reduce a large number of the headaches that most investigators associate with these files.

Check back for the next instalment and for news on the release of the VSC software