The evolution of RH850 hacking: from a DIY to the Pico Glitcher v3

FlUxIuS · March 6, 2026, 12:35pm

I just finished reading Quarkslab’s post published yesterday on bypassing the ID Code debug protection of the RH850, and its timing couldn’t be better for me personally: I just received a Pico Glitcher v3, and it turns out that’s exactly one of the tools they used to validate the attack.

Here’s a little rundown of how this research area has evolved, from its origins to today, and I think I will miss a lot of other researches → so do not hesitate to reply on this thread!

Background: What is the RH850?

The RH850 is Renesas’ family of high-performance 32-bit microcontrollers, designed for safety-critical applications in the automotive industry. You’ll find them in pretty much everything that requires ASIL certification: electric power steering, engine management, body electronics. This isn’t a hobbyist chip → it’s industrial-grade silicon!

The main protection we care about here is debug access. In production, ECU manufacturers can:

disable it entirely (serial programming disable mode),
lock it behind a 16-byte password, called an ID Code (Renesas ID Code password protection) != IDCODE (IEEE 1149.1 instruction).

These two modes are distinct and correspond to different classes of attacks, which is important for understanding the timeline below.

2021: Franck Jullien, CVE-2021-43327, and the RX65

The first significant public research I’m aware of in this space came from Franck Jullien (@fjullien06), targeting Renesas’ RX65 architecture (published as CVE-2021-43327. His article on collshade.fr is worth reading.

Choosing the attack surface: FINE over SCI

The RX65 boots into programming mode via three interfaces: USB, FINE (proprietary single-wire), and SCI (serial UART, documented). Franck’s first key decision: attack via FINE, not SCI. The reason is that the SCI interface allows only 3 wrong ID code attempts before potentially wiping all flash. FINE has unlimited attempts. For a glitching campaign that may take thousands of tries, that’s not a preference, it’s a hard requirement.

Reversing FINE from scratch

The problem: FINE is completely undocumented. Franck couldn’t just implement it. His approach to reverse it, and he added a small resistor on the debugger (OCD) side of the single-wire bus, creating a voltage divider. When the MCU pulls the line low: 0V at the midpoint. When the OCD pulls low: ~200 mV. A NUCLEO board’s ADC reads the midpoint and separates host-to-device from device-to-host bytes on a bus that carries both directions on a single wire.

Note: this approaches rings a bell if you have read our forum previous post: How to Hack Any Micro-controller with a Raspberry Pi Pico: Easy Fault Injection by Traffic Mocking - #6 by kaipyroami

From the captured traffic, he and a colleague noticed that FINE is essentially SCI commands chunked into 5-byte frames. HOST->MCU transfers start with 0x84, the MCU ACKs with 0x00, then 0xC6 is used as a “ready?” poll. Once you know that, mapping FINE frames to the documented SCI command set becomes tractable.

The glitch

Using the NUCLEO-F429ZI platform, and running at 180 MHz with a full FINE protocol implementation, and generating the glitch trigger he could be precise enough to target the ID check window.

Remaining setup:

Target pin: VCL: the external capacitor pin for the RX65’s internal core voltage regulator. Same principle as all the research that follows: remove the decoupling cap to make the internal rail directly injectable via a transistor.
Trigger timing detail: the timer is started just before the last byte of the “Serial Programming ID Code Check Command” is sent → starting at the very end would be too late to inject in the right window.

By looping over a trigger offset ~50 times, incrementing and repeating over the time he could recover the option-setting memory contents, with the ID Code sitting at addresses 0xFE7F5D50–0xFE7F5D5F, later confirmed by disassembling the bootloader in Ghidra with the red ballon RX processor extension.

But then he goes further: using the same glitching approach on the Read Command, he bypasses the address access checks (which normally return error 0xD0 for forbidden regions) and dumps the reserved areas → finding the bootloader itself. What starts as an ID code bypass turns into a full bootloader extraction → very nice!

This sets the template for everything that follows: understand the protocol deeply enough to time the glitch precisely, target the internal regulator pin, and iterate.

2022: Willem Melching and the RH850/P1M-E & KM-S1

Willem Melching (@PD0WM) published an excellent write-up in November 2022 bypassing the RH850/P1M-E.

(source: Bypassing the Renesas RH850/P1M-E read protection using fault injection | I CAN Hack)

In this post, Willem was explaining he was trying to dump the firmware from the Electronic Power Steering module of a 2021 Toyota RAV4 Prime to understand the SecOC (Secure Onboard Communication) implementation, and potentially restore compatibility with third-party driver assistance systems.

So the target was an R7F701381 (RH850/P1M-E, G3M core, ASIL-D), with the programming interface fully disabled, no password, just a flag that blocks entry into the command waiting phase.

The approach and setup:

2-wire UART interface (FLMD0 pulled high),
Timing window: ~100 µs between the last byte of the SYNC command and the error response 0xDC,
Minimal hardware: a Raspberry Pi Pico (RP2040) + two N-FETs on the VCL pins (internal regulator), decoupling capacitors removed,
Trigger: UART pattern monitoring directly in the RP2040 firmware (wait for SYNC command bytes, then calibrated delay + pulse).

During his quest, Willem has to deal with some mechanisms:

external watchdog,
and second core that functions as a checker:

In fact, the EPS module had an external watchdog that would forcibly pull the reset line low shortly after the MCU entered the bootloader → killing the attack window. Willem’s fix: force the reset line high with a 100Ω resistor to +5V (enough to overpower the watchdog), while keeping software control over reset via an N-FET (e.g: DMN2050L)) driven by the DTR line of the USB-TTL adapter.

But he need a second N-FET! Indeed, a second checker core runs in parallel, and verifies the main core cycle by cycle. There are two VCL pins, one per core. Both need to be glitched simultaneously → if only one core is affected, they fall out of sync and the MCU resets, aborting the attack.

The code looks simple: a few lines of C on the Pico for trigger and glitch generation:

if (uart_getc(uart0) != '\x01') continue;
if (uart_getc(uart0) != '\x00') continue;
if (uart_getc(uart0) != '\x01') continue;
if (uart_getc(uart0) != '\x00') continue;
if (uart_getc(uart0) != '\xff') continue;

busy_wait_at_least_cycles(real_delay);
gpio_put(GLITCH_PIN, 1);
busy_wait_at_least_cycles(width);
gpio_put(GLITCH_PIN, 0);

A Python script on the PC to sweep glitch parameters. After about a day of searching, he dumps the entire firmware.

(source: Bypassing the Renesas RH850/P1M-E read protection using fault injection | I CAN Hack)

Willem later tested glitching only a single VCL pin. Glitching pin 11 alone still works. But glitching only pin 66 produces a curious asymmetric result: it gets past the SYNC command, but memory reads subsequently fail with a flow error. The exact reason isn’t fully explained — likely related to which core (main vs. checker) each pin belongs to, but it hints that the two cores are not fully equivalent from a glitching perspective.

(source: Bypassing the Renesas RH850/P1M-E read protection using fault injection | I CAN Hack)

The rh850-glitch repository contains two folders. The expected rh850-p1m-e/, and a second one: rh850-f1km-s1/, committed around the same time with the message “wip chipshouter rh850-f1km-s1”. Willem had also started exploring the RH850/F1KM-S1, the direct sibling of the F1KM-S4 that Quarkslab would target years later, this time with a ChipShouter (NewAE’s EM fault injection tool) rather than a crowbar voltage glitch. AFAIK, the work was never written up publicly, but it’s a direct thread connecting his research to Quarkslab’s, and it shows the F1KM family was already on the radar as a natural next target.

Worth noting: this attack targets the “programming disabled” flag, not an ID Code. The distinction matters → Willem himself points it out in his conclusion: if an ID Code had also been set, the attack would have required two consecutive successful glitches and would have been significantly harder.

2024: Breaking 16-byte ID Code Authentication for Firmware Extraction in Automotive ECU with Voltage Glitching

A little update here I completely missed to mention is this nice article, I’m quickly explaining in reply to this first post.

2025: Caesar Creek Software, and the 7-Part Series

This is the body of work that tends to get overlooked in the timeline, but it’s genuinely significant → both for what it tried and for what it couldn’t quite finish. Caesar Creek Software (CCSW), a US-based security firm, published a 7-part blog series on RH850 attacks throughout 2025, with the actual research conducted by Ibrahima Keita. The work appears to date back to at least 2023 based on oscilloscope capture timestamps in the code.

Their full series structure:

Part 1: Introduction to the RH850 and the attack motivation
Part 2: Overview of the RH850’s security features
Part 3: Introduction to fault injection and side-channel theory
Part 4: Fault injection characterization on a development board
Part 5: “The Real Deal”: bypassing serial programming prohibition on a locked RH850
Part 6: EM fault injection: improving the attack wirelessly
Part 7: Power analysis: attempting to understand the ID authentication timing

What they confirmed (Parts 3–5)

Target: An RH850 development board running at 16 MHz → notably much slower than the P1M-E (160 MHz) or F1KM-S4 (240 MHz). Same class of attack as Melching was used → bypassing serial programming prohibition, not an ID Code.

Part 4 is a careful characterization exercise before attempting the real attack. They wrote and flashed two test programs:

Test Scenario 1: A simple conditional check (if (x != 100)). The glitch window was only 20 µs (~600 clock cycles at 16 MHz). No successes → the comparison and branch instructions take up a negligible fraction of that window, dominated by GPIO calls,
Test Scenario 2: A flash memory read comparison (*(unsigned int *)0x0 vs a known value). Window of ~30 µs (~900 cycles). After a 3-day unattended sweep, they converged on a reliable parameter region: ext_offset [1730–1741], repeat [10–11]. 143+ consecutive successes overnight.

Part 5 applied this to the real target and successfully bypassed the serial programming prohibition —-> confirmed in Part 7’s conclusion: “I have successfully performed the serial programmer prohibition bypass.”.

(source: Renesas RH850 Attacks (Part 5 of 7) – The Real Deal: Glitching a Locked RH850 | Caesar Creek Software)

Part 6: Going wireless with EMFI

Part 6 is the most distinctive contribution of the CCSW series: they moved to Electromagnetic Fault Injection (EMFI) as an alternative to the crowbar voltage glitch. EMFI (“wireless glitching”) injects faults via a handheld or positioned EM coil, without needing a direct electrical connection to the target’s power rail — potentially removing the need to remove decoupling capacitors or tap the VCL pin directly. This directly anticipates the third point on my personal “what’s next” list: whether we can avoid board modification for certain ECU configurations.

Parts 5 and 6 are currently behind a JavaScript wall on the CCSW site, so the full methodology isn’t accessible at the time of writing — but the series conclusion confirms both attacks succeeded.

Part 7: Power analysis: an honest attempt at an honest limitation

Keita attempts SPA on the RH850 during ID authentication using the Nordic Semiconductor Power Profiler Kit 2 (and later the ChipWhisperer Husky). The PPK2 samples at only 100 kSamples/s — against a chip running at 16 MHz, that’s nowhere near enough resolution to see per-instruction power variations.

(source: Renesas RH850 Attacks (Part 7 of 7) – RH850 Power Analysis: An Attempt | Caesar Creek Software)

He does make one useful observation: power trace dips during UART transmission (the TX line being pulled low to send bits creates measurable current drops), which allows him to identify the region after the UART TX phase as the likely password verification window. But characterizing what’s happening inside that window, or using it for a timing oracle, was out of reach with the available equipment.

His conclusion is worth quoting (paraphrased): the ID authentication check either runs in constant time, or executes too quickly to distinguish byte-by-byte using available SPA equipment. He explicitly leaves this as future work → and of course, this is exactly what Quarkslab’s SPA approach on the ISOVCL pin later resolves.

March 2026: Quarkslab with Reliable ID Code bypass

This brings us to the freshly published work by Philippe Azalbert at Quarkslab: Bypassing debug password protection on the RH850 family using fault injection.

They tackle the problem Willem had left open: bypassing the ID Code (the 16-byte password). The target is an RH850/F1KM-S4 (G3KH core, 240 MHz, ASIL-B) — a different and faster chip than the one used by Melching.

The Trigger Problem

This is the core contribution of the paper. Using the byte before the password checksum as a UART trigger works in principle — but introduces a ~80 µs jitter, likely a random anti-glitch delay baked into the RH850. Too unreliable to use directly.

The solution: Simple Power Analysis (SPA) on the ISOVCL pin (the ISO internal regulator, which powers the CPU subsystem and Code Flash). They identify a ~4 µs pattern in the power trace that corresponds to the password verification routine. Importantly, this pattern is consistent across multiple ECUs — validating the approach for real-world cross-device use.

Sequenced Trigger on ChipWhisperer Husky

To exploit this pattern, they use the trigger sequencer of the ChipWhisperer Husky first:

First stage: UART trigger on the last byte of the ID Code frame,
Second stage: ADC trigger on the power consumption spike (at 80% of the measured peak level)

(source: Bypassing debug password protection on the RH850 family using fault injection - Quarkslab's blog)

Result: bypass in 88 attempts, roughly one minute. Neat!

Validation on the Pico Glitcher v3

And this is where it gets directly relevant to me since I order the PicoGlitcher v3 to lower some attack costs → to validate that the attack is reproducible with accessible hardware, they tested it using the Pico Glitcher v3, driven by by Matthias Kesenheimer’s findus Python library.

(source: Bypassing debug password protection on the RH850 family using fault injection - Quarkslab's blog)

The Pico Glitcher v3 is based on the Raspberry Pi Pico 2 and integrates two high-power MOSFETs for crowbar glitch generation, level shifters, and adjustable Schmitt trigger inputs (EXT1/EXT2) → these are what they attempt to use to detect the power consumption pattern on a budget.

The verdict: the spikes in the target pattern are in the order of a few millivolts, which is at the limit of what the Pico Glitcher’s Schmitt triggers can reliably detect. They work around this by directly modifying the Pico Glitcher’s MicroPython firmware (StatesMachines.py) to implement a custom sequenced trigger using PIO (Programmable I/O):

Edge counter on EXT1 to track the UART password frame
Calibrated delay
Rising edge trigger on EXT2

@asm_pio()
def edge_trigger_threshold_rising_edge():
    pull(block)
    mov(x, osr)  # Read edge counter threshold
    pull(block)
    mov(y, osr)  # Read trigger #1 delay

    label("edge_count_loop")
    wait(0, pin, 1)
    wait(1, pin, 1)
    jmp(x_dec, "edge_count_loop")

    label("delay_loop")
    jmp(y_dec, "delay_loop")

    wait(0, pin, 0)
    wait(1, pin, 0)

    irq(block, 1)
    push(block)

(source: Bypassing debug password protection on the RH850 family using fault injection - Quarkslab's blog)

Result with the Pico Glitcher: ~7,000 attempts for one success. Less efficient than the ChipWhisperer Husky (88 attempts), but it works → and the hardware costs €30–50

What about your experience out there?

References

FlUxIuS · March 6, 2026, 4:12pm

Thanks to our friend Willem (@PD0WM) message on X, we can complete this thread with a resource I didn’t mentioned at all: Renesas RH850 Voltage Glitching

Jerin Sunny and Shakir Zari from FEV Secure Lab (FEV India) published Unlocking Renesas RH850/F1L Security with Voltage Glitching in 2024, and they’re working on a real production ECU from the start: a Body Control Module (BCM) pulled from a vehicle.

(source: Renesas RH850 Voltage Glitching)

Target & reconnaissance

The BCM contains an RH850/F1L: yet another family member not seen in the other research, adding a 3rd distinct RH850 variant to the timeline (alongside the P1M-E and the F1KM-S4). They first tried to extract memory via the CAN interface, found it protected behind Security Access. Physical disassembly followed, then connectivity via the JTAG pins and a Renesas E1 debugger, which promptly asked for the 16-byte ID Code. Common codes were tried, all failed. So, same as everyone else in this timeline: fault injection it is.

Protocol analysis

They replicated the same 2-wire UART approach: FLMD0 pulled high, logic analyser on the lines, full decode of the RFP command sequence. Notably they document the exact flow clearly: sync zeros → device info → clock frequencies → bitrate (9600) → serial programming check → ID Code Check command (16 bytes). Useful reference if you’re building your own tooling!

(source: Renesas RH850 Voltage Glitching)

Hardware setup: CW Lite + a hardware mod

Here’s where it gets interesting. They used a ChipWhisperer Lite, the entry-level model, cheaper than the Husky used by CCSW and Quarkslab with the glitch output connected to ISOVCL.

Decoupling caps on ISOVCL were replaced (not just removed) with custom values chosen to shape the glitch profile more precisely.

The CW Lite doesn’t give precise enough control over glitch voltage levels out of the box, the crowbar was pulling too hard or inconsistently. So they claim having fixed the CW Lite circuitry** to regain voltage precision.

(source: Renesas RH850 Voltage Glitching)

The post is a little vague about this modification, but it is worth to mention the CW Lite crowbar is binary by design. The most common fix for this is adding a series resistor on the crowbar path between the MOSFET drain, and the SMA glitch output to limit the effective short-circuit current, and produce a softer, shallower voltage droop rather than a hard rail-to-GND. A second possibility is that they modified the target supply voltage path, reducing VTARGET so that the same crowbar depth produces a proportionally gentler glitch. This is essentially what the Pico Glitcher v3’s 1.2V/1.8V/3.3V/5V multiplexed supply achieves programmatically.

Results

Firmware extracted, but one successful glitch isn’t enough to dump the full memory, the target stops responding mid-read, requiring multiple successful glitches to pull the complete code flash and data flash. Once done, they pack the data into a binary by stripping RFP command metadata.

(source: Renesas RH850 Voltage Glitching)

Then the firmware reversing starts. And this is where this entry stands alone in the timeline:

Found secret keys used to unlock Secure Diagnostic Services
With security access bypassed: ability to control vehicle actions

Full end-to-end, from soldering to vehicle control. All vulnerabilities were privately disclosed to the manufacturer and patched.

It’s very interesting post!