safemode.space
← All techniques
EX-0004
ST0004Execution

Compromise Boot Memory

Description

The attacker manipulates memory and configuration used in the earliest stages of boot so that their code runs before normal protections and integrity checks take hold. Targets include boot ROM vectors, first-stage/second-stage bootloaders, boot configuration words and strap pins, one-time-programmable (OTP) fuses, non-volatile images in flash/EEPROM, and scratch regions copied into RAM during cold start. Techniques range from replacing or patching boot images to flipping configuration bits that alter trust decisions (e.g., image selection, fallback order, watchdog behavior). Faults can be induced deliberately (timed power/clock/EM glitches) or via crafted update/write sequences that leave a partially programmed but executable state. Once resident, the modification can insert early hooks, disable or short-circuit checks, or select downgraded images; destructive variants corrupt the boot path to induce a persistent reset loop or safeing entry (a denial of service). Because boot logic initializes buses, memory maps, and handler tables, even small changes at this stage cascade, shaping how command handlers load, how keys and counters are initialized, and which peripherals are trusted for subsequent execution.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(d)
    addresses
    moderate
    derived

    Authentication of boot artefacts (signed bootloaders, hardware root of trust) is a manufacturer-side protection mechanism encompassed by (2)(d) access-control obligations.

  • craAnnex I, Part I, (2)(f)
    addresses
    high
    derived

    Integrity protection on programs and configurations is the manufacturer-side obligation that requires secure boot, measured boot and integrity-verified bootloader chains — the precise defense against pre-OS boot-memory compromise.

  • craAnnex I, Part II, (5)
    addresses
    moderate
    direct

    Flight-software exploitation handled through the secure-update channel (primary mapping: Annex I, Part II, (7) secure update distribution) presumes a CVD policy as the upstream intake; (5) supplements (7) by establishing how vulnerabilities reach the manufacturer in the first place.

  • craAnnex I, Part II, (7)
    addresses
    moderate
    derived

    Secure update-distribution mechanisms protect boot-stage code paths; the same provenance and integrity requirements that protect runtime updates apply to boot-image updates.

  • craAnnex I, Part II, (8)
    addresses
    moderate
    direct

    Flight-software exploitation handled through the secure-update channel (primary mapping: Part II, (7)) cascades to (8)'s timely-dissemination obligation — secure update distribution and dissemination-without-delay are paired.

  • eu-space-actArt. 76(4)
    addresses
    moderate
    direct

    Boot memory and OTP fuse configuration are decided at 76(4)(b)'s manufacturing and test phases — secure-boot and root-of-trust are lifecycle obligations of risk management measures across these phases.

  • eu-space-actArt. 84(2)
    addresses
    moderate
    inferred

    Art. 84(2)'s comply-with-Annex-VII-5.1 reference is domain-relevant to boot-chain compromise, but names no specific interdicting mechanism in the cited text; secure-boot signature verification would be the interdiction.

  • nis2Art. 21(2)(e)
    addresses
    high
    direct

    Bootloaders, OTP fuses, boot configuration words, and non-volatile boot images are network-and-information-systems development/maintenance artefacts; Art. 21(2)(e), including disclosed-vulnerability handling on those mechanisms, is the obligation that governs their integrity.

  • nis2Art. 21(2)(h)
    addresses
    high
    inferred

    Secure boot and anti-rollback are cryptographic mechanisms that interdict boot-image replacement and downgraded-image selection, but they do not reach the glitch-fault and configuration-bit-flip vectors that act before the signature check, where the operative control is boot integrity and fault resistance. The CIR (EU) 2024/2690 Annex assigns that control to section 6 (6.9; 6.4 change management), not to the section 9 cryptography requirements. At NIS2 Art. 21(2)(h) the relationship is addresses.

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Boot ROM images and bootloader keys are top-classification assets; their classification governs the strict storage and access controls that prevent the pre-runtime manipulation this technique requires.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Boot memory artefacts are produced in the secure-development life cycle; the rules for that lifecycle govern signing, integrity protection and storage of boot-stage components.

  • nis2-implAnnex 6.4.1
    addresses
    high
    derived

    Boot ROM, bootloader configuration and early-init code are managed under change-management procedures; the implementing regulation requires the entity to control modifications to these crown-jewel components.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i01
    mitigates
    moderate

    Configuration management of boot-configuration words, OTP fuses, and image-selection logic identifies unauthorized changes that EX-0004 introduces.

  • ENISA-STL-2025-03-sD.22-i02
    addresses
    moderate

    Tamper protection at shipping/receiving with physical inspection is relevant to the supply-chain vector of boot-memory compromise (pre-delivery image tampering), governing handling rather than actively defending the operational boot path.

  • ENISA-STL-2025-03-sD.25-i10
    addresses
    high

    Integrity-checking mechanisms covering programmable logic and firmware images directly defeat modifications to boot ROMs, bootloaders, and OTP fuses.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EX-0004 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.