The author was working with a device that had the Renesas RX65 chip on it. The author wanted to see the contents of firmware. Alas, the chip had a write programmer lock on it. The author needed a 16 byte ID code that they clearly did not have. Additionally, all of the protocols for communication were proprietary. This looks like a challenge to me if I've ever seen one!
Three interfaces for firmware operations appeared in the docs: USB, FINE and SCI. FINE is a proprietary interface used by Renesas and is not documented. USB is also not documented, so the easiest option is to use the serial interface. The Serial protocol had a limit on the amount of ID codes and USB was not exposed on the device. So, the best option was FINE.
By reading schematics and datasheets, the author found out that FINE was a single wire interface. Using the Renesas Flash programmer on a dev board allows us to see the traffic being sent. Here's the problem though: this did not allow for us to discriminate the host and device communication.
In order to fix this problem, the author added a small resistor small resistor on the OCD side, which is a divider. When the MCU pulls the line low, the voltage at the center point (ADC) is 0V. However, when OCD pulls the line LOW there is a small voltage (about 200mV) at the center point. This allowed for the differentiating between the two lines of communication and better reversing of the protocol.
Even with this amazing setup and some reversing, a friend of the author noted that the SCI protocol looked quite similar to the FINE protocol (which is well documented in the manual). There are some notes on the two protocols but the author leaves the rest of this reversing for someone else to do.
How can the ID check be bypassed? Glitching! If we can change the path that the code running hits by physically altering the device, then we can access the programming mode. In this case, the goal was to glitch the power supply of the MCU right after sending the Serial Programming ID Code Check Command, which was in FINE.
To set this up properly, the author removed every capacitor on VCC to create a direct connection to the Core power supply. This makes the voltage and current actually glitch the system instead of their normal smoothing operation. To setup the glitching, this is what the author did:
- Run the initialization sequence of FINE until the ID Check is sent.
- Send the command to the MCU. This is where our timer for the glitch starts.
- Glitch the system at a set interval.
- Loop over the position 50 times. Increase the timer if this does not work.
After running this for a very long time, the programmer works to extract the Flash! Glitching is extremely powerful but complicated to setup. The author submitted the CVE 2021-43327 for this vulnerability on the chip is well. Interesting bypass and it's real cool to see a real setup of glitching.