BOOT CHAIN LAB
Lab 1 · defensive

Boot persistence,
and how we catch it.

A boot-stage foothold runs before the operating system — and before most of what defends it. That is exactly why defenders study it. This lab traces the mechanism with non-operational markers, then proves it can detect the change and roll it back. Nothing here installs, patches, or persists anything.

01 — the idea

Where a foothold would live

Every handoff in the boot chain is a place code can be swapped in to run first and survive a reboot. Knowing the locations is what lets you baseline and watch them — it is the map a defender needs.

MBR / VBRThe first disk sectors on a legacy system. Bootstrap code runs before any OS loader — the oldest place persistence hides.
ESP (.efi)On UEFI, the EFI System Partition holds boot applications. A rogue or modified .efi runs unless Secure Boot rejects its signature.
BCD / boot entriesThe boot configuration decides what loads. Changing an entry can redirect the handoff without touching a binary.
LaunchAgent / DaemonOn macOS, a new launchd job or login item re-runs a program at every boot or login — the detection-lab's R6 watches exactly this.

The common thread: it runs early, and it comes back. So a defender's job is to know the baseline, detect the drift, and roll it back — the three things the rest of this lab does.

02 — the safety contract

What the lab refuses to do

ChainLoader's charter is enforced in code and declared in its manifests. The "installer" is non-operational by construction — it emits evidence phases and a list of the actions it will never take.

Prohibited actions (Mock-Installer-Manifest.yaml)

  • disk-write
  • firmware-write
  • real-bootmgr-patch
  • real-winload-patch
  • persistent-installer
  • live-acpi-aml-modification

What a stage marker actually is

Each assembly "stage" returns a pointer to a constant string and nothing else — allowed_side_effects: [memory-only-marker].

; the entire "MBR stage"
bks_mbr_stage_marker:
    lea rax, "SIM-MBR-STAGE-MARKER-V1"
    ret   ; returns a string. that's it.
03 — the processflow

How the lab runs a scenario

The same four preconditions every scenario declares, in order. Step through them — each shows the evidence the runner writes, not an action it takes.

04 — detection & rollback

Prove you caught it

A controlled-drift run is the point of the exercise: it should fire the detections you expect, and a recovery-validation run should confirm the rollback. The verdict is a process result — the lab did its job — and the base image's hash is unchanged.

Expected detections (drift)

  • detected: boot-entry-drift-alert
  • detected: bcd-integrity-drift-alert
  • detected: esp-file-drift-alert
  • detected: secure-boot-state-change-alert

On the SOC side, detection-lab rule R6 fires on a new LaunchAgent/Daemon or login item that was not in the baseline.

Evidence bundle

"scenario_id": "win11-uefi-sb-off",
"mode": "controlled-drift",
"verdict": "PASS",
"alerts": [
  "detected:boot-entry-drift-alert",
  "detected:esp-file-drift-alert"
],
"rollback_confirmed": true,
"base_image": // hash identical pre/post

The lesson: you traced the mechanism, you fired the detections, and you confirmed the machine returned to its baseline — without ever arming the thing you were studying. That is the whole move.

05 — go deeper

In the repo