GigaVulnerability: readout protection bypass on GigaDevice GD32 MCUs

Disclaimer. This article is for informational purposes only and is not intended to instruct or encourage any illegal activity. Our goal is to describe the existing vulnerabilities that can be exploited by attackers, to warn users, and to provide recommendations on how to protect their personal information online. The authors are not responsible for how the information is used. Remember to always prioritize the security of your personal data.

When developing hardware solutions based on microcontrollers (MCUs), manufacturers seek to protect their firmware from falling into the hands of attackers, because it may contain sensitive information, encryption keys, unique valuable algorithms, and so on. To achieve this, most microcontrollers implement flash memory readout protection technologies. But do they really provide sufficient protection?

Unfortunately, no. Not all readout protection technologies work as intended. Vulnerabilities in debug interfaces, non-trivial fault injection attacks, and even invasive tampering can be exploited to bypass the protection.

At Positive Labs, we conduct security research on a wide variety of hardware. So when a device based on GigaDevice’s GD32 microcontroller fell into our hands, we found ourselves investigating its protection technologies before we knew it. GD32 microcontrollers are quite popular and are used everywhere, including as replacements for STM32 microcontrollers, as they are often pin-compatible and even share the same memory address map. The research turned out to be quite fascinating, and the results were impressive!

Readout protection: what is it and how it works

Readout protection technologies go by different names. For example, STMicroelectronics calls it Readout Protection, or RDP, in nRF microcontrollers it’s known as APPROTECT; and for GigaDevice it’s called Security Protection. Further in this article, we will talk about Security Protection, but we will use the name Readout Protection (or RDP) because it is more widely used and best conveys the essence of the technology.

The operating principles of these technologies are very similar, despite their different names. All of these technologies implement multiple protection levels, each imposing its own restrictions:

• RDP0 (level 0, no protection). No restrictions are imposed. In this state, microcontrollers are delivered to developers — they can be freely programmed and debugged.
• RDP1 (level 1, low protection). At this level, access to flash memory is blocked when a debugger is connected. However, the contents of the SRAM generally remain accessible for reading and writing via the debugger. This level can be downgraded, but doing so will erase the flash memory contents. For some microcontrollers, this level of protection is the maximum available.
• RDP2 (level 2, high protection). At this level, the debug interface is typically permanently disabled, and the possibility of booting via the built-in bootloader (used for programming) and accessing the SRAM is also disabled. As a result, the ability to interact with the microcontroller or influence its execution is significantly reduced. Moreover, this level cannot be downgraded, meaning the microcontroller cannot be repurposed for other uses.

Usually, the current protection level is determined by the value of a specific byte that is physically stored in the same flash memory cells (in the Option Bytes area) where the microcontroller firmware is located, but the method of programming this byte varies.

Before moving on, it’s worth talking about some known techniques for bypassing readout protection on various microcontrollers. This will help understanding the general approaches available. Moreover, some well-known techniques have proven useful and were applied in our research. In our opinion, to fully immerse oneself in the topic, one should review the two studies by Johannes Obermeier and his co-authors, along with related materials. Below is an overview based on them.

Shedding too much light on a microcontroller’s firmware protection

Here you can find a Johannes Obermeier’s STM32F0 research. In this research, three techniques are described: Cold-Boot Stepping (CBS), RDP2 downgrade and exploitation of debug interface vulnerabilities.

As we noted before, at the low level (RDP1), a SRAM content is typically accessible. During development, it’s necessary to take this into account and try to clear the SRAM contents of secrets as soon as possible. In some cases, however, even this will not suffice. The Cold-Boot Stepping (CBS) technique allows one to obtain a set of intermediate SRAM states with high precision—even down to the state after each instruction.

For example, the researchers describe a case where firmware integrity is verified using the CRC32 algorithm. By intercepting all intermediate CRC32 values with the CBS technique, it is possible to fully reconstruct the firmware content.

The second technique is an example of an invasive attack that requires access to the chip’s internals. The researchers used acid to gain access to the crystal inside the microcontroller. By exposing memory cells to ultraviolet rays of a specific wavelength, they were able to alter the byte responsible for the protection level. As a result, the protection level was reduced from RDP2 to RDP1. This attack is quite complex, as it requires the researcher to have knowledge of chemistry, memory cell physics, and crystal structure, and the process of etching the chip’s package should ideally be performed in a specialized laboratory.

The last technique demonstrated in the research exploits a vulnerability via the debug interface at RDP1. The researchers found that flash memory locking occurs upon the first access to the bus via SWD, and if that access is a flash memory read, there is a chance to obtain the read result. For the exploitation, the researchers used a different STM32 microcontroller as the attacking device. There are ported projects available for alternative microcontrollers (for example, RP2040). Additionally, note that the attack works on some other microcontrollers (not only STM32). If an attack board is not available to implement the attacking device, one can make do with a J-Link paired with OpenOCD and a software-controlled relay.

Thus, the researchers demonstrated that the protection of the STM32F0 can be completely bypassed regardless of the set RDP level. The attack on RDP1 is very easy to implement, which cannot be said for the invasive attack on RDP2.

One exploit to rule them all? On the security of drop-in replacement and counterfeit microcontrollers

The research itself and its materials can be found here.

The main focus of the research was on the STM32F1 microcontrollers and its clones, including those from GigaDevice. The research demonstrates various techniques for bypassing RDP1 via the debug interface, an invasive attack on RDP2, and a voltage glitch technique to bypass RDP1. More details on each method can be found in the original source. For now, we will only discuss those most critical to our research.

Access to the flash memory controller (FMC) can be gained through various means as shown in the block diagram above: the core has direct access to the FMC via the instruction and data buses. In addition, the FMC is connected to the AHB bus, and the bus master devices (the core, DMA engine) can initiate flash memory operations. Many well-known attacks are possible because not all of these methods of accessing the flash memory are accounted for when the lock is activated. In some microcontrollers, RDP1 does not block the core’s access via the instruction and data buses, which allows the flash memory content to be obtained using load instructions. Sometimes, only access via the instruction bus remains possible, in which case a security researcher can retrieve the flash memory contents by manipulating the vector table offset register (VTOR) and manually triggering various interrupts, as detailed in the “Exception(al) Failure — Breaking the STM32F1 Read-Out Protection” research. In the case of the GD32F103, the possibility of an attack by copying the flash memory content into SRAM via the DMA engine using a debugger is demonstrated. The idea of using the DMA engine proved useful in our research when exploiting one of the vulnerabilities.

Let’s take a look at the invasive attack on the GD32F103/GD32F130 chips. In this attack, the researchers exploit the microcontroller’s multi-chip structure.

As shown in the diagram, the microcontroller consists of a logic crystal and a flash memory crystal, connected by bonding wires, which can be accessed using a polishing sheet. In our opinion, this is simpler than the chemical decapsulation described earlier, but it still requires certain skills. The researchers discovered that the flash memory communicates using the QSPI protocol, through which, after a power-on reset, the following are read: factory configuration, built-in bootloader, Option Bytes, and part of the firmware. The read data is apparently cached for faster access later. This information about the primary initialization process also proved very useful. Based on this, we were able to make some assumptions about how the vulnerabilities we discovered operate at a lower level.

Finally, let’s talk briefly about fault injection attacks. It seems that, along with invasive attacks, these are the last resort for a potential attacker to bypass readout protection, especially in RDP2, when the debug interface is inaccessible and the attack surface is considerably reduced. In the discussed work, the researchers managed to use a voltage glitch to reset the flash memory lock state after connecting the debugger, while not losing the pre-prepared SRAM content needed for subsequent attack stages. This attack targets RDP1, but there are numerous successful examples of lowering RDP2 and enabling the debug interface using voltage glitches:

• nRF52 Debug Resurrection (APPROTECT Bypass). An example of bypassing the APPROTECT technology in nRF52 to gain access to the debug interface and flash memory.
• wallet.fail — Hacking the most popular cryptocurrency hardware wallets. This research examines the security of popular crypto wallets and various attacks against them. One of the cases is the Trezor wallet based on STM32F2/4. By applying a voltage glitch, the researchers successfully