Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Microcontroller's require that the binary be loaded into the memory of the chip. On many production chips, it's important that this information cannot be read out. If it could, an attacker could steal industry secrets or secrets particular to the device, like cryptographic secrets. So, many chips disable the reading out of the chips flashed data altogether.

The STM32F1 series does not provide a feature to disable the debug interface (SWD), allowing it to continually be used but with the flash readout protections on. When initially testing how this worked they noticed that the reset halt command gave them information about the Program Counter (PC) with a valid address located in flash memory. How is the chip able to read out from this section?

When an exception is generated, like a halt, the processor loads the corresponding entry address from the vector table. This procedure is called vector fetch. Upon device reset, the vector table is located in flash memory even though the flash memory has read-out protection enabled. In the documentation of the manual, this is explained: the reset vector is fetched via the ICode bus similar to an instruction fetch which IS allowed. Can this be abused?

The initial idea is simple: use the vector table address information to leak the contents of the flash via the PC register. In the case of this device, it's possible to manually set the address of the Vector Table because debug access is not disabled. By changing this over and over again, triggering the particular exception and reading the PC once halted, we can leak the contents of the hidden flash!

Not all of the entries can be triggered though but there's a cool workaround. If the Vector table is unaligned and exceptions are generated with numbers greater than the vector table size then it wraps! Using this, it's possible to access contents that should normally not be accessible. Of course, this assumes that all exceptions can be triggered. The article explains how to trigger these. Even with this trick, not all data can be extracted though.

Overall, a small yet important observation led to a cool vulnerability. Great write up on the discovery and exploitation.