Lessons from Data Recovery – Part 1 (Repost)

I originally posted this entry over on the Disklabs computer forensic forum (http://www.computer-forensics.co.uk/computer-forensics-forums/forum.php) but also thought a lot of people would benefit from it being repeated here too.

I’ve been working at Disklabs for a few weeks now. I’ve mostly been confined to the digital forensics lab but I’ve been able to poke my head out from time to time and see what the data recovery department are up to. I’m happy for this opportunity as it has taught me some interesting things that are useful for computer forensics, and some things that are potentially dangerous.

Over the next few weeks I’ll be posting articles about how data recovery has the potential to impact computer forensics in ways that few have thought possible.

A scenario occurred recently in which an employee left a company on less than gracious terms. The next day the employee’s former colleagues showed up for work and realised that the file server was inoperable. Upon closer inspection they found that all of the server’s drives were blank. Forensic analysis was conducted and nothing was found. If the drive had been wiped it had been done so with undetectable software. The forensic investigator, and the tools at his disposal, had failed to provide an adequate answer.

What would you do in a situation like this? I imagine that my report would be very sparse and contain very little information at all. You could look at wiping software artefacts, such as the sequence of bytes used, in order to determine if this individual had maliciously wiped the data from the drive but, failing this, what other avenues of investigation could be followed?

One of the first things I learned after starting at Disklabs was that each hard drive contains certain information that is not stored on the platters, but on the system area of the drive. The two items that I found to be of most interest are the number of times the drive has been powered on and the number of hours that the drive has been active. This may not seem like a huge finding but the implications are awesome.

Going back to our scenario the hard disk drives were turned over to a data recovery expert who was able to unequivocally state that the drive had only been powered on a handful of times and only had only been in operation for a few hours. What does this means in terms of this investigation? We can draw one of two conclusions either the drives had been replaced as a result of drive failure or they were replaced as a deliberate act intended to deceive. As it turns out the IT department of this company stated that the original drives should still be in operation inside the file server and that the information provided by the data recovery expert contradicted their own opinions.

The original drives were recovered from the former employee’s home a few days later.

My short time at Disklabs has proven to me that we need to educate ourselves on these matters. How can we offer opinion or facts in our reports if we haven’t covered every possibility?

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

Mac Forensics

Last Thursday I had the pleasure of attending the Mac Forensics F3 training day.  For those of you that do not know what F3 is, it is the ‘First Forensic Forum’.  Most digital forensic investigators in the UK are linked to this organisation in some way and they offer training days every few months.

I thought that I would quickly note some items that were shared with us before I either forget about it or lose my notes.

Imaging

This can be accomplished on either a Mac or a PC. If you’re looking to image with a Mac there are a few options to choose from but one of the best is offered by the guys over at http://macosxforensics.com.  Their Mac OS X Forensics Imager is based on libewf and offers a graphical interface to the console-driven acquisition tool.

Obviously there are the common everyday items such as DD and DCFLDD that are easily run on the Mac.

Although a write blocker is always recommended it is possible to image a drive without.  In order to do this you need to turn off ‘Disk Arbitration’. This is the process that automounts drives when they are connected to the computer.  After turning this off any newly connected drives will not be mounted. Just don’t forget to turn it back on once you’re finished otherwise you may run into some difficulty.  In order to turn this off just open Terminal and type:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.diskarbitration.plist

To turn it back on type:

sudo launchctl load /System/Library/LaunchDaemons/com.apple.diskarbitration.plist

Artefacts

Spotlight Files – These maintain an index of the volume from which the file is taken.

Swap File – /private/var/vm/swapfile0

Sleepimage – This file is like the hiberfile on Windows.

Log Files – /var/log – can be opened with the Mac ‘Console’

Property Lists – Two main types: XML and Binary – plists are like the Windows registry. A plist editor is available on the Mac Developer Tools provided with a new Mac. There is also ‘Pref Setter’ (which has a nice search feature) and iPod Robot offers a plist reader for Windows.

Printing – The Mac has an inbuilt PDF printer. This doubles up as a printer spool. This means that, regardless of the printer used, a PDF is created of anything that is printed from a Mac. Once the printing is finished the PDF is released into unallocated clusters. A file carve for PDFs in unallocated space will return items printed with the Mac. These PDFs will also contain metadata providing the application used to print.  I thought that this was the most interesting part of the day. This may be worth some more investigation and a full article written.

Useful Software

PeekIt, iBored, Hex Fiend, File Juicer, Mactracker, and Firefox Add-ons – CacheViewer and SQLiteManager.

MacBook Air Acquisition

The MacBook Air presents a unique problem that is not found with other Apple products.  With other Apple computers the ‘Macquisition’ tool can be used to create an image of the drive in question if the drive is not easily accessible.  Unfortunately Macquisition requires a free firewire (IEEE 1394) port in order to boot the computer into acquisition mode.  The MacBook Air has only one USB port, no firewire port, and no optical drive.  The Apple website suggests that only an Apple branded USB optical drive will allow booting from optical media (such as Helix).  These drives can be costly and largely pointless to purchase.
This guide provides a (relatively) simple method of removing the internal drive and imaging the drive using EnCase (or whatever brand of imaging tool you use).
Firstly, meet the MacBook Air:

The first thing you will notice is that this is a very thin computer; it has an aluminium (aluminum for you non-Brits) case.  This is quite slippery so take care not to drop it.
The first thing you will need to do is turn it over.
There are ten screws that need removing (circled below).  The front six screw are the same size; the rear-corner screws are a little longer; the middle-rear screws are longer still.  Keep track of these for putting it back together.

Once the bottom of the case is off you are going to focus your attention on the rear-right corner of the computer (highlighted below).

When you look closer at this corner you can see two ribbon cables.  The first of these is disconnected at ‘A’ by pulling on tab ‘B’ below:

Once this has been completed you will see four more screws (circle below).  The top two screws are easily enough removed, the bottom two screws are partially obscured by a thin wire.  The wire is tucked in the drive cage.  Gently pry the cable away until the screws are exposed and remove the screws.

We are now ready to remove the second ribbon cable.  Gently pull it away (marked in red below) until it is no longer connected.

Removing the drive is not difficult, carefully life the drive cage and slide the hard drive out from underneath.  Do not pull it out from the top or try to remove the drive cage as you may cause irreparable damage.

Once you have removed the drive the drive turn it over and carefully remove the black tape covering the ribbon connection (marked below).

Once the tape has been removed the ribbon connection is exposed.  Carefully pull the ribbon cable out of the connector (marked below).

When finished you should have something the looks like the picture below:

This is a ‘ZIF’ drive.  These drives are commonly found in iPods and ultraportable PCs.  In order to image this drive you will require the following:

• Either a ‘Tableau T14 IDE’ or a ‘Tableau T35e’ write blocking device
• A ‘TDA5-ZIF’ drive adapter kit

Why so specific? Well, Tableau state that the ‘ZIF’ adapter is only guaranteed to work with one of the two Tableaux mentioned above.  I do not want to risk something going wrong so I’ll follow their advice.  Thankfully I had a ‘T35e’ already available.  You can try using this adapter with a different model, or even a different brand of write-blocker, but its not recommended.
Carefully insert the new ribbon (provided with the adapter) into the ribbon connector on the hard drive and then connect the other end of the ribbon into the adapter (see below).  Then plug the adapter into the Tableau.

From this point forward it is exactly the same as acquiring any other hard drive.  The Tableau will pick up the drive allowing you to image as normal.

Hope this is useful to someone out there.