SANS Digital Forensics and Incident Response Blog

Sizing up the FAT

Another Tuesday, another FAT post. If you're just joining us, you can find the whole series of posts here.

Over the last month or two, we've been working with a FAT image that has been modified by the suspect in a case we're working. We have slowly been undoing the changes made by the suspect, one file at a time. We have one file left to make right so let's see what's going on with our third and final file. Recall the output from fls from previous posts:
fls ouput from usbkey.img
We've already recovered the first two files and adjusted the cluster chains in the File Allocation Tables or starting cluster values in the FAT Directory Entry. Our final file to recover is "Scheduled Visits.exe".

Let's get to it. As with previous files, we'll start with the istat command:
istat usbkey.img 11
We give istat the name of the image file and the directory entry, 11 in this case, that we got from the output of the fls command. istat shows us a bunch of information about the file and looking over it all there's nothing that jumps out at us like the last file we recovered. You may remember that with that file we had an incorrect starting cluster and istat's output only showed a single allocated cluster as a result.

Our metadata looks like it lines up, let's copy it out of the mount point and run file against it and see what we get:
cp Scheduled Visits.exe

Interesting, our exe file is a zip archive. Could it be a self-extracting archive? Let's try using unzip to extract it:
unzip sched visits
Unzipping the file fails and based on the error message, it appears that the unzip command doesn't like the way the file ends. In the real world, we could be dealing with a corrupt zip file and a great way to figure that out would be to create a few sample zip files and examine them with a hex editor to see if they have a common footer and then see if our file is missing the same footer. I'll leave this as an exercise for the reader. In this case we're dealing with a file system that's been modified by our suspect and this is an exercise to teach us about FAT file systems and how they work.

Given that, let's get to our challenge question and give away a copy of Mac OS X, iPod, and iPhone Forensic Analysis DVD Toolkit by Ryan R. Kubasiak, Sean Morrissey and Jesse Varsalone, courtesy of Syngress. Our zip file has come to a premature end, but istat shows the file size is 1000 bytes and that there are two clusters allocated to it, which is more than enough. If you look back at screen shots from previous posts or if you have the a copy of the usbkey.img file and use the right tools to examine it, you'll see that something's not right about what istat is telling us. For the book, what's wrong, in which file system data structure do we fix it and how exactly? The first correct answer posted in the comments, wins the book. As in previous weeks, I'll update with some hints as time goes on, no more than one per day based on the feedback I've received previously from those who have been so close, but didn't have enough time. If you want to contact me outside the blog, there are a number of ways to do so (you figure it out). If no one posts the correct answer before 12:20 UTC next Tuesday, the book goes back in the giveaway pile.

Good luck.


Posted August 11, 2009 at 4:35 PM | Permalink | Reply


Parsing the FAT directory entry for "Scheduled Visits.exe" indicates that the file size is 1,000 bytes and is contained in sectors 487 and 488, cluster 73 and 74 respectively. By manually parsing the FAT table, we look up these cluster entries and find that cluster 74 does not contain an end-of-file marker (0xffff) as expected. Instead, we see that cluster 74 points to cluster 75 telling us that the file is greater than the 1,000 bytes as stated in the file directory entry. We continue to parse the FAT: cluster 75 points to cluster 76; cluster 76 points to cluster 77; cluster 77 contains the end-of-file marker (0xffff) and we now know we've reached the end of the file according to the FAT. Using this information, we know that the file starts at 73 and continues through clusters 74, 75, 76, and stops at cluster 77. In terms of physical sector addresses, we have sectors 487 through 491.
To carve the Scheduled Visits.exe file, we start at sector 487 and continue to 491 and extract a 2,560 byte chunk of data. If we open this file with 7-zip, we find that it is an encrypted zip archive containing the following file: "Scheduled Vists.xls".

Posted August 11, 2009 at 4:43 PM | Permalink | Reply


Awesome Joel. You've clearly stated what the problem is, but where and how do we fix it, exactly? Once we've made the correction, we should be able to copy the file out of the mount point and unzip it'' Well, without an error message anyway.

Posted August 11, 2009 at 4:57 PM | Permalink | Reply


We can tweak the image by changing the "Scheduled Visits.exe" directory listing, specifically the file size. The file size is contained in bytes 28-31 of the FAT directory listing. At this point, it contains 0x0003e8 (1,000) and we need to change it to 2,560 or 0x000A00. Don't forget the little endian conversion when making the modification to the image file. Here is the complete entry (long file name entries omitted):
53 43 48 45 44 55 7E 31 45 58 45 20 00 53 53 46 2B 2D 2B 2D 00 00 90 42 B8 2C 49 00 00 0A 00 00
After making this simple change to the image, the "Scheduled Visits.exe" file will copy out using the commands in the original blog post.

Posted August 11, 2009 at 5:20 PM | Permalink | Reply


Did you have to Re-Chain the Fat to add the additional clusters?

Posted August 11, 2009 at 5:38 PM | Permalink | Reply

Bryan Geraghty

It looks like the problem has been solved but I pose this question simply to further my own understanding:
Since fsstat in the very first post told us that the file beginning at cluster 487 actually consisted of 5 clusters (instead of 2), wouldn't modifying the EOC entry in the FAT allow us to copy the file?

Posted August 11, 2009 at 5:39 PM | Permalink | Reply


@Rob ''" I did not modify the FAT since it appeared to be intact. It was "chained" starting with the cluster listed in the file directory entry (73). 73 pointed to 74, which pointed to 75, which pointed to 76, which pointed to 77. 77 contained the EOF marker indicating that cluster 77 was the last cluster containing that file. Since the clusters were already ordered correctly, I simply extracted the contents of the clusters and appended the data to create a new file.

Posted August 11, 2009 at 5:58 PM | Permalink | Reply


Congrats, your answer is correct. Since the FAT cluster chain is in tact, we only need to modify the file size in the FAT Directory Entry for the file.
I'll contact you out of band for where to send the book.

Posted August 11, 2009 at 6:00 PM | Permalink | Reply


@Bryan ''" Please note that End-Of-File (EOF) and End-Of-Cluster (EOC) are synonymous. As the original problem suggested, the zip file wasn't being copied out in its entirety suggested that the file size was inaccurate. Note that the copy command uses the file size to calculate how much data to actually copy out and doesn't look at the FAT entry. To figure out how much data is actually there, we can analyze the FAT entry to find out which clusters are allocated (and in which order) to the "Scheduled Visits.exe" file. We can review the file's cluster chain in the FAT to discover that the file actually consists of five clusters and not the two as reported by istat based on the file's reported size stored in the file directory entry.

Posted August 11, 2009 at 6:02 PM | Permalink | Reply


If you look at that FAT, you'll see that the EOC marker is in the right place already. That's where fsstat is pulling those FAT cluster chains from. The problem is that the FAT Directory Entry for the file has the incorrect size of 1000 bytes, so when the file system drivers are told to read the file, they stop based on the reported file size rather than the EOC in the FAT. Strange how it all works'' or doesn't.

Posted August 11, 2009 at 6:05 PM | Permalink | Reply


Next week I'll have a post that attempts to explain the problems with this file and how Joel's solution can be implemented using a hex editor. There will be screen shots'' and another book to give away so check back in.

Posted August 11, 2009 at 7:05 PM | Permalink | Reply

Bryan Geraghty

Thank you for the answers to my question. It all makes sense to me now :)

Posted August 12, 2009 at 1:01 AM | Permalink | Reply


Good Stuff Joel'' I didn't look closely at the FAT and assumed since it was only reporing the LOGICAL size it didn't know that more existed on the physical drive..
I really like this problem set..this was my first look and couldn't hang out a bit longer to look at it''

Posted August 12, 2009 at 9:26 AM | Permalink | Reply


Hi trustedsignal, your post is remarkably great. Are you going to share to us the image so we can somehow replicate the steps.
Thank you

Posted August 12, 2009 at 12:28 PM | Permalink | Reply


Yaggi: There's a link to the usbkey.img file in the second line of the post. That's the original without any of the corrections made during this series of posts. Glad you're finding this to be useful.

Posted August 12, 2009 at 10:25 PM | Permalink | Reply


How do you know where the FAT directory is located? Did you take the output of fsstat which said "194" and multiply by 512? Joel said he "parsed" the FAT directory, but I am not clear on how he knows where the directory is located, how he know where to look, how he read the contents, where the file info was in the directory, and how he know where the cluster chains could be found. I notice in the first post a picture of hexedit at position 30,000 but I did not see an explanation of how anyone knew to look at 30,000. It is not clear because so many details are left out of the posts.

Posted August 13, 2009 at 12:42 AM | Permalink | Reply


JD, I apologize. With all the posts, it's difficult to track where we picked up the various details such as the location of the root directory entry's byte offset in the image. It's explained in the post on FAT directory entry repair. Do a search for 196608 to jump right to the explanation.
"We learned from fsstat that the Root Directory was located in sector 384. To get the byte offset in the image, we multiply 384 by the sector size which is 512, 384 * 512 = 196608 so we jump to that location in our hex editors and see the following''"
If you have additional questions, please let me know.

Posted August 13, 2009 at 12:44 AM | Permalink | Reply


JD, one more thing, you can see the full output for fsstat against this image in the first post in the series:

Posted August 13, 2009 at 1:11 AM | Permalink | Reply


Hello, can you elaborate on the process on the changing of the value to restore the file. Is it done in the GHEX? (sorry for this newbie question,I just wanted to understand the process)
"If we want to restore our deleted file, we need to do a couple things. One is change the starting character of the filename from 0xE5 to some other value and the other is to rebuild the cluster chain for the file in the FAT."

Posted August 13, 2009 at 2:23 AM | Permalink | Reply


Nick, any hex editor will do. Open the usbkey.img file in a hex editor and jump to the byte offset for the root directory entry. In this case the root directory entry is in sector 384, our sector size is 512 bytes so 384 * 512 = 196608. If you jump to that byte offset in the image file, you'll be at the start of the root directory entry. In FAT file systems, when files are deleted, the first character of the filename is changed to the hex value of 0x5e. Changing that to any other character will indicate to the FAT file system that the file is not deleted. The cluster chain resides elsewhere on the disk and will have to be recreated as it is zeroed out when files are deleted.