I am targeting the embedded bootROM code of a Renesas MCU. The code is executed by connecting the bootstrap pins in a certain way, and issuing a reset. The bootROM exposes some interesting functions, like ReadMemory, and can also be protected with certain flags - readout protection and write protection, for instance. My aim is to bypass the check code readout protection check, and I have a few general questions:
How to determine target clock from oscilloscope capture? The bootROM expects a command with clock configuration, which probably means it starts with an internal clock.
The purple line is the UART, the yellow is processor power, and blue is reset. There’s a big spike just after sending the clock set command.
I want to find where the readout protection flag is checked, and I will do that on another device, which is not locked, by comparing traces with security flag = 1 and flag = 0. Is it a common practice for the bootROMs to check the security flag only once upon startup, or it could be checked in each function call (for example on ReadMemory handler)?
Is using a scope.glitch.output = 'enable_only', with repeat of 1 and same frequency as the target, a viable strategy for targeting a certain instruction? I assume the code checking the protection flag will boil down to a compare instruction, but of course that may be wrong.
I haven’t done any work with recovering a clock from a power trace. Maybe @coflynn can chime in?
AFAIK, typically the security flag is stored in flash and read into some sort of internal register on startup, so if you can glitch past that read on startup, you shouldn’t run into any issues until the device is reset. As for how that interacts with the internal boot ROM, it’s hard to say - they could be checking the actual flash location, or checking the internal register, or possibly even just attempting the memory read and relying on a fault being generated to detect that the read failed.
I’d say it’s better to focus on having decent width/offset settings that give you reliable glitches, but if enable_only/repeat=1 works for you, then that sounds fine.
I’ve found that enable_only/repeat=1 works in skipping or mangling instructions on that processor, but in user code, which is running with a different oscillator than the bootROM.
I know that the user code uses an oscillator frequency of 16MHz, and I’ve set the glitch clock to be the same. Probably it’s pure luck that it worked and who knows what exactly is happening in the CPU, which utilizes a 5-stage pipeline. My aim was to disturb the execution of a single instruction (a compare) and it worked. I was thinking of using the same strategy for the bootROM, but first I need to find the instruction which checks the security flags.
Then I need to make an educated guess about the frequency. However, if I target the ReadMemory command handler, I will know that the oscillator is set to whatever frequency I’ve set it to be in the initializing phase.
I’ve captured a number of traces of the MCU performing the ReadMemory command handler, for both locked and unlocked MCU, but can’t spot the difference. Here’s a plot of the average of 100 traces in both states:
My assumption has been that the bootloader receives the request, calculates checksum, and if valid it proceeds to decide if the authorization level is what it is expected to be. I really hoped that I will stop a difference between the traces of a locked and an unlocked MCU, however probably some of my assumptions are wrong.
On the other hand, when I target the region between the request and the response, I sometimes receive “strange” responses, which I can’t interpret, but are valid messages (with checksum. start and end byte). That gives me some hope that at least the target is glitchable.
