GhostBus

The brief

The vendor insists the secure element is locked and the sealed region cannot be read. A field engineer probed the hub's internal UART bus between the MCU and the secure element, and separately dumped the hub's external SPI NOR flash. Recover the hidden read, reverse the key derivation and open the sealed region. No brute force needed: all crypto is standard, and every byte you need is in the provided evidence.

• ghost_bus.zip, 48 KB

In short

A smart lock hub kept a 48 byte sealed record in its flash. Its secure element sent the record nonce in clear over the internal UART, and the firmware built the AES key from that nonce and one constant. The lab joined the three pieces and decrypted the record.

Three files from one hub

The lab had three files from one smart lock hub. One captures the UART between the MCU and its secure element, one is a 1 MiB dump of the SPI flash, and one is the MCU firmware.

The nonce crossed the wire in clear

Decoded at 115,200 baud, each frame is AA 55, a length, a command, the payload and a CRC16. The hub sent command 0x10, and the secure element answered with the 16 byte record nonce. Every CRC checks out.

48 sealed bytes at 0x6A000

The board metadata at 0x7F000 names the sealed region, 48 bytes at 0x6A000. There the lab found three AES blocks of ciphertext, followed by the marker SEALED v2.

The key recipe in the firmware

The firmware hashes a 24 byte constant from its read only data, then the nonce, with SHA-256. The first 16 bytes of that digest are the AES-128 key, and the nonce doubles as the IV.

Swap every word, then CBC

Before decrypting, the firmware reverses the bytes of every 32 bit word, then runs AES in CBC mode. The lab confirmed both by running the firmware's own routines. Out came 41 flag bytes and 7 bytes of padding, an exact fit.

The insight

The locked secure element guarded nothing. It sent the nonce over the wire in clear, and the only other key input was a constant in the firmware.

The flag

hiCTF{gh0st_bu5_uart_n0nc3_r3v3al_9c3f12}