Cryptographic Automotive Software Handler and Bootloader (CrASHBoot)

Installation and development guide for the most secure (TM) automotive bootloader on the planet! We guarentee that cars running our software will be unhackable (provided hacking is not attempted). Of all the automotive bootloaders, this is certainly one of them. Read on and tremble at our embedded security skillz.

Team Cohesion's Solution

Our solution uses AES-GCM (Galois Counter Mode) with a 256-bit key. GCM handles confidentiality, integrity and authenticity all at once, provided the key is secured; at its core, this type of design allows for only one point of failure (i.e., the security of the key), which can compromoise the entire system. However, without access to the key, the attacker is effectively powerless to:

1. decrypt our data,
2. tamper with it, or
3. attempt to send their own, unauthorized data.

Our key is stored in microcontroller's flash memory (which, being non-volatile, means the key should persist through reboots of the device) – since debugging is disallowed, this should prevent basic dumping of the key from memory in GDB.

Internal Notes

//TODO: Make the design secure
//TODO: Hire interns
//TODO: Delete TODOs before publishing

I find myself trapped in the labyrinthine depths of my company, shackled by an unending torrent of menial tasks. My desk has become my prison, my workload, my jailer. I am buried under a mountain of code, my skills squandered on trivialities while critical applications do not get the attention they deserve. In a desperate attempt to keep up with the workload, I've had to rapidly create a functional, yet insecure, product. It's a risky move, one that fills me with dread. I haven't had the time to implement the necessary security goals of confidentiality, integrity, and authentication. If you are reading this: I implore you, proceed with caution. Do not release this software. It is potentially riddled with vulnerabilities and exposed to the most basic types of attacks.

Please, send help. I need to escape this relentless cycle. I need a team of talented interns to tackle this challenge. Otherwise, I fear the worst.

External Notes

Ship it!

Project Structure

├── bootloader *
│   ├── bin
│   │   ├── bootloader.bin
│   ├── src
│   │   ├── bootloader.c
│   │   ├── startup_gcc.c
│   ├── bootloader.ld
│   ├── Makefile
├── firmware
│   ├── bin
│   │   ├── firmware.bin
│   ├── lib
│   ├── src
├── lib
│   ├── driverlib
│   ├── inc
│   ├── uart
├── tools *
│   ├── bl_build.py
│   ├── fw_protect.py
│   ├── fw_update.py
│   ├── util.py
├── README.md

Directories marked with * are part of the CrASHBoot system

Bootloader

The bootloader directory contains source code that is compiled and loaded onto the TM4C microcontroller. The bootloader manages which firmware can be updated to the TM4C. When connected to the fw_update tool, the bootloader checks the version of the new firmware against the internal firmware version before accepting the new firmware.

The bootloader will also start the execution of the loaded vehicle firmware.

Tools

There are three python scripts in the tools directory which are used to:

1. Provision the bootloader (bl_build.py)
2. Package the firmware (fw_protect.py)
3. Update the firmware to a TM4C with a provisioned bootloader (fw_update.py)

bl_build.py

This script calls make in the bootloader directory.

fw_protect.py

This script bundles the version and release message with the firmware binary.

fw_update.py

This script opens a serial channel with the bootloader, then writes the firmware metadata and binary broken into data frames to the bootloader.

Building and Flashing the Bootloader

1. Enter the tools directory and run bl_build.py

cd ./tools
python bl_build.py

2. Flash the bootloader using lm4flash tool

sudo lm4flash ../bootloader/bin/bootloader.bin

Bundling and Updating Firmware

1. Enter the firmware directory and make the example firmware.

cd ./firmware
make

2. Enter the tools directory and run fw_protect.py

cd ../tools
python fw_protect.py --infile ../firmware/bin/firmware.bin --outfile firmware_protected.bin --version 2 --message "Firmware V2"

This creates a firmware bundle called firmware_protected.bin in the tools directory.

3. Reset the TM4C by pressig the RESET button

4. Run fw_update.py

python fw_update.py --firmware ./firmware_protected.bin

If the firmware bundle is accepted by the bootloader, the fw_update.py tool will report it wrote all frames successfully.

Additional firmwares can be updated by repeating steps 3 and 4, but only firmware versions higher than the one flashed to the board (or version 0) will be accepted.

Interacting with the Bootloader

Using the custom car-serial script:

car-serial

Using pyserial module:

python -m serial.tools.miniterm /dev/ttyACM0 115200

You can now interact with the bootloader and firmware! Type 'B' to boot.

Exit miniterm: Ctrl-] Exit picocom: Ctrl-A X

Launching the Debugger

Use OpenOCD with the configuration files for the board to get it into debug mode and open GDB server ports:

openocd -f /usr/share/openocd/scripts/interface/ti-icdi.cfg -f /usr/share/openocd/scripts/board/ti_ek-tm4c123gxl.cfg

Start GDB and connect to the main OpenOCD debug port:

gdb-multiarch -ex "target extended-remote localhost:3333" bootloader/bin/bootloader.axf

Go to main function and set a breakpoint

layout src
list main
break bootloader.c:50

Copyright 2024 The MITRE Corporation. ALL RIGHTS RESERVED
Approved for public release. Distribution unlimited 23-02181-25.