STM32F407 Secure Bootloader Demo

This repository contains a two-image firmware setup for STM32F407G-DISC1:

• f4_bootloader: first-stage bootloader at flash base 0x08000000
• f4_app: application image relocated to 0x08004000

Current implementation includes robust jump handoff and phase-1 secure image validation (fixed header + SHA-256 integrity check).

Hardware

• Board: STM32F407G-DISC1
• UART debug: USART2 (PA2=TX, PA3=RX)
• FTDI wiring:
  • FTDI RXD -> PA2
  • FTDI TXD -> PA3
  • FTDI GND -> GND
• USER button: blue button (PA0)
• Reset button: black button (NRST)

Flash Layout

• Bootloader: 0x08000000 -> 0x08003FFF (16 KB, sector 0)
• App slot: 0x08004000 -> 0x080FFFFF (remaining flash)

Repository Structure

• f4_bootloader/ - STM32CubeIDE bootloader project
• f4_app/ - STM32CubeIDE app project
• tools/sign_f4_app.py - post-build app signing/hash tool

Current Security Scope (Phase 1)

Bootloader jump is allowed only when all checks pass:

1. App header magic and header_version are valid.
2. App image size is in slot bounds.
3. Vector table values are structurally valid:
   • MSP in SRAM range
   • reset handler in flash, Thumb mode, and in image range
4. SHA-256 over app image matches hash stored in header.

App header is placed at fixed address APP_BASE + 0x200 (0x08004200).

Prerequisites

• STM32CubeIDE (tested with 1.18.1)
• GNU Arm toolchain from STM32CubeIDE
• ST-LINK connection for flashing/debugging

Build

Build both projects in STM32CubeIDE (Debug configuration):

1. Build f4_app
2. Build f4_bootloader

Signing the App Image

After building f4_app, generate signed app artifacts:

python C:\STM_Exps\tools\sign_f4_app.py `
  --input-elf C:\STM_Exps\f4_app\Debug\f4_app.elf `
  --output-bin C:\STM_Exps\f4_app\Debug\f4_app_signed.bin `
  --output-hex C:\STM_Exps\f4_app\Debug\f4_app_signed.hex

Output:

• f4_app_signed.bin
• f4_app_signed.hex

Flashing Sequence

1. Program f4_bootloader image (base 0x08000000).
2. Program f4_app_signed.hex (app slot at 0x08004000).
3. Open serial terminal on COM10, 115200 8N1.
4. Press black reset button.

Runtime Behavior

Bootloader behavior:

• Blue button held during reset -> stay in bootloader (force_boot=1)
• Blue button not held + valid signed app -> jump to app
• Invalid app -> stay in bootloader

Expected logs:

• Boot mode:
  • BOOT: ... force_boot=1 app_valid=1 ...
  • BOOT: staying in bootloader
  • BOOT: waiting...
• App mode:
  • BOOT: ... force_boot=0 app_valid=1 ...
  • BOOT: jumping to app
  • APP: startup at 0x08004000
  • APP: running

Boot Validation Error Codes

err=<n> in boot logs maps to:

• 1 bad app magic
• 2 bad header version
• 3 invalid image size
• 4 invalid MSP
• 5 invalid reset vector/range
• 6 SHA-256 mismatch

Common gotchas

• If you flash plain f4_app.elf without signing, bootloader is expected to reject app hash validation.
• If you run f4_app directly from debugger, you bypass bootloader checks.