#KEYS TO THE KINGDOM INSTALL#
#KEYS TO THE KINGDOM SERIAL#
#KEYS TO THE KINGDOM UPDATE#
#KEYS TO THE KINGDOM PATCH#
#KEYS TO THE KINGDOM CODE#

This signaled to the thread that data was ready to process.

After receiving a FRAME END byte, the interrupt handler pushed a pointer to the filled buffer, as well as the length of the payload (as an unsigned 32-bit integer) into the protocol handler thread's work queue.

There was no check to make sure the input message did not exceed the length of one of these buffers. An array of eight of these buffers was allocated as one contiguous array.

As bytes arrive, the interrupt handler read out of a FIFO (first-in, first-out) hardware queue into a buffer until a FRAME END byte was received.

#KEYS TO THE KINGDOM SERIAL#

One universal asynchronous receiver/transmitter (UART), or serial port, exposed a framed command protocol.

#KEYS TO THE KINGDOM CODE#

The new code was a point from which to hunt for flaws in the communications protocol handling code the client claimed this code had not changed substantially.

#KEYS TO THE KINGDOM INSTALL#

All I had was the compiled release version of the firmware and a new version of the source code the client wanted to install on the deployed devices in the field. Since time was of the essence, and static analysis of the production binary would take a lot of time, I needed to find a quick path to code execution. Both the bootloader and the realtime operating system were used by many such projects. One fact worked in my favor, however: The firmware was built on top of open source components.

To make things even more challenging, release firmware images would not emit debugging log messages. Worse, I could not easily use a production device to test this (it could be done, but would have added a lot of time to the engagement-time the client could not afford), and the client went to great lengths to protect the device against firmware read-out, even disabling the Joint Test Action Group (JTAG) debug port. The client did not have the exact source code for the firmware shipped on the device, since the entire release was lost during the fat-fingering. Notably, there was nothing to ensure the bootloader wasn't modified. This microcontroller had no hardware root of trust, so the bootloader provided all of the firmware security features. The main microcontroller in the design included an off-the-shelf Arm Cortex-M3 core, with built-in flash and on-board RAM. The device in question has multiple serial ports that expose a variety of complex protocols once the client's application starts. Since the bootloader was hardened (so my client claimed), direct attacks on the firmware updater were out of the question.

#KEYS TO THE KINGDOM PATCH#

The task seemed straightforward: Find a way to patch a new static root of trust into the bootloader (a philosophical question: Is it that static?), thereby enabling the client to sign firmware updates with a new key. A reverse-engineering attempt was the final 'Hail Mary' effort before a recall would be necessary. The financial loss would be huge, and orchestrating such a program would be incredibly daunting. Given the sheer number of these devices in the field, as well as the cost per unit, a replacement program was the option of absolute last resort. How could they come up with a meaningful date? They had lost the ability to sign a new firmware release. Their customers were growing impatient, but my client had to stall when asked for a release date.

They had some exciting new features to ship, along with the usual host of reliability improvements.

The client was proud of how secure the design was after all, most consumer products at the time had barely figured out firmware readout protections.Īn unlucky fat-fingering precipitated the current crisis: The client had accidentally deleted the private key needed to sign new firmware updates.

#KEYS TO THE KINGDOM UPDATE#

They had even hardened their boot-loader to defend against anyone attacking the firmware update protocol directly-countermeasures against people like me. The client's engineers had attempted to build the right security features into their firmware: a bootloader that normally can't be updated, a static root of trust contained therein, and cryptographically signed binary firmware updates. These devices are driven by firmware running on a microcontroller that delivers robust wireless communications I knew this was my kind of job. Their latest creation had all the right security features, the best possible given their hardware constraints. This client builds embedded devices found in offices around the world. They needed someone to help them out of a jam-and fast. It was a warm, late summer afternoon when a long-time client called.

Keys to the kingdom