I have been reading a book from Sybex on Encase, called Encase Computer Forensics, which was a reading assignment for my forensics course this semester. In reading the 2nd chapter, it discusses in some detail the FAT16 and FAT32 file systems. This got me thinking about how the FAT was used in legacy FAT (FAT 12/16/32) and how it changed in exFAT.
First, let’s levelset on the FAT. FAT stands for the File Allocation Table, and is basically a single uni-directional linked list that chains the clusters of a file together to define the file extent. One terminology that is used for this chain is a “cluster run”.
So, in legacy FAT (what I call the pre-exFAT FAT versions), when each cluster is written out to the disk, the FAT is updated with a link to the next cluster, or if the last (or only cluster) is marked with a EOF marker. So, unallocated clusters have a zero value, and allocated clusters have a non-Zero value. When a file is deleted, the cluster run is zeroed out, resulting in the clusters being marked as free and available for a new allocation. This presents an issue in file recovery, because if the file that was deleted was fragmented, then it is possible when recovering the file that the wrong clusters may be collected during the recovery.
exFAT uses a bitmap for allocation status. It does not rely on the FAT table to track allocation anymore. This makes file recovery a little less interesting and maybe easier.
When a file is allocated in exFAT, the key is whether the file is fragmented or not. If the file is fragmented, then exFAT builds the cluster run almost exactly as in legacy FAT file systems. However, if the file is NOT fragmented, then a bit in the Stream Extension Directory Entry is marked that the FAT Chain is invalid. This is one major difference in exFAT than legacy FAT, and can have a substantial I/O improvement. The FAT itself is written in sectors, not clusters, as it is written outside the cluster heap. Lets say the file is 1024 clusters, thus requiring 1024 FAT entries to define the file. That is 4096 bytes (each entry is 32 bits) and assuming a sector boundary that would be 8 sectors I/O. Yet, if the file is not fragmented, then only ONE bit in the directory entry is required to be changed, otherwise those 1024 entries (on 8 sectors) would have to be updated. Now, 128 bytes in the bitmap does require updating for the allocation status of all those clusters regardless of whether the file is fragmented or not.
So, let’s look at this (exFAT) in another way. If a file is not fragmented, then when the file is written the FAT is not updated. That means that the FAT is not filled in with a cluster run. Whatever was there from the previous file, stays there. When a file is deleted, regardless of whether the file was fragmented, the FAT is not wiped out (zeroed) on deletion. This means that if the file was fragmented, and there was a cluster chain, the chain is NOT destroyed on deletion. Remember, in legacy FAT, when a file was deleted, the cluster run had to be zeroed to show each cluster as ow being unallocated. But in exFAT, since allocation status is in the bitmap, there is no need to zero out the cluster run.
What this implies is that as long as the clusters themselves have not been reused for newer files, it is possible to accurately recover even heavily fragmented files that were deleted because the cluster run would still be intact.
However, it is important to realize that in exFAT, a zero in the FAT entry always has NO meaning, and non-zero values (except “bad” cluster) also have no meaning when the FAT Invalid bit is set. Any data in the FAT entries that exist when the FAT Invalid bit is set are residual cluster runs from fragmented files that once occupied the cluster before the current file was written there.
For the forensics examiner, knowing these changes in how the FAT is used in exFAT is important because the change from legacy FAT was significant.