This new post presents a hardware exploit to unlock the debug port on the EFM32 Gecko MCUs Series 1 designed by Silicon Labs.

Once again, after the previous nRF52 episode, this security research reveals an entire range of products vulnerable to a silicon design vulnerability.

The way to unlock these chips was quite challenging and required the development of an home-made EM Injection System, der Injektor.

Intro

Silabs

Silicon Labs aka Silabs is a semiconductor company specialised in ultra-low power consumption MCUs and Wireless SoCs.

They offers several product lines of 32-bits MCUs, identified by different species of Geckos. Understanding the convention name between the different Silicon Labs chipsets represents the first challenge.

EFM32

The EFM32 family is targeted toward applications and industry segments that require ultra-low power, high memory and connectivity, and stable life cycles. These chipsets are designed using 180nm or 90nm Mixed-Signal CMOS process technologies.

EFM32 consists of a number of sub-families, according to the wiki:

That represents a lot of devices to analyse/hack, from the EFM32 Zero Gecko based on Cortex-M0+ to the higher performing EFM32 Wonder Gecko based on Cortex-M4.

EFM32 applications include the following:

• Energy, gas, water and smart metering
• Health and fitness applications
• Smart accessories
• Alarm and security systems
• Industrial and home automation

Longevity Commitment

Silicon Labs targets a minimum 10-year life cycle for all members of its EFM32 family of ARM Cortex-M microcontrollers. The minimum longevity is set to March 2026.

The selected Target: EFM32WG

The EFM32 Wonder Gecko is one of the latest Silabs MCUs, based on Cortex-M4.
The data sheet is available here and the simplified architecture block diagram is shown below:

Debug Lock

Of course, Silabs has implemented a debug protection mechanism, called Authentication Access Port (AAP).

This mechanism protects an attacker having physical access to connect to the Serial Wire Debug (SWD) Interface, in order to dump the firmware and start reverse-engineering.

Authentication Access Port (AAP)

The Authentication Access Port (AAP) mechanism is illustrated below:

Lockbits

The Lock bits are located in Flash at 0x0FE04000.

The AAP is activated (debug locked) by clearing the Debug Lock Word (DLW) and resetting the device.

Word 127 is the debug lock word (DLW). The four LSBs [3:0] of this word are the debug lock bits. If these bits are 0xF, then debug access is enabled. If the bits are not 0xF, then debug access to the core is locked.

This design seems familiar…

Coincidence with nRF52? I don’t think so…

In term of design, this AAP mechanism from Silabs is similar to the Nordic nRF52 APPROTECT.

Is EFM32 vulnerable to debug resurrection attack too?

Somehow, the vulnerability would be spread across different silicon vendors during the design of several MCU families.
This is quite cool. Two main potential reasons for that:

• ARM IPs distributed to different silicon vendors contains the design vulnerability.
• or some EFM32 Engineers from Energy Micro before/after being acquired by Silabs moved later to Nordic Semiconductors to design the nRF52. (just an assumption).

Test environment

EFM32WG-STK3800

I need a dev-kit, so 100$ later:

The user guide is available here. The exact reference of the chipset is EFM32WG990F256, with 256 KB Flash and 32 KB RAM.
An integrated Segger J-Link debugger is present (under the LCD screen). That will make the setup simpler.

Silabs IDE

I install Simplicity studio 5, in order to be able to compile and flash easily the micro-controller present on the dev-kit.

This IDE is quite easy to use, detecting automatically the dev-kit and the target. It provides a lot of demo codes.

I choose a random blink_led project, compile and flash the target. The led is blinking, I am satisfied.

Commander

The commander tool offers command line interface to lock the debug (graphic interface is also available).

Enabling the AAP:

$ ./commander device lock

Once locked, OpenOCD cannot connect to the target:

Disabling the AAP (if needed):

$ ./commander device unlock 

The unlock command will erase the full content of the Flash memory.

Starting the analysis

EFM32 Power network

The manufacturer does not provide a lot of details regarding the power network. The reference manual presents an high-level diagram:

Brown-out Detectors (BOD) are present on the power lines VDD, VDD_REGULATED, Analog VDD.

The schematics found in the IDE installation folders corresponds to the old board revision (the same than the dev-kit picture). Nevertheless, It is still helpful:

The DECOUPLE Pin draws my attention.

PCB modification

I remove some capacitors and decide to solder a wire on the DECOUPLE pin (DEC), which is I guess the connection for the decoupling capacitor of the Digital Domain.

The chip is acting normally after these modifications, I can see the led is still blinking. (always important to have this kind of visual indicator).

Power Consumption

Instead of using the USB or the AEM Mode, I connect the Battery Pins to a linear supply voltage. I set the board to the lowest limit of the VMCU (around 2V).

The EFM32 is ultra-low power MCU and analysing its power consumption requires an higher resolution scope (I am a little bit limited by my MSO5074 in this case..)

But LR made some investments recently:

• Low Noise Amplifier 90$
• DC blocker 25$

With this upgrade, monitoring the signal on DEC offers much more details:

A timing window (approximately 50us) is defined (red frame), in order to perform the fault injection during the AAP process execution.

Likewise, this is matching with some information I found previously during my analysis. When an EFM32 is reset, there is a small window where a module called Authentication Access Port (AAP) is connected to the debug interface. This window is 47 µs long and occurs right before the core starts executing code.

Hacking Strategy

The strategy stays the same then the one on nRF52.

I will achieve a fault injection during the initialisation of the AAP in order to keep the debug port on the whole-bus system (AHB-AP) alive, bypassing/modifying the AAP configuration, and allow the external debugger to connect to the CPU.

When Voltage Glitching fails…

Once I connect the PocketGlitcher to the EFM32 DEC line, I quickly understand the BODs are really effective. Any glitch attempts leads to a hard reset:

BOD

According to the reference manual, the EFM32WG has 4 brownout detectors, one for the unregulated 3.0 V power, one for the regulated internal power, one for Analog Power Domain 0 (AVDD0), and one for Analog Power Domain 1 (AVDD1). The BODs are constantly monitoring the voltages and they are pretty well configured.

I spent one evening to characterize them, I can say they are the most efficient BODs I have seen so far on consumer-grade MCUs.

So, the vulnerability is here but I just cannot exploit it.

…Use the ElectroMagnetic way

To bypass the BODs, my last hope is to use EM Fault Injection (EMFI).

There are some existing systems on the market like ChipShouter. Very good feedbacks from the HW Hacking community since the release, but it is still considered as a professional equipment and LR cannot afford it.
Also, Ledger Donjon wrote a paper at the beginning of the year about a Compact EMFI setup (but they didn’t release the full design and schematics afaik).

In the context of embedded security, I believe EMFI can be achieved at very low price, with an equivalent budget than voltage glitching.

Der Injektor by LR

I work since a little bit of time on a low-cost EMFI solution and I think it is the right moment to see it in action. It generates powerful and short EM Pulse, which can be triggered on demand.

The architecture is the following:

I started prototyping few times ago and I can share the technical characteristics below:

• Maximum Voltage 750V (safety first)
• Voltage input 0.5V to 3.3V
• Variable pulse width 20ns – 200 ns
• Jitter < 100ns

Prototype setup below:

Note: I will probably share more details in a future post, I am working on a release version for the end of the year. Contact me if you are interested.

EMFI Debug Resurrection on EFM32

Due to the high efficiency of the BODs, I need to produce very localised eddy currents to inject a fault. So I select one of my tiniest hand-made coil probe (2.5mm diameter).

The spatial position is a crucial parameter for EMFI and has to be added to the equation of the parameters’ optimisation, (not easy here because I don’t even use a precision XYZ stage, but I found some tricks…)

I am now targeting the previous identified 50us timing window by injecting the EM pulse at each boot-up. Here is successful EMFI attempt, leading to debug resurrection:

On the terminal, OpenOCD proposes to connect to the efm32 target, identifying breakpoint and watchpoints common to Cortex-M:

EFM32 is unlocked. Mission accomplished. Dumped Firmware is legit, I can compare 🙂

This attack also validates the capabilities of my new contactless Fault Injection system, der Injektor.

Conclusion

In this post, LimitedResults proved the debug protection on EFM32, called Authentication Access Port (AAP), can be unlocked via an ElectroMagnectic Fault Injection (EMFI) attack. The PoC was achieved on the EFM32 Wonder Gecko dev-kit (STK-3800).

All the Geckos based on Cortex-M0+, Cortex-M3 and Cortex-M4 implements the AAP block to protect the debug interface, so they are likely impacted by this attack.

The cost of the home-made injector is around 50$ and brings definitely Low-cost EMFI attack into the limited world.

Time Disclosure

On their vulnerability disclosure policy, Silicon Labs clearly indicates that they don’t compensate security researchers for their findings.

2021-06-08: LR contacts Silabs PSIRT.

2021-06-09: Silabs PSIRT answers.

2021-06-22: Posted.

[UPDATE] 2021-06-26: Silabs shared Security Advisory A-00000310 through their Customer portal. 
Subject: Debug port lock state is susceptible to fault injection attacks.
CVSS Severity: Medium (Base Score 6.8).