Continuing our 7-part series on attacking the Renesas RH850. Work conducted by Ibrahima Keita.

Background

As stated in the previous blog posts, one of the ultimate goals of this project was to bypass the serial programming and ID authentication checks on an RH850. Since we were able to fault the RH850 with our test cases from before, we can now move forward with what we wanted to originally target.

When performing research for this project, we came across Willem Melching’s attempt to glitch the RH850. To quickly summarize, Melching obtained his RH850 from a 2021 Toyota RAV4 Prime’s Electronic Power Steering module, and attempted to dump the firmware for research purposes. The RH850 he was working with disallowed serial programmer connections, making any attempt to dump the flash contents futile, even with official tools. While there are official tools to remove the serial programmer protection bit, they are internal to Renesas. However, Melching was able to successfully bypass this check by attacking the voltage regulator line (VCL) of the RH850 with a crowbar.

Similar to what we have done for the simple tests, Melching found:

• A suitable trigger, which is a source that we can reliably use to place our glitch.
• The proper delay (or ext_offset), which is how many cycles to wait before performing the glitch.
• The glitch repeat, which is how many clock cycles to drop the voltage for.

With a Raspberry Pi Pico and a few fast field effect transistors, Melching was able to find suitable conditions to perform the glitch, and bypassed the serial programmer connection bit, granting him access to the processor.

Knowing that, we decided to repeat the experiment ourselves to see if we could reproduce his result.

Setup

Hardware

Similar to Melching, our setup is as follows:

• We have our crowbar connected to VCL/VCC_REG for the same reason as before; to force the chip’s voltage to rise/fall as we please.
• We include an FTDI so we can simulate the actions a Renesas E1 programmer would take (requesting data, sending boot commands).
  • This FTDI uses a two-wire UART interface. It is not exactly the same as the model depicted below in the schematic, but it was the simplest symbol with the correct outputs.
• We connect our FTDI to LPDIO and LPDO (RX and TX, respectively) in the following manner:

• We have the ChipWhisperer monitoring the FTDI’s TX, via IO2. This is so we can use the commands we send via the FTDI programmer as trigger points (as we will see later).
• We have the nRST of the ChipWhisperer connected to the RH850’s RESET, so we can force the system to reboot if our glitch fails.
• Finally, we short the FLMDO to VCC, so we can force the chip into programming mode.

The detailed schematic can be seen below.

Furthermore, to simulate the scenario which Melching faced, we will disable serial programming on a spare RH850 development board that we had from testing fault injection (as done in the last post). This is done very easily via the Renesas Flash Programming tool with a Renesas E1 programmer. After this process completes, we are ready to go.

Software

Just like before, we will be using the ChipWhisperer’s Python API to perform our glitching.

To determine the range of ext_offsets to use, we need to first identify a trigger, which means we need to have a general idea of how the read flow should go. Luckily, I documented all of that here.

Target

When serial programming is disabled, running the INQUIRE command results in the following flow:

sequenceDiagram
    Programmer->>+RH850: RH_COMMAND<INQUIRE>()
    RH850->>+Programmer: RH_DATA<INQUIRE>(SERIAL_PROGRAMMING_DISABLED)

This makes it so all subsequent commands cannot be run, as the RH850 will prevent this from happening. I believe this is because this command allows the flash programmer to read. However, if this command returns success, then the rest of the flow should work as expected. As such, we want to target this process, as it will allow us access to the flash contents.

Therefore, we should setup a UART trigger that waits for the command we want to be sent. Luckily, the ChipWhisperer API has a set of options for this:

scope.io.tio2 = 'serial_rx'
scope.io.glitch_trig_mcx = 'trigger'
scope.trigger.triggers = 'tio2'
scope.trigger.module = 'UART'
scope.UARTTrigger.enabled = True
scope.UARTTrigger.baud = 9600
scope.UARTTrigger.set_pattern_match(0, '\x80\x22\x03')
scope.UARTTrigger.trigger_source = 0

To briefly explain what each of these options do:

• We configure tio2 on the ChipWhisperer Husky as a serial RX line. This way, we can connect it to the TX line of our FTDI, so we can monitor what we send.
• We set the glitch_trig_mcx on the ChipWhisperer Husky to output a signal whenever the ChipWhisperer triggers.
• We enable the ChipWhisperer Husky’s UARTTrigger, set the RX line’s baud rate to 9600 (since this is the initial communication speed of the RH850), then tell it to trigger on the RX line (tio2) when some bytes are sent to the RH850.

The keen eye may have noticed that the bytes in the pattern here do not represent the Inquire command. This is because the ChipWhisperer Husky’s UART triggering is a bit slow with a lot of bytes, causing our trigger to happen too late (as the trigger will happen mid-way during the work range). If this happens, then the glitch will also happen too late, and we will keep getting serial programming errors as we have not bypassed the authentication. So, we used one of the earlier commands in the stream as a trigger, and corrected this with our ext_offset. We figured this out by trial and error, so it may not make much sense depending on your setup.

Now that we have our trigger, we experimentally determine our initial ext_offset range by sweeping from 0 upwards, until we hit the end of our target window (which is when the processor starts talking to us again).

We saw that ext_offset 197825 puts our glitch right after the programmer finishes sending the command we want, and 219000 puts us pretty much directly at the end of our window (when the device starts to respond). We ended up glitching with the following parameters:

min_delay = 197825
max_delay = 209925

scope.glitch.width = 40
scope.glitch.offset = -45
gc.set_range("ext_offset", min_delay, max_delay)
gc.set_range("repeat", 10, 15)
gc.set_global_step(100)
gc.set_step('repeat', 0.1)

Running the Glitch

We ran this, walked away for 20 or so minutes, then came back to a complete flash dump, meaning we successfully bypassed the check! We saw this happen at ext_offset [209725, 209925] with repeat 10.8.

We ran the test again with ext_offset ranges [209725,209925] as follows:

# Original parameters: ext ~ 197825 -> 219000, repeat ~ 10 -> 15
# Glitched with: ext ~ 209725 -> 209925, repeat ~ 10 -> 11
min_delay = 209725
max_delay = 209925

scope.glitch.width = 40
scope.glitch.offset = -45
gc.set_range("ext_offset", min_delay, max_delay)
gc.set_range("repeat", 10.8, 11.01)
gc.set_global_step(10)
gc.set_step('repeat', 0.1)

And within a few minutes, I was greeted with the following output:

d = 209725, w = 10.8
[+] Timed out.
d = 209725, w = 10.9
[+] Timed out.
d = 209725, w = 11.0
[+] Timed out.
[Many runs later...]
[+] Timed out.
d = 209825, w = 10.8
[+] Dumping segments...
[+] Block Start: 0x0
[+] Block End: 0x7ff
[-] Requesting block...
[+] Block Start: 0x800
[+] Block End: 0xfff
[-] Requesting block...
[+] Block Start: 0x1000
[+] Block End: 0x17ff
[-] Requesting block...
[...]
[-] Requesting block...
[+] Block Start: 0x1006800
[+] Block End: 0x1006fff
[-] Requesting block...
[+] Block Start: 0x1007000
[+] Block End: 0x10077ff
[-] Requesting block...
[+] Block Start: 0x1007800
[+] Block End: 0x1007fff
[-] Requesting block...
[$] Dump was successful; ext_offset = 209825, repeat = 10.8

Looks like we did it! To confirm, I compared the dump we obtained to a known good dump (which was obtained by flashing a chip with our own firmware, then pulling it via the Renesas Flash Programmer tool) to see if it was the same, which it was!

So, with controlled fault injection, we were able to dump the firmware of a locked Renesas RH850 by forcing the device to believe it can be talked to over serial!

However, we can definitely make some improvements. While this glitching attempt was successful, performing fault injection by attaching directly to the board is extremely intrusive. Just look at our setup:

In the next blog post, we will attempt to perform the same glitch again, but with a cleaner fault injection method.