Project 2: Boot Chain Map

Map every boot component, signature, and trust boundary for a target OS.

Quick Reference

Attribute	Value
Difficulty	Level 2
Time Estimate	Weekend
Main Programming Language	Python (Alternatives: Bash, PowerShell)
Alternative Programming Languages	Bash, PowerShell
Coolness Level	Level 3
Business Potential	Level 2
Prerequisites	OS boot process basics, CLI usage
Key Topics	Boot chain, Secure Boot, trust boundaries

1. Learning Objectives

By completing this project, you will:

Enumerate boot components and signature metadata.
Document trust boundaries and boot insertion points.
Produce a boot chain diagram and evidence report.

2. All Theory Needed (Per-Concept Breakdown)

Boot Chain, Secure Boot, and Measured Trust

Fundamentals The boot chain is the sequence of components that initialize a system from firmware to kernel. Secure Boot establishes trust by verifying digital signatures on boot components, while Measured Boot records hashes of those components into a TPM for later attestation. Rootkits that target the boot chain (bootkits) aim to execute before the operating system, which lets them subvert the kernel before it can defend itself. A defender must know exactly which files and firmware stages participate in boot, which signatures are expected, and where trust transitions occur. Without this map, you cannot know what to baseline or where to look for tampering.

Deep Dive into the concept Modern systems rely on a multi-stage boot process. On UEFI systems, firmware verifies a bootloader image using Platform Key (PK), Key Exchange Keys (KEKs), and signature databases (db, dbx). The bootloader then loads the OS kernel and early drivers. Secure Boot prevents unsigned or revoked components from loading, but it does not guarantee the integrity of already-signed components if an attacker can replace them with other signed-but-malicious binaries or abuse vulnerable signed drivers. Measured Boot complements Secure Boot by recording hashes of each stage into TPM PCRs. This does not block boot; it enables post-boot validation by comparing PCR values to a known-good baseline.

Trust boundaries in the boot chain exist at each handoff: firmware trusts the bootloader, the bootloader trusts the kernel, and the kernel trusts early drivers. Attackers target these boundaries because a single compromised stage can persist across reboots and hide within normal boot flows. Bootkits often target the EFI System Partition (ESP), replacing or modifying bootloaders, or they modify boot configuration data to load a malicious component early. On legacy BIOS/MBR systems, the first sectors of disk are the attack surface. Because boot components are rarely observed by routine host tools, a defender must explicitly inventory them and measure them.

Practical defense requires three activities: mapping, baselining, and verification. Mapping is enumerating the exact files, partitions, and signatures involved in boot. Baselining is recording hashes and signature metadata for those components and storing the baseline offline. Verification is continuously comparing current boot components to the baseline and alerting on drift. When updates occur, the baseline must be updated in a controlled, audited workflow.

Secure Boot policy is only as strong as the enforcement of signature databases. If dbx revocations are outdated or if a platform allows custom keys without governance, attackers can introduce their own trusted components. Measured Boot adds accountability: if PCRs change unexpectedly, you know the boot chain differs. But measuring is not detecting; you must actually retrieve and compare measurements. Rootkit defense therefore depends on operationalizing those checks, not just enabling Secure Boot in firmware.

How this fit on projects You will apply this in Section 3.1 (What You Will Build), Section 3.5 (Data Formats), and Section 4.1 (High-Level Design). Also used in: P02-boot-chain-map, P08-boot-integrity-monitor, P19-secure-boot-policy-review, P13-bootkit-response-playbook.

Definitions & key terms

Boot chain: Ordered sequence of firmware, bootloader, kernel, and early drivers that start the OS.
Secure Boot: Signature verification that blocks untrusted boot components from loading.
Measured Boot: Recording hashes of boot components into TPM PCRs for later attestation.
Bootkit: Rootkit that compromises boot components to execute before the OS.

Mental model diagram

[UEFI Firmware]
   |  (verifies)
   v
[Bootloader] --(loads)--> [Kernel] --(loads)--> [Early Drivers]
   |
   v
[TPM PCR Measurements]
   |
   v
[Attestation / Baseline Compare]

How it works (step-by-step)

Firmware verifies bootloader signature using platform keys.
Bootloader loads kernel and early drivers; hashes are measured into TPM.
OS starts and reads boot configuration data and driver lists.
Defender tool compares current hashes and PCR values to a trusted baseline.
Any mismatch triggers investigation or containment.

Minimal concrete example

boot_component, path, signer, sha256
bootloader, \EFI\Microsoft\Boot\bootmgfw.efi, Microsoft, 9f...
kernel, C:\Windows\System32\ntoskrnl.exe, Microsoft, 4a...
boot_driver, C:\Windows\System32\drivers\elam.sys, Microsoft, c1...

Common misconceptions

“Secure Boot means no bootkits.” It reduces risk but does not prevent signed malicious components.
“Measured Boot blocks tampering.” It only measures; you must compare measurements.
“Boot integrity is a one-time check.” Updates and configuration changes require re-baselining.

Check-your-understanding questions

What is the difference between Secure Boot and Measured Boot?
Why is the ESP a common bootkit target?
What evidence proves a boot chain is unchanged?

Check-your-understanding answers

Secure Boot blocks untrusted components; Measured Boot records hashes for later validation.
The ESP contains bootloaders and configuration that execute before the OS; modifying it enables early execution.
Matching hashes or PCR measurements against a known-good baseline is strong evidence.

Real-world applications

Enterprise boot integrity baselining and compliance checks.
Incident response for suspected boot-level compromise.

Where you’ll apply it You will apply this in Section 3.1 (What You Will Build), Section 3.5 (Data Formats), and Section 4.1 (High-Level Design). Also used in: P02-boot-chain-map, P08-boot-integrity-monitor, P19-secure-boot-policy-review, P13-bootkit-response-playbook.

References

Microsoft Secure Boot documentation
NIST SP 800-147 (BIOS protection guidelines)
UEFI specification sections on Secure Boot

Key insights Boot integrity is a chain; the weakest or unmeasured link decides trust.

Summary Secure Boot verifies; Measured Boot records. You need both, plus baselines and monitoring.

Homework/Exercises to practice the concept

Enumerate the boot components on your OS and note their signature status.
Compare boot hashes before and after a system update.

Solutions to the homework/exercises

Your list should include firmware, bootloader, kernel, and early drivers with signer names.
After updates, at least one boot component hash should change; document it and update the baseline.

3. Project Specification

3.1 What You Will Build

A script and report that list firmware mode, bootloader paths, kernel image locations, and signature status, plus a diagram annotating trust boundaries and potential bootkit insertion points.

3.2 Functional Requirements

Detect firmware mode (UEFI/BIOS) and Secure Boot status.
Enumerate bootloader paths and kernel image locations.
Collect signature or hash metadata for each boot component.
Generate a diagram and a machine-readable report.

3.3 Non-Functional Requirements

Performance: Boot chain scan completes within 2 minutes.
Reliability: Paths are resolved deterministically across reboots.
Usability: Report is readable by security and operations teams.

3.4 Example Usage / Output

$ ./boot_chain_map.py --os windows --out reports/boot_chain.json
[boot] firmware: UEFI
[boot] secure_boot: enabled
[boot] bootloader: \EFI\Microsoft\Boot\bootmgfw.efi
[boot] kernel: C:\Windows\System32\ntoskrnl.exe

3.5 Data Formats / Schemas / Protocols

Boot chain JSON schema:

{ “firmware”: “UEFI”, “secure_boot”: true, “components”: [ {“stage”: “bootloader”, “path”: “\EFI\Microsoft\Boot\bootmgfw.efi”, “hash”: “9f…”}, {“stage”: “kernel”, “path”: “C:\Windows\System32\ntoskrnl.exe”, “hash”: “4a…”} ] }

3.6 Edge Cases

Legacy BIOS systems without EFI System Partition.
Dual-boot systems with multiple bootloaders.
Secure Boot disabled in firmware.
Bootloader paths stored in non-default locations.

3.7 Real World Outcome

A boot chain report and diagram that a responder can use to identify where a bootkit could persist.

3.7.1 How to Run (Copy/Paste)

./boot_chain_map.py --os windows --out reports/boot_chain.json

3.7.2 Golden Path Demo (Deterministic)

Report includes firmware mode, Secure Boot status, and bootloader paths.
Diagram labels trust boundaries between firmware, bootloader, and kernel.

3.7.3 Failure Demo

$ ./boot_chain_map.py --os windows --out /readonly/report.json
[error] cannot write report file
exit code: 2

Exit Codes:

0 success
2 report output error

4. Solution Architecture

4.1 High-Level Design

[OS Query] -> [Boot Component Resolver] -> [Signature/Hash Collector]
                               |                |
                               v                v
                          [Diagram]        [JSON Report]

4.2 Key Components

Component	Responsibility	Key Decisions
Firmware Detector	Identifies UEFI/BIOS and Secure Boot state	Use OS-native queries
Component Resolver	Finds bootloader and kernel paths	Support multiple OSes
Signature Collector	Collects hashes and signer metadata	SHA-256 baseline

4.3 Data Structures (No Full Code)

boot_component = { stage, path, hash, signer, version }

4.4 Algorithm Overview

Key Algorithm: Boot Component Discovery

Detect firmware mode and Secure Boot state.
Enumerate bootloader files and kernel image paths.
Hash each component and record signer metadata.
Emit report and render diagram.

Complexity Analysis:

Time: O(n) for n boot components.
Space: O(n) for report size.

5. Implementation Guide

5.1 Development Environment Setup

python3 -m venv .venv && source .venv/bin/activate
pip install pyyaml

5.2 Project Structure

boot-chain-map/
|-- src/
|   `-- boot_chain_map.py
|-- reports/
|-- diagrams/
`-- README.md

5.3 The Core Question You’re Answering

“Where does trust begin in the boot process, and where can a bootkit persist?”

A bootkit runs before your OS defenses, so you must know every step in the boot chain and how it is verified.

5.4 Concepts You Must Understand First

Secure Boot and Measured Boot
EFI System Partition structure
Boot configuration data and update workflows

5.5 Questions to Guide Your Design

Which boot components are signed and by whom?
How will you verify signatures or hashes?
Where are the trust boundaries in your OS boot flow?

5.6 Thinking Exercise

Draw a boot chain diagram and annotate each verification step.

5.7 The Interview Questions They’ll Ask

What is the difference between Secure Boot and Measured Boot?
Where do bootkits typically persist?
How do updates impact boot integrity baselines?

5.8 Hints in Layers

Hint 1: Start from firmware and trace to kernel.

Hint 2: Identify signature verification points.

Hint 3: Map boot files to the EFI System Partition.

Hint 4: Capture hashes before and after an update.

5.9 Books That Will Help

Topic	Book	Chapter
Boot process	Operating Systems: Three Easy Pieces	Boot chapters
Platform security	Windows Internals	Secure Boot sections

5.10 Implementation Phases

Phase 1: Discovery (2-3 days)

Goals:

Identify firmware mode and Secure Boot state.
Locate bootloader and kernel files.

Tasks:

Query firmware mode via OS tools.
Locate ESP and bootloader paths.

Checkpoint: Component list produced.

Phase 2: Reporting (2-3 days)

Goals:

Hash components and collect signer data.
Produce JSON report and diagram.

Tasks:

Compute hashes for each component.
Generate diagram with trust boundaries.

Checkpoint: Report and diagram match observed state.

Phase 3: Validation (1-2 days)

Goals:

Validate report against updates.
Document bootkit insertion points.

Tasks:

Re-run after a system update.
Note changes and update documentation.

Checkpoint: Drift accounted for and documented.

5.11 Key Implementation Decisions

Decision	Options	Recommendation	Rationale
Output format	JSON, YAML	JSON	Easier to diff and parse
Diagram format	ASCII, SVG	ASCII	Portable and easy to version

6. Testing Strategy

6.1 Test Categories

Category	Purpose	Examples
Unit Tests	Component resolution	ESP path parsing
Integration Tests	End-to-end scan	Firmware + bootloader + kernel
Edge Case Tests	Legacy BIOS	No ESP present

6.2 Critical Test Cases

UEFI and Secure Boot state detected correctly.
Bootloader path resolved and hashed.
Report contains deterministic component ordering.

6.3 Test Data

Use a known VM snapshot and confirm report matches manual inspection.

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall	Symptom	Solution
Missing ESP mount	Bootloader not found	Mount ESP and scan it
Multiple bootloaders	Confusing results	Include OS selection flag

7.2 Debugging Strategies

Validate ESP mount path and permissions.
Compare script output to manual bcdedit or efibootmgr outputs.

7.3 Performance Traps

Walking large partitions unnecessarily; restrict to boot-related paths.

8. Extensions & Challenges

8.1 Beginner Extensions

Add a Markdown summary report.
Include boot configuration file hashes.

8.2 Intermediate Extensions

Add Measured Boot PCR collection.
Support dual-boot detection.

8.3 Advanced Extensions

Integrate TPM attestation checks.
Add remote reporting for fleet-scale checks.

9. Real-World Connections

9.1 Industry Applications

Compliance audits for Secure Boot enforcement.
Incident response boot integrity assessments.

chipsec - firmware security assessment
osquery - boot state checks

9.3 Interview Relevance

Explaining boot chain trust boundaries.
Discussing Secure Boot limitations and drift.

10. Resources

10.1 Essential Reading

Microsoft Secure Boot documentation
UEFI specification sections on Secure Boot

10.2 Video Resources

Conference talks on boot security
Vendor webinars on Secure Boot

10.3 Tools & Documentation

bcdedit, efibootmgr documentation
TPM tooling references

Previous: P01-lab-isolation-snapshotting
Next: P03-integrity-baseline-builder

11. Self-Assessment Checklist

11.1 Understanding

I can explain the difference between Secure Boot and Measured Boot.
I can locate bootloader and kernel files on my OS.

11.2 Implementation

Boot chain report is generated and reproducible.
Diagram includes trust boundaries and insertion points.

11.3 Growth

I can explain how bootkits bypass certain checks.
I documented changes after system updates.

12. Submission / Completion Criteria

Minimum Viable Completion:

Report includes firmware mode, bootloader path, kernel path, and hashes.
Diagram created with trust boundaries.

Full Completion:

Measured Boot or TPM data added to report.

Excellence (Going Above & Beyond):

Automated baseline comparisons across multiple OSes.

Project 2: Boot Chain Map

Quick Reference

1. Learning Objectives

2. All Theory Needed (Per-Concept Breakdown)

Boot Chain, Secure Boot, and Measured Trust

3. Project Specification

3.1 What You Will Build

3.2 Functional Requirements

3.3 Non-Functional Requirements

3.4 Example Usage / Output

3.5 Data Formats / Schemas / Protocols

3.6 Edge Cases

3.7 Real World Outcome

3.7.1 How to Run (Copy/Paste)

3.7.2 Golden Path Demo (Deterministic)

3.7.3 Failure Demo

4. Solution Architecture

4.1 High-Level Design

4.2 Key Components

4.3 Data Structures (No Full Code)

4.4 Algorithm Overview

5. Implementation Guide

5.1 Development Environment Setup

5.2 Project Structure

5.3 The Core Question You’re Answering

5.4 Concepts You Must Understand First

5.5 Questions to Guide Your Design

5.6 Thinking Exercise

5.7 The Interview Questions They’ll Ask

5.8 Hints in Layers

5.9 Books That Will Help

5.10 Implementation Phases

Phase 1: Discovery (2-3 days)

Phase 2: Reporting (2-3 days)

Phase 3: Validation (1-2 days)

5.11 Key Implementation Decisions

6. Testing Strategy

6.1 Test Categories

6.2 Critical Test Cases

6.3 Test Data

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

7.2 Debugging Strategies

7.3 Performance Traps

8. Extensions & Challenges

8.1 Beginner Extensions

8.2 Intermediate Extensions

8.3 Advanced Extensions

9. Real-World Connections

9.1 Industry Applications

9.2 Related Open Source Projects

9.3 Interview Relevance

10. Resources

10.1 Essential Reading

10.2 Video Resources

10.3 Tools & Documentation

10.4 Related Projects in This Series

Next: P03-integrity-baseline-builder

11. Self-Assessment Checklist

11.1 Understanding

11.2 Implementation

11.3 Growth

12. Submission / Completion Criteria