Signed, but not verified.

Four vendors shipped secure boot with signature checks that never ran. We show the extraction, the patch, and the fix.

Secure boot is a chain. Every link has to hold, and every link has to actually be executed. In four of the six flight controllers we examined, the verification code was present, correct, and unreachable.

How verification goes missing

The pattern is the same each time. The primary boot path verifies. A secondary path — recovery, DFU, factory reset, or a vendor update mode — does not, because it was written first, or written by a different team, or written under a deadline.

if (boot_mode == BOOT_NORMAL) {
    if (!verify_signature(image)) fail();
}
jump_to(image);   /* every other boot_mode lands here */

That is a paraphrase, not a quote, but it is the shape of all four findings.

Extraction

• Locate the debug interface. On three of six it was populated on the production board.
• Dump flash. Two devices had read-out protection set; one of those could be reset by glitching the supply during boot.
• Identify the bootloader and the branch that reaches the image without verification.
• Sign nothing. Flash a modified image through the unverified path.

Why this matters for a manufacturer

Third-party assessment against defence supply-chain standards examines software integrity and secure boot specifically. A verification routine that exists but never runs will not survive that examination — and it will not survive an adversary with physical access to a downed aircraft.

The fix

• Verify in one place, before the jump, unconditionally. Not per boot mode.
• Enable read-out protection and test that it is actually set on production units.
• Treat recovery and DFU as the primary attack path, because they are.
• Add a boot-path test to CI that asserts an unsigned image is rejected in every mode.