Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The Renesas R7F701381 is a microcontroller for safety critical applications. It contains a second core with a lockstep core (runs instructions in parallel) to check the first core. Additionally, the instruction cache and RAM has ECC as well. Even though the chip has read out protection, the author wants to bypass this on the chip.

Renesas chip supports a two wire protocol that can be hooked up with a 5V USB-TTL cable. In order to enable debug mode, a pin needs to be pulled high. However, there was an external watchdog to prevent this was happening. The watchdog would pull the reset line low in order to reset the chip whenever the debug mode was entered. So, the author of the post added a 100 ohm resistor to the 5V line to overpower the watchdog.

While in the debug mode, the author tried to connect via the flash programmer for the chip put got an error message from the flasher. Instead of moving on, they decided to analyze the protocol and see if it was the tool deciding it was done or if a custom implementation of the protocol could bypass the protections. The hooked up a logic analyzer and read through documentation of other chips to see what was going on.

The documentation of a different chip gave the author a good insight: the command waiting phase is the only location where the device checks if the programmer is allowed. If this stage could be skipped then we would be allowed to use the programmer. Since there was no direct vulnerability in the implementation, the author turned to fault injection.

Fault injection is the act of causing the CPU to behave strangely by forcing it outside the normal ranges of operation. For instance, changing the operating voltage, clock frequency or adding in electromagnetic signals. The authors choice was to perform a voltage glitch on the power circuit of the device to modify the course of the program. In particular, they decided to glitch the portion where the synchronize command was being received and checking if debugging was enabled.

The datasheet shows a block diagram of the power supply circuit. Inside of the CPU core, there an internal 1.25 voltage regular. To stabilize this, an external pin is attached to a capacitor (VCL). This pin is where the author decided to put the glitch at, since the stability would be affected.

Since the RH850 is used for safety critical operations there is a second core being used. As a result, there is a VCL pin for each core! So, the idea was to remove the capacitors for each of these pins to prevent the smoothing out and glitch these cores at the same moment! By doing this, the cores won't go out of sync.

The author hooked up an N-FET switch for each of the cores, along with a Raspberry Pi Pico to actually perform the glitching. The Pi would drop the voltage for very small time intervals on the GPIO, which was super controllable. Additionally, the author had reimplemented the protocol with a Python script. Upon each glitch, they would check to see if the debug protocol was returning successfully. After a day of finding the proper parameters, they had a successful debug mode! Each attempt after this only takes 5 to 30 minutes, since we know the parameters now.

With this memory can be read out to dump the entire firmware! This was a complete bypass of the functionality in place. Afterwards, they attempted the glitch on ONLY one of the pins. For whatever reason, only glitching the main core works as well, which doesn't make sense to the author. Overall, great post on fault injection which really gets into the interesting details of it.