Fried FAT: A look into FAT file systems

Once in a while, a colleague, neighbor or friend will call me in a panic over files they have accidentally deleted from the SSD card in their daughter's camera or worse. In such cases it's often possible to carve out files from the data layer using something like foremost or in a best case scenario, if metadata still exists, sorter can be put to good use to recover the data.

But what about a case where an enterprising perpetrator with above average tech savvy has deliberately altered a partition's metadata in order to inhibit access to the data? I know it's a stretch, but let's say there's a small time drug dealer who carries operational data on a USB stick, but he's altered the metadata in such a way that recovering the files from the USB stick is non-obvious.

During SANS Security 508: Computer Forensics, Investigation and Response, such a case is presented to the students. They are given an image from a USB key that has been altered and are asked to recover all the files it contains and for extra credit to repair the image by undoing the modifications made by the perp so the contents appear as they normally would. Granted, the case is a bit contrived, but the point of the exercise is to help students grok FAT file systems. And lest you scoff that FAT file systems went out with flannel shirts and grunge music, consider that USB keys are typically formatted as FAT32. Why? Because there's no security and there is near universal support for the file system. FAT is the lingua franca of file systems and with the advent of XFAT or FAT64, it's going to be with us for some time to come.

Mike Murr, of Code-X Technologies and Forensicblog.org, has provided an excellent solution to the problem of recovering the files on the USB image and has documented the issues with each of the files for students attending 508. What is not provided in his solution, is a solution to the extra credit problem of repairing the USB key. This series of blog entries will detail most of the steps required to repair the USB key image and provide some insight into the FAT file system.

Let's test the waters.

For starters, we need to gather some information about the USB image. To do so, we run fsstat against it and get the following output:

We learn from fsstat that we're dealing with a FAT16 file system and that our cluster size matches our sector size of 512 bytes. We see our primary File Allocation Table (FAT) begins at sector 4 or byte offset 2048 (4 sectors * 512 bytes). Our secondary FAT begins at byte offset 99328. The root directory begins at byte offset 196608.

We also see that there are two FAT "cluster chains" beginning in sectors 456 and 487. Students who pick up on this fact and understand what they are looking at are quickly able to recover two files from the USB image, but most are being exposed to the concepts for the first time and don't understand that those chains represent files so they move on to other methods of data recovery.

As an investigator, we'd take some notes in our notebook about what we're seeing:

• Partition type: FAT16
  
• Cluster size: 512 bytes
  
• FAT 0 at byte offset 2048
  
• FAT 1 at byte offset 99328
  
• Root directory at byte offset 196608
  
• FAT Cluster Chains:
  
• 456 - 486 (31 sectors)
  
• 487 - 491 (5 sectors)

That's it for today. In the next entry, we'll look at the files on the USB key and explore additional artifacts of the FAT file system in our quest to return the image to its unaltered state.

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.