Renesas RH850 Attacks (Part 6 of 7) – Glitching a Locked RH850, Wirelessly

Background

In the previous blog posts, we detailed a fault injection attack on the Renesas RH850 that allowed us to bypass one of its security features: the serial programming prohibition. In this blog post, we will go over how we improved the fault injection attack.

Electromagnetic Fault Injection

When it comes to voltage glitching, especially with microprocessors, modifications to the circuit are often required. We’d need to attach a crowbar to the voltage regulator line and use it to fault the system’s voltage regulator. This might involve severing connections to existing traces, or pulling components off the board, which are fairly destructive processes, and often irreversible without a significant effort. For this reason, we look for a less destructive approach. What about a magnet?

Magnetic fields can store electrical charge, as Hans Oersted discovered in 1820. This property effectively allows magnetic fields to act as electric fields, and vice-versa.

This charge can pass through a surface. By Faraday’s law of induction, the induced voltage ϵ\epsilonϵ of a magnetic field is directly proportional to the negative product of the number of windings on a given coil (for example, copper wire wrapped around a ferrite core), n, and the instantaneous rate of change of magnetic flux,

In other words:

​ With this knowledge, we can create a probe that induces a voltage through the air. Not only that, but by varying the number of windings , and the change in magnetic flux , we can control exactly how strong the induced voltage is. If we were able to generate a magnetic field with a charge strong enough to pass through a target, we could use the charge stored in this field to generate an electromagnetic pulse (EMP) that disrupts the flow of electrons through the target, causing the same effect as attacking the voltage regulator line. This is exactly what Electromagnetic Fault Injection (EMFI) is.

Knowing this, we can weaponize this electromagnetic pulse generator to rapidly send charge perpendicular to the flow of the electrons in an integrated circuit, momentarily disrupting the flow — similar to a crowbar circuit, but wirelessly.

The NewAE ChipSHOUTER EMP can do this. It can generate up to 500V pulses and has a plethora of safety features and creature comforts built in. However, it costs (at the time of writing) $4,350, which is quite the chunk of change.

Fortunately, there are other options from NewAE which we can use as a starting point before making the big jump. The ChipSHOUTER PicoEMP is a $60 dollar pulse generator that can generate up to 250V, and is fairly barebones. It isn’t as strong as the ChipSHOUTER is (meaning a closer proximity is needed), but it can still perform decently well. We have a couple of these lying around, so we will use those.

Now, with the EMP, we need to have the tip of the electromagnetic pulse generator in close proximity to the surface of the integrated circuit. The user could hold the electromagnetic pulse generator, but this is not ideal; not only is it not as precise, but the capacitors on some electromagnetic pulse generators can store a lot of voltage (200V+), which is not safe to touch!

As such, we need a safer and more precise method for positioning the probe, via computer numerical control (CNC). A lot of CNC systems provide 3-axis (X, Y, Z) control, but can be a bit pricey. But, there is one “CNC” machine that we had lying around that serves us just as well as the pricey ones could: an Ender 3 Pro.

XY-Plane

While the Ender 3 Pro is designed for 3D printing, it is extremely moddable; for example, one user on Reddit was able to convert their Ender 3 into a laser cutter. So, this got us thinking: why not turn our Ender 3 Pro into an CNC-based EMP controller?

And that’s exactly what we did. We now introduce the XYZ Plane, which allows us to target areas of the processor’s package using a ChipSHOUTER PicoEMP & a NewAE ChipWhisperer Husky.

The way the XYZ-Plane was constructed is as follows: 1. A mount for the ChipSHOUTER & ChipWhisperer Husky was designed in a computer-aided design (CAD) software, TinkerCAD. This mount is a drop-in replacement of the bowden assembly on the Ender 3 Pro. 2. After a successful print, the bowden tube assembly was removed from the gantry, and our mount installed in its place. The PicoEMP & ChipWhisperer Husky were then attached after moving the gantry to accomodate them. 3. The stock Ender 3 Pro magnetic bed was removed (leaving just the heat-plate), and the end-stops were raised to accommodate the new traversal pattern of the PicoEMP. 4. From this point onwards, we now instrument the movements of the Ender 3 with Marlin G-Code sent via UART (and not from a slicer). This is fairly simple; all that is needed is a UART channel with a baud rate of 115,200 bps (trivially done in Python 3 via PySerial). The Ender 3 Pro’s motherboard has a CH340 built into it, which is a USB serial chip. 5. The components on the gantry were wired as follows:

Now that we have an EMFI setup, we can attempt to glitch the RH850 with it.

Glitching the RH850 in 3 Dimensions

Hardware

We’ve now added three dimensions worth of complexity to our setup. We need to keep track of the X, Y, and Z of our probe, which is slightly offset from the gantry’s mid-point. Luckily, this is not too hard. We need to home the probe, or zero its coordinates, to known points. From there, we can calculate a deviation which gives us the printer relative coordinates. That is exactly what the Ender 3 will do for us. From there, we use our instrumentation to send gantry movement commands.

The rest of the setup is exactly the same as the non-XY case, but will be reiterated for clarity.

• 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, which is the same as the non-XY case, can be seen below.

Software

Similar to before, we will be using the ChipWhisperer’s Python API to perform our glitching. However, because we need to instrument the XY plane to move the probe around, some changes are needed.

As mentioned before, the XY-Plane has a CH340 USB UART chip. All that needs to be done is sending valid Marlin G-Code commands to move the gantry. The simplest one which accomplishes this is G0 – Linear Move. As such, we wrote a simple Python API to instrument the XY plane.

Now, as for our parameters:

• In terms of ext_offset range, we can use the same range as the non-XY case, as our trigger is exactly the same. For the purposes of reiteration, 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.
• In terms of repeat, we need to widen our range. The primary motivation for this is how the EMP sends pulses. They travel through the air, and setting too short of a repeat would make it less likely to affect the silicon as much. And of course, going too high would make the effect stronger, causing unrecoverable crashes.
• For x and y ranges, we chose them by manually positioning the PicoEMP over the chip at a start point and an end point, such that the PicoEMP can iterate over the entire chip.
• For the z range, we chose a range such that the PicoEMP is close to the silicon on the chip, but not too close (i.e to the point where the probe would scrape the silicon).

So, we ended up glitching with the following parameters (relative to how we placed our development board):

XMIN, XMAX = 138, 150
YMIN, YMAX = 106, 120
ZMIN, ZMAX = 37.2, 37.2
EXT_MIN, EXT_MAX = 209725, 209925

gc = cw.GlitchController(groups=["success", "normal"], parameters=["ext_offset", "x", "y", "z", "repeat", 'tries'])
gc.set_global_step([1])
gc.set_range("x", XMIN, XMAX)
gc.set_range("y", YMIN, YMAX)
gc.set_range("z", ZMIN, ZMAX)
gc.set_range("tries", 1, 5)

gc.set_range("ext_offset", EXT_MIN, EXT_MAX)
gc.set_range("repeat", 1, 24)
gc.set_step("ext_offset", 1)
gc.set_step("x", 2.5)
gc.set_step("y", 0.5)
gc.set_step("z", [1])

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 with repeat 24.

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!

d = 209725, r = 23, coords = (169.5, 104.0, 28.2)
[+] Error: b'\xdc'
d = 209725, r = 23, coords = (169.5, 104.0, 28.2)
[+] Error: b'\xdc'
d = 209725, r = 23, coords = (169.5, 104.0, 28.2)
[+] Error: b'\xdc'
d = 209725, r = 24, coords = (169.5, 104.0, 28.2)
[+] Error: b'\xdc'
d = 209725, r = 24, coords = (169.5, 104.0, 28.2)
d = 209725, r = 24, coords = (169.5, 104.0, 28.2)
d = 209725, r = 24, coords = (169.5, 104.0, 28.2)
[+] Error: b'\xdc'
d = 209725, r = 24, coords = (169.5, 104.0, 28.2)
[*] Dump was successful; d = 209725, r = 24, coords = (169.5, 104.0, 28.2)

So, it looks like we were able to translate our glitch from crowbar-based attacks to an electromagnetic pulse-based one!

As a postmortem, we decided to investigate. The reason why it worked at that coordinate is because that coordinate put the probe near the chip’s voltage regulator, which made it very easy to interfere with the logic of the system. Hitting it with just the right pulse forced it to spit out the data.

In the final blog post, I will go over the power analysis I have done on the RH850, in order to get an idea of whether or not we can leak the ID/glitch the check.