Using an FPGA to Glitch the Olimex LPC-P1343

After trying out hardware hacking using an FPGA to interface with target hardware, [Grazfather] was inspired to try using the iCEBreaker (one of the many hobbyist FPGAs to have recently flooded the market) to build a UART-controllable glitcher for the Olimex LPC-P1343.

FPGA Modules (The cmd module intercepts what the host computer sends over UART, the resetter holds the reset line until the target is reset, the delay starts counting on reset and waits for a configured number of cycles before sending its signal, the trigger waits for the delay to finish before telling the pulse module to send a pulse, and the pulse works similar to the delay module and outputs to the power multiplexer.)

When the target board boots up, the bootROM reads the flash and determines whether the UART goes to a shell and if the shell can be used to read out the flash. This is meant for developing firmware and debugging it in the bootloader, only flashing a version when the firmware is production-ready. The vulnerability is that only a specific value read from address 0x2FC and the state of a few pins can lock the bootloader in the expected way, and any other value at the address causes the bootROM to consider the device unlocked. Essentially, the mechanism is the opposite of how a lock ought to work.

The goal is to get the CPU to misread the flash at the precise moment it is meant to be reading the specific value, then jumping to the bootloader in the unlocked state. The FPGA can be used as a tool between the host machine and target board, communicating via UART. The FGPA can support configuring the delay between resetting the target board and pulsing a ‘glitch voltage’, as well as resetting the target board and activating the glitch. The primary reasons for using the FPGA over a different microcontroller are that the FPGA allows for precise timing (83.3ns precision) and removes worries about jitters (a Raspberry Pi might have side effects from OS scheduling and other processes and microcontrollers might have interrupts messing up the timing).

The logic analyzer view

To simulate the various modules, [Grazfather] used Icarus Verilog as well as GTKWave to observe the waveforms generated. A separate logic analyzer observes the effects on real hardware.

With enough time, it is possible to brute force any combination of delay and width until you get a dump of the flash you’re not meant to read. You can check out how the width of the pulse gets wider until the max, when the delay is incremented and the width values are tried again.

from Hackaday https://ift.tt/3bV49PF