Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
We may have a $20,000 Raspberry Pi and Hextree RP2350 winner Hacking challenge. Engineer Aidan Cullen announces himself Breakthrough RP2350 Presentation at the recent 38th Chaos Conference (38C3), and there GitHub repo It has now been posted to accompany the video here. Colin studied the RP2350 in detail before embarking on a voltage injection fault attack on pin 53 of the RP2350 chip, which managed to power the “permanently disabled” RISC-V cores and the debug access port, enabling him to read the secret.
Raspberry Pi ft RP2350 via Raspberry Pi Pico 2 As successor to RP2040 – With additive protection Features to attract commercial and industrial customers. To promote the new microcontroller, we collaborated with Hextree to design the RP2350 hacking challenge, It was announced at DEF CON in August. This challenge ended on December 31, 2024, but we will have to wait until January 14 for the official announcement of the winner. Colin gave his presentation at 38C3 on December 27 and also shared a GitHub repo with an outline of the hacking process and Python code. However, we don’t know if Colin is the winner, so this may not be a $20,000 winning hack.
Specifically, the RP2350 comes with a quartet of new security features, which Raspberry Pi was keen to highlight. These are Secure Boot, TrustZone, Redundancy Coprocessor (RCP), and Glitch Detectors. The challengers have hidden a secret on one of these “fully secured” chips, which will be made available to hackers who apply, and the first provable success story will receive $20,000 and the fame of being the winner of the challenge. Attacks using hardware and/or software means were permitted under competition rules, so the situation was almost unthinkable.
The Raspberry Pi and Hextree will hide the secret in the RP2350’s on-chip OTP (one-time programmable) memory, which is said to be a binary code that is set once but never forgotten. Picotool was used to write the secret code to the OTP. The RP2350’s OTP memory was then locked behind the hardware protection feature Page Locks, and was set to an “inaccessible” state of “13:12” according to the table above. The firmware was also signed, with Secure Boot enabled, and they disabled the chip’s debugging feature, so prying eyes couldn’t access the secret via the Serial Wire Debug (SWD) interface. Furthermore, all other operating switches were disabled, and the RP2350 fault detector was turned on and then set to the highest sensitivity level. It definitely looks like it has been closed.
Colin says he started his hacking process by studying the RP2350 datasheet and the dependencies described in the documentation. Colin then looked into how to operate the RP2350 and adjust its security settings, paying special attention to the OTP.
Colin’s first idea was to make the OTP misread important bit settings, and you could make the chip operate in an unsafe manner. Colin even X-rayed the RP2350 as part of his investigation and annotated the chip blocks. However, he maintains that this was merely attention-seeking and was not effective in overcoming the challenge.
Research forced Colin to focus on Pin 53, called USB-OTP_VDD, because it is connected to the OTP (and USB) functions. Perhaps a hacker could “externally tamper with this power supply” to affect these functions, he thought. So he removed the chip and isolated pin 53 (which actually cuts off the PCB trace), so that it was ready to be electrically manipulated separately on a reassembled board.
image 1 to 3
Using this hardware-modified setup, Colin checked pin 53 to “inject whatever voltage I wanted” and checked what happened. I kept the unshielded RP2350 board on hand for side-by-side comparisons. Once the device is set up, see what typically happens when the RP2350 is both guaranteed and non-guaranteed starting up – based on the probe readings on the oscilloscope.
16 clusters of spikes were seen, corresponding to the initial 16 OTP readings at startup. Colin then tested for a power failure to occur at Pin 53 at certain points in the boot process. It is disappointing that debugging has remained closed. Next, a Python script was used to scan the fault power input position through the full 600 μs range of OTP readings during startup. Debugging functionality was verified but never became available. So Colin looked at the unlocked RP2350 board again, with debugging enabled, for clues.
Then, something interesting was observed: the RISC-V cores came across a glitch in the unlocked RP2350. Cullen then used another script to check where the RISC-V debug access port appeared. This technology can also run on a secured RP2350 – the debugger can now be connected to a secured RP2350 and read the secret from the OTP!
The secret is revealed
RISC-V cores that were “permanently disabled” were awakened by the bug to enable this access. Colin explains the reason behind flaw 0x00030033 is that it disables both the Arm and RISC-V kernels, but the Arm disable instructions have a higher priority, leaving RISC-V running. Most importantly, the bug successfully cleared Debug_Disable.
image 1 to 2
For more information on the background of this hack, especially bypassing the guard-reading mechanism, we recommend watching the video recorded during 38c3 (link above). There is also an interesting Q&A at the end of the session. You may find attendees asking questions similar to those you may have.
Colin concluded his presentation with three eloquent points:
- The human connection factors are huge. Sideense (the company behind the memory technology used OTP NV) knew how to do guards right, but RPi missed it.
- “Permanent” is nothing unless it involves destroying the chip. There’s some copper somewhere with every signal…
- Remember to make mistakes in places they don’t tell you.
