Secure Boot Uefi Research

Secure Boot / UEFI research

The chain, in enforcement order: firmware (SEC→PEI→DXE→BDS) verifies the boot loader (db signatures), bootmgr/winload verify kernel + ELAM + Critical services, kernel CI takes over. Each link has distinct attack surface; identify which link a question belongs to before touching anything.

Inventory the box first (windows-internals platform truth)

Confirm-SecureBootUEFI                       # SB state (needs admin, UEFI boot)
bcdedit /enum {current}                      # nointegritychecks/testsigning flags
manage-bde -status                            # BitLocker state, protector IDs
Get-Tpm; Get-TpmEndorsementKeyInfo           # TPM present/owned/attestation-ready
# Measured-boot evidence: parse C:\Windows\Logs\MeasuredBoot\*.log (TCG log) directly

UEFI variables live in HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot (state mirror) and the real store in NVRAM — query with GetUefiVariable-style tools or the firmware shell; never assume the registry mirror is authoritative.

Variable/authority model

• PK (Platform Key) owns KEK; KEK updates db (allowed signers) / dbx (revocation). SetupMode variable open at deployment = the classic "deploy own keys" lab path (physical presence required).
• dbx updates arrive via Windows Update — for bootkit research, track dbx revocations as the defender's move history (each entry = a killed bypass).
• *Default variables matter: on some firmware, failure to read db falls back to vendor defaults — historically a bypass class (default-db trusting vendor-only chains).

BCD policy layer (most-used in driver work)

bcdedit /set testsigning on            # allows test-signed kernel modules
bcdedit /set nointegritychecks on      # CI bypass for ELAM-era checks (may be ignored on recent builds)
bcdedit /set debug on                  # KDNET — pairs with windbg-ttd

These live in the BCD store (\EFI\Microsoft\Boot\BCD + registry hive HKLM\BCD00000000 view). Research notes: (a) flags are themselves measured into PCR context on some configs (BitLocker sees tampering), (b) bootmgr honors them before winload — a bootkit's cheapest trick is BCD surgery, which is why defenders watch the store hash, (c) some flags are ignored when Secure Boot is ON — always verify effective policy with an actual unsigned-driver load test, not documentation.

BitLocker key hierarchy

• FVEK (encrypts data) ← VMK ← protector(s): TPM (PCR-bound), PIN, USB, recovery password, AD escrow.
• PCR binding for TPM-only: PCR0..7 (firmware/config), PCR11 (bitlocker/ access control). testsigning flips measured state → recovery prompt on next boot. Research flow: manage-bde -protectors -get C:, note PCRs, suspend before lab changes, resume after — avoid burning recovery prompts (they're logged and, on managed boxes, noticed).
• "Hardware encryption" on cheap SSDs (TCG Opal self-encrypting drives with default keys) historically degraded to trivially-decryptable states — check manage-bde -status "Encryption Method" before assuming FVEK-based crypto.

Measured vs Secure Boot (don't conflate)

• Secure Boot = signature enforcement (an active gate).
• Measured Boot = PCR hash log (TPM) of everything booted — evidence, not enforcement. You can boot unsigned stuff and TPM happily records your sin; detection comes only from attestation (remote/PCR quotes — see tpm-attestation-research) or BitLocker's PCR-bound unsealing.
• TCG log (\Windows\Logs\MeasuredBoot\*.log) is parseable — as an attacker, read it to know exactly what you changed that got measured.

Bootkit precedent classes (what public attacks did)

When researching a new one: diff the ESP contents (mountvol S: /S), hash bootmgr/winload against known-good from the installed build, parse the TCG log for unexpected measurements before the loader.

Lab setups

• QEMU + OVMF (in WSL2/secondary box — QEMU not installed locally, install per need): enroll your own PK/KEK/db (KeyTool on the OVMF frontend), sign test binaries with created certs — full authority over every link; the only way to cheaply iterate on dbx/PKI logic.
• Hardware: Intel Boot Guard present boxes (OEM signed IBB) resist firmware replacement — check with bootguard status tools before planning firmware-level persistence experiments; boxes without Boot Guard remain open to SPI reflashing (CH341A-class programmer for extraction — pairs with hardware-security).
• Tooling gaps on this workstation: no UEFITool/chipsec — install when the task needs them and record in tool-index.md.

OPSEC/tripwires while researching on live boxes

• Secure Boot state changes and BitLocker recovery events land in Event Log (Microsoft-Windows-BitLocker, Event 246/546 families) — clean your lab state before abandoning a box, or note the noise you made.
• Never flip secure-boot-critical vars on a box whose BitLocker recovery keys you don't hold.

Pair with

vbs-hvci-research (the trust stack above boot), tpm-attestation-research (PCR/attestation deep dive), windbg-ttd (boot debugging: bcdedit /bootdebug), firmware-pentest (embedded/IoT firmware flows), hardware-security (SPI/JTAG extraction), windows-internals (platform truth first).