The File Allocation Table (FAT) file system was originally designed by Marc McDonald at Microsoft in 1977 for use with Microsoft Standalone Disk BASIC-80. It was later refined and incorporated into MS-DOS, with contributions from Bill Gates and other Microsoft engineers. Over time, it evolved into three main versions—FAT12, FAT16, and FAT32—distinguished primarily by the size of their addressable entries in the FAT structure.
Microsoft stopped using FAT file systems for operating systems with the advent of Windows NT in the mid- to late 1990s. Early versions of Windows assumed that there was only one user. The FAT file system did not have any way to store file ownership or file access permissions, so it was unsuitable for an operating system that could handle multiple users. The one arena where FAT32 still survives is in USB drives. They need to go from a camera to a PC to a phone, etc. Support for FAT32 is ubiquitous, so it is still the standard on USB drives.
The layout of the FAT file system has three physical sections to it, which can be seen in the figure below.
![]() |
| Figure 1: Layout of the FAT file system |
The reserved area begins at sector 0 of the file system, and its size is defined in the boot sector. In FAT12 and FAT16, it typically consists of a single sector, while FAT32 usually reserves multiple sectors. The data at byte offsets 0xe-0xf in figure 2 (i.e., 0x0026) represents the size in sectors for the reserved area. This corresponds to 38 sectors.
The FAT area follows the reserved area and contains one or more FAT structures. There are two important parameters related to this area: the number of FAT copies and the size of each FAT table. Its total size is determined by multiplying the number of FATs by the size of each one, both values specified in the boot sector. The data at byte offset 0x10 in Figure 2 represents the number of FAT copies, which is “0x02” (or 2 copies). And the data at byte offsets 0x16-0x17 represents the size in sectors for one FAT table, which is “0x0000.” It indicates the file system here is FAT32. Then, it should be referred to the data at byte offsets 0x24–0x27 for the FAT table size in sectors, which is "0x0000038D" (i.e., 909 sectors).
Next is the data area, which holds the clusters used to store files and directories. It begins immediately after the FAT area, and its size is calculated by subtracting the data area’s starting sector from the total number of sectors in the file system, as indicated in the boot sector. The data area is divided into clusters, with the number of sectors per cluster also defined in the boot sector. The size in sectors for the file system is represented by the data either at byte offsets 0x13-0x14 (a 2-byte value) or at byte offsets 0x20-0x23 (a 4-byte value) if the 2-byte value above (bytes 0x13-0x14) is zero. It is obvious that in Figure 2, the total size of the file system is stored at byte offsets 0x20-0x23. The size of the file system is 0x000E37BA = 931770 sectors. Therefore, the size of the data area is 930823 sectors after subtracting the sizes of the reserved and FAT areas.
Within the data area, there is one important structure, the root directory. The root directory is always located immediately following the FAT region (i.e., the beginning of the data area) in FAT12 and FAT16, whereas it can be stored anywhere within the data area in FAT32 (though it is commonly placed at the beginning). This flexibility enables FAT32 to work around bad sectors and allows the root directory to expand as needed. The starting cluster of the FAT32 root directory is defined in the boot sector, while its size is managed through the FAT structure. In FAT12/16, we know the root directory is located immediately after the FAT area. Then, we know the number of directory entries by referring to the data at byte offsets 0x11-0x12. Since each directory entry is 32 bytes in size, the size of the root directory is obtained by multiplying the number of directory entries by 32 bytes. However, in FAT32, the root directory is treated as a regular file, and the starting cluster that stores the root directory is specified at byte offsets 0x2c-0x2f in the FAT32 boot sector (usually cluster 2 by default).
The FAT Volume Boot Record
The Volume Boot Record (VBR)—also known as the Partition Boot Sector—is the first sector of a FAT-formatted volume. It resides in the Reserved Area and lies in sector 0. It contains information about the partition, such as the number of bytes per sector, the number of sectors per cluster, the number of reserved sectors, the number of FATs, the size of each FAT, and the location of key data areas. Reading the VBR, the OS knows where the data clusters start and can find the root directory (always at data cluster #2). The first value in the boot sector, bytes 0 to 2, is a boot code instruction that tells the computer where to find the code needed to boot the operating system by way of a jump instruction. If the file system is not used to boot the computer, the value is not needed. Note that DOS and Windows require the value to be set on non-bootable file systems, but other operating systems, such as Linux, do not.
The format varies between (partitioned) hard disks and (unpartitioned) floppies, and between various releases of DOS and Windows ... but conceptually, the boot record:
- begins with a branch instruction (to the start of the real bootstrap code)—offsets 0x00-0x02.
- followed by a volume description (the BIOS Parameter Block).
- followed by the bootstrap code.
- followed by a signature (for error checking).
![]() |
| Figure 2: Hex dump of FAT32 Volume Boot Record |
The most important data structure in the FAT volume is the BIOS Parameter Block (BPB), where the configuration parameters of the FAT volume are stored. FAT12/16 and FAT32 have different versions of the boot sector, but they both have the same initial 36 bytes. From byte 36 onward, FAT12 and FAT16 have a different layout than FAT32. The one value that they both have in common is the signature 0x55 in byte 510 and 0xAA in byte 511.
BIOS Parameter Block
The BIOS Parameter Block (BPB) is located in the first sector of the volume in the Reserved Region. On partitioned devices, such as hard disks, the BPB describes the volume partition, whereas on unpartitioned devices, such as floppy disks, it describes the entire medium. The FAT file system's BIOS Parameter Block (BPB) is a data structure in the boot sector that provides essential information about the file system's geometry:
- number of bytes per (physical) sector.
- number of sectors per track.
- number of tracks per cylinder.
- total number of sectors on the volume.
It also describes the file system's layout on the volume:
- number of sectors per (logical) cluster.
- the number of reserved sectors (not part of the file system).
- the number of alternate File Allocation Tables.
- the number of entries in the root directory.
These information allows the operating system to correctly read and write data to the storage volume. In the first implementation of the FAT file system (MS-DOS version 1), there was no BPB in the boot sector, and the determination of the media type, of which only two were possible, was carried out by looking at the first byte of the FAT itself. This was changed in MS-DOS version 2 by placing a BPB in the boot sector. This BPB only allowed for a FAT volume with less than 65,536 sectors due to the fact that the “Total sectors” field was only two bytes in size, and this resulted in the 32 MB limit. This limitation was lifted in MS-DOS 3, where the BPB was modified to include a new alternative 4-byte field for the “big total sectors” value.
![]() |
| Figure 3: FAT 12/16 VBR BIOS Parameter Block |
With the introduction of FAT32 in the Microsoft Windows 95 operating system (OSR2), the BPB was again modified. This new version exactly matches the FAT12 and FAT16 BPB up to but excluding offset 24h (see Figure 3). Thereafter, the changes are as shown in Figure 4 below.
![]() |
| Figure 4: FAT32 VBR BIOS Parameter Block |
It should be noted that the FAT32 boot record is contained in three logical sectors: 0, 1, and 2. Each of these sectors has the values “55 AA” in the last two bytes of the sector. The BPB and initial bootstrap code are contained within sector 0, and an information structure called FSInfo is normally held in sector 1 (see offset 30–31, Figure 4). Much of the code that enables the boot record to read FAT32 entries is held in sector 2. A copy of all three sectors of the boot record is normally held in sectors 6 to 8 (see offset 32–33, Figure 4).
The FSInfo structure contains two signatures, a lot of reserved space, and two entries that might be useful for an analyst to examine, namely: a count of free clusters and the next available cluster. The count of free clusters is a 4-byte field located at offset 1E8h from the start of the sector. If the value is FFFFFFFFh, then the count is unknown; otherwise, it is the last known count of free clusters on the volume. The literature helpfully tells us that it might not be correct! The four-byte value at offset 1ECh is a hint to the FAT driver of where to start looking for the next free cluster. Again, if its value is FFFFFFFFh, there is no hint; otherwise, it might be the next available free cluster.
![]() |
| Figure 5: Hex dump of the FAT32 BIOS Parameter Block |
|
Offset (hex) |
Length |
Sample Hex Values (big endian) |
Description |
|
0B-0C |
WORD |
0200h (= 512d) |
Bytes per sector. This is the size of the hardware sector. Allowed values include 512, 1024, 2048, and 4096. |
|
0D |
BYTE |
08h (= 08d) |
Number of sectors per cluster (data unit). Allowed values are powers of 2, but the cluster size must be 32KB or smaller. |
|
0E-0F |
WORD |
0026h (= 38d) |
Size in sectors of the reserved area |
|
10 |
BYTE |
|
Number of file allocation tables (FATs). The number of copies of the file allocation table on the volume. Typically, the value of this field is 2 for redundancy, but according to Microsoft it can be one for some small storage devices. |
|
11-12 |
WORD |
0000h |
For FAT12 and FAT16 volumes, this field contains the count of 32-byte directory entries in the root directory. For FAT32 volumes, this field must be set to 0. For FAT12 and FAT16 volumes, this value should always specify a count that when multiplied by 32 results in an even multiple of bytes per sector. For maximum compatibility, FAT16 volumes should use the value 512. |
|
13-14 |
WORD |
0000h |
Small Sectors. The number of sectors on the volume if the number fits in 16 bits (65535). For volumes larger than 65536 sectors, this field has a value of 0 and the Large Sectors field is used instead. For FAT32 volumes, this field must be 0. For FAT12 and FAT16 volumes, this field contains the sector count, and Large sectors field is 0 if the total sector count fits (is less than 0x10000). |
|
15 |
BYTE |
F8h |
Media descriptor byte. The legal values for this field are 0xF0, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE, and 0xFF. 0xF8 is the standard value for fixed (non-removable) media. For removable media, 0xF0 is frequently used |
|
16-17 |
WORD |
0000h |
This field is the FAT12/FAT16 16-bit count of sectors occupied by one FAT. On FAT32 volumes this field must be 0, and the data at byte offsets 0x24 0x27 should contain the FAT size count. By using this information, together with the Number of FATs and Reserved Sectors, you can compute where the root folder begins. By using the number of entries in the root folder, you can also compute where the user data area of the volume begins. |
|
18-19 |
WORD |
003Fh |
Sectors per track for interrupt 0x13. This field is only relevant for media that have a geometry (volume is broken down into tracks by multiple heads and cylinders) and are visible on interrupt 0x13. |
|
1A-1B |
WORD |
00FFh |
Number of heads for interrupt 0x13. This field is relevant as discussed above for Sectors per track. |
|
1C-1F |
DWORD |
1D0D9045h |
Count of hidden sectors preceding the partition that contains this FAT volume. This field is generally only relevant for media visible on interrupt 0x13. This field must always be zero on media that are not partitioned. |
|
20-23 |
DWORD |
000E37BA (= 931770d) |
Large Sectors. If the Small Sectors field is zero, this field contains the total number of sectors in the volume. If Small Sectors is nonzero, this field contains zero. For FAT32 volumes, this field must be non-zero. This is the total number of sectors used by the FAT volume. |
|
From offset 0x24 onward, FAT12 and FAT16 volumes have a different layout than FAT32 volumes. |
|||
The table below shows the BPB layout for FAT 12 and FAT 16 from byte offset 0x24 onwards.
|
Offset (hex) |
Length |
Sample Hex Values (Big endian) |
Description |
|
24 |
BYTE |
80h |
Int 0x13 drive number. This field supports MS-DOS bootstrap and is set to the INT 0x13 drive number of the media (0x00 for floppy disks, 0x80 for hard disks). NOTE: This field is actually operating system specific. |
|
24 |
BYTE |
00h |
Reserved (used by Windows NT). Code that formats FAT volumes should always set this byte to 0. |
|
26 |
BYTE |
29h |
Extended boot signature. This is a signature byte that indicates that the following three fields in the boot sector are present. Set to 0x29 if either of the following two fields are non-zero. |
|
27-2A |
DWORD |
1C3B15F1h |
Volume serial number. This field, together with Volume label field, supports volume tracking on removable media. These values allow FAT file system drivers to detect that the wrong disk is inserted in a removable drive. This ID is usually generated by simply combining the current date and time into a 32-bit value. |
|
2B-35 |
11 bytes |
5445535431202020202020h (Little endian) |
Volume label. This field matches the 11-byte volume label recorded in the root directory. The setting for this field when there is no volume label is the string NO NAME . The sample value is decoded in ASCII as TEST1. |
|
36-3D |
QWORD |
4641543136202020h (Little endian) |
One of the strings FAT12 or FAT16 . The sample value is decoded in ASCII as FAT16. Note: Many people think that the string in this field has something to do with the determination of what type of FAT FAT12, FAT16, or FAT32 that the volume has. This is not true. This string is informational only and is not used by Microsoft file system drivers to determine FAT type because it is frequently not set correctly or is not present. |
The table below shows the BPB layout for FAT 32 from byte offset 0x24 onwards.
|
Offset (hex) |
Length |
Sample Hex Values (Big endian) |
Description |
|
24-27 |
DWORD |
0000038Dh (= 909d) |
This field is only defined for FAT32 media and does not exist on FAT12 and FAT16 media. This field is the FAT32 32-bit count of sectors occupied by ONE FAT. the FAT12/FAT16 16-bit count of sectors given in byte offsets 16-17 must be zero. |
|
28-29 |
WORD |
0000h |
Defines how multiple FAT structures are written to.
|
|
2A-2B |
WORD |
0000h |
This is the version number of the FAT32 volume where the most significant byte is the major version number and the least significant byte is the minor version number. This supports the ability to extend the FAT32 media type in the future without worrying about old FAT32 drivers mounting the volume. This document defines the version to 0:0. If this field is non-zero, back-level Windows versions will not mount the volume. FAT32 file system drivers must check this field and not mount the volume if it does not contain a version number that was defined at the time the driver was written. |
|
2C-2F |
DWORD |
00000002h |
This is the cluster number of the first cluster of the root directory, usually 2 but not required to be 2. |
|
30-31 |
WORD |
0001h |
Sector number of FSINFO structure in the reserved area of the FAT32 volume. Usually 1. Note: There will be a copy of the FSINFO structure in Backup Boot, but only the copy pointed to by this field will be kept up to date (i.e., both the primary and backup boot record will point to the same FSINFO sector). |
|
32-33 |
WORD |
0006h |
Set to 0 or 6. If non-zero, indicates the sector number in the reserved area of the volume of a copy of the boot record. |
|
34-3F |
12 bytes |
000000000000000000000000h |
Reserved for future expansion. Code that formats FAT32 volumes should always set all of the bytes of this field to 0. |
|
40 |
BYTE |
80h |
Int 0x13 drive number. This field supports MS-DOS bootstrap and is set to the INT 0x13 drive number of the media (0x00 for floppy disks, 0x80 for hard disks). NOTE: This field is actually operating system specific. |
|
41 |
BYTE |
00h |
Reserved (used by Windows NT). Code that formats FAT volumes should always set this byte to 0. |
|
42 |
BYTE |
29h |
Extended boot signature. This is a signature byte that indicates that the following three fields in the boot sector are present. Set to 0x29 if either of the following two fields are non-zero. |
|
43-46 |
DWORD |
6C76AB95h |
Volume serial number. This field, together with the Volume label field in offsets 0x47-51, supports volume tracking on removable media. These values allow FAT file system drivers to detect that the wrong disk is inserted in a removable drive. This ID is usually generated by simply combining the current date and time into a 32-bit value. |
|
47-51 |
11 bytes |
4E4F204E414D4520202020h (Little endian) |
Volume label in ASCII. This field matches the 11-byte volume label recorded in the root directory. The setting for this field when there is no volume label is the string NO NAME . |
|
52-59 |
QWORD |
4641543332202020h (Little endian) |
Always set to the ASCII string FAT32 . Note: Many people think that the string in this field has something to do with the determination of what type of FAT FAT12, FAT16, or FAT32 that the volume has. This is not true. This string is informational only and is not used by Microsoft file system drivers to determine FAT type because it is frequently not set correctly or is not present. |
Although it is important to be aware of the low-level details, we do not need to do all this interpretation ourselves. At the Fig. 6 below is shown the Active@ Disk Editor Boot Record view of a FAT32 volume. From this, we can obtain many of the details about the hard disk partition.
![]() |
| Figure 6: Active@ Disk Editor boot record view |
It is possible to produce a hiding place on both floppy and hard disks, which cannot be addressed in the normal way through the file or operating system, by tampering with the “Total sectors” and the “Big total sectors” fields in the boot record. An analyst should be aware that it is prudent to examine these fields in the boot records of all floppy and hard disk partitions to ensure that they have not been modified to produce more possible hiding places. This applies to all FAT and NTFS disks.







Post a Comment