Following my work on bypassing the Secure Boot feature of the RP2350 microcontroller using laser fault injection (see the relevant article for more details), I was honored to be invited to the 33rd edition of the DEFCON convention by Raspberry Pi.

There, I showcased my budget-friendly “Laser Fault Injection Platform” and gave two small talks discussing its design.

This short article provides access to some of the materials presented at the conference, including slides, and additional source code.

In August 2024, Raspberry Pi introduced the RP2350 microcontroller. This part iterates over the RP2040 and comes with numerous new features. These include security-related capabilities, such as a Secure Boot implementation.

A couple of days after this announcement, during DEFCON 2024, an interesting challenge targeted at these new features was launched: the RP2350 Hacking Challenge.

After some work and the development of a fully custom “Laser Fault Injection Platform”, I managed to beat this challenge and submitted my findings to Raspberry Pi.

This article will provide technical details about this custom platform, including manufacturing files for those interested in building their own. Additionally, I will explain how injecting a single laser-induced fault can bypass the Secure Boot feature of the RP2350.

In a previous article, the vulnerabilities of the ESP32-C3 and ESP32-C6 against side-channel attacks have been demonstrated.

Recovering enough key information to decrypt the external flash data is possible. However, a new attack needs to be performed for each new 128-byte block. Since attacking a single block takes hours, this makes decrypting the entire flash content using such a method very impractical.

This frustrating limitation led me to the following question: is it possible, given control of as few bytes of the flash as possible, to run custom code on a ESP32-C3 and ESP32-C6?

After encountering several dead-ends, I concluded that the answer to this question is yes, with:

• For the ESP32-C3, it requires control over the first 128 bytes (one block).
• For the ESP32-C6, it necessitates control over the first 128 bytes and a few bytes starting from offset 0x180 (two blocks).

Achieving the above demands bypassing the Secure Boot feature of both the ESP32-C3 and ESP32-C6. This is accomplished using simple voltage fault injections, despite the countermeasures that Espressif has integrated into its Boot Rom.

I recently read the Unlimited Results: Breaking Firmware Encryption of ESP32-V3 paper.

This paper is about breaking the firmware encryption feature of the ESP32 SoC using a Side-Channel attack.

This was an interesting read, and soon, I wanted to try to reproduce these results with the following constraints:

• To understand everything about this attack, I wanted to start from scratch, even if it meant sometimes reinventing the wheel.
• I wanted to keep things low-cost. This means no five-figure digital oscilloscope could be used, as it’s sometimes the case for such attacks.

A few weeks later, not only have I been able to reproduce the paper’s results regarding the ESP32, but I have also:

• Mounted a similar attack against the ESP32-C3 and ESP32-C6.
• Mounted a secure boot bypass attack based on voltage glitches for both the ESP32-C3 and ESP32-C6.

The first article will detail the side-channel attacks, starting from the basics. A second one will focus on Secure Boot bypass techniques.

As demonstrated in the previous articles of this website, I’ve always been interested in running my own code on consumer devices.

In this series of two articles, we’ll take a look at the well-known Google Home Mini.

To achieve this goal, we’ll have to go rather deep into the rabbit hole. Various topics and techniques will be explored.