Rebuilding FAT cluster chains

For those reading this entry and not familiar with the others in the series, a brief bit of background is in order. This post is the fourth in a series about the FAT file system. We have a disk image taken from a suspect's USB key, but some of the metadata has been modified to make getting at the evidence more difficult, though only slightly. We're attempting to undo the modifications our suspect has made and restore the image to its unaltered state.

I did a little digging over the weekend and discovered a couple links that may be of interest to those playing along at home. First, Mike Murr, of Code-X Technologies and Forensicblog.org, has covered some aspects concerning our image on his blog here. He also has a link to the Honeynet.org web site where you can download a disk image that is remarkably similar to the one I've been using, but not exactly the same. Still, if you want to get some hands-on experience, download it and go to town.

In the previous entry, we repaired a FAT Directory Entry in an effort to recover a deleted file. We mounted the image as a loopback device and saw a directory listing showing the file appearing as we would expect, but when we attempted to copy the file out of the mounted file system, the copy operation erred out.

I explained the reason for this, we hadn't yet rebuilt the cluster chain in the File Allocation Table. So when the copy begins, it pulls the starting cluster number for the file from the FAT Directory Entry that we repaired, but there's no map or cluster chain in the File Allocation Table to tell where the file continues.

In this post, we'll rebuild the cluster chain and try the copy again. In order to do this, we'll need to reopen the FAT in our hex editors. Recall from previous posts the FAT is located at byte offset 2048 in our image. Here's what we saw there:

By now you know from the previous entries that this structure in the FAT was zeroed out when the file was deleted and that the file system uses the data contained in these 16 bit cluster entries to map out the file's location on disk. Without this map, who knows where the file lies.

To rebuild the map, we have to populate the 16 bit cluster entries with cluster addresses where the data resides on disk. We saw in the previous entry that the FAT Directory Entry told us the file began in cluster two. We know from the way a file system optimizes writes that it will put the file down contiguously if it can and in this instance we have enough available cluster entries in the FAT to accommodate our file.

Let's see the corrected FAT:

Aside from the fact that I've masked out the values we're not interested in seeing, you can now see the 16-bit values (also known as words) that make up each cluster entry in the FAT. Each pair of bytes (03 00, 04 00, 05 00...) represents a cluster on the disk, and inside each word is the next cluster address on the disk where the file continues. Previously, when the file was deleted, each word contained 00 00, 00 00, etc.

We know from the FAT Directory Entry that our file started in cluster two. The 16 bit value in the FAT entry for cluster two is 0x0300, the 16 bit value in the FAT entry for cluster three is 0x0400, the 16 bit value in the FAT entry for cluster four is 0x0500 and so on. If we convert these values to decimal we get three, four, five and so on. So, cluster two is the start of the file, the FAT Directory Entry tells us this, to see where the file continues, we look at cluster two's entry in the FAT itself where we find that the file continues in cluster three, then we look in cluster three's entry in the FAT and see that the file continues in cluster four, then we look in cluster four's entry in the FAT and see that the file continues in cluster five. We continue this process until we reach the end-of-file marker.

Now that we've rebuilt the FAT cluster chain, let's see if copying the file from the mounted file system works:

With any luck, these first four posts have given you a greater understanding of how FAT file systems work. In the next post, we'll tackle the next file in the image.

In the meantime, here's a challenge with a reward. Angelina Ward from Syngress Publishers has generously provided the blog with some books to give away. The reward will be a copy of Chris Pogue's Unix and Linux Forensic Analysis DVD Toolkit.

Here's the challenge: What modifications would have to be made to the FAT in order to get the following output from istat against FAT Directory Entry 5:

The first person to submit the correct answer as a comment on this post, wins the book. U.S. residents only.

Dave Hull, GCFA Silver #3368, is a technologist focusing on incident response, computer forensics and application security. He can be found on the web at TrustedSignal.com.