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.

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.

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.

I received the Aura, a device advertised as a “Connected Alarm Clock”. This device in itself is quite cool and uses different sounds and color patterns to help the user fall asleep and wake him up during light stages of his sleep cycles.

Soon I was interested in doing some reverse engineering on it because:

• It was fun.
• I wanted to really own the device, I wanted to be able to run my own code on it.

This article describes my journey into the Aura, from firmware image grabbing to remote buffer overflow exploitation.