The VBR

Volume Boot Record (VBR)

Field Name	Offset (byte)	Size (byte)	Description/Value
Jump Boot	0	3	0xEB7690
File System Name	3	8	“EXFAT “
Must Be Zero	11	53	Must be 0x00
Partition Offset	64	8	Sector Address
Volume Length	72	8	Size of total volume in sectors
FAT Offset	80	4	Sector address of 1st FAT
FAT Length	84	4	Size of FAT in Sectors
Cluster Heap offset	88	4	Sector address of the Data Region
Cluster Count	92	4	Number of clusters in the Cluster Heap
Root Directory First Cluster	96	4	Cluster address of the Root Directory
Volume Serial Number	100	4	Volume Serial Number
File System Revision	104	2	VV.MM (01.00 for this release)
Volume Flags	106	2	Field Offset bits Size bits Description Active FAT 0 1 0 – 1st 1 – 2nd Volume Dirty 1 1 0 – Clean 1 - Dirty Media Failure 2 1 0 – No Failures 1 – Failures Reported Clear to Zero 3 1 No Meaning Reserved 4 12
Bytes Per Sector	108	1	This is a power of 2. Range: min of 29 = 512 byte cluster size, and a max of 212 = 4096.
Sectors Per Cluster	109	1	This is a power of 2. Range: Min of 21=512. The maximum Cluster size is 32 MiB, so the Values in Bytes per Sector + Sectors Per Cluster cannot exceed 25.
Number of FATS	110	1	This number is either 1 or 2, and is only 2 if TexFAT is in use.
Drive Select	111	1	Used by INT 13
Percent In Use	112	1	Percentage of Heap in use
Reserved	113	7
Boot Code	120	390	The Boot Program
Boot Signature	510	2	0xAA55
Excess	512		If the sector is larger than 512 bytes, extra padding may exist beyond the signature
Comments: Volume size is minimum of 1MB and maximum size is 264-1 sectors

Table 3 Layout for Main and Backup Boot Sector Structure

The Volume Boot Record (VBR), as shown in Table 3, is the first critical file system collection of metadata needed by the forensics examiner. This collection of sectors defines the limits and locations of the exFAT regions, and has a pointer to the Root Directory.

The Main Boot Region of the VBR is composed of five sub-regions of a total of 12 sectors:

• The Main Boot Sector (MBS)
• The Main Extended Boot Sectors (MEBS)
• The OEM Parameters
• A reserved sector
• The Checksum Sector

The Backup Boot Region is a repeat of the 12 sectors found in the Main Boot Region, and together, both regions total 24 sectors. Since the concept of the term cluster only applies to the contents of the Cluster Heap, the VBR will always be expressed as sectors.

The MBS does not differ conceptually from the partition Master Boot Sectors or Volume Boot Records of previous FAT file systems. It contains Boot Code, the BIOS Parameters Block (BPB), and a signature. The purpose of the BPB is to describe the physical layout of the file system volume. The common signature (as shown in Figure 14) used in this sector is 0xAA55.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............Uª

Figure 14 Winhex Display of VBR Signature

The Boot Code is located in the first 3 bytes of the MBS and also consumes 390 bytes at offset 120. The first 3 bytes is a Jump Boot sequence which bypasses the BPB and jumps to the Boot Code. Since any executable sequence of computer instruction may be stored in the boot code, this may be of interest to the forensics examiner should customized boot code be stored. It would be in this area of the sector that a Boot Sector Virus would modify and implant itself.

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 EB 76 90 45 58 46 41 54 20 20 20 00 00 00 00 00 ëvEXFAT .....

16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

64 3F 00 00 00 00 00 00 00 C1 F3 01 00 00 00 00 00 ?.......Áó......

80 80 00 00 00 80 00 00 00 00 01 00 00 58 3E 00 00 €...€.......X>..

96 05 00 00 00 EC 99 D1 C4 00 01 00 00 09 03 01 80 ....ì™ÑÄ.......€

112 5C 00 00 00 00 00 00 00 \.......

Figure 15 Winhex of the first 120 bytes of a MBS

The File System Name, also referred to as the OEM label, is an 8 byte ASCII field containing the name of the file system. This makes identification of the file system easier, and as shown in Figure 15 the name is “EXFAT” and is padded with training blanks. If this file system is created on a fixed hard drive in a partition, you cannot rely on the partition type within the MBR to determine the file system type because the partition code for exFAT is 0x07 and is shared with other file systems (see Table 20). The next field, Must Be Zero, defines 53 bytes of 0x00 in a location that the older FAT file systems used to define their BPB. This reduces the risk of the legacy FAT implementations of accidently mounting an exFAT volume by mistake.

The Volume Length is a count of the total number of sectors on the volume. This number needs to be larger than a 32 bit number, so it is defined as 2⁶⁴. Suppose for example the maximum sized Cluster Heap was defined, which is currently limited to 2³²-11 clusters. If the cluster ratio is set to 1 sector per cluster (1:1), then a 32 bit number is required to hold the volume length. If the sector to cluster ratio was 1:16, then a 36 bit number would be required. If the current maximum as per the specification were used, and assuming a sector size of 512 bytes, an additional 16 bits need to be added, requiring a 48 bit number. This is based on a 25 bit maximum (32MiB cluster size) and 9 of those bits are used to define 512 bytes for the sector size.

Four fields are used to describe the FAT. The FAT offset is used to define the sector offset of the FAT region and points to the 1^st FAT. If the number of FATS is 2, then the 2^nd FAT will immediately follow the 1^st FAT, starting on a sector boundary. The number of FATS will always be 1 because TexFAT is not implemented and the 2^nd FAT only exists in a TexFAT environment. If the implementation does not verify this value, then the file system could be modified to increase this number and imbed fake FATS in the volume in order to create additional slack space to hide data. The FAT length is the length of the FAT in sectors. In the Volume Flags there is a flag for the Active FAT. This only applies in a TexFAT environment, when number of FATS is equal to 2. This flag indicates which of the two FATS is active.

Figure 16 Chkdsk of an exFAT formatted disk

The final region, the Cluster Heap, is the data portion of the volume structure and holds the directories and files. The Cluster Heap is allocated in cluster units and the Cluster Count defines how many allocation units are defined. The Cluster Offset identifies the sector address of where the Cluster Heap begins. Once inside the Cluster Heap, the addressing units are in clusters. In Figure 16 the Cluster Count is shown as total allocation units on disk, and in this example shows 15,960.

In comparison, a FAT32 file system requires a minimum of 65,526 clusters making FAT32 unusable for small disks formats. exFAT does not have that restriction and smaller media may be used. In testing, a 32MB compact flash card was formatted as an exFAT file system.

A key value in this sector for the forensics examiner is the Root Directory First Cluster. The details of the Root Directory are described in section 6.1, and this value points to the first cluster of the Root Directory which resides in the Cluster Heap. The VBR defines the structure of the volume, but the Root Directory defines the contents within the Cluster Heap. All the metadata about files, subdirectories, the volume label, etc reside in this directory.

Two critical fields are the bytes per sector and sectors per cluster. One thing that is special about these fields is that the values contained are exponents. For example Figure 15 shows that the bytes per sector are 9 and the sectors per cluster are 8. This is 2⁹ bytes per sector (512) and 2³ sectors per cluster (8) resulting in a cluster size of 4096 bytes. The maximum aggregate sum of these two exponents is 25, for a maximum cluster size of 32MiB. The maximum value for the bytes per sector field is 12 (2^{12 =} 4096 bytes).

At offset location 104 is the file system revision number, which appears in Figure 15 and is 0x0100 and translates to version 01.00.

The boot signature of the MBS is always at offset location 510. If the sector size is defined as greater than 512 bytes, the signature will still be located at this location, and the remainder of the sector will be undefined and not used.

Field Name	Offset (byte)	Size (byte)	Description/Value
Extended Boot Code	0	508-4092	Additional Boot Code
Extended Boot Signature	508-4092	4	0xAA550000
Comments: Signature actually stored as 0x000055AA

Table 4 Layout for Extended Boot Sector Structure

The Main Extended Boot Region takes up the next 8 sectors, even when not used. This allows a larger boot program by providing additional sectors for boot code. Unlike the MBS, the MEBS, when extended to larger than 512 bytes, allows usage of the entire sector for boot code and the record signature is moved to the last four bytes. If a sector size of 4096 bytes was used, the boot signature would be at offset 4092. If a MEBS sector is not in use, the boot code should all be 0x00, followed by the boot signature.

Field Name	Offset (byte)	Size (byte)	Description/Value
Parameters[0]	0	48	Parameters
Parameters[1]	48	48	Parameters
Parameters[2]	96	48	Parameters
Parameters[3]	244	48	Parameters
Parameters[4]	192	48	Parameters
Parameters[5]	240	48	Parameters
Parameters[6]	288	48	Parameters
Parameters[7]	336	48	Parameters
Parameters[8]	384	48	Parameters
Parameters[9]	432	48	Parameters
Reserved	480	32-3616	Rest of sector Reserved

Table 5 Layout for OEM Parameter Structure

The next sector in the VBR (sector 9) is the OEM parameters record. Since this record really doesn’t exist yet (it is all zeros in the file systems that were generated), there is little analysis that can be done at this time. The patent specifies this table as 10 fields of 48 bytes, the first 16 bytes of each field is the GUID and the remaining 32 bytes are the parameters, but no additional definition is provided.

The entries are not sorted, and it is possible that the first 9 are empty and the last has data, so the specification states that all 10 entries should be searched. This sector is filled out by the media manufacturer at the factory and a format operation is not supposed to erase this sector with the exception of a secure wipe of the media.

Examination of Microsoft MSDN AA914663 provides a definition of the 32 byte parameter field, as shown in Figure 17:

struct

{

GUID OemParameterType; //Value is OEM_FLASH_PARAMETER_GUID

UINT32 EraseBlockSize; //Erase block size in bytes

UINT32 PageSize;

UINT32 NumberOfSpareBlocks;

UINT32 tRandomAccess; //Random Access Time in nanoseconds

UINT32 tProgram; //Program time in nanoseconds

UINT32 tReadCycle; // Serial read cycle time in nanoseconds

UINT32 tWriteCycle; // Write Cycle time in nanoseconds

UCHAR Reserved[4];

}

FlashParameters;

Figure 17 OEM Parameters Type Definition

Sector 10 is reserved, and is not currently defined. Sector 11 is a checksum sector, where every 4 byte integer is a 32 bit repeating checksum value of the previous 11 sectors. If anyone wanted to tamper with the VBR by changing values in the BPB or the boot code, like a boot sector virus infecting the VBR, then the checksum would have to be recalculated and sector 11 would need to be updated. The last 3 sectors of this 12 sector VBR (sectors 9, 10 and 11) do not contain signatures, the signatures are only used for sectors containing boot code and are in the first 9 sectors.

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

5632 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 }.N)}.N)}.N)}.N)

5648 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 7D 0A 4E 29 }.N)}.N)}.N)}.N)

Figure 18 Winhex dump of part of a VBR checksum sector

Figure 18 shows a partial dump of the checksum sector, the checksum is 0x294E0A7D and repeats in every 4 bytes of the entire sector. For a sector size of 512 bytes, it would repeat 128 times. Figure 19 shows the Microsoft Visual C function that was used to compute and verify the checksum value.

UINT32 VBRChecksum(const unsigned char octets[], long NumberOfBytes)

{

UINT32 Checksum = 0;

long Index;

for (Index = 0; Index <>

{

if (Index == 106 || Index == 107 || Index == 112)

{

continue;

}

Checksum = ((Checksum <<31)>> 1)) + (UINT32) octets[Index];

}

return Checksum;

Figure 19 Code snippet of VBR checksum calculation function in C

For comparison, the FAT32 VBR is within a reserved 32 sector region, with a primary VBR of 3 sectors at sectors 0, 1 and 2 and then a backup VBR located at sectors 6, 7 and 8. (Mueller, Scott (2003)) In a FAT32 VBR, executable boot code can reside in the 1^st and 3^rd sectors, where an exFAT VBR can have 9 sectors containing executable code.