We may have a winner for the $20,000 Raspberry Pi and Hextree RP2350 Hacking Challenge, but we won’t officially find out who the winner is until January 14. Engineer Aedan Cullen went public with his Hacking the RP2350 presentation at the recent 38th Chaos Communication Congress (38C3), and there is a GitHub repo now published to accompany the video here. Cullen studied the RP2350 in detail before going for a voltage injection glitch attack on pin 53 of the RP2350 chip, which managed to turn on the ‘permanently disabled’ RISC-V cores and their debug access port, enabling him to read the secret.
Raspberry Pi introduced the RP2350 via the Raspberry Pi Pico 2 as a successor to the RP2040 – with added security features to appeal to commercial and industrial customers. To publicize the new microcontroller it teamed up with Hextree to devise the RP2350 Hacking Challenge, announced at DEF CON in August. This challenge concluded on 31 Dec 2024, but we must wait until January 14 for the official winner announcement. Cullen made his presentation at 38C3 on Dec 27 and also shared a GitHub repo with an outline of his hacking process and Python code. However, we don’t know if Cullen is the winner, so this may not be the $20K winning hack method.
Specifically, the RP2350 comes with a quartet of new security features, that Raspberry Pi was keen to highlight. These are Secure Boot, TrustZone, Redundancy Coprocessor (RCP), and Glitch Detectors. The setters of the challenge hid a secret on one of these ‘fully secured’ chips, which would be supplied to hackers who applied, and the first demonstrable success story would get $20,000 and the kudos of being the winner of the challenge. Attacks using hardware and/or software means were permissible by the competition rules, so it was almost an anything-goes situation.
Raspberry Pi and Hextree would hide the secret in the RP2350’s OTP (One Time Programmable) memory on the chip, said to be a once-set but never-forget binary code. Picotool was used to write the covert code to the OTP. Then the RP2350’s OTP memory was locked behind the Page Locks hardware protection feature, set to an ‘inaccessible’ state ’13:12′ as per the table above. Firmware was also signed, with Secure Boot enabled, and they disabled the chip debug feature, so prying eyes couldn’t get to the secret via a Serial Wire Debug (SWD) interface. Furthermore, all other bootkeys were disabled, the RP2350 Glitch Detector was turned on and then set to its highest sensitivity. It certainly sounds like it was locked down.
Cullen says he started his hacking process by studying the RP2350 data sheet and the dependencies outlined in the documentation. Then Cullen drilled down on how the RP2350 boots and establishes its security settings, with particular attention to the OTP.
Cullen’s first idea was to get the OTP to misread its critical bit settings, you could get the chip to work in a non-secure way. Cullen even X-rayed the RP2350 as part of his investigations and annotated the chip blocks. However, he stresses that this was just a pursuit of interest and not really instrumental to beating the challenge.
Research compelled Cullen to focus on Pin 53, labeled USB-OTP_VDD, as it is connected to OTP (and USB) functions. Perhaps a hacker could “mess with this power supply externally” to affect these functions, he pondered. So he took off the chip and isolated Pin 53 (physically cutting PCB trace), so it was ready to be electrically tampered with separately on a reassembled board.
Image 1 of 3
With this hardware-modified setup, Cullen probed Pin 53 to “inject whatever voltages I want” and checked what happened. An unprotected RP2350 board was kept on hand for side-by-side comparisons. Once the hardware was set up he watched what normally occurs when a secured and a non-secured RP2350 started up – according to the probe readout on an oscilloscope.
16 groups of spikes were seen, corresponding with 16 initial OTP reads on startup. Cullen then tested injecting power glitches to Pin 53 at certain points in the boot process. Disappointingly, the debug remained locked down. Next, a Python script was used to sweep the position of a glitch power input through the entire 600-microsecond range of OTP reads during startup. The debug functionality was checked but never became available. So Cullen looked at the unlocked RP2350 board again, with debugging enabled, for clues.
Then, something interesting was observed, as the RISC-V cores showed up via the glitch on the unsecured RP2350. Cullen then used another script to check where the RISC-V debug access port shows up. This technique could also be triggered on the secured RP2350 – and a debugger could now be connected to the secured RP2350 and the secret read from the OTP!
Secret gets busted
The ‘permanently disabled’ RISC-V cores had been woken by the glitch to enable this access. Cullen explains the odd underlying reason that the glitch 0x00030033 works is that it disables both Arm and RISC-V cores but, the Arm disable instruction has higher priority, leaving RISC-V turned on. Importantly the glitch successfully clears Debug_Disable.
Image 1 of 2
For more information about the background to this hack, particularly bypassing the guard read mechanism, we advise watching the video recorded during the 38c3 (linked top). There’s also an interesting Q&A at the end of the session. You might find attendees ask similar questions to those you may have.
Cullen concluded his presentation with three pithy points:
- Human communication factors are huge. Sidense [the company behind OTP NV memory tech used] knew how to do guards properly, and RPi missed out.
- “Permanent” is not a thing unless it involves chip destruction. There is some copper somewhere with each signal…
- Remember to glitch in the places they don’t tell you.
