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.

After the work detailed in part 1, altering the content of the NAND Flash of the Google Home Mini with ease is now possible.

Despite this very privileged access, because of Google’s secure boot implementation, running arbitrary code on the CPU of the device isn’t possible using simple and naive methods.

However, as we’ll see, there is still a way.

This post will detail how I achieved code execution. It will require fuzzing, understanding some Linux code and finally exploiting a kernel bug.

Of course, NandBug, the hardware tool previously introduced, will be used.

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.

A couple of months ago, I spent some time fiddling around my ISP-provided residential gateway. This gateway is actually not just a gateway. It’s more like a mix between a set-top Box and a gateway. Additionally, to access the Internet, the end-user can also use it to watch TV through the HDMI output of the device.

I actually went quite far, and I’ve found a couple of interesting things.

This post won’t go through all of my findings. Instead, I’ll focus on the most “unusual”, educational and interesting one. I’ve indeed found a rather creative way of bypassing (under certain conditions) the WPA2 protection of the gateway’s hotspot. This will involve reverse-engineering, electronics, desoldering things, microcontrollers, and even Software Defined Radio.

Finding and exploiting this flaw allowed me to write a bunch of general purpose tools and even to contribute to the radare2 project. I’m releasing my code along with this article. Hopefully, someone may find it useful.