FAT Directory Entry repair

This is the third installment in a series of posts about FAT file systems. We're using the usbkey.img file that's given to students of SANS SEC 508. The image has been altered by the suspect. Our goal is to return it to it's unaltered state.

In the second post, we gathered some information about the files on the image and using a hex editor took a look at the two metadata structures for FAT file systems, the FAT Directory Entry and the File Allocation Table. We glossed over lots of details in the last post, so let's dig into some of those details now.

First, how did I know where to locate the FAT in the usbkey.img file?

Recall from the first post that running fsstat against the image told us that the first FAT was located at sector offset four and that our sector size was 512, thus in our hex editors, we jump to byte offset 2048 (4 * 512) and voila! we're sitting at the primary FAT.

On FAT file systems, the cluster numbering begins at two and despite the fact that our sector size and our cluster size are the same on this image, cluster two does not equal sector two. The output of fsstat from the first post showed us that there were four reserved sectors, then two copies of the FAT, then the Root Directory and finally the cluster area of the disk, which actually contains the data for our files, starts in sector 416.

So in our image, cluster two is in sector 416. Given that our sector size equals our cluster size, cluster three is in sector 417, cluster four is in sector 418 and so on. Where's cluster one? There is no cluster one in FAT file systems, they begin numbering with two. No, I don't know why.

Let's look again at our FAT cluster chain from the previous post:

The highlighted portion is the FAT cluster chain entry for our deleted file, note the last nibble that's highlighted should in fact be a byte that's highlighted.

In the previous post, I asked how istat knew what sectors the deleted file occupied since they were zeroed out, as we would expect for a deleted file.

And the answer is that istat takes the size of the file and the starting cluster number as given in the FAT Directory Entry for the file (in FAT file systems, the metadata for a deleted file is preserved in the FAT Directory Entry, but the metadata in the FAT is wiped out, indicating that the clusters the file had occupied are now available), then istat looks in the FAT for the cluster entry that corresponds to the starting cluster and parses the cluster chain. If the cluster is unallocated, as it is in this case, istat assumes the cluster still contains data for our deleted file. istat will walk the entire cluster chain, and if it encounters an allocated cluster, it will skip that cluster and assume the file is fragmented and will adjust its output accordingly. So for deleted files, istat makes an educated guess.

Let's compare this to a file that hasn't been deleted. Look back at the hex editor capture above. See the "2B 00 2C 00 2D 00..." Let's convert those 16 bit values to decimal, we have to flip the bytes to convert from little to big endian, so 2B 00 becomes 00 2B, 2C 00 becomes 00 2C, etc. Converting these values to decimal gives us 43, 44, 45... What we see is a cluster chain starting in the FAT Directory Entry for cluster 42, the contents of that cluster entry contain 43, telling us the file that begins in cluster 42 continues in cluster 43, we look at cluster 43's entry and see it contains the value 44, telling us the file continues in cluster 44, cluster 44's entry contains the value 45. We could repeat this process, following the chain all the way through to the End-of-File marker.

Remember the calculations we did about the cluster to sector numbering in this image? We said cluster two was in sector 416 for a difference of 414. If we add 414 to 42, we get 456. You've probably forgotten about the output from fsstat that was saw previously, so let's see it again:

That 456-486 is the cluster chain we see the beginning of in the hex editor screen capture above.

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.

Let's tackle the FAT Directory Entry changes first and see what that does for us. We open the usbkey.img in our hex editors and jump to the Root Directory. 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:

The directory entry begins at the bottom of the figure at byte offset 0x30040 (196672 in decimal). I won't give you the complete data structure for the FAT Directory Entry, but there are a few things to point out. For one, the starting cluster for this file is given as a two byte value starting in byte offset 26 from the beginning of the record, in this case the value there is 0x0200, which when converted to decimal is two (remember to swap the bytes to get big endian ordering during your conversion). So the starting cluster for our deleted file is two, add 414 to convert to starting sector 416. Another good thing to know is that the size of the file is given as a four byte value beginning at byte offset 28 in the record. In this case, that four byte value is 0x0050 0000. Converted to decimal, this is 20480.

To alter this directory entry to recover the file, we only have to change the 0xE5 at byte offset zero (of this record) to 0x4A, which is the ASCII character 'J'. If we want to preserve the long file name entry, there are a few other things to change but these are optional, the system will work just fine without the long file name entry. Long file name entries will precede the standard 8.3 file name entry in the FAT Directory Entry for the file. Each long file name entry will be 32 bytes and will begin with sequence number 0x01 and increment until the last long file name entry, which will begin with 0x4n. The four indicates this is the final long file name entry and the n signifies the number of the long file name sequence. In this instance there are two additional long file name entries for this file. During the deletion of this file, the long file name sequence numbers were replaced with 0xE5 and the long file name attributes (at byte offset 11) were zeroed out, they should be set to 0x0F.

Making all these required changes to the FAT Directory Entry, here's what the fixed version looks like for our file:

After making these modifications, we can mount the image and run ls against the mount point and see the following:

Awesome, we've made the necessary changes to the FAT Directory Entry so that we can now see the previously deleted file's long file name in the directory listing. Let's see what happens when we try to copy that file to another location?

Why doesn't this work? Remember I said we'd have to fix the FAT Directory Entry and the cluster chain in the FAT? We haven't altered the cluster chain yet, so when we start the file copy the OS and file system drivers start reading the file, but fail because without the cluster chain in the FAT, they have no idea where the file continues and no way of knowing where the file ends. In order to be able to copy the file, we'll need to rebuild the cluster chain. You've read about it and seen it in a hex editor; we know the chain's been zeroed out, so what values do we need to put in the FAT to rebuild it? Think about that. Do you know the answer? We'll go over it in the next post in the series.

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.