6.3 FAT12/16/32 and exFAT Architecture, Directory Entries & File Deletion Mechanics

6.3 FAT12/16/32 and exFAT Architecture, Directory Entries & File Deletion Mechanics

Quick Answer: The File Allocation Table (FAT) family (FAT12, FAT16, FAT32) divides volumes into four physical regions: Reserved Area (VBR/BPB), FAT Area (FAT 1 & FAT 2), Root Directory, and Data Area. File cluster allocations are tracked as linked lists inside the FAT, terminating with an End-of-File (EOF) marker (0xFFF / 0xFFFF / 0x0FFFFFFF). Individual files are referenced by 32-byte directory entries that record 8.3 filenames, DOS-encoded timestamps, the file's starting cluster, and file size. When a file is deleted, Windows replaces the first byte of its directory entry with 0xE5 (sigma σ) and marks its cluster chain in the FAT as 0x00 (free). The actual data clusters and directory metadata remain intact until overwritten, allowing full recovery of contiguous files. exFAT eliminates cluster chaining for contiguous files via the "No FAT Chain" bit in its Stream Extension entry (0xC0), enhancing flash drive endurance and forensic recovery.

---

Evolution of the FAT File System Family

Originally designed by Bill Gates and Marc McDonald in 1977 for standalone disk BASIC, the File Allocation Table architecture became the standard file system for MS-DOS and early Windows. Because of its simplicity and universal compatibility, FAT variants and exFAT remain dominant across removable storage media: USB flash drives, SD/SDXC cards, digital cameras, and embedded IoT systems.

Comparative Technical Matrix

---

The Four Physical Architectural Areas of FAT

A FAT volume is structured into four strictly ordered, contiguous physical regions on storage media:

+-------------------------------------------------------------------------+
|                        FAT VOLUME ARCHITECTURE                          |
+-------------------------------------------------------------------------+
|  1. Reserved Area   |  2. FAT Area    |  3. Root Directory | 4. Data    |
|  VBR & BPB (Sec 0)  |  FAT 1 & FAT 2  |  (FAT12/16 only;   | Clusters   |
|  FSInfo (FAT32)     |  Cluster Map    |  in Data on FAT32) | 2 to N     |
+-------------------------------------------------------------------------+

1. The Reserved Area

Starts at Sector 0 of the partition. Its size is defined by the "Reserved Sector Count" field in the boot parameter block.

• Volume Boot Record (VBR - Sector 0): Contains the bootstrap loader code and the critical BIOS Parameter Block (BPB) and Extended BPB, which specify the physical geometry of the file system:
  • Bytes 11–12 (0x0B-0x0C): Bytes Per Sector (typically 0x0200 = 512 bytes).
  • Byte 13 (0x0D): Sectors Per Cluster (must be a power of 2: 1, 2, 4, 8, 16, 32, 64).
  • Bytes 14–15 (0x0E-0x0F): Reserved Sector Count (e.g., 1 for FAT12/16; typically 32 for FAT32).
  • Byte 16 (0x10): Number of File Allocation Tables (almost universally 0x02: FAT 1 and FAT 2).
  • Bytes 17–18 (0x11-0x12): Root Directory Entry Count (fixed count for FAT12/16; 0x0000 for FAT32).
  • Bytes 19–20 (0x13-0x14): Total Sectors 16-bit (if 0, see 32-bit field at offset 32).
  • Byte 21 (0x15): Media Descriptor (0xF8 for fixed hard disk; 0xF0 for 1.44 MB floppy).
  • Bytes 22–23 (0x16-0x17): Sectors Per FAT (FAT12/16 only).
  • Bytes 36–39 (0x24-0x27): Sectors Per FAT 32-bit (FAT32 only).
  • Bytes 44–47 (0x2C-0x2F): Root Directory Starting Cluster (FAT32 only; typically Cluster 2).
• FSInfo Sector (Sector 1 on FAT32): Tracks the volume's current free cluster count and provides a hint for the next available free cluster, accelerating allocation without scanning the entire FAT.
• Backup Boot Sector (Sector 6 on FAT32): A forensically critical exact replica of Sector 0. If malware or physical corruption destroys Sector 0, examiners can restore the VBR from Sector 6.

2. The FAT Area

Contains the File Allocation Tables. By default, every FAT volume maintains two identical copies:

• FAT 1: The active allocation map.
• FAT 2: The mirror / backup allocation map.

The FAT is an array of numerical entries where the index of the entry corresponds directly to a physical cluster number in the Data Area. Clusters 0 and 1 do not physically exist in the Data Area; the first two entries in the table are reserved for the Media Descriptor and End-of-Chain markers. User data clusters begin at Cluster 2.

3. The Root Directory Area

• FAT12 & FAT16: Occupies a fixed, pre-allocated physical region immediately following FAT 2 and preceding the Data Area. On hard drives, it is typically restricted to 512 directory entries (16 KB). If all 512 entries are populated, no further files can be created in the root directory regardless of remaining disk space.
• FAT32: The root directory is no longer fixed. It is treated as an ordinary cluster chain stored within the Data Area (usually starting at Cluster 2), allowing an unlimited number of root entries.

4. The Data Area

Occupies the remainder of the partition. It is divided into uniform allocation units called clusters. The byte offset of any cluster N (where N >= 2) can be calculated mathematically from the BPB:

• Data Area Start Sector = Reserved Sectors + (FAT Count * Sectors Per FAT) + Root Directory Sectors
• Cluster N Sector = Data Area Start Sector + ((N - 2) * Sectors Per Cluster)

---

FAT Cluster Chains & Entry Status Values

FAT tracks file allocations using a singly-linked list architecture inside the table.

Directory Entry for "secret.pdf": Starting Cluster = 3
+-------------------------------------------------------------------------+
| FAT Index | 0 | 1 |  2   |  3   |  4   |  5   |  6   |  7               |
| Value     |RES|RES| 0x00 | 0x04 | 0x06 | 0x00 |0xFFF8| 0x00             |
+-------------------------------------------------------------------------+
Linked Chain: Cluster 3 -> Cluster 4 -> Cluster 6 -> EOF (0xFFF8)

To locate the contents of secret.pdf:

1. The OS reads the starting cluster (Cluster 3) from the file's directory entry.
2. The OS inspects index 3 in the FAT, which contains the value 4.
3. The OS reads cluster 4 from disk, then inspects index 4 in the FAT, which contains 6.
4. The OS reads cluster 6 from disk, then inspects index 6, which contains 0xFFF8 (End-of-File marker).
5. The file read operation completes.

Hexadecimal Status Values in FAT Chains

---

The 32-Byte Standard Directory Entry Structure

Every file and subdirectory in FAT is defined by at least one 32-byte directory entry formatted according to the legacy MS-DOS 8.3 Short File Name (SFN) standard.

+-------------------------------------------------------------------------+
|                   32-BYTE DIRECTORY ENTRY STRUCTURE                     |
+-------------------------------------------------------------------------+
| Filename (8B) | Ext (3B) | Attr (1B) | NT (1B) | C-Time (3B) | C-Date (2B)|
| A-Date (2B)   | High Clus(2B) | M-Time (2B) | M-Date (2B) | Low Clus(2B)| Size (4B) |
+-------------------------------------------------------------------------+

Detailed Byte-by-Byte Structural Breakdown

Directory Entry Attribute Byte (0x0B) Bitmask

• 0x01 (Bit 0): Read-Only
• 0x02 (Bit 1): Hidden
• 0x04 (Bit 2): System
• 0x08 (Bit 3): Volume ID / Label (entry represents volume label, not a file)
• 0x10 (Bit 4): Directory (entry represents a subdirectory containing its own 32-byte entries)
• 0x20 (Bit 5): Archive (set whenever a file is created or modified; used by backup utilities)
• 0x0F (0x01 | 0x02 | 0x04 | 0x08): Special marker designating a Long File Name (LFN) entry!

DOS 16-Bit Date and Time Binary Bitfield Decoding

DOS timestamps store temporal data compactly within two 16-bit little-endian words:

DOS TIME (16 bits): [ h h h h h ] [ m m m m m m ] [ s s s s s ]
                    Bits 15 - 11  Bits 10 - 5     Bits 4 - 0
                    Hours (0-23)  Minutes (0-59)  Seconds / 2 (0-29)

DOS DATE (16 bits): [ y y y y y y y ] [ m m m m ] [ d d d d d ]
                    Bits 15 - 9       Bits 8 - 5  Bits 4 - 0
                    Year from 1980    Month (1-12) Day (1-31)

• Formula for DOS Time: Hour = Value >> 11; Minute = (Value >> 5) & 0x3F; Second = (Value & 0x1F) * 2;
• Formula for DOS Date: Year = 1980 + (Value >> 9); Month = (Value >> 5) & 0x0F; Day = Value & 0x1F;

---

Long File Name (LFN / VFAT) Mechanics

MS-DOS was restricted to 8-character filenames with 3-character extensions (README~1.TXT). To introduce long, case-sensitive filenames (up to 255 UTF-16 characters) in Windows 95 while maintaining backward compatibility with legacy DOS systems, Microsoft designed VFAT Long File Names (LFN).

LFN Architectural Implementation

1. For every file with a long name, the system generates a standard 8.3 Short File Name (SFN) directory entry, preceded by one or more 32-byte LFN entries.
2. LFN entries are written immediately before the SFN entry in reverse sequential order.
3. Each LFN entry holds up to 13 UTF-16 characters across three separate string segments:
   • Bytes 1–10: Characters 1–5 (10 bytes)
   • Bytes 14–25: Characters 6–11 (12 bytes)
   • Bytes 28–31: Characters 12–13 (4 bytes)
4. Attribute Byte (0x0B) = 0x0F: The attribute byte is set to READ_ONLY | HIDDEN | SYSTEM | VOLUME_ID. Legacy MS-DOS disk utilities treat 0x0F as an invalid combination and ignore the entry, preventing corruption.
5. Sequence Number (Byte 0): Numbered sequentially (1, 2, 3...). The last LFN record written (the first one encountered when scanning backward) has its 6th bit set (0x40), marking the end of the long name.
6. SFN Checksum (Byte 13): Contains an 8-bit checksum calculated from the 11-byte short filename. If an older operating system renames the 8.3 file, the checksum no longer matches, causing Windows to discard the stale LFN.

---

File Deletion Mechanics in FAT & Forensic Recovery

Understanding exactly what happens at the binary level when a user deletes a file in FAT is a cornerstone of the CHFI curriculum.

+-------------------------------------------------------------------------+
|                        FAT DELETION MECHANICS                           |
+-------------------------------------------------------------------------+
|  1. Directory Entry Byte 0x00  --> Overwritten with 0xE5 (Sigma 'σ')     |
|  2. FAT Allocation Table       --> Entire cluster chain zeroed to 0x00  |
|  3. Metadata Preserved         --> Starting Cluster & File Size INTACT  |
|  4. Data Area Clusters         --> Untouched in unallocated space       |
+-------------------------------------------------------------------------+

The Step-by-Step Deletion Process

When a file (e.g., CONFIDEN.DOC) is deleted on a FAT volume:

1. Directory Entry Modification: The operating system navigates to the file's 32-byte directory entry and overwrites Byte 0x00 with the hexadecimal byte 0xE5 (in ASCII/Code Page 437, this renders as the lowercase Greek sigma σ or character 229). If LFN entries exist, the first byte of each LFN entry is also marked with 0xE5.
2. FAT Chain Deallocation: The OS looks up the starting cluster in the FAT and traverses the linked list, overwriting every cluster pointer in the chain with 0x0000 (free/unallocated).
3. Preservation of Critical Metadata: Crucially, the OS does not zero out the remainder of the directory entry! The starting cluster pointers (Bytes 0x14-0x15 and 0x1A-0x1B), the 32-bit file size (Bytes 0x1C-0x1F), the timestamps, and characters 2 through 11 of the filename remain completely intact.
4. Preservation of Data Clusters: The actual clusters in the Data Area are never wiped or overwritten during deletion; they are merely reclassified as unallocated space.

Forensic Recovery Methodology

• Scenario A: Contiguous Files (100% Recovery Success): If the file was written to disk contiguously (as is standard on newly formatted flash drives or defragmented media), forensic recovery is trivial:
  1. Read the Starting Cluster C from directory entry bytes 0x14-0x15 (high) and 0x1A-0x1B (low).
  2. Read the File Size S from bytes 0x1C-0x1F.
  3. Calculate the number of clusters required: K = ceil(S / Cluster Size).
  4. Read K consecutive clusters starting at Cluster C directly from the Data Area. The file is completely reconstructed.
• Scenario B: Fragmented Files (The FAT Challenge): If the file was fragmented across non-contiguous clusters (e.g., clusters 50–52, then jumping to clusters 80–84), recovery via directory entries recovers only the first fragment (clusters 50–52) because the link pointing to cluster 80 was zeroed out (0x0000) in the FAT table during deletion. Reconstructing the remaining data requires file carving (header/footer analysis using tools like PhotoRec or Scalpel) across unallocated space.

[!CAUTION] Directory Entry Recycling: When a new file is created on a FAT volume, the file system scans directory entries for the first available slot: either an entry starting with 0x00 (never used) or 0xE5 (previously deleted). If a user creates a new file, the operating system will overwrite the 0xE5 directory entry, permanently destroying the deleted file's starting cluster pointer, timestamps, and file size.

---

exFAT Architecture & Modern Flash Optimizations

Introduced with Windows CE 6.0 and Windows Vista SP1, Extended FAT (exFAT / FAT64) was engineered specifically to overcome FAT32's limitations while avoiding the overhead, metadata churn, and journal wear of NTFS on flash storage.

Architectural Innovations of exFAT

1. Elimination of the 4 GB File Size Limit: Supports theoretical file sizes up to 16 Exabytes (2^64 - 1 bytes), enabling storage of 4K/8K video recordings and massive disk images on SDXC cards.
2. Cluster Size Scalability: Supports cluster allocation sizes up to 32 MB, minimizing allocation overhead on large multi-terabyte flash media.
3. Allocation Bitmap: Unlike FAT32, which must traverse linked lists across the FAT table to locate free space, exFAT maintains a centralized Allocation Bitmap (similar to NTFS $Bitmap), where 1 bit represents 1 cluster (0 = free, 1 = allocated). This permits instantaneous free-space calculation and reduces flash memory wear.
4. Directory Entry Sets: exFAT groups directory entries into sets of 32-byte records:
   • Primary File Directory Entry (0x85): General secondary flags and attributes.
   • Stream Extension Directory Entry (0xC0): Contains the critical allocation parameters (see below).
   • File Name Directory Entries (0xC1): Up to 17 entries holding 15 UTF-16LE characters each (total 255 characters).

+-------------------------------------------------------------------------+
|                     exFAT DIRECTORY ENTRY SET                           |
+-------------------------------------------------------------------------+
| Primary File Entry (0x85)  | Timestamps, File Attributes                |
| Stream Extension (0xC0)    | Starting Cluster, File Size, NoFatChain Bit|
| File Name Entries (0xC1)   | UTF-16LE Filename Characters (up to 255)   |
+-------------------------------------------------------------------------+

The "No FAT Chain" Optimization & Forensic Impact

The most significant architectural feature of exFAT for digital forensic examiners is the No FAT Chain flag located within the Stream Extension Directory Entry (0xC0):

• General Secondary Flags (Byte 1 of entry 0xC0):
  • Bit 0 (AllocationPossible): 1 if allocation exists.
  • Bit 1 (NoFatChain): 1 indicates that the file is stored contiguously without a cluster chain in the FAT!

Why Microsoft Implemented NoFatChain

On traditional FAT32 flash media, writing a large file requires thousands of repetitive write cycles to update the FAT table clusters. On flash memory, repeated writes wear out NAND memory cells prematurely. Under exFAT, if a file is written contiguously, the operating system sets NoFatChain = 1, logs the starting cluster and valid data length in entry 0xC0, and completely skips writing entries to the FAT table!

Forensic Utility

When a contiguous file is deleted on an exFAT volume:

1. The Allocation Bitmap bits are toggled to 0 (free).
2. However, the Stream Extension directory entry (0xC0) retains the exact starting cluster, the valid data length, and the NoFatChain = 1 bit intact.
3. Because the examiner knows mathematically that the file was contiguous, the entire file can be 100% extracted directly from the Data Area without carving and without consulting a broken FAT chain.

---

Practical DFIR Tool Commands & Workflows

# 1. Examine FAT volume geometry and BPB structure
fsstat -o 2048 /dev/sdc1

# 2. List directory entries including deleted files (marked with * and 0xE5)
fls -o 2048 -r -d -p /dev/sdc1

# 3. View metadata for a specific FAT directory entry (inode/entry offset 205)
istat -o 2048 /dev/sdc1 205

# 4. Extract data starting at cluster 1420 for an exact length of 65,536 bytes
dd if=/dev/sdc1 of=carved_file.bin bs=4096 skip=1420 count=16

[!TIP] In FTK Imager or Autopsy, deleted FAT files appear with a red "X" icon and their filenames show an underscore or question mark replacing the first character (e.g., _ONFIDEN.DOC). The first letter was replaced with 0xE5 by the operating system, but all trailing characters and the starting cluster pointer remain preserved in the directory table.