SANS Digital Forensics and Incident Response Blog

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:Deleted FAT cluster chain

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:Fixed 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:
File recovered

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:

Syngress Book Challenge

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.

6 Comments

Posted July 14, 2009 at 4:44 PM | Permalink | Reply

Mark McKinnon

0003 00010004 0005 0006 0007 0008 0009 000A 000B 000C 000D 000E 000F 0010
0011 0012 0013 0014 0015 0016 0017 0018 0019 001A 001B 001C 001D 001E 001F 0020
0021 0022 0023 0024 0025 0026 0027 0028 0029
C:\\mark\\sleuth\

in>istat c:\\mark\\usbkey.img 5
Directory Entry: 5
Allocated
File Attributes: File, Archive
Size: 20480
Name: JIMMYJ~1.DOC
Directory Entry Times:
Written: Mon Apr 15 14:42:30 2002
Accessed: Wed Sep 11 00:00:00 2002
Created: Wed Sep 11 08:49:48 2002
Sectors:
416 415 417 418 419 420 421 422
423 424 425 426 427 428 429 430
431 432 433 434 435 436 437 438
439 440 441 442 443 444 445 446
447 448 449 450 451 452 453 454

Posted July 14, 2009 at 4:47 PM | Permalink | Reply

Mark McKinnon

Tags for eof were left out before the 0003 and after the 0029. Sorry was not thinking in html.

Posted July 14, 2009 at 4:59 PM | Permalink | Reply

J C Gordon

it's a trick question ''" sector 415 would be in cluster 1 which does not exist in FAT file systems.

Posted July 14, 2009 at 5:03 PM | Permalink | Reply

trustedsignal

You're right JC, but you can still make istat produce this output by modifying the FAT.
Mark, what hex editor are you using? Does it automagically do the little/big endian conversion?
Either way, you've obviously arrived at the same solution I did. The book is yours.
I'll give away another title next week, or perhaps another blog contributor will throw in a question this week to give one way.
Thanks for playing.

Posted July 15, 2009 at 10:44 AM | Permalink | Reply

Mark Mckinnon

I was using Fat Explorer by runtime.org, usually I use winhex though. Yes it was a trick question J C and like Dave said I just had to make istat show what Dave wanted he never said anything about trying to recover the file.
Now I guess a question is should istat have reported that the file would be in error since it said it was in cluster 1?
Nice Challenge Dave makes you stop and think about things which is a good thing sometimes. Also always good to get back to the basics as it is sometimes easy to forget these little things.

Posted July 15, 2009 at 12:40 PM | Permalink | Reply

trustedsignal

I'll have to check out FAT Explorer, haven't seen that yet.
I promise the next question for a book will be more straight forward. Should be up next Tuesday.