UEFI is the new BIOS

What it is

The introductory post in Leviathan Security's UEFI reverse-engineering/exploit-dev series (seven more parts planned: lab setup, static/dynamic analysis, fuzzing, and three exploit-dev posts). Beyond the boot-flow/chain-of-trust overview, the page gives concrete technical specifics worth noting for anyone building UEFI RE skills.

How it works

Key mechanism details the summary omits:

• Boot Guard's root of trust: the Authenticated Code Module (ACM) runs in Cache-as-RAM (CAR) and verifies the Initial Boot Block (IBB = SEC+PEI) using a key burned into the motherboard's Field-Programmable Fuse (FPF), before the CPU executes the first IBB instruction after reset.
• BIOS Guard's specific gap-fill: it restricts SPI flash read/write specifically from SMM code (SMI handlers) and most POST code, running only in BIOS Guard's AC-RAM mode — this is the mechanism that closes the "Boot Guard doesn't block SPI read/write" gap mentioned in the summary.
• DXE independence from PEI: DXE only requires a valid HOB list to execute — PEI is just one possible producer of that list, not a hard dependency (quoted from the PI Spec).
• PPI vs. Protocol symmetry: PEI's LocatePpi()/InstallPpi()/ReinstallPpi() map directly to DXE's EFI_BOOT_SERVICES.LocateProtocol()/InstallProtocolInterface()/etc. — useful for RE pattern-matching across phases.
• ExitBootServices() boundary: at end of BDS, this call destroys EFI_BOOT_SERVICES (no longer callable), but EFI_RUNTIME_SERVICES persists into OS runtime — the only firmware/OS bridge left post-boot.

Preconditions / Affected

Applies to Intel-based platforms specifically (the post states it only covers Intel's three mechanisms: UEFI Secure Boot, Intel Boot Guard, Intel BIOS Guard — AMD/ARM equivalents are out of scope). The X58I reference BIOS image used for UEFITool screenshots is from the edk2-platforms repo, useful as a concrete practice target for the lab-setup post.

What to do

No patches or defensive actions here — this is foundational/offensive-research reading. Practical next step the page itself points to: open an X58I (or similar edk2-platforms) BIOS image in UEFITool to see the SEC/PEI/DXE firmware-volume structure firsthand before the series' Part 1 (lab setup) post.

flowchart TD
    A[SPI Flash: PI firmware] --> B[SEC phase]
    B --> C[PEI phase]
    C --> D[DXE phase]
    D --> E[BDS phase]
    E -->|ExitBootServices| F[OS Runtime]
    G[Boot Guard: ACM in CAR, FPF key] -.verifies.-> B
    G -.verifies.-> C
    H[UEFI Secure Boot: PK/KEK/db/dbx] -.verifies.-> D
    I[BIOS Guard: blocks SMM/POST flash access] -.protects.-> A

Caveats

The post explicitly calls its design-flaw list "noncomprehensive" and defers Boot Guard/Secure Boot bypass specifics to later posts and external references — no CVEs or bypass PoCs are given here, only the architectural gaps already noted in the summary.