MBR and GPT Analysis

What is MBR and GPT?

The boot process is responsible for bringing the entire system to life. It begins by initializing the hardware, then loads the operating system into memory, and ultimately hands control over to the user. In this task, we focus on the early stages of booting before the MBR or GPT becomes involved. The goal is to understand the fundamental startup sequence of a system before examining the structure of MBR/GPT and their significance in forensic analysis.

MBR is the classic, decades‑old partitioning scheme introduced back in 1983. It sits in the very first 512 bytes of a disk and acts like a tiny gatekeeper:

• It contains a small bootloader stub
• It stores a partition table with room for exactly four primary partitions
• It uses 32‑bit addressing, which limits disk size to 2 TB

MBR is simple, rigid, and deeply tied to the early PC boot process. Its structure is small enough to inspect manually in a hex editor, which is why it’s so valuable in digital forensics. But its limitations show its age — modern systems have outgrown what MBR can comfortably handle.

GPT: The Modern Blueprint

GPT is the successor, designed for the UEFI era. Instead of squeezing everything into 512 bytes, GPT spreads its metadata across the disk like a well‑designed blueprint:

• It supports virtually unlimited partitions (Windows defaults to 128)
• It uses 64‑bit addressing, enabling disks far beyond 2 TB
• It stores redundant headers and partition tables for resilience
• Each partition has a globally unique identifier (GUID)
• It includes CRC32 checksums to detect corruption

GPT is structured, self‑aware, and built for reliability. It’s the kind of design that makes sense in a world of multi‑terabyte SSDs and modern firmware.

Booting Process

Powering On the System

The boot process begins the moment you press the power button. This action sends electrical signals through the motherboard, waking up and initializing the hardware components. The CPU is the first to receive power, but it can’t proceed without instructions. To continue, it retrieves its initial code from a firmware chip on the motherboard — known as the BIOS or UEFI. This firmware provides the essential instructions that kick‑start the entire boot sequence.

BIOS (Basic Input/Output System) and UEFI (Unified Extensible Firmware Interface) are responsible for verifying whether all the hardware components work properly. A system can either use BIOS or UEFI firmware. The difference between them lies in their capabilities and features.

• BIOS has been used for decades and is still used in some hardware. It runs in the basic 16-bit mode and supports only up to 2 terabytes of disks. The most important thing to note is that BIOS supports the MBR partitioning scheme, which we will discuss later in the task.
• UEFI came as a replacement for BIOS, offering 32-bit and 64-bit modes with up to 9 zettabytes of disks. UEFI offers a secure boot feature to ensure integrity during the system boot process. It also offers redundancy, allowing us to recover from the backup even if the boot code is corrupted. UEFI uses a GPT partitioning scheme, unlike the MBR partitioning scheme used by BIOS.

There are several ways to check if your system uses BIOS or UEFI firmware. The process can be different depending on the operating system you use. For the Windows OS, first open the Run dialog box by pressing Windows+R . Type msinfo32 in this dialog box and press enter. This will show you the system summary. If it is running BIOS, the field named BIOS Mode would be shown as the Legacy. Otherwise, it would be UEFI.

msinfo32

Power-On-Self-Test (POST)

The system is now powered on, and the CPU has executed instructions from the firmware (BIOS/UEFI) installed. The BIOS/UEFI then starts a Power-On-Self-Test to ensure all the system’s hardware components are working fine. You may hear a single or multiple beeps during this process in your system; this is how the BIOS/UEFI communicates any errors in the hardware components and displays the error message on the screen, e.g., keyboard not found.

Locate the Bootable Device

After the BIOS/UEFI has performed the POST check, it is time for the BIOS/UEFI to locate bootable devices, such as SSDs, HDDs, or USBs, with the operating system installed. Once the bootable device is located, it starts reading this device. Now, here comes the role of the MBR/GPT. The very first sector of the device would either contain the MBR (Master Boot Record) or the GPT (GUID Partition Table). The MBR/GPT would be taking control of the boot process from here. In the upcoming tasks, we will see how the boot process propagates from here if the MBR partitioning scheme is used and what happens if it is GPT instead.

Analysis

The Master Boot Record (MBR) occupies the first 512 bytes of the disk, located in the very first sector. Since we know its starting point, the next question is how to determine where the MBR ends. The logic is simple: every pair of hexadecimal digits represents one byte, and once you reach the first 512 bytes, you’ve reached the end of the MBR. In the hex editor we’re using, each row contains 16 bytes, so the entire MBR spans the first 32 rows.

Another reliable way to identify the end of the MBR is by locating its signature. The final two bytes of the MBR are always 55 AA, which act as a marker indicating the end of the boot record.

In the screenshot, you can see the MBR region — the first 512 bytes — displayed in the hex editor. The first 32 rows are shown, ending with the 55 AA signature. The highlighted sections represent three things: the byte offset on the left, the hexadecimal values in the center, and their ASCII representation on the right. For this task, our focus will be on the hexadecimal values themselves, as we break down and interpret the meaning behind each part of the MBR.

The MBR Structure :

Partitions Table (Bytes 446–509)

The second component of the MBR is the partition table, which comprises 64 bytes (Bytes 446–509). This table contains the details of all the partitions present on the disk. One of the partitions in the disk contains all the operating system files necessary for booting, known as a bootable partition. The initial bootloader that was started from the bootloader code of the MBR finds the bootable partition from this partition table, and it loads the second bootloader from it. The second bootloader then loads the Operating System’s Kernel. A partition table is used during this boot process. However, this partition table can also give us valuable information during forensics. Let’s dive into the details of this partition table.

An MBR disk has a total of 4 partitions, and each partition is represented by 16 bytes in the partition table. In the screenshot below, four partitions (each with 16 bytes) are highlighted with different colors.

Now, for your understanding, we have also shown the partition details of the same disk through the disk management utility of the Windows OS. The same four partitions can be seen here:

Unlike the bootloader code, the hexadecimal digits of these partitions themselves can tell you many things. Let’s use the first partition from the partition table screenshot as a reference to analyze the meaning of all the hexadecimal digits.

The screenshot below shows the first partition from the partition table of the MBR. All the bytes have some specific meaning. Some bytes individually represent a field, while others are grouped together to form a field. We have highlighted all these different byte groups with different colors.

The table below shows the fields represented by these bytes.

Why 00 08 00 00 is Starting LBA

• You’re looking at offset 0x1C6 in HxD.
• The first partition entry starts at 0x1BE.
• Byte 8 of that entry is 0x1BE + 8 = 0x1C6.
• So the 4 bytes at 0x1C6–0x1C9 represent the Starting LBA.

Each field tells you something about the partition. Below is an explanation of all these fields:

1. Boot Indicator: This byte tells you whether the partition is bootable or not. A bootable partition contains files necessary for the operating system to boot. This boot indicator can only have one of the two values: 80 or 00. If it's 80, it means that the partition is bootable; else, if it's 00, it means that the partition is not bootable. In Windows based systems, C: is the partition that is typically bootable. If visualized through the partition table, this partition would have the boot indicator set to 80.
2. Starting CHS Address: Cylinder Head Sector (CHS) is the 3 bytes that tell you where this partition is starting from on the disk. It will give you the starting physical address of the partition, such as the cylinder, head, and sector number. This field is not that important as we now have the simplified logical address of the partition in the form of the Starting LBA Address discussed ahead.
3. Partition Type: Every partition uses a filesystem such as NTFS, FAT32, etc. This byte indicates the filesystem of the partition. The partition we are taking as a reference has this byte as 07, which means it is an NTFS partition. Every filesystem has its own unique byte. You can learn about the bytes used for other filesystems from here.
4. Ending CHS Address: The last 3 bytes at the end of the CHS Address indicates the physical location where the partition ends on the disk. This field is also not that important, just like the stated CHS address, as we mostly use the logical address (LBA) instead of the physical address.
5. Starting LBA Address: Logical Block Addressing (LBA) is the logical address that indicates the start of the partition. We saw that the Starting CHS Address also gives us the starting address of the partition, but because CHS gives you the physical address of the partition, it becomes difficult for us to locate it. However, the Starting LBA Address gives you the logical address of the partition rather than the physical address. You can use it to easily find the start of the partition on the disk in a hexadecimal editor. By locating the partition on the disk, you can also carve data from a disk’s hidden or deleted partitions. Based on the partition we are analyzing as a reference with 00 08 00 00 LBA, we will use this logical address to locate our partition later in this task.
6. Number of Sectors: These last 4 bytes of a partition tell you the number of sectors in the partition. We will calculate the sector’s size by using this field ahead.

From the information above, the boot indicator and the partition type bytes are pretty straightforward and do not need any more explanation. The starting and ending CHS addresses are physical addresses and do not hold much importance. However, let’s see how we can use the Starting LBA Address to locate a partition and the Number of Sectors to calculate the size of the partition.

Get Aman Varma’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Locating the Partition

The starting LBA address bytes of the partition we are using as a reference in this task is 00 08 00 00. These bytes are stored in the little-endian format in which the Least Significant Byte (LSB) is first, and the Most Significant Byte (MSB) is last. So, we must first reverse these bytes. Reversing these bytes would make it 00 00 08 00.

The next step is to convert these into decimal format. You can either use an online tool for this or view the decimal converted value of these bytes within the HxD hex editor tool. Select the bytes for which you need the decimal value, and it will be displayed in the Int32 option of the Data Inspector pane on the right side.

Now that we have the decimal value as 2048, we have to multiply it by the size of the sector, which is 512 bytes.

2048 x 512 = 1,048,576

1,048,576 is the exact value where the partition is stored. The last step is to search for this value in the HxD tool to jump to the start of this partition. To search this value, first click the Search button and then click the Go to option.

Now, input the value in the prompt, select the decimal format (dec) and click the OK button.

This will take you to the start of this partition on the disk. This can help you in carrying out detailed forensics of a specific partition. You can also recover any hidden or deleted data from here that has not yet been overwritten. As the file provided to you in this task is just comprised of the MBR and not the whole disk, you would not be able to jump to the starting LBA of the partition, which is in a separate place from the MBR.

Note: Please remember this method of reversing the LBA address (little endian), converting it to decimal, multiplying it with the sector size (512 bytes), and finally searching it into the hex editor to jump to the exact location. You will encounter some other Logical Block Addresses (LBA) in the GPT structure.

Calculating the Size of Partition

The last four partition bytes represent the Number of Sectors field. As per our partition, these bytes are 00 B0 23 03 and if we reverse it as they are in little-endian, they become 03 23 B0 00. The next step is to convert them to decimal. You can find the decimal value within the HxD tool by highlighting the bytes just as we did for the starting LBA address while locating the partition. The decimal value comes out to be 52,670,464. Now, as we know, each sector's size is 512 bytes. We can multiply them to get the size of this partition in bytes.

52,670,464 x 512 = 26,967,277,568 bytes

MBR Signature (Bytes 510–511)

The last part of the MBR is the MBR Signature. It is just two bytes, which is short, but if messed up, it can cause huge trouble. The screenshot below shows the whole MBR with the MBR signature highlighted at the very bottom.

These two bytes 55 AA are also known as a Magic Number and they indicate that the MBR has been ended now. If these two bytes are changed to some value other than 55 AA, the system cannot boot. These bytes often get corrupted due to bad sectors on the disk and sometimes can be intentionally changed by malware to interrupt the normal boot process.

UEFI firmware with the GPT partitioning scheme replaced BIOS firmware with the MBR partitioning scheme. This replacement occurred due to some limitations in the BIOS and the MBR. The GPT supports up to 9 zettabytes of hard disks, unlike the MBR, which supports a maximum of 2 terabytes. The GPT also supports up to 128 partitions, unlike the MBR, which only supports 4. There are some other differences between both of the partitioning schemes.

GPT is now a preferred partitioning scheme in most modern systems. It is compatible with systems that have UEFI firmware. Let’s take a look at the structure of the GPT.

We previously saw that the MBR only occupies the disk’s first sector (512 bytes). However, this is not the case with the GPT. The GPT has five components spread across multiple sectors of the disk. Let’s start dissecting each component of the GPT.

Protective MBR

Ideally, if the disk is GPT partitioned, the system should have UEFI firmware to handle it. However, some legacy systems still use BIOS firmware even though the disk is GPT partitioned. This can be a problem as the BIOS firmware is designed to work with the MBR and UEFI firmware is designed to work with the GPT. To solve this problem, the GPT has Protective MBR. The Protective MBR is in the disk’s first sector, partitioned with the GPT. The purpose of the Protective MBR is to signal the BIOS system that this disk is using the GPT, so please don’t mess up with it thinking that it is the MBR.

The Protective MBR also has three components, just like the general MBR, but with a few differences. Below is a screenshot of the Protective MBR found in the GPT, with its three components highlighted with different colors.

The details of these components are given below:

1. Bootloader Code: This bootloader code is not the same as it is in the general MBR. This bootloader code does not perform any function during the boot process. It is just there to look like it’s the same standard MBR bootloader. This would be all 00s in most scenarios; however, sometimes, this can contain some placeholder code for legacy compatibility.
2. Partition Table: This partition table contains only one partition (the first 16 bytes), and this partition has one job; to redirect the system to the EFI Partition (which we will discuss later). The screenshot of the protective MBR above shows that it only has one partition in the table, and the other partitions are labeled with 0s. In this single partition, there is only one important thing: the 4th byte. This byte is set to EE, indicating that this is a GPT-formatted disk.

Primary GPT Header

The GPT header starts right from the next byte (the start of sector 1) after the Protective MBR ends at 55 AA (the end of sector 0). It acts as a blueprint of the partitions on the disk. All the bytes in the GPT header have a specific meaning. Below is a screenshot of the GPT header with these bytes highlighted with different colors. It has the whole 512 sector space but occupies the first 92 bytes of space, and after these 92 bytes, there would be all 00 bytes for padding purposes to complete the sector's total bytes. So, for the Primary GPT header, you only need to focus on the first 92 bytes, which can give you some meaningful information.

The table below shows the position of these bytes and their field names.

Each of these 14 fields has a specific purpose and meaning. Below is an explanation of all these fields. Before starting with the explanation of these fields, it is important to note that some of the fields represent Logical Block Addresses (LBA). To calculate the exact address through these LBAs, you must follow the same steps we performed while locating the partition in the MBR task. These steps included reversing the bytes stored in a little-endian format, then converting them to decimals and searching them on the HxD tool to jump to the exact LBA location.

1. Signature: This field has a value 45 46 49 20 50 41 52 54 which recognizes it as a GPT header. This value is always at the start of the GPT header.
2. Revision: The revision number is of 4 bytes and it represents the version of the GPT. Most of the times it would be 00 00 01 00 which means the GPT version is 1.0.
3. Header Size: This field represents the size of the GPT header. It is typically 5C 00 00 00 in hex and if you convert it to decimal (after reversing the order of bytes as they are in little-endian), it is 92 bytes which is the length of the GPT header.
4. CRC32 of Header: This is the CRC32 checksum of the GPT header, which if changed, would indicate that either the GPT header is tampered or corrupted.
5. Reserved: These are reserved bytes. The purpose of having them is to utilize them for any future changes in the GPT header.
6. Current LBA: The Current Logical Block Address (LBA) indicates the location of the GPT header. We know that its location is in sector 1, and we can verify this by converting the 8 Current LBA bytes 01 00 00 00 00 00 00 00 into decimal.
7. Backup LBA: In the GPT partitioning scheme, we have a backup of the GPT header as well, which we will be studying later on in this task. This field indicates the LBA of the backup GPT header.
8. First Usable LBA: This LBA address indicates the first address from which the partition can start on the disk.
9. Last Usable LBA: This LBA address indicates the last address to which the partitions on the disk can be written. Any partitions cannot occupy the disk space after the last usable LBA.
10. Disk GUID: This field is of 16 bytes and it presents a Globally Unique Identifier of the disk. The purpose of this GUID is to distinguish the disk from any other disks present in the system. In the current GPT header that we are analyzing, these bytes are 1D F1 B0 D6 43 BE 37 4E B1 E6 38 66 EC B1 73 89. We can convert them to the standard GUID format of the disk by just reformatting them as 1DF1B0D6-43BE-374E-B1E6-3866ECB17389.
11. Partition Entry Array LBA: This LBA address indicates the start of the Partition Entry Array which we are going to discuss ahead as the 3rd component of the GPT.
12. Number of Partition Entries: This field indicates the number of partitions that are on the disk. The GPT supports 128 partitions, unlike the MBR, which supports 4 partitions only. The value of this field is 80 00 00 00 which if converted to decimal will be 128.
13. Size of Each Partition Entry: This field indicates the size occupied by each partition entry array. In this example, it set to 80 00 00 00 which is 128 in decimal. It is important to note that this is not the size of the partition itself. This is just the size of partition entry array that we would be discussing next.
14. CRC32 of Partition Array: This is the CRC32 checksum of the whole partition entry array, which if changed, would indicate that either the partition entry array is tampered or corrupted.

Partition Entry Array

We saw that sector zero was occupied by the Protective MBR, and the GPT header occupied sector 1. Now, from sector 2, the Partition Entry Array starts, just like the partition table present in the MBR, with a few differences. There are a total of 128 partitions on a GPT disk, and this partition entry array contains information about all these partitions. Below is the screenshot of the Partition Entry Array of a GPT disk. Each partition entry is represented by 128 bytes. You can only see the 6 partition entries out of the total 128 partition entries of the GPT. This is because there are only six working partitions in this disk. These six partitions would be present in blocks (128 bytes each) in this partition entry array, and after these working partitions, all the remaining 122 partition entries would be marked with 00.

Let’s use the first partition of the above screenshot as a reference to analyze the meaning of all the hexadecimal digits present in it.

The screenshot below shows the first partition entry from the partition entry array of the GPT. All the bytes (or groups of bytes) have some specific meaning. We have highlighted the different byte groups with different colors.