In the previous post in this Fried FAT series, we gathered some details about an altered FAT partition on a USB key by running fsstat against it. Our goal is to return the USB key image to its unaltered state.
Let's run fls to get some information about the files on the image:
Here we're concerned with the first three entries. We see a regular file that's been deleted, with metadata information at FAT Directory Entry 5. What do we mean by metadata information? Timestamps, file size and the addresses for the clusters that the file occupies on the disk are all metadata.
How do we know the first file has been deleted? Two ways, first, fls puts an asterisk before the metadata address to indicate the file has been deleted and second, on FAT file systems a deleted file has the first character in its name replaced with hexadecimal value 0xE5 which corresponds to the ASCII underscore. There are two other files, "cover page.jpg" and "Scheduled Visits.exe" with metadata at FAT Directory Entries 8 and 11. In our case notes, we record the information about these three files, including their names, allocation status and the address of the metadata information.
Let's pursue the first file in fls' output. Since we know the address for the file's metadata, we'll use the istat command and the metadata address that fls gave us:
Now we've got a load of useful information. We see the file is not allocated, which we already knew, the file size, timestamps and the sectors that the file is occupying.
Metadata for files on FAT file systems is stored in two locations. Each file has a FAT Directory Entry that lists the file name, starting cluster and length. Another location for metadata is the File Allocation Table (FAT) that maintains two pieces of information, cluster allocation status and which clusters a given file occupies.
For each cluster on the disk there's a corresponding entry in the FAT indicating if that cluster is allocated or unallocated. For FAT16, each cluster entry is a two byte value (16 bits, hence FAT16). For allocated clusters, the two byte cluster entry in the FAT will contain a number, that number will be the cluster address for the next cluster the file occupies on disk. So, the FAT Directory Entry tells where the first cluster of the file is, and the FAT tells what additional clusters the file occupies.
Using a hex editor, we can look at the directory entry for a file to determine its starting cluster, then look at the contents of that starting cluster's entry in the FAT to see the second cluster the file occupies. We can then look at the value stored in the second cluster for the file to see the third cluster the file occupies and so on, until we hit an End-Of-File marker in the FAT cluster chain (for simplicity sake 0xFFFF, see Brian Carrier's amazing File System Forensic Analysis book for full details as I'm oversimplifying a bit). (Carrier's book is an essential reference for digital investigators, if you don't own a copy, you owe it to yourself to check it out, there's a reason it's provided to students taking 508.)
Let's take a quick look, then we'll wrap up and next time we'll cover what we're seeing in the hex editor in more depth. Let's look at the two metadata locations, first the FAT Directory Entry for our deleted file and its corresponding FAT:
Recall that the FAT Directory Entry tells us, among other things, the file name, starting cluster address and file size. We'll cover some of these details in more depth in the next post.
And here we see the FAT cluster entries for our deleted file. Just as we expect, they've been zeroed out because the file has been deleted.
But wait a minute, if the cluster chain for the file has been zeroed out, where did istat get that list of sectors that the file occupies?
Ponder that. We'll talk about it next week.
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.
