Blogs on Raelize - Embedded Device Security Services Consultancy Testing Research Training

Google Wifi Pro: Glitching from Root to EL3

Thu, 17 Jul 2025 09:00:00 +0200

In this third blog post, we will explain in detail, how we were able get arbitrary code execution at EL3 leveraging the arbitrary write.

Google Wifi Pro Glitching from Root to EL3

Wed, 16 Jul 2025 09:00:00 +0200

In this second post, we explain in detail, how we used a single EM glitch to read and write a 32-bit value from/to an arbitrary address.

Google Wifi Pro: Glitching from Root to EL3

Tue, 15 Jul 2025 09:00:00 +0200

In this first post, we explain in detail, how we were able to inject EM glitches in order to characterize Qualcomm’s IPQ5018 SoC susceptibility to EM glitches.

Espressif ESP32

Wed, 18 Jun 2025 08:00:00 +0200

In this blog post, we describe our adventure(s) reproducing our EMFI attack on Espressif’s ESP32 using Crowbar glitches.

Measuring Billions of Traces Per Day using Segmented Memory

Mon, 03 Apr 2023 20:00:00 +0200

Side Channel Analysis (SCA) attacks generally speaking consisting of three phases: acquisition, pre-processing and analysis. The time it takes to extract a key from an embedded devices is the sum of these three phases combined. In our previous blog posts about Power Analysis and Electromagnetic Analysis, we discussed how we extracted the key from the ESP32’s hardware AES accelerator. In this blog post we discuss in more details how we were able to perform a super fast acquisition using our Piscoscope oscilloscope.

Espressif ESP32: Glitching The OTP Data Transfer

Fri, 10 Mar 2023 12:00:00 +0200

Modern System-on-Chips (SoCs) include security critical features which are often configured securely using One-Time Programmable (OTP) bits, often implemented using electronic fuses (i.e., eFuses). Most SoCs will transfer these configuration bits from OTP memory to dedicated shadow registers from where they will be consumed by either hardware modules (e.g. cryptographic engines) or software (e.g. ROM code). These bits must be transferred correctly during boot to ensure the SoC is configured as intended. This mechanism is referred to by us in the remainder of this blog post as the OTP Data Transfer or simply the OTP Transfer. When the OTP Transfer is completed, the SoC is assumed to operate as expected, according to the supplied (security) configuration. However, what if we can break this fundamental assumption?

Espressif ESP32: Breaking HW AES with Electromagnetic Analysis

Thu, 02 Mar 2023 22:00:00 +0100

In our previous blog post, we’ve shown how we extracted the secret key from the ESP32’s hardware AES accelerator using a Power Analysis attack. In this blog post, we measure the electromagnetic emissions from the chip in order to extract the same secret key.

Important, please read our previous blog post on power analysis first if you have not done that yet. Espressif released an advisory after Ledger demonstrated the hardware AES accelerator of the ESP32 chip is vulnerable.

Espressif ESP32: Breaking HW AES with Power Analysis

Fri, 24 Feb 2023 22:00:00 +0100

Side Channel Analysis (SCA) attacks are commonly used for extracting the secret key of cryptographic engines found in modern devices. They exploit side channels, such as Timing, Power and Electromagnetic (EM) leaks, to obtain information about the secret key used by the cryptography algorithm. Even though these type of attacks were traditionally performed on smart cards, they are effective on embedded devices as well.

Even the strongest cryptography algorithms, such as AES, are susceptible to SCA attacks, especially if no countermeasures are in place. That’s why, Ledger Dojon’s discovery that the key used by the flash encryption feature of the ESP32 chip could be extracted through a power analysis attack, was not surprising. Nonetheless, their in-depth research is very cool and we definitely recommend to watch their Black Hat presentation and read their paper. Espressif released an advisory related to their research results.

Vulnerable tzdemuxerservice TA on Samsung TVs (J-series)

Mon, 01 Nov 2021 17:00:00 +0200

We often analyze the security of devices that implement a Trusted Execution Environment (TEE) and the information described in this post is a result of that. One of the goals of a Trusted Execution Environment (TEE) is to provide an environment for the secure execution of Trusted Applications (TAs).

The source code for a TA is rarely available for attackers and often only the binary code is available. As always, there are several exceptions like the default TAs provided by OP-TEE, an open-source TEE OS, and the TAs available for the Ledger hardware wallet which is used for storing cryptocurrencies securely.

Qualcomm IPQ40xx: Achieving QSEE Code Execution

Mon, 14 Jun 2021 10:00:00 +0200

In this post we finally dive into our approach for exploiting the vulnerabilities we’ve identified in QSEE, Qualcomm’s Trusted Execution Environment (TEE), on Qualcomm IPQ40xx-based devices (see post #1 and post #2). This allowed us to achieve arbitrary code execution in the context of QSEE.

Interestingly, the exploitation approach described in this post can also be used for the with the Electromagnetic Fault Injection (EMFI) attack we performed as well (see post #3). This allows achieving code execution in absence of any software vulnerability.

Qualcomm IPQ40xx: Breaking into QSEE using Fault Injection

Mon, 07 Jun 2021 11:00:00 +0200

We’ve identified multiple critical software vulnerabilities in QSEE, Qualcomm’s Trusted Execution Environment (TEE), on Qualcomm IPQ40xx-based devices (see post #1 and post #2). We exploited these vulnerabilities in order to disable the secure range checks performed by QSEE in order to execute arbitrary code at the highest privilege (see post #4). As these vulnerabilities are software vulnerabilities, they were easily fixed by Qualcomm after we disclosed them responsibly.

As you may have already raelized, at Raelize we like to look further than just software vulnerabilities. Therefore, we decided to analyze the resilience of the Qualcomm IPQ40xx-family of chip towards Electromagnetic Fault Injection (EMFI). We used the Linksys EA8300 WiFi router (see post #2).

Qualcomm IPQ40xx: Analysis of Critical QSEE Vulnerabilities

Tue, 02 Mar 2021 16:00:00 +0200

It’s time to get technical! In our previous blog post we notified you already about the vulnerabilities we identified in Qualcomm’s Secure Execution Environment (QSEE). This Trusted Execution Environment (TEE) is found on many Qualcomm-based devices like mobile phones. The vulnerabilities we identified are applicable to (most) devices that are designed around the Qualcomm IPQ40xx SoC family, which is used by major manufacturers like Linksys, Netgear and Cisco. Qualcomm disclosed these vulnerabilities publicly during their January 2021 Security Bulletin after our coordinated disclosure process was finished.

Qualcomm IPQ40xx: An Unexpected Cup of TEE

Mon, 15 Feb 2021 14:00:00 +0200

The Qualcomm IPQ40xx family of chips, which includes the IPQ4018, IPQ4019, IPQ4028 and IPQ4029, are popular System-on-Chip (SoC) solutions for consumer and enterprise networking products. Many devices like the ASUS RT-AC58U, Cisco Meraki MR33 and Aruba AP-365 use an IPQ40xx chip as the main System-on-Chip (SoC) in their design. The OpenWRT Project supported device database shows at least 34 products, manufactured between 2018 and 2020, that are designed around a IPQ40xx chip. The total number of products is likely much larger as many devices, like the Netgear Orbi RB20, are not supported by OpenWRT and therefore not included in the database.

Espressif ESP32: Bypassing Encrypted Secure Boot (CVE-2020-13629)

Tue, 22 Sep 2020 08:00:00 +0200

We arrived at the last post about our Fault Injection research on the ESP32. Please read our previous posts as it provides context to the results described in this post.

During our Fault Injection research on the ESP32, we gradually took steps forward in order to identify the required vulnerabilities that allowed us to bypass Secure Boot and Flash Encryption with a single EM glitch. Moreover, we did not only achieve code execution, we also extracted the plain-text flash data from the chip.

Espressif ESP32: Bypassing Flash Encryption (CVE-2020-15048)

Mon, 14 Sep 2020 09:00:00 +0200

In our previous post we described an attack where we load an arbitrary value indirectly into the PC register using EMFI. During that attack we achieved our initial goal where we wanted to last year's research, where we turn Data Transfers into Code Execution, into practice.

As we already pointed out, the Flash Encryption feature of the ESP32 chip, which Espressif advises to use, significantly increases the complexity for bypassing Secure Boot. The typical approach of making modifications to the plain-text code or data stored in external flash is not possible any more once Flash Encryption is enabled.

Espressif ESP32: Controlling PC during Secure Boot

Tue, 08 Sep 2020 12:00:00 +0200

In our previous post we demonstrated that the ESP32 chip is vulnerable to EMFI. We used this to bypass the Secure Boot implementation of the ESP32. During this post we also shared already that our goal was to put our previously conducted research, where we turn Data Transfers into Code Execution, into practice.

When a target is undergoing a Fault Injection attack, it's extremely difficult to guarantee that the hardware operates as intended. This subverts a fundamental assumption of software engineering, where it's assumed that the hardware always flawlessly executes the instructions. Fault Injection attacks undermine the execution of software at the lowest level.

Fault Injection Reference Model (FIRM)

Wed, 26 Aug 2020 11:00:00 +0200

In today's world, physical access to a device is considered a significant threat as devices often play a central role for the underlying business model. A multitude of assets, intellectual property (IP) and even the devices themselves have become sufficiently valuable to require adequate protection.

This gave rise to security features specifically designed to mitigate threats related to physical access. These type of security features, for example Secure Boot, are nowadays way more common than they used to be just a handful of years ago.

Espressif ESP32: Bypassing Secure Boot using EMFI

Fri, 24 Jul 2020 20:40:00 +0200

Our research during the last few years definitely points out our interest in Fault Injection (FI) attacks. We produced numerous publications, which we presented at both academic and security conferences. Among other research, we showed that FI is an effective technique for for bypassing Secure Boot (2016, 2019 and 2019) and escalating privileges on Linux (2017, 2017 and 2017).

Like many of you, our curiosity is constantly sparked and therefore we cannot prevent ourselves from injecting glitches. This post will be your first peek into our new and exciting FI research.

Security Advisories: D-Link DSL-2640B

Sat, 28 Mar 2020 11:00:00 +0100

In a previous post we shared our considerations on the impact of vulnerabilities in Internet connected devices that are EoL. We used the vulnerabilities that we identified in the D-Link DSL-2640B DSL gateway as a use case to support our considerations. In this post we describe the technical details of these vulnerabilities.

Before we dive into the technical details, it's important to note that:

all vulnerabilities are (at least) applicable to the D-Link DSL-2640B (HW revision B2, Firmware version: EU_4.01B)
all vulnerabilities apply to the latest available firmware (as of 27/03/2020)
all vulnerabilities have been reported to D-Link
we are not aware of any security fix released by D-Link
as the device is EoL, following D-Link's policy, no fix may ever be available

The vulnerabilities described in this post may apply to other hardware revisions, other firmware versions and even completely different models. We did not investigate this further and D-Link did not provide any additional insights.

Threat After Death: Security Impact of EoL Devices

Wed, 18 Mar 2020 20:30:00 +0200

We identified several vulnerabilities in the D-Link DSL-2640B DSL gateway which will likely not be fixed as the device is EoL (more details will come soon). A vulnerability identified in an EoL device typically has a guaranteed, infinite lifetime. Basically a NO-day. Although Shodan only reports only two active devices, we like to stress that the impact of these vulnerabilities should not be neglected.

The DNSChanger malware has been updated in 2018 to target the DSL-2640B. The attacker's efforts would be hard to explain with just Shodan's figures. An analysis performed by Bad Packets using data from a different source, identified a much larger device population, excessing 14,000 active devices. The stark difference between device population numbers questions our ability to correctly assess relevance, scale and impact of EoL devices.