Comprehensive Guide to Booting, Bootloaders, and related Attack Vectors and Security — Part 1

Bootloaders are a critical component of modern computer systems, forming the bridge between the hardware and the operating system (OS). In this blog, we’ll be covering a detailed explanation of their role, importance, development, and functionality.

What are Bootloaders?

A bootloader is a piece of software that is executed when a computer or embedded device is powered on. It is responsible for initializing hardware components and loading the operating system or kernel into memory, thereby starting the system’s operational state.

Why Are Bootloaders Needed?

Hardware Initialization:

• Bootloaders are essential for initializing hardware peripherals, such as the CPU, memory (RAM), and input/output devices. At startup, hardware is in a minimal, unconfigured state, and the bootloader ensures it’s ready for higher-level operations.

Loading the Operating System:

• The bootloader locates the operating system’s kernel, loads it into memory, and passes control to it. Without the bootloader, the OS would not know how to communicate with the hardware or begin execution.

Platform Agnosticism:

• Bootloaders abstract hardware differences, enabling the same OS to run on various hardware platforms. For example, ARM-based devices and x86 PCs use different initialization processes, which the bootloader handles.

Multi-Boot Management:

• Bootloaders like GRUB (used in Linux) allow users to choose between multiple installed operating systems at startup.

Security:

• Bootloaders often enforce cryptographic verification of the kernel and OS images, ensuring the system is booting trusted code.

Irreplaceable Roles of a Bootloader

Hardware-to-Software Transition:

• A bootloader facilitates the transition from hardware’s low-level operations to the high-level OS environment. This role cannot be replaced since there’s no other mechanism to bridge the gap.

Error Recovery and Debugging:

• Many bootloaders provide recovery environments or minimal command interfaces for system recovery and diagnostics.

System Security:

• Secure Boot processes rely on bootloaders to validate signatures of the OS image and prevent unauthorized modifications.

Flexibility in Deployment:

• Bootloaders allow the installation of OS updates or changes without requiring hardware modifications.

High-Level and Low-Level Tech Associated

High-Level Perspective:

Multi-OS Support:

• Tools like GRUB or Windows Boot Manager provide user-friendly menus for selecting operating systems.

Modular Design:

• Modern bootloaders support extensibility, where additional modules handle advanced functionality like network booting (PXE) or virtualization.

Cross-Platform Compatibility:

• Many bootloaders can handle different architectures, such as x86, ARM, or RISC-V.

Low-Level Perspective:

Assembly Language and Machine Code:

• At its core, the bootloader is often written in low-level languages like assembly or C to interact directly with the hardware.

Initialization of CPU Modes:

• On x86 platforms, the bootloader switches the CPU from real mode to protected mode or long mode (64-bit), enabling the OS to utilize modern features.

Hardware Drivers:

• Embedded bootloaders may include minimal drivers for essential components, such as UART (for serial communication) or NAND flash (for storage).

Interrupt Handling:

• In low-level initialization, the bootloader sets up basic interrupt vectors that the OS later takes over.

Windows Booting Process: Low-Level Overview

The Windows boot process can be broken down into the following stages:

1. Firmware Initialization (BIOS/UEFI Stage):

BIOS (Legacy Systems):

• The Basic Input/Output System initializes the hardware, performs a POST (Power-On Self-Test), and identifies the boot device (e.g., HDD, SSD, USB).
• It then reads the Master Boot Record (MBR) from the bootable drive to locate the bootloader.

UEFI (Modern Systems):

• Unified Extensible Firmware Interface performs a similar role but supports GPT (GUID Partition Table) instead of MBR.
• UEFI loads a boot manager directly, bypassing the need for the MBR.

2. Boot Manager Initialization:

• Once the bootable drive is identified, the bootloader (Windows Boot Manager) is loaded into memory.

3. Bootloader (Windows Boot Manager):

• The bootloader is the Windows Boot Manager (bootmgr) on modern systems.

It is responsible for:

• Loading the Boot Configuration Data (BCD), which contains information about available operating systems and their configurations.
• Displaying the OS selection menu (in case of multiple OS installations).
• Locating and loading the Windows OS loader (winload.exe).

4. Windows OS Loader:

The bootloader hands control to the Windows OS loader (winload.exe), which:

• Initializes essential drivers and the hardware abstraction layer (HAL).
• Loads the kernel (ntoskrnl.exe) and core components into memory.
• Passes execution to the kernel.

5. Kernel Initialization:

• The kernel (ntoskrnl.exe) takes over, initializes system processes, and starts the Session Manager (smss.exe).
• This transitions the system to a fully operational state.

Where the Bootloader Steps In

The bootloader (Windows Boot Manager) steps in during the Boot Manager Initialization stage. It is the first piece of Windows-specific software to be executed after the firmware (BIOS/UEFI) completes its tasks.

Specific Roles of the Bootloader:

Loading Boot Configuration Data (BCD):

• The bootloader reads the Boot Configuration Data (BCD) file, which contains essential details like:
• The location of the Windows OS loader (winload.exe).
• Parameters to pass to the kernel.

Kernel Handoff:

• The bootloader ensures that the kernel and its dependencies are loaded into memory and hands control to winload.exe.

Where the Bootloader is Stored/Configured

Storage Location:

Legacy Systems (MBR):

• The bootloader is stored in the Master Boot Record (MBR) and the active partition’s boot sector.

Modern Systems (UEFI):

• The bootloader (bootmgr) resides in the EFI system partition (ESP) under the directory \EFI\Microsoft\Boot\.
• The BCD store is typically located in the same ESP or on the system partition under \Boot\BCD.

Configuration:

• The bootloader configuration is managed via the Boot Configuration Data (BCD) file.
• Tools like bcdedit (command-line) or third-party software can be used to modify the BCD.

How the Bootloader is Initialized at the Correct Step

Mechanism for Bootloader Invocation:

Legacy BIOS Systems:

• The BIOS looks for the MBR on the boot device.
• The MBR contains the first-stage bootloader, which points to the location of the second-stage bootloader (bootmgr).
• Control is passed to the bootloader via the MBR code.

UEFI Systems:

• UEFI directly reads the EFI system partition (ESP) and identifies the bootloader file (bootmgr).
• The UEFI firmware executes the bootloader file according to the boot order defined in the firmware settings.

Ensuring Bootloader Initialization:

Boot Sequence:

• The boot sequence is configured in the BIOS/UEFI settings.
• The bootloader is guaranteed to execute because the firmware is explicitly directed to locate and load it from the designated partition.

Security and Verification:

• On Secure Boot-enabled systems, UEFI ensures that the bootloader (bootmgr) is cryptographically signed and verified before execution.
• If the signature check fails, the system halts or falls back to recovery mode.

Fail-Safe Mechanisms:

• If the primary bootloader is corrupted or missing, recovery tools or a backup bootloader can be invoked.
• Tools like Windows Recovery Environment (WinRE) provide fallback options.

Detailed Timeline: Bootloader’s Role in Booting Windows

BIOS/UEFI Execution:

• Detects the boot device.
• Invokes the bootloader (bootmgr) from the MBR or EFI system partition.

Bootloader Execution:

• Reads and parses the BCD configuration.
• Displays the OS selection menu (if applicable).
• Loads the OS loader (winload.exe).

OS Loader Execution:

• Initializes the kernel and essential system components.
• Passes control to the kernel (ntoskrnl.exe).

What is the BIOS?

The BIOS (Basic Input/Output System) is a critical component in the booting process of a computer, serving as the initial layer of software that runs immediately after power-on. Let’s break down your questions into detailed sections:

BIOS is firmware embedded in a chip on the computer’s motherboard. It provides the low-level software interface between the system’s hardware and higher-level software (like the bootloader and operating system). It contains instructions for performing basic hardware initialization and preparing the system to load the operating system.

BIOS is practically a mixture of both hardware and software:

Hardware:

• The BIOS firmware is stored on a chip, usually an EEPROM or Flash ROM, soldered onto the motherboard.

Software:

• The BIOS program is a collection of instructions written in low-level programming languages (Assembly or C) that the CPU executes during the boot process.
• The software part interacts with the hardware and prepares the system to run higher-level software (OS).

Why Both?:

• It’s hardware because it’s a physical chip integrated into the motherboard.
• It’s software because it contains code that performs system initialization and interacts with hardware.

Characteristics of BIOS:

Firmware Nature:

• Practically, the BIOS is firmware, which is a blend of software (the BIOS program) and hardware (the chip storing the BIOS).
• It resides in non-volatile memory, traditionally in EEPROM (Electrically Erasable Programmable Read-Only Memory) or Flash ROM, allowing updates when needed.

Purpose:

• Initialize hardware components like the CPU, memory (RAM), storage devices, and peripherals.
• Perform the POST (Power-On Self-Test) to ensure hardware is functioning correctly.
• Locate and load the bootloader from a bootable device.

Types:

• Legacy BIOS: Older systems use this, limited to MBR partitioning and 16-bit real mode operations.
• UEFI (Unified Extensible Firmware Interface): Modern systems use UEFI, which replaces Legacy BIOS with advanced features like GPT partitioning, 64-bit mode, and Secure Boot.

How BIOS is Initialized at the First Stage

Power-On:

• When the system is powered on, the CPU fetches its first instruction from a predefined memory address, which is hardwired into the CPU’s architecture.
• This address points to the BIOS firmware stored in ROM.

BIOS Execution:

• The CPU begins executing the BIOS code from ROM.
• The BIOS initializes itself and starts interacting with the hardware components.

System Initialization:

• Basic system components like the clock, power management, and memory controllers are initialized.
• The CPU is brought out of a reset state and configured to operate in real mode (a simple 16-bit operating mode).

BIOS Bootstrapping:

• The BIOS sets up basic input/output routines (e.g., for the keyboard, display, and disk drives).
• This ensures minimal hardware functionality to allow further initialization.

How BIOS Performs POST

The Power-On Self-Test (POST) is a diagnostic testing process executed by the BIOS to ensure the basic hardware is functioning correctly. Here’s how it works:

Initial Diagnostic Checks:

• The CPU, ROM, and system clock are verified first, as they are essential for the system to proceed further.
• POST ensures the integrity of the BIOS firmware.

Memory Check:

• The BIOS checks the system RAM by writing to and reading from it to ensure it is functioning without errors.

Peripheral Initialization:

• Hardware components like the keyboard, mouse, video card, and storage controllers are checked for proper connection and functionality.

Beep Codes and Indicators:

• If any issue is detected during POST, the BIOS provides feedback through beep codes (on systems with a speaker) or diagnostic LEDs on the motherboard.
• For example, no RAM installed might result in a series of long beeps.

POST Completion:

• If all tests are successful, the BIOS prepares to locate the bootloader by identifying the boot device.

How the Bootloader Comes Into Picture

Identifying the Boot Device:

• After POST, the BIOS checks the boot sequence defined in its settings (e.g., first USB, then HDD).
• It looks for a bootable device containing a valid boot record.

Loading the Bootloader:

In Legacy BIOS:

• The BIOS reads the Master Boot Record (MBR) of the selected device, which contains the bootloader or the first stage of it.

In UEFI:

• The BIOS (UEFI firmware) reads the EFI System Partition (ESP) and loads the bootloader file (e.g., bootmgr.efi for Windows).

Handoff to Bootloader:

• The BIOS hands control to the bootloader by transferring execution to the memory address where the bootloader resides.
• From this point, the bootloader takes over to load the operating system.

What is MBR (Master Boot Record)

The Master Boot Record (MBR) is an essential component of the boot process for computers using Legacy BIOS. It is the first sector of a storage device (e.g., HDD, SSD, USB drive) that contains the information needed to locate and load the operating system’s bootloader.

The MBR is a special section located at the very beginning of a storage device. It is exactly 512 bytes in size and contains three main parts:

Bootloader Code (446 bytes):

• Contains executable code that initializes and loads the bootloader or operating system.

Partition Table (64 bytes):

• Holds information about the primary partitions on the disk (up to 4 partitions).

Boot Signature (2 bytes):

• A marker (0x55AA) indicating that the sector is a valid MBR.

Where is the MBR Located?

• The MBR is stored in the first sector (sector 0) of the bootable storage device.
• Address: Cylinder 0, Head 0, Sector 1.
• This location is reserved and accessed directly by the BIOS during the boot process.

How the MBR Works

Loading by BIOS:

• After the BIOS completes POST, it looks for the MBR on the bootable storage device.
• The BIOS loads the first 512 bytes (the MBR) into memory and transfers control to its bootloader code.

Partition Table Interpretation:

• The MBR bootloader code examines the partition table to find the active (bootable) partition.
• The active partition contains the next stage of the bootloader or the operating system.

Execution Handoff:

• The MBR bootloader locates the starting address of the boot sector of the active partition.
• It loads the partition’s boot sector into memory and transfers control to it, continuing the boot process.

Structure of the MBR

Partition Table Entry Format (16 bytes per entry):

Sample MBR Code

Here’s an example of a simple MBR bootloader written in Assembly. It outputs a message and halts:

BITS 16              ; Set processor to 16-bit real mode
ORG 0x7C00           ; BIOS loads the MBR to address 0x7C00

start:
    MOV AH, 0x0E     ; BIOS teletype function
    MOV SI, msg      ; Load the address of the message
print_char:
    LODSB            ; Load byte at SI into AL, then increment SI
    OR AL, AL        ; Check if the byte is 0 (null terminator)
    JZ halt          ; If 0, end the program
    INT 0x10         ; Call BIOS interrupt to print character
    JMP print_char   ; Loop to print the next character

halt:
    HLT              ; Halt the CPU
    JMP halt         ; Infinite loop

msg db "MBR Bootloader Activated!", 0

times 510-($-$$) db 0 ; Fill up to 510 bytes
dw 0xAA55             ; Boot signature (2 bytes)

Explanation:

• Location: The MBR code runs at memory location 0x7C00, where the BIOS loads the MBR.
• Size: The program fills up to 510 bytes, and the last 2 bytes are reserved for the boot signature.

How the MBR Ensures the Next Step in the Boot Phase

BIOS Execution:

• The BIOS reads the MBR from the boot device and loads it into memory.
• Control is transferred to the MBR’s bootloader code.

Partition Identification:

• The MBR’s bootloader code examines the partition table to identify the active partition.

Locating the Boot Sector:

• Using the starting LBA (Logical Block Address) from the partition table, the MBR calculates the location of the active partition’s boot sector.

Loading the Boot Sector:

• The bootloader loads the active partition’s boot sector into memory.

Handoff to the Next Bootloader Stage:

• Control is transferred to the code in the partition’s boot sector, which may contain:
• The second-stage bootloader (e.g., GRUB for Linux, NT loader for older Windows versions).
• The operating system kernel (in some configurations).

Limitations of the MBR

Partition Limit:

• MBR supports only 4 primary partitions. Extended partitions are used to work around this limitation.

Storage Size Limit:

• MBR can only address up to 2 TB of storage due to its 32-bit addressing scheme.

No Redundancy:

• The MBR has no built-in redundancy, making it vulnerable to corruption.

Compatibility:

• MBR is replaced by GPT (GUID Partition Table) in systems with UEFI firmware, which overcomes these limitations.

What is GUID Partition Table (GPT)

The GUID Partition Table (GPT) is a modern partitioning scheme designed to overcome the limitations of the traditional Master Boot Record (MBR). It is part of the UEFI (Unified Extensible Firmware Interface) specification and is now the standard for partitioning storage devices in modern computers.

It is a partitioning standard that stores information about partitions on a disk, such as their size, type, and location. Unlike MBR, which uses a 32-bit partitioning system, GPT uses a 64-bit addressing scheme, allowing it to support larger storage devices and more partitions.

Why was GPT Introduced?

GPT was introduced to address the following limitations of MBR:

Storage Capacity:

• MBR can only manage disks up to 2 TB in size due to its 32-bit addressing.
• GPT supports disks up to 9.4 zettabytes (theoretically).

Partition Limit:

• MBR supports only 4 primary partitions.
• GPT supports up to 128 partitions (on Windows) or more, depending on the operating system.

Redundancy and Integrity:

• MBR has no built-in redundancy, so corruption can render the entire disk unusable.
• GPT stores multiple copies of the partition table and includes a CRC32 checksum for integrity verification.

Where is GPT Located?

GPT structures are stored in specific locations on the disk:

Protective MBR (Sector 0):

• Even GPT disks start with an MBR at sector 0, but it is a “protective MBR.”
• It exists to prevent older tools from misinterpreting the GPT disk and accidentally overwriting it.

Primary GPT Header:

• Located at sector 1.
• Contains metadata about the disk and pointers to the partition entries.

Partition Entries:

• Immediately follow the GPT header.
• Each entry is 128 bytes and contains information about a partition (type, GUID, start/end sectors, attributes, and name).

Backup GPT Header:

• Stored at the last sector of the disk.
• Ensures redundancy and can be used to recover the partition table if the primary header is corrupted.

How GPT Works

Partitioning a Disk:

• GPT divides a disk into sectors.
• The primary GPT header specifies:
• The location of the partition entries.
• The number of partition entries.
• A CRC32 checksum for error checking.

Accessing Partitions:

• The UEFI firmware reads the GPT header and partition table to locate partitions on the disk.
• Each partition has a GUID (Globally Unique Identifier) and a type (e.g., EFI System Partition, NTFS, Linux filesystem).

Redundancy and Integrity:

• The backup GPT header ensures that the partition information can be restored if the primary header is corrupted.
• The CRC32 checksum detects corruption in the headers or partition entries.

Boot Process:

• GPT works in conjunction with UEFI firmware.
• The EFI System Partition (ESP) contains bootloader files, which the UEFI firmware loads to start the operating system.

Structure of GPT

Primary GPT Header (Sector 1):

Partition Entry (128 bytes per entry):

Sample Code for GPT Header (C-Like Pseudocode)

Here’s a pseudocode snippet demonstrating how a GPT header might be represented and parsed. This header is read by the UEFI firmware to identify and manage partitions.

struct GPTHeader {
    char signature[8];          // "EFI PART"
    uint32_t revision;          // Revision number
    uint32_t headerSize;        // Header size in bytes
    uint32_t headerCRC32;       // CRC32 checksum of the header
    uint32_t reserved;          // Must be zero
    uint64_t currentLBA;        // Current LBA of the header
    uint64_t backupLBA;         // Backup LBA of the header
    uint64_t firstUsableLBA;    // First usable LBA for partitions
    uint64_t lastUsableLBA;     // Last usable LBA for partitions
    GUID diskGUID;              // Disk GUID
    uint64_t partitionEntryLBA; // Starting LBA of partition entries
    uint32_t numPartitionEntries; // Number of partition entries
    uint32_t partitionEntrySize;  // Size of each partition entry
    uint32_t partitionArrayCRC32; // CRC32 checksum of partition array
};

How GPT Ensures the Next Step in the Boot Phase

UEFI Reads the EFI System Partition (ESP):

• The ESP is a special partition on GPT disks that stores bootloader files (e.g., bootmgfw.efi for Windows, grubx64.efi for Linux).

Locating the Bootloader:

• UEFI firmware reads the partition table to locate the ESP.
• The bootloader file is loaded from the ESP and executed.

Integrity Verification:

• CRC32 checks ensure that the GPT header and partition table are not corrupted.
• If corruption is detected, the firmware attempts recovery using the backup GPT header.

Why GPT Replaced MBR

Storage Capacity:

• MBR’s 32-bit addressing limits disks to 2 TB.
• GPT’s 64-bit addressing supports disks up to 9.4 ZB.

Partition Limit:

• MBR allows only 4 primary partitions.
• GPT supports 128 or more partitions.

Redundancy:

• MBR has no redundancy, making it vulnerable to corruption.
• GPT has both primary and backup headers for recovery.

Integrity:

• MBR lacks error-checking mechanisms.
• GPT uses CRC32 checksums to verify data integrity.

UEFI Compatibility:

• GPT works seamlessly with UEFI, enabling modern boot features like Secure Boot and faster boot times.

How Bootloaders Are Developed

The development of bootloaders involves creating a program that bridges the firmware (BIOS/UEFI) and the operating system. Bootloaders must be lightweight, efficient, and secure because they operate at the lowest levels of the system and are critical to the integrity of the boot process.

Below is an in-depth, practical exploration of how bootloaders are developed, their integration in the boot process, and their broader utility.

A bootloader is a small program that:

• Initializes hardware: Sets up the environment for the operating system.
• Loads the OS kernel: Finds and loads the operating system into memory.
• Transfers control: Passes control to the OS kernel to continue the boot process.

Types of Bootloaders

First-Stage Bootloader:

• Executes immediately after the BIOS/UEFI or firmware.
• Responsible for minimal hardware initialization and loading the second-stage bootloader or OS kernel into memory.
• Example: The MBR bootloader or UEFI’s boot manager.

Second-Stage Bootloader:

• Provides advanced functionality, such as selecting between multiple operating systems, setting boot parameters, and interacting with the user.

Examples:

• GRUB (GRand Unified Bootloader) for Linux.
• Windows Boot Manager for Windows.

Development of Bootloaders

High-Level Development Overview

Bootloaders are developed in stages:

Define Requirements:

• Identify the type of system (BIOS/UEFI) and storage (MBR/GPT).
• Understand the operating system requirements.

Design:

• Decide the features (e.g., multi-boot, secure boot, graphical interface).
• Define partition table compatibility (MBR or GPT).
• Choose interaction mechanisms (menu-driven, command-line, or silent).

Implementation:

• Develop low-level hardware initialization routines in Assembly and C.
• Implement higher-level logic for filesystem access, kernel loading, and user interaction.

Testing and Debugging:

• Verify functionality on real hardware and in emulators (e.g., QEMU).
• Test for compatibility with different operating systems and filesystems.

Security Features:

• Integrate cryptographic verification (e.g., Secure Boot).
• Implement fallback mechanisms for recovery in case of corruption.

Low-Level Development

Bootloaders must interact directly with hardware and storage, often written in a combination of Assembly and C for performance and portability.

Example: A Minimal First-Stage Bootloader (Assembly)

BITS 16            ; 16-bit real mode
ORG 0x7C00         ; BIOS loads the bootloader at 0x7C00

start:
    mov ah, 0x0E   ; BIOS teletype function
    mov si, msg    ; Address of the message
print_char:
    lodsb          ; Load the next byte into AL
    or al, al      ; Check if it's the null terminator
    jz done        ; If null, we're done
    int 0x10       ; Print character
    jmp print_char ; Loop for the next character

done:
    cli            ; Disable interrupts
    hlt            ; Halt the system

msg db "Hello, Bootloader!", 0

times 510-($-$$) db 0 ; Fill the rest of the sector with 0s
dw 0xAA55             ; Boot signature

Key Points:

• Entry Point: The bootloader starts at 0x7C00 after the BIOS loads it.
• Minimal Functionality: The example prints a message and halts the system. A real bootloader would locate and load the next stage.

Ensuring Safety and Security

Digital Signatures and Secure Boot:

• Bootloaders include cryptographic checks to verify the integrity and authenticity of the OS kernel or second-stage bootloader.
• Example: UEFI’s Secure Boot ensures only signed bootloaders and kernels can execute.

Code Minimization:

• Keep the first-stage bootloader small and simple to minimize attack surfaces.

Fallback Mechanisms:

• Implement recovery partitions or redundancy for corrupted bootloader files.

Memory Protection:

• Securely clear sensitive data after loading the OS kernel.

Kernel Verification:

• Before passing control to the OS, the bootloader checks the kernel’s hash or digital signature.

Integration with the Boot Process

Previous Step: Firmware (BIOS/UEFI):

• The firmware initializes hardware and reads the bootloader from the storage device.
• For BIOS systems, the firmware loads the first 512 bytes (MBR) of the storage device into memory.
• For UEFI systems, the firmware reads the GPT and loads the bootloader from the EFI System Partition (ESP).

Next Step: Operating System Kernel:

• The bootloader loads the OS kernel into memory and provides necessary boot parameters.
• Transfers control to the kernel to continue the boot process.

Broader Use Cases of Bootloaders

Beyond loading the operating system, bootloaders have several other applications:

Multi-Booting:

• Bootloaders like GRUB allow users to choose between multiple operating systems at startup.

Recovery and Diagnostics:

• Bootloaders can provide recovery options for repairing or reinstalling the OS.
• Include tools for memory testing, disk diagnostics, or firmware updates.

Custom Boot Parameters:

• Bootloaders allow users to pass custom parameters to the OS kernel, such as enabling debugging or configuring hardware.

Embedded Systems:

• In embedded systems, bootloaders initialize specialized hardware and load firmware or OS for specific tasks.

Chain Loading:

• Bootloaders can load another bootloader in complex boot setups (e.g., GRUB loading Windows Boot Manager).

Real-Life Bootloaders

GRUB (Linux):

• Highly configurable, supports multiple OSes.
• Works with BIOS and UEFI systems.
• Can load kernels directly or chain-load another bootloader.

Windows Boot Manager:

• Default bootloader for Windows systems.
• Manages recovery, multi-boot, and advanced boot options.

LILO (Linux):

• Predecessor to GRUB, simpler but less flexible.

Syslinux:

• Lightweight bootloader often used for bootable USB drives.

PXELINUX:

• Network bootloader used for diskless systems.

Sample Workflow: GRUB

Bootloader Installation:

• Install GRUB on the boot device (e.g., /dev/sda).
• GRUB writes its first stage to the MBR (or EFI System Partition for UEFI).

Configuration:

• GRUB reads its configuration file (grub.cfg) to display the boot menu and locate kernels.

Execution:

• GRUB loads the Linux kernel and initrd (initial RAM disk) into memory.
• Passes control to the Linux kernel with boot parameters.

Diving into Multibooting

Multibooting is the process of installing and using multiple operating systems (OS) on a single computer. A multiboot setup allows the user to choose which operating system to load during startup. This is typically achieved through a bootloader that presents a menu for OS selection.

Let’s break this down practically and understand the internal workings, including how it’s supported, how it interacts with MBR/GPT, and how the bootloader manages the process.

What Is Multibooting?

Multibooting refers to having more than one OS installed on separate partitions of a storage device. At boot time, a bootloader presents a menu to let the user choose which OS to boot.

Use Cases for Multibooting:

• Running different OSes (e.g., Windows and Linux).
• Testing or developing software on multiple platforms.
• Using specialized OSes for gaming, development, or legacy applications.

How Multibooting Is Supported

Partitioning for Multiboot:

• Each OS requires its own partition or set of partitions.

MBR Disk:

• Limited to 4 primary partitions.
• To accommodate multiple OSes, one primary partition can be converted to an extended partition, containing multiple logical partitions.

GPT Disk:

• Supports up to 128 primary partitions by default.
• This makes GPT ideal for multibooting modern systems.

Bootloaders Supporting Multibooting:

GRUB (GRand Unified Bootloader):

• Commonly used in Linux.
• Can detect and boot multiple OSes, including Windows.
• Configurable menu for OS selection.

Windows Boot Manager:

• Supports dual-booting with other Windows versions or Linux (via chainloading GRUB).

rEFInd:

• A graphical bootloader for UEFI systems.
• Detects OSes automatically.

How Multibooting Works Internally

Step-by-Step Process:

Installation:

• Install the first OS on one partition (e.g., Windows on Partition 1).
• Install the second OS on another partition (e.g., Linux on Partition 2).
• During Linux installation, the bootloader (GRUB) usually replaces the MBR or configures the UEFI firmware boot manager.

Bootloader Detection:

• The bootloader scans the disk for operating systems.
• GRUB, for example, looks for bootable kernels or bootloader files (e.g., bootmgfw.efi for Windows) on each partition.

User Prompt:

• At startup, the bootloader displays a menu showing the available OSes.
• The user selects an OS using the keyboard or mouse (depending on the bootloader).

Loading the OS:

• The bootloader loads the selected OS kernel into memory.
• Control is passed to the OS kernel, which initializes the system.

How MBR/GPT Looks in Multiboot Scenarios

MBR Layout:

When using MBR, the bootloader is installed in the first 512 bytes (sector 0) of the disk.
The partition table in MBR typically looks like this:

• The bootloader code is in sector 0, while the partition table is in the same sector (bytes 446–510).
• The active partition flag determines which OS the BIOS should boot by default (if no menu is used).

GPT Layout:

With GPT, there is no fixed size for the bootloader. Instead:

• The UEFI firmware reads the EFI System Partition (ESP), which contains bootloader files for all installed OSes.

Example GPT layout:

The ESP typically contains files like:

• /EFI/Microsoft/Boot/bootmgfw.efi (Windows Boot Manager).
• /EFI/ubuntu/grubx64.efi (GRUB for Ubuntu).

Interaction Between Bootloaders and OSes

Primary Bootloader (BIOS/UEFI):

• For BIOS, the bootloader is installed in the MBR.
• For UEFI, the bootloader files are stored in the ESP, and the firmware launches the appropriate one.

Second-Stage Bootloader:

• If the first-stage bootloader cannot directly load an OS, it chainloads another bootloader.
• Example: GRUB can chainload Windows Boot Manager for booting Windows.

How Bootloaders Prompt Users

GRUB:

• GRUB generates a configuration file (/boot/grub/grub.cfg) listing all detected OSes.

Example GRUB menu entry:

menuentry 'Windows 10' {
    set root=(hd0,1)
    chainloader +1
}

menuentry 'Ubuntu' {
    set root=(hd0,3)
    linux /boot/vmlinuz root=/dev/sda3
    initrd /boot/initrd.img
}

Windows Boot Manager:

• The Windows Boot Manager stores configuration in the Boot Configuration Data (BCD) store.

To add an entry for Linux

bcdedit /set {id} path \EFI\ubuntu\grubx64.efi

rEFInd:

• Automatically detects OS bootloaders in the EFI System Partition and displays a graphical menu.

How Multiboot Ensures the Next Step in Boot Phase

Filesystem Compatibility:

• The bootloader must support the filesystem of each OS (e.g., NTFS for Windows, ext4 for Linux).

Chainloading:

• For systems like Windows, the main bootloader (GRUB or rEFInd) hands off control to the OS-specific bootloader (e.g., bootmgfw.efi).

Kernel Loading:

• Linux bootloaders like GRUB load the kernel (vmlinuz) and initial RAM disk (initrd).
• Windows Boot Manager loads the Windows kernel and starts the OS initialization.

Types of Booting and Their Practical Workings

Booting is the process by which a computer initializes hardware, loads system software, and prepares the operating system for use. There are different types of booting processes, categorized based on the method or purpose of booting. Below, we discuss hard booting, soft booting, cold booting, warm booting, and secure booting in detail, along with their practical workflows.

Hard Booting

Also referred to as a “hard reset,” this is when the system starts fresh after being powered off or forcibly reset by cutting power.

Key Characteristics:

• Involves a complete hardware reset.
• All hardware components, including RAM and peripherals, are reinitialized.
• Occurs when the system is powered on for the first time or restarted after a power interruption.

Practical Workflow:

Power-On:

• The power button is pressed, supplying electricity to the motherboard.

Power-On Self-Test (POST):

• The BIOS/UEFI firmware runs diagnostic checks on hardware (CPU, memory, storage, etc.).
• Errors during POST (e.g., missing memory) cause the boot process to halt, and error codes or beeps are emitted.

Bootloader Invocation:

• After successful POST, the firmware identifies the boot device and loads the bootloader (e.g., MBR or UEFI bootloader).

OS Loading:

• The bootloader loads the OS kernel, and the operating system begins its initialization process.

Use Case:

• Used when the system is powered off completely.
• Required for initial startup or recovering from a system hang.

Soft Booting

Also called a “soft reset,” this refers to restarting the system without turning off the power completely.

Key Characteristics:

• Hardware remains powered, but software and firmware components are reset.
• Achieved through operating system commands like Restart or keyboard shortcuts (e.g., Ctrl+Alt+Del).

Practical Workflow:

Restart Command Issued:

• A user issues a restart from the operating system or triggers a keyboard shortcut.

OS Shutdown:

• The OS stops all running processes and services.
• Hardware drivers are reset, and any cached data is cleared.

BIOS/UEFI Initialization:

• The firmware restarts the POST process to reinitialize hardware.

Bootloader Loading:

• The bootloader is loaded as in hard booting, and the OS kernel is reloaded into memory.

Use Case:

• Restarting to refresh system processes.
• Applied during software installations or updates.

Cold Booting

A subset of hard booting, cold booting refers specifically to starting a system from a completely powered-off state.

Key Characteristics:

• Similar to hard booting but emphasizes that the system was powered off and “cold.”
• Commonly happens when the power button is pressed after the system was unplugged or shut down.

Practical Workflow:

The process is identical to hard booting: power-on, POST, bootloader execution, and OS loading.

Use Case:

• Regular startup from a powered-off state.
• Necessary when moving hardware or ensuring a complete reset.

Warm Booting

A subset of soft booting, warm booting refers to restarting the system while it is powered on.

Key Characteristics:

• Less time-consuming than a cold boot since hardware power states don’t change.
• Often triggered by software commands or a key combination.

Practical Workflow:

Command Execution:

• A Restart or similar command is issued.

OS Restarts:

• The OS gracefully stops processes, saves states, and hands over control to the firmware.

Hardware Not Fully Reset:

• The firmware initializes the system without cutting power to components like RAM or CPU caches.

OS Kernel Reloaded:

• The bootloader loads the OS kernel, completing the process.

Use Case:

• Applied when rebooting after system updates or software installations.

Secure Boot

Secure Boot is a feature of UEFI firmware that ensures only trusted, digitally signed software (e.g., bootloaders and kernels) is executed during the boot process.

Key Characteristics:

• Protects against bootkits and rootkits by preventing unsigned or malicious code from executing.
• Relies on cryptographic keys stored in the UEFI firmware.

Practical Workflow:

UEFI Initialization:

• The firmware begins executing and checks if Secure Boot is enabled.

Bootloader Verification:

• The bootloader’s digital signature is compared against the trusted certificates stored in UEFI.
• If the signature matches, the bootloader is executed. Otherwise, the boot process halts with an error.

OS Kernel Verification:

• The bootloader (e.g., GRUB) verifies the OS kernel’s digital signature before loading it.

Kernel Execution:

• The verified kernel is loaded into memory, and the OS begins initialization.

Use Case:

• Required for secure environments, such as government or enterprise systems.
• Protects against malware that compromises the bootloader or kernel.

Practical Observations During Each Type

• Hard Boot/Cold Boot: Hardware reinitialization (fans spin up, devices power on) is evident.
• Soft Boot/Warm Boot: The system restarts without turning off peripherals or hardware completely.
• Secure Boot: Users might observe boot errors if unsigned or incompatible software is loaded.

Secure Boot: Comprehensive Overview and Internals

Secure Boot is a feature of modern UEFI firmware designed to protect the system from running malicious or tampered software during the boot process. It ensures that only trusted, digitally signed software (bootloaders, OS kernels, drivers, etc.) is executed. Below, we explore Secure Boot in detail, covering its features, internals, configuration, benefits, limitations, and practical examples.

Secure Boot is a security standard developed by the Unified Extensible Firmware Interface (UEFI) Forum. It ensures that the boot process begins with software that has been verified as authentic and trusted.

Core Goals:

• Prevent unauthorized/malicious software (e.g., rootkits, bootkits) from executing.
• Ensure the integrity of the boot process by verifying the digital signatures of critical boot components.
• Maintain a secure chain of trust from the firmware to the operating system.

How Secure Boot Works

1. The Chain of Trust

Root of Trust:

• Secure Boot begins with the firmware (UEFI) acting as the root of trust.
• UEFI firmware is preloaded with a list of trusted keys and certificates.

Verification Process:

• Each software component (e.g., bootloader, OS kernel) is digitally signed.
• The signature is verified against trusted keys in the firmware before execution.

Untrusted Components:

• If a signature mismatch is detected (e.g., unsigned or tampered software), the boot process halts, displaying an error.

2. Key Components

Platform Key (PK):

• The ultimate authority in Secure Boot.
• Controls access to the firmware configuration and ensures no unauthorized changes.

Key Exchange Key (KEK):

• Manages updates to the database of trusted (and revoked) certificates.

Signature Databases:

• db: Contains trusted certificates and hashes of allowed executables.
• dbx: Contains revoked certificates and hashes of disallowed executables.

Secure Boot Internals

Step-by-Step Boot Process

UEFI Initialization:

• During power-on, the UEFI firmware is loaded from a chip on the motherboard.

Verify Bootloader:

• UEFI checks the bootloader's signature against the db database.
• If trusted, the bootloader is executed.

Bootloader Verification:

• The bootloader (e.g., GRUB, Windows Boot Manager) verifies the OS kernel's signature.

Kernel Execution:

• A verified OS kernel is loaded, continuing the system initialization.

Digital Signatures

How Signing Works:

• Boot components (e.g., bootloaders, kernels) are cryptographically signed using a private key.
• The corresponding public key is embedded in the UEFI firmware's trust database (db).

During the boot process, UEFI verifies the component by:

1. Decrypting the signature with the public key.
2. Comparing the resulting hash with the actual hash of the software.
3. If they match, the component is trusted and allowed to execute.

Key Features of Secure Boot

1. Trusted Execution

• Ensures that the system only boots software from verified sources.
• Prevents tampering with the bootloader or kernel.

2. Tamper Detection

• If an attacker modifies the bootloader or kernel, the signature will no longer match, and the boot process will halt.
• Protects against bootkits and rootkits, which embed themselves in the boot process.

3. Revocation

• The dbx database is used to revoke trust for compromised keys, certificates, or binaries.
• For example, if a vulnerability is discovered in a trusted bootloader, its hash can be added to dbx, blocking its execution.

4. Key Management

• Administrators can add or remove keys from the db and dbx databases.
• This allows for custom trust chains, such as adding keys for custom bootloaders or kernels.

Practical Implementation of Secure Boot

1. Enabling Secure Boot

• Secure Boot is enabled or disabled in the UEFI firmware settings (commonly accessed via a key like F2, Delete, or F10 during startup).
• Configuration involves:
• Enabling Secure Boot.
• Managing keys (PK, KEK, db, and dbx) via firmware tools.

2. Custom Key Management

• Custom keys are often used in enterprise environments to support:
• Proprietary software.
• Custom operating systems.
• Tools like KeyTool or sbkeysync are used to manage UEFI keys.

3. Signing Boot Components

• Boot components (e.g., GRUB, Linux kernels) must be signed before being added to the db database.
• Example: Signing a Linux kernel:

sbsign --key db.key --cert db.crt /boot/vmlinuz > /boot/vmlinuz.signed

Diagnosing Secure Boot Errors

If a component fails verification, the system will display errors like:

• “Secure Boot Violation.”
• “Invalid signature detected.”
• Tools like mokutil can manage keys and resolve such errors in Linux environments.

Why Secure Boot is Important

1. Protection Against Bootkits and Rootkits

• Malicious software that runs during boot can compromise the OS and remain hidden from antivirus tools.
• Secure Boot blocks such attacks by enforcing trust at the lowest level.

2. Ensuring System Integrity

• Critical for systems in high-security environments (e.g., government, finance, healthcare).
• Prevents tampering with critical boot components.

3. Compliance

• Secure Boot helps meet compliance standards (e.g., NIST, PCI DSS) that mandate secure initialization processes.

Secure Boot Limitations

1. Compatibility Issues

• Older operating systems or unsigned software may fail to boot when Secure Boot is enabled.
• This often requires disabling Secure Boot for legacy systems.

2. Key Management Complexity

• Mismanagement of keys can lead to:
• Systems refusing to boot valid software.
• Security vulnerabilities if keys are leaked.

3. Bypasses and Vulnerabilities

• In the past, vulnerabilities in certain bootloaders allowed bypassing Secure Boot (e.g., Shim vulnerabilities in Linux).
• Keeping the firmware and trust databases updated is critical.

MBR/GPT and Secure Boot

MBR Systems:

• MBR systems usually use BIOS, which does not support Secure Boot.
• Upgrading to GPT and UEFI is necessary to enable Secure Boot.

GPT Systems:

• GPT is required for UEFI and Secure Boot.
• The EFI System Partition (ESP) stores signed bootloaders and kernels.

Comparison: Secure Boot vs Legacy Boot

Advanced Secure Boot Use Cases

1. Dual-Boot Systems

• Secure Boot can coexist with multiboot configurations by signing all bootloaders.
• Example: Dual-booting Windows and Linux with Secure Boot enabled requires signing GRUB.

2. Enterprises and Servers

• Secure Boot is essential in enterprise environments where tampering with firmware or bootloaders can compromise data centers.

3. Virtualized Environments

• Virtual machines (VMs) can also use Secure Boot when the hypervisor supports it (e.g., VMware, Hyper-V).

Securing the Boot Process and Bootloaders: A 360-Degree View

The boot process is a critical part of a computer’s startup sequence. If compromised, it can allow attackers to gain full control of a system from the very start, often bypassing operating system security and making it difficult for antivirus and other protective measures to detect the intrusion. Below, we explore various attack methods used to corrupt, infect, or take control of bootloaders, MBR, GPT, and the entire boot process. We also cover how advanced threats like ransomware, APT (Advanced Persistent Threat) groups, and rootkits/bootkits use these vectors for attacks, along with real-world examples.

1. Attack Methods on Bootloaders, MBR, and GPT

1.1. MBR Corruption and Manipulation

The Master Boot Record (MBR) is a primary target for malicious actors due to its role as the first sector of the disk. A compromise here can lead to a system being hijacked early in the boot process.

Methods of Attack:

MBR Rootkits:

• Attackers can modify the MBR to include malicious code that runs before the OS is even loaded.
• This can result in complete control of the system, often by loading a rootkit or keylogger.

MBR Hijacking:

• MBR code can be replaced or modified to direct the system to boot an alternative operating system or malicious software.
• This might be done by an attacker who gains access to the system or via malware that infects the system.

Example:

• In the Bootkit attack on Windows in 2011 (e.g., TDL-4 rootkit), the MBR was manipulated to load malicious code during boot, enabling a hidden attack without detection by conventional security software.

Detection/Prevention:

• Using cryptographic hashes and checksums for MBR and boot sectors.
• Digital signatures on bootloaders and OS files ensure that the integrity of the MBR is checked before execution.
• Specialized tools like MBRFilter can monitor changes to the MBR.

1.2. GPT and EFI System Partition (ESP) Corruption

With the rise of UEFI and GPT-formatted disks, the boot process is more secure due to the EFI System Partition (ESP) and Secure Boot. However, these can still be targeted by attackers.

Methods of Attack:

EFI/ESP Hijacking:

• Attackers can compromise the ESP, which stores bootloaders and boot-related files, by replacing the legitimate bootloader with a malicious one.
• Malicious bootloaders can be inserted into the ESP to bypass security checks and initiate a chain of attacks.

Firmware-Level Exploits:

• UEFI malware like Rufus (the Black Hat UEFI malware from 2016) targets the UEFI firmware itself, modifying the EFI partition to load malicious firmware or tools.
• Infected firmware allows the attacker to persist even after reinstallation of the OS.

Detection/Prevention:

• Enabling Secure Boot prevents unauthorized firmware and bootloaders from being loaded.
• Regular checks on ESP to verify that only trusted bootloaders are stored.
• Tools like UEFI Tool or Chipsec can be used to inspect and analyze UEFI firmware for signs of tampering.

1.3. Bootloader Compromise

Bootloaders themselves can be vulnerable targets for compromise. A modified bootloader can execute malicious payloads or open a backdoor into the operating system.

Methods of Attack:

Bootloader Hijacking:

• Attackers can inject malicious code into the bootloader (e.g., GRUB, Windows Boot Manager) to alter the normal boot process.
• A compromised bootloader could pass control to a malicious kernel or exploit an OS vulnerability during startup.
• This attack typically occurs when the bootloader’s security is bypassed or when the system is running with insecure configurations.

Example:

• Stuxnet used a modified bootloader to exploit vulnerabilities in industrial systems during their boot process, enabling the malware to load before OS-level defenses could be activated.

Detection/Prevention:

• Digital signatures for bootloaders ensure only verified versions are used.
• Use of GRUB password protection or LUKS encryption to prevent unauthorized modifications.

2. Sophisticated Attacks Leveraging Boot Process Vulnerabilities

2.1. Bootkits

A bootkit is a type of rootkit that targets the boot process, specifically the MBR, bootloader, or kernel, to gain control before the operating system is even loaded. Once the bootkit is active, it has full access to the system, often hidden from security software.

How Bootkits Work:

• The bootkit manipulates the MBR, GPT, or UEFI firmware to load malicious code at boot time.
• It can hide itself from antivirus software, as it operates at a low level, before the OS is loaded.
• Some advanced bootkits also disable certain security mechanisms (e.g., Secure Boot) to prevent detection.

Example:

• TDL-4 bootkit targeted Windows machines and modified the MBR to load a rootkit. It infected over a million machines, creating an invisible backdoor on compromised systems.

Detection/Prevention:

• Use Secure Boot and trusted UEFI/EFI signatures to prevent unauthorized bootloaders from executing.
• MBR protection tools and antivirus software that perform boot-time scans can help detect these attacks.

2.2. Rootkits

Rootkits are a type of malware that hide their presence on a system. They can install themselves during the boot process, making them very difficult to detect and remove.

How Rootkits Use the Boot Process:

• A rootkit can replace or modify system files, including bootloaders, kernel modules, or drivers.
• Rootkits like SysInternals RootkitRevealer allow attackers to hide themselves from antivirus software by placing hooks in the kernel or modifying bootloaders.
• Kernel-level rootkits (e.g., ZeroAccess, Sonic rootkits) are especially dangerous, as they provide an attacker with privileged access to the system while remaining invisible.

Example:

• Alureon (also known as TDL-4) was a rootkit that infected Windows systems by replacing the MBR and using bootkits to load malicious software before the OS could start.

Detection/Prevention:

• Kernel integrity checkers like chkrootkit or Rootkit Hunter can detect hidden rootkits in Unix-like systems.
• Monitoring the UEFI and ESP for unusual changes can help detect attempts to modify or insert malicious code into bootloaders.

2.3. Ransomware Attacks

Sophisticated ransomware attacks sometimes target the boot process to ensure that they are executed early on during system startup.

How Ransomware Uses Bootloaders:

• LockScreen Ransomware: Some ransomware, such as Locker Ransomware, may modify bootloaders to display ransom notes during boot before the OS loads.
• Bootloader Encryption: Ransomware can also encrypt the bootloader or the MBR and demand a ransom before allowing the system to boot properly.

Example:

• Petya ransomware used a bootkit to encrypt the MBR, effectively preventing the system from booting until the victim paid the ransom.

Detection/Prevention:

• Secure Boot helps protect against ransomware manipulating the bootloader.
• Maintaining regular backups and using strong file-system encryption like BitLocker can mitigate ransomware’s impact.

2.4. APT Groups Using the Boot Process

APT (Advanced Persistent Threat) groups, which are often state-sponsored or highly skilled cybercriminal groups, use sophisticated techniques to compromise the boot process and establish a foothold on a system.

How APTs Exploit the Boot Process:

• APT groups typically use custom malware, including bootkits, that alter the bootloader or firmware.
• They use this to gain control of systems and exfiltrate sensitive information over an extended period.
• Some APT groups target UEFI firmware directly, embedding malicious code into the firmware itself, allowing them to maintain persistence even after OS reinstallations.

Example:

• Equation Group (linked to the NSA) used the GrayFish UEFI rootkit to infect the firmware of hard drives. This rootkit allowed the group to persist in the target system even if the OS was wiped.

Detection/Prevention:

• Regularly updating UEFI firmware and monitoring for unauthorized changes.
• Using hardware-based trusted platform modules (TPM) and enabling secure boot.

MBR Rootkit Injection (Practical Example)

Step-by-Step Attack:

1. Accessing the MBR:

• Use dd (Disk Dump) command in a Linux or Unix system to manipulate the MBR. This wipes the first sector, including the MBR.

sudo dd if=/dev/zero of=/dev/sda bs=512 count=1

2. Injecting Malicious Code:

• Create a malicious bootloader code, for example:

; Simple Assembly code to load malicious payload
mov ah, 0x0e
mov al, 'M'  ; First byte of malicious message
int 0x10

This code will print “M” during boot, which could be part of a larger attack chain.

3. Rewriting MBR:

• Now, we can write this malicious code to the MBR:

sudo dd if=malicious_bootloader.img of=/dev/sda bs=512 seek=0

This writes the malicious MBR to the disk, replacing the original bootloader.

4. Booting the System:

• Upon booting, the system will load the modified MBR, executing the malicious code before the OS even starts.

Prevention:

• Enabling Secure Boot ensures the MBR’s integrity and verifies the bootloader’s authenticity.
• Regular integrity checks using chkrootkit on Linux systems to detect rootkit activities.

GPT and EFI System Partition (ESP) Hijacking (Practical Example)

Step-by-Step Attack:

1. Compromise the EFI System Partition:

• Mount the EFI partition

sudo mount /dev/sda1 /mnt/efi

Here, we can see files like bootx64.efi (Windows Boot Manager or GRUB).

2. Inject Malicious Bootloader:

• Replace the default bootloader with a malicious one, for example:

sudo cp /path/to/malicious_bootloader.efi /mnt/efi/EFI/Boot/bootx64.efi

This will make the system load the attacker’s code instead of the normal OS bootloader.

3. Modify Boot Settings (if necessary):

• Using efibootmgr to manipulate UEFI boot entries:

sudo efibootmgr -o 0001,0000

• This forces the system to boot the malicious entry first.

Real-World Example:

• Rufus malware from 2016 was able to modify the EFI partition, replacing the original bootloader with malicious code designed to maintain persistence.

Prevention:

• UEFI Secure Boot prevents unauthorized changes to the EFI partition by verifying signatures.
• Regularly audit the ESP and UEFI settings for any signs of unauthorized bootloaders.

#Bootloaders #booting #linux #Windows