5.2 Partition Tables & Boot Structures: MBR, GPT, VBR, BIOS vs. UEFI Secure Boot

5.2 Partition Tables & Boot Structures: MBR, GPT, VBR, BIOS vs. UEFI Secure Boot

Quick Answer: Partition tables and boot structures dictate how a storage device initializes and transfers execution to the operating system. The legacy Master Boot Record (MBR) resides at Sector 0 (LBA 0), containing 446 bytes of bootstrap code, four 16-byte partition entries (64 bytes), and the validation signature 0x55AA, capped at 2.19 TB due to 32-bit sector addressing. Modern systems utilize the GUID Partition Table (GPT) under UEFI, which features 64-bit addressing, supports up to 128 partitions, maintains a Protective MBR at LBA 0, and guards against disk tampering via dual headers (Primary at LBA 1, Backup at disk end) verified by CRC32 checksums. Modern UEFI Secure Boot enforces a cryptographic chain of trust (PK, KEK, db, dbx) to prevent unauthorized bootkits from executing prior to kernel initialization.

---

Master Boot Record (MBR) Internals & Hex Anatomy

Introduced with IBM PC DOS 2.0 in 1983, the Master Boot Record (MBR) occupies the very first sector of a partitioned hard drive (LBA 0 / Cylinder 0, Head 0, Sector 1) and spans exactly 512 bytes.

+-------------------------------------------------------------------------+
|                    MASTER BOOT RECORD (LBA 0: 512 BYTES)                |
+-------------------------------------------------------------------------+
| Offset 0x000 - 0x1BD (446 Bytes): Master Bootstrap Executable Code      |
| Offset 0x1BE - 0x1CD (16 Bytes):  Partition Entry #1                    |
| Offset 0x1CE - 0x1DD (16 Bytes):  Partition Entry #2                    |
| Offset 0x1DE - 0x1ED (16 Bytes):  Partition Entry #3                    |
| Offset 0x1EE - 0x1FD (16 Bytes):  Partition Entry #4                    |
| Offset 0x1FE - 0x1FF (2 Bytes):   Boot Signature / Magic Bytes [0x55 AA]|
+-------------------------------------------------------------------------+

The MBR Structure Breakdown

1. Bootstrap Code (446 Bytes, Offsets 0x000–0x1BD): Executable machine instructions loaded into RAM by the system BIOS. Its primary function is to parse the partition table, identify the single active (bootable) partition, load that partition's Volume Boot Record (VBR) into physical memory at address 0x7C00, and pass CPU execution to it.
2. Partition Table (64 Bytes, Offsets 0x1BE–0x1FD): Contains exactly four 16-byte records defining primary partitions. Because the table is hardcoded to 64 bytes, an MBR disk can host a maximum of four primary partitions (or three primary partitions and one extended partition containing logical drives linked via Extended Boot Records [EBRs]).
3. Boot Signature (2 Bytes, Offsets 0x1FE–0x1FF): The two-byte hexadecimal word 0x55 0xAA (displayed in little-endian hex viewers as 55 AA). BIOS firmware checks for this exact signature before executing the bootstrap code; if these bytes are corrupted or zeroed, the system halts with "No bootable device found."

Detailed Breakdown of a 16-Byte MBR Partition Entry

Every partition entry in the MBR conforms to a strict 16-byte binary structure:

The Mathematical 2TB Limit of MBR

Why does MBR fail on modern drives larger than 2 Terabytes?
The limitation stems directly from the 4-byte (32-bit) field allocated for the total sector count and starting LBA:

• A 32-bit integer can address a maximum of $2^{32} = 4,294,967,296$ unique sectors.
• Multiplied by the standard sector size of 512 bytes:
  $4,294,967,296 \text{ sectors} \times 512 \text{ bytes} = 2,199,023,255,552 \text{ bytes} \approx 2.199 \text{ TB (2 TiB)}$
• Any storage capacity beyond 2.19 TB on an MBR disk is completely unaddressable and invisible to the operating system.

---

GUID Partition Table (GPT) Architecture

Part of the Unified Extensible Firmware Interface (UEFI) specification, the GUID Partition Table (GPT) completely supersedes MBR. It utilizes 64-bit logical block addressing, expanding maximum addressable storage to $2^{64}$ sectors (9.4 Zettabytes with 512-byte sectors; 75.5 Zettabytes with 4Kn sectors).

+-------------------------------------------------------------------------+
|                    GUID PARTITION TABLE (GPT) DISK MAP                  |
+-------------------------------------------------------------------------+
| LBA 0:         Protective MBR (Type 0xEE spanning disk; prevents wiping)|
| LBA 1:         Primary GPT Header (Signature: 'EFI PART'; CRC32 check)  |
| LBA 2 - 33:    Partition Entry Array (128 partition records x 128 bytes)|
| LBA 34:        First Usable LBA (Beginning of Volume Storage)           |
| ...            ... Usable Partitions (NTFS, ext4, APFS, ESP) ...        |
| LBA N - 34:    Last Usable LBA                                          |
| LBA N - 33..2: Backup Partition Entry Array (Secondary GPT Table)       |
| LBA N - 1:     Backup GPT Header (Mirrored Header at Disk End)          |
+-------------------------------------------------------------------------+

GPT LBA Breakdown

1. LBA 0: Protective MBR:
   • To prevent legacy MBR disk utilities (e.g., older versions of FDISK) from failing to recognize the GPT disk and mistakenly reporting it as unpartitioned space, LBA 0 contains a "Protective MBR".
   • It contains a single partition table record covering the entire disk with Partition Type ID 0xEE.
   • Legacy utilities see a single massive, unrecognized partition and refuse to overwrite the disk, preserving GPT structures.
2. LBA 1: Primary GPT Header:
   • Contains metadata defining the disk's partition architecture.
   • Header Signature (Offsets 0x00–0x07): The 8-byte ASCII string "EFI PART" (0x54 0x52 0x41 0x50 0x20 0x49 0x46 0x45 in little-endian).
   • Header CRC32 Checksum (Offset 0x10): 32-bit CRC checksum of the GPT header itself (computed with the CRC field zeroed during calculation). Any tampering with the header causes firmware CRC validation to fail.
   • Current LBA (Offset 0x18): Pointer to LBA 1.
   • Backup LBA (Offset 0x20): Pointer to the Backup GPT Header located at LBA $N-1$.
   • First Usable LBA (Offset 0x28): Typically LBA 34.
   • Last Usable LBA (Offset 0x30): Typically LBA $N-34$.
   • Disk GUID (Offset 0x38): Unique 128-bit GUID assigned to the physical drive.
   • Partition Array Starting LBA (Offset 0x48): Points to LBA 2.
   • Number of Partition Entries (Offset 0x50): Typically 128 entries.
   • Size of Partition Entry (Offset 0x54): Exactly 128 bytes.
   • Partition Array CRC32 (Offset 0x58): CRC32 checksum verifying the integrity of the entire partition entry array.
3. LBAs 2–33: Partition Entry Array:
   • Standard GPT allocates 32 sectors for partition records. With each record measuring 128 bytes, this accommodates a minimum of 128 partition entries ($32 \text{ sectors} \times 512 \text{ bytes} = 16,384 \text{ bytes} \div 128 \text{ bytes/entry} = 128$).
   • Structure of a 128-Byte Partition Entry:
     • Offsets 0x00–0x0F (16 Bytes): Partition Type GUID (defines role, e.g., Basic Data, Recovery, ESP).
     • Offsets 0x10–0x1F (16 Bytes): Unique Partition GUID (unique identifier for this specific partition instance).
     • Offsets 0x20–0x27 (8 Bytes): Starting LBA (64-bit integer, little-endian).
     • Offsets 0x28–0x2F (8 Bytes): Ending LBA (64-bit integer, little-endian).
     • Offsets 0x30–0x37 (8 Bytes): Attribute Flags (bit 0 = System partition; bit 60 = Read-only; bit 62 = Hidden; bit 63 = Do not automount).
     • Offsets 0x38–0x7F (72 Bytes): Partition Name (36 UTF-16LE characters).
4. LBAs $N-33$ through $N-1$: Backup (Secondary) GPT:
   • A major forensic advantage of GPT is structural redundancy. The Backup Partition Entry Array sits at LBAs $N-33$ to $N-2$, and the Backup GPT Header resides in the very last sector (LBA $N-1$).
   • Forensic Recovery Impact: If a threat actor or wiper malware executes an anti-forensics zeroing attack against the first 34 sectors (LBA 0–33) to destroy partition definitions, an investigator can recover the entire partition table by extracting the secondary GPT header and array from the end of the raw disk image.

Common Partition Type GUIDs

---

Volume Boot Record (VBR) & BIOS Parameter Block (BPB)

While the MBR/GPT defines physical disk slicing, the Volume Boot Record (VBR)—also known as the Partition Boot Sector—is the very first sector of an individual logical volume or formatted partition (e.g., LBA 2048 for Partition 1).

+-------------------------------------------------------------------------+
|                   VOLUME BOOT RECORD (VBR) STRUCTURE                    |
+-------------------------------------------------------------------------+
| Jump Instruction (3 Bytes) + OEM ID / File System Type (8 Bytes)        |
| BIOS Parameter Block (BPB): Bytes/Sec, Sec/Cluster, Reserved Sectors    |
| Extended BPB: Volume Serial Number, Volume Label, Total Sectors         |
| Bootstrap Code: File system loader (e.g., loads NTLDR or BOOTMGR)       |
| End of Sector Signature: 0x55 AA                                        |
+-------------------------------------------------------------------------+

The BIOS Parameter Block (BPB)

The VBR contains critical file system geometry stored in the BIOS Parameter Block (BPB). When analyzing corrupted or partially wiped partitions, examiners parse the BPB to recover cluster size and volume geometry:

• Bytes Per Sector (Offset 0x0B, 2 Bytes): Typically 0x00 0x02 (512 bytes).
• Sectors Per Cluster (Offset 0x0D, 1 Byte): Crucial allocation metric (e.g., 0x08 = 8 sectors = 4,096-byte clusters).
• Reserved Sectors (Offset 0x0E, 2 Bytes): Number of sectors preceding the file allocation tables (e.g., in FAT32, typically 32 sectors).
• Media Descriptor (Offset 0x15, 1 Byte): 0xF8 identifies fixed hard disks.
• Total Sectors (Offset 0x28 in NTFS, 8 Bytes): 64-bit integer specifying the volume size.
• MFT Cluster Offset (Offset 0x30 in NTFS, 8 Bytes): Cluster address where the Master File Table ($MFT) begins.
• Clusters Per MFT Record (Offset 0x40 in NTFS, 1 Byte): In signed integer format: 0xF6 = -10, meaning $2^{10} = 1024 \text{ bytes}$ per $MFT record.

[!TIP] NTFS Backup VBR: NTFS maintains a duplicate copy of the Volume Boot Record at the very last sector of the partition. If ransomware or an anti-forensic tool corrupts the primary VBR at LBA 2048, an investigator can copy the backup VBR from the partition's terminating sector to fully restore partition readability.

Legacy BIOS vs. UEFI Boot Sequences

The boot sequence represents the handoff of system control from firmware to the operating system kernel. Investigating boot-level persistence (bootkits, rogue hypervisors) requires understanding the differences between legacy BIOS and modern UEFI boot pipelines.

+-------------------------------------------------------------------------+
|                    LEGACY BIOS vs. UEFI BOOT PIPELINE                   |
+-------------------------------------------------------------------------+
| LEGACY BIOS:                                                            |
| Power On -> POST -> BIOS ROM (0xFFFF0) -> Read MBR (0x7C00)             |
|          -> Parse Partition Table -> Read Active VBR -> Load BOOTMGR    |
|                                                                         |
| UEFI PIPELINE:                                                          |
| Power On -> SEC (Security) -> PEI (Pre-EFI Init) -> DXE (Driver Exec)    |
|          -> BDS (Boot Device Select) -> Load \EFI\...\bootmgfw.efi      |
|          -> ExitBootServices() -> OS Kernel Execution                   |
+-------------------------------------------------------------------------+

The Legacy BIOS Boot Pipeline

1. Power-On & POST: CPU initializes in 16-bit real mode and executes the BIOS firmware located at reset vector 0xFFFF0 in ROM/Flash memory. The Power-On Self-Test (POST) validates motherboard chipset, CPU registers, and RAM.
2. MBR Loading: BIOS interrogates boot priority devices, loads the first 512 bytes (LBA 0) into RAM at physical memory address 0x0000:7C00, verifies the 0x55AA signature, and jumps execution to the MBR bootstrap code.
3. Active Partition Search: MBR bootstrap code parses the 64-byte partition table looking for the active boot indicator flag (0x80).
4. VBR Execution: The MBR reads the active partition's Volume Boot Record (VBR) into RAM at address 0x7C00, which in turn parses the BPB and loads the OS boot manager (BOOTMGR in Windows, NTLDR in legacy systems, or GRUB Stage 1.5/2 in Linux).
5. Kernel Transition: The boot manager transitions the CPU from 16-bit real mode into 32-bit protected mode or 64-bit long mode, loads kernel drivers, and initializes ntoskrnl.exe.

The UEFI Boot Pipeline (Five Architectural Phases)

UEFI completely abandons 16-bit real mode, executing 32-bit or 64-bit code from the first instruction cycle across five distinct phases:

1. SEC (Security Phase): Executes directly from SPI flash. Initializes temporary memory (Cache-as-RAM [CAR]) because physical DRAM is not yet initialized. Authenticates the initial firmware volume and acts as the system root of trust.
2. PEI (Pre-EFI Initialization Phase): Initializes physical memory controllers, basic chipset structures, and CPU sockets. Builds the Hand-Off Block (HOB) table passed to the next phase.
3. DXE (Driver Execution Environment Phase): The core operational engine of UEFI. Loads hardware device drivers (PCIe, USB, NVMe, SATA), initializes system tables, and enforces Secure Boot policy checks.
4. BDS (Boot Device Selection Phase): Evaluates non-volatile RAM (NVRAM) boot variables (BootOrder, Boot####), identifies the target boot volume, and reads the EFI System Partition (ESP).
5. TSL (Transient System Load Phase): The UEFI firmware executes the operating system loader binary directly from the ESP (e.g., \EFI\Microsoft\Boot\bootmgfw.efi or grubx64.efi). The OS loader prepares memory maps and calls the UEFI runtime function ExitBootServices(), terminating UEFI execution and transferring complete control to the operating system kernel.

---

UEFI Secure Boot Architecture & Cryptographic Key Hierarchy

UEFI Secure Boot is a security standard defined in the UEFI specification that ensures endpoints execute exclusively authentic, cryptographically signed firmware, option ROMs, and operating system bootloaders.

+-------------------------------------------------------------------------+
|                 UEFI SECURE BOOT CRYPTOGRAPHIC HIERARCHY                |
+-------------------------------------------------------------------------+
| [Platform Key (PK)]      Root OEM Key; controls updates to the KEK      |
|         |                                                               |
|         v                                                               |
| [Key Exchange Key (KEK)] Issued by OS Vendor (Microsoft) / OEM; updates db|
|         |                                                               |
|    +----+----+                                                          |
|    |         |                                                          |
|    v         v                                                          |
| [db DB]   [dbx DB]       db = Whitelist of allowed signatures/hashes    |
| (Allowed) (Forbidden)    dbx = Blacklist of revoked bootkit binaries    |
+-------------------------------------------------------------------------+

The Four Cryptographic Key Databases

1. Platform Key (PK): The root of trust for the hardware platform. Installed into SPI flash by the hardware OEM (e.g., Dell, HP, Lenovo). Establishes a mutual trust relationship between the platform owner and the firmware. Authorizes updates to the Key Exchange Key (KEK).
2. Key Exchange Key (KEK): Intermediate cryptographic keys issued by operating system vendors (primarily the Microsoft Corporation KEK CA) and OEMs. Enforces authorization checks before any modifications can be committed to the signature databases (db and dbx).
3. Authorized Signature Database (db): The signature whitelist. Contains X.509 digital certificates and SHA-256 cryptographic hashes of authorized EFI executables, third-party hardware Option ROMs, and OS boot managers.
4. Forbidden Signature Database (dbx): The revocation blacklist. Contains hashes and certificates of known vulnerable bootloaders, revoked signing keys, and malicious bootkits. If a binary's hash appears in dbx, the UEFI firmware immediately terminates execution.

Bootkit Forensics & Secure Boot Bypass Mechanics

A Bootkit is an advanced form of rootkit that modifies or replaces boot components (MBR, VBR, or EFI bootloaders) to execute prior to the operating system kernel. Running at this privileged tier, a bootkit subverts kernel security controls, hypervisor-protected code integrity (HVCI), and endpoint detection and response (EDR) sensors.

How Bootkits Bypass Secure Boot (The BlackLotus Case Study)

In 2022, security researchers identified BlackLotus, the first in-the-wild UEFI bootkit capable of bypassing Secure Boot on fully patched Windows 11 systems.

• The Vector (Baton Drop / CVE-2022-21894): BlackLotus did not compromise the private Microsoft signing keys. Instead, it exploited an unrevoked, legitimately signed 2020 Windows bootloader (bootmgfw.efi) that contained a known vulnerability allowing arbitrary memory modification.
• The Exploit Sequence:
  1. The malware replaced the target system's current bootloader in the EFI System Partition with the vulnerable 2020 binary.
  2. Because the 2020 binary was legitimately signed by Microsoft and had not yet been added to the system's dbx blacklist, UEFI Secure Boot verified its signature and executed it without error.
  3. During execution, the malware triggered CVE-2022-21894 to hijack memory, disabled BitLocker enforcement, deactivated Windows Defender and HVCI, and established persistence as an EFI runtime driver.

Forensic Investigation of the EFI System Partition (ESP)

To investigate suspected UEFI bootkit compromises, the examiner must mount and analyze the ESP:

# Mount EFI System Partition on Linux
mount -t vfat /dev/nvme0n1p1 /mnt/esp

# Or on Windows via administrative command prompt
mountvol S: /S

# Compute SHA-256 hashes of all EFI boot applications
sha256sum /mnt/esp/EFI/Microsoft/Boot/*.efi

# Inspect NVRAM boot variables and Secure Boot status using efibootmgr
efibootmgr -v

# Query Secure Boot key status in PowerShell
Get-SecureBootUEFI -Name PK
Get-SecureBootUEFI -Name db
Get-SecureBootUEFI -Name dbx

---

Partition Parsing with The Sleuth Kit: mmls

The Sleuth Kit utility mmls displays the layout of partitions in a volume system, supporting MBR, GPT, BSD disk labels, and Sun slices:

# Analyze partition layout of a suspect physical image
mmls -t gpt /evidence/suspect_drive.raw

# Sample Output:
# GUID Partition Table (Sector size: 512)
# Units are in 512-byte sectors
#      Slot      Start        End          Length       Description
# 000:  Meta      0000000000   0000000000   0000000001   Safety Table (LBA 0)
# 001:  Meta      0000000001   0000000001   0000000001   GPT Header (LBA 1)
# 002:  Meta      0000000002   0000000033   0000000032   Partition Table
# 003:  000       0000002048   0000206847   0000204800   EFI System Partition
# 004:  001       0000206848   0000239615   0000032768   Microsoft Reserved
# 005:  002       0000239616   0976771071   0976531456   Basic Data Partition
# 006:  Meta      0976773135   0976773166   0976000032   Backup Partition Table
# 007:  Meta      0976773167   0976773167   0000000001   Backup GPT Header

From this output, an investigator identifies that the Primary Basic Data Partition begins at LBA 239616. To mount or inspect this volume directly with file system tools, the examiner supplies the sector offset:
fls -o 239616 /evidence/suspect_drive.raw.