🦉 Thanatology part 3: MBR and GPT forensics with the Exhume ToolKit.
This blogpost is part of the Thanatology blogpost series. If you haven’t check it out, I recommend reading the following first:
- Thanatology part 1: Introduction to the Thanatology project
- Thanatology part 2: Multiple disk images formats handling using the Exhume ToolKit
In this blogpost, we will dive into the concepts of GPT and MBR partition schemes and explore them using Exhume Partitions.
Discovering a Disk Image Layout
In the last blogpost we presented how Exhume Body is providing us with an easy way of reading sectors on multiple disk image formats. Now that we have this module, the next step when performing the digital forensic analysis of a disk image is to discover its layout.
In order for any computer to load an operating system when powering it up, the processor must locate and execute bootstrapping code stored in a well-defined location on the disk. This code is typically found in the Master Boot Record (MBR) for legacy BIOS systems or the GUID Partition Table (GPT) for modern UEFI-based systems.
These structures define how the disk is divided into partitions. Partitions are simply set of logical segments that can each contain a filesystem. Proper partition analysis helps forensic investigators understand how the disk was used, identify hidden or suspicious partitions, and extract meaningful artifacts. It also provides context, such as whether the disk uses a standard layout or one that suggests tampering or obfuscation.
Understanding the partitioning scheme is critical as an investigator, as it determines how data structures are interpreted in subsequent analysis phases. Once the partition layout is identified, each partition can be parsed individually for deeper inspection of its filesystem contents. In the later blogposts of this series we will dive into a lot of filesystems like extfs, NTFS, exFAT, and more!
Metric used in this series
A bit of vocabulary so we are on the same page. In this blogpost and all of the others of this series:
A sector is the smallest addressable unit of data on a disk or other block storage device. Usually, a sector is 512 bytes in size, though modern devices may use 4,096-byte (or 4K) sectors for improved efficiency. Unless specified, we will always use a 512 bytes size when mentioning sector size.
The Master Boot Record (MBR)
The Master Boot Record (MBR) is a special boot sector located at the very beginning of a storage device, typically the first 512 bytes (1 sector). It plays a crucial role in the booting process of legacy BIOS systems. The MBR consists of three main components: the bootloader code (usually the first 446 bytes), the partition table (the next 64 bytes), and a boot signature (the last 2 bytes, typically 0x55AA). The bootloader contains the machine code that initiates the process of loading the operating system. The partition table holds information about up to four primary partitions, including their type, starting sector, and size.
Partition entries in MBR
As you can see, an MBR partition entry is 16 bytes long and describes one partition on the disk. The partition table in the MBR contains space for up to four partition entries, located between byte 446 and 509 of the 512-byte MBR sector. In MBR, a partition entry is composed of metadata providing the necessary metadata to the system in order to continue the booting process.
The boot indicator gives the information on whether the partition is bootable (active) with the value 0x80 or not bootable (inactive) with the value 0x00. Note that only one partition should be marked as active. Multiple active partitions should trigger your interest as a digital forensic investigator. The Starting and Ending CHS Addresses are legacy special addresses used to locate the partition starting point. CHS stands for Cylinder-Head-Sector and is a legacy value divided into 3 bytes indicating the 3D coordinates and was used back in time when all disks were just a pile of cylinders with a head to read the data. It is very interesting to learn about CHS just to understand where all of those terms we are using are coming from.
Well, CHS is deprecated now, and the values you might find nowadays can be false because it’s deprecated. Instead, we know rely on the Logical Byte Addressing (LBA) metric. LBA is not a coordinate system but simply a linear numbering system to specify the location of (sectors) on a storage. In MBR the Start LBA is referring to the address of the beginning of the partition in sectors. A value of 0x800 means that the sector number 0x800 of the disk is the start of the partition. With this information we can compute the physical address in the entire disk in bytes as:
Absolute Address = LBA x SizeOfOneSector
In our example, the absolute address of the beginning of our partition would be 0x800 * 0x200 = 0x100000. But where does the partition ends? Well, instead of using the end CHS address that is deprecated, we use the sector count field which represent the number of sectors taken by the partition. We just have to multiply this value by the size of one sector, and we have the size in bytes of the partition.
PartitionSize = SectorsCount * SizeOfOneSector
Another very important field is the partition type number. This number indicates the partition type or rather the "filesystem type". In MBR, each filesystem type is assigned to a unique value between (0x00 to 0xFF). Originally, in the 1980s and early 90s, the field had just a few defined values like 0x01 for FAT12, 0x04 for FAT16 As more operating systems and filesystems emerged (e.g., NTFS, Linux ext, swap, HPFS, etc.) new values were assigned which was still manageable. Eventually, third parties started overloading the values — meaning one type of code might refer to multiple possible formats. For example, the value 0x07 can be used for NTFS, HPFS, exFAT and QNX. Well this is a mess and in digital forensics we can use this field as an information but as this is not authoritative, we rely on partition identification validation using other methods that we will describe in the next blogpost of this series.
Finally, the MBR signature field. It occupies the last 2 bytes of the 512-byte MBR sector with the constant value of 0x55AA (in hex) (or AA 55 as it appears in little-endian order in a hex editor). Just overwriting this field will lead to an unbootable system using a legacy BIOS. Malware authors can target the MBR when writing Wipers. Malware like Whispergate is a real-world example that is overriding the MBR bootloader section with a custom code to display a ransom note and override the first 199 bytes of each partition entry found.
EBR: The “ugly” fix for the partition entries limitation
If you followed everything until now, well first: congrats and thank your. Secondly, you noticed that the MBR is limiting the number of partition entries to 4. That is not enought nowadays as modern systems are using way more partitions entries like dualboot systems, servers with multiple partitions to separate system functions, and more.
To counteract this, IBM and Microsoft introduced the Extended Boot Record. EBR is a special partition table that is pointed by a standard MBR partition entry and is holding metadata for one logical partition at a time. It follows a scheme very similar to MBR (with the same signature) and holds only 2 partition entries:
- The first one is describing a logical partition
- The second one is describing the location of another EBR partition
With this method you can chain as many partition as you wish and “extend” the number of partitions you can fit into MBR. But this comes at the price of complexity and unused fields like the bootloader section of each EBR records. I haven’t been digging into research, but I guess letting these empty unused bootloader sections could be used by malware to hide malicious code in there. Might be worth investigating this possibility.
The MBR’s simplicity makes it widely supported, but also susceptible to tampering and limited in scalability compared to newer schemes like GPT.
GUID Partition Table (GPT): The modern layout
The GUID Partition Table (GPT) is the modern partitioning scheme that replaces MBR, offering greater flexibility, scalability, and reliability. It was introduced as part of the UEFI (Unified Extensible Firmware Interface) standard, GPT supports disks larger than 2 terabytes and allows for an almost unlimited number of partitions (up to 128 by default, compared to MBR’s limit of 4 primary partitions). Unlike MBR, we will use the LBA metric to describe the structure. As a reminder, 1 LBA = 1 Sector = 512 (0x200) bytes in our blog post series context.
Protective MBR
The Protective MBR (PMBR) is a compatibility trick used in the in GPT to protect GPT disks from being misinterpreted by older, MBR-only tools. That’s why the GPT Header is located at LBA 1. The PMBR is non-bootable and has a partition type value of 0xEE with a start LBA address at 0x1 and a number of sectors equal to the entire disk (or 0xFFFFFFF if the disk is too large). Its whole purpose is to prevents MBR-only tools (like old versions of fdisk or BIOS utilities) from thinking the disk is unpartitioned and say “This is a GPT disk. Don’t mess with it.” It also gives us as a Digital Forensics Investigator the clue that we are dealing with GPT. We can also check the PMBR to see if it was corrupted or messed up with by a potential malware.
The GPT Header
The GPT Header is a 512-byte structure (typically) that sits at LBA 1 (right after the Protective MBR at LBA 0). It describes: • The layout of the GPT partition table • Where to find partition entries • How many partition entries exist • Redundant (backup) GPT structures
The GPT Header is very helpful in order for the Investigator to identify the partitions but if it was tampered with or corrupted, we can still rely on the fact that the backup information are still present at the end of the volume. We will see how we can do that with Exhume in a later section.
The GPT Partition entries
Each partition entry in GPT includes a Globally Unique Identifier (GUID), a partition name, and CRC32 checksums for integrity verification that make GPT more robust and resistant to corruption than MBR. It also has attributes that can give us more specific information about the kind of filesystem and operating system we are dealing with.
GPT is now the default partitioning method for Windows, Linux, and macOS on UEFI-enabled hardware. However you can and you will still find a lot of MBR.
Exhume Partitions: Disk Layout Investigation
We integrated MBR/EBR and GPT partition investigation capabilities into the Exhume ToolKit inside the "exhume_partitions" module. Let's see how you can investigate a disk image layout using the CLI.
After installing exhume partitions, we can view the different options we can pass to the program using the --help argument.
Let's investigate a corrupted GPT Disk Image. In this case the main GPT Header at LBA 1 is no longer available. On the screenshot bellow, we can see the GPT Signature that is suppoed to be "EFI PART" in ASCII was modified to corrupt it.
Exhume as the capability to try to parse the backup GPT header and entries if the LBA 1 metadata are corrupted. Let's witness it by using exhume_partition on this disk image.
We can see that the tool identified the PMBR, and didn't successfully parse the GPT signature. It as reverted to the backup Header thus making the parsing possible.
JSON output
Let's now say we want to use this output for our custom tool. We can use the --json argument to have the results of the disk layout in JSON. In the example bellow, we pipe the resulted output into jq to fetch some interesting info.
Using as a library
Like all Exhume modules, you can use it as a library in your own rust based tools ! Learn more with the documentation: https://www.forensicxlab.com/docs/exhume_partitions/library
Conclusion
We now have a new exhume module builded on top of Exhume Body to discover the layout of a disk image. In the next blogpost, we will dive into the forensic of the Extended FileSystem with Exhume ExtFS! We hope you enjoyed and learn things about MBR and GPT ! Join us on Discord if you want to participate to the project.