Replicating a Voltage Fault Injection Attack on a Bitcoin Cold Wallet
Have you ever wondered about what acually Chip Does, or how it actually process something, or even how to interrupt it in a way that makes the chip bypass something?. At first glance the hardware itself may not be interesting, so let’s take a look closer. Welcome to the Hardware Hacking world!
The Hardware
STM32F205 based Trezor One Model
Firstly, the case needs to be removed carefully which eventually exposes Debug pins located on the left side of the device. Those pins are Reset, Ground, SWO, SWCLK, SWDIO, and VDD/ 3.3v Respectively. Trezor one use STM32F205 as a main chip also known as Micro Controller Unit (MCU). Three capacitors which have to be removed are Reset Capacitor, and VCAP1 & 2 Capacitor. Those capacitor work like a tiny battery to prevent the device from power surge which might harm the components.
Secondly, two SMA pins need to be attached to VCAP1 whose Capacitor has been removed along with a 10 ohm resistor on Measurement part. Keep in mind that the wire should be “as short as humanly possible” to prevent signal quality degradation. Another note is that the whole devices should share a common ground so that a short circuit won’t occur.
Chip Whisperer and STLink
The next step is connecting the Chip Whisperer and STLink to the target in the following order:
Preparing The Attack
Firmware Analysis
Since trezor is an opensource platform, a firmware analysis can be performed by downloading the frimware from Trezor’s github repository.
Measuring the Power Trace from VCAP
After the hardware has been completely set up, next stage is measuring the power trace from VCAP. During this stage, no glitch is needed because our goal is to analyze the trace so then the glitch can be shot right in the bull’s eye. More over, during this experiment, I used Jupyter Notebook to control the hardwares and was assisted by Claude Code to generate the code.
The chart shows power trace while the target is powered by 3.3volt. We can see various activity regions marked on the red boxes. Our actual target would be the SRAM and Flash which are only accessible on RDP 1 and RDP 0. By analyzing the trace, we can identify which specific area should be glitched and it is at between 180 us-250 us (Immediately after Start of boot rom and before the Flash Memory Access).
STM32F205 Security Feature
By default, STM32F205 has security protection called RDP (Readout Protection), separated on 3 levels , as follows:
Our target is to glitch the Main Controlling Unit and bypass the Readout Protection, making it’s restricted area and file could be discovered. By default, Trezor One model applied RDP2 as a Factory Standard and in this experiment we would like to bypass it to RDP1.
Shaping the glitch (Voltage Fault Injection)
Before shooting the glitch to VCAP1, it is necessary to shape the glitch to ensure that it is sufficient. The more power the glitches have, the more likely they are to lead to a broken devices and in contrast, the less power the glitches possess, the less effect they might have. For STM32F205, i found these configuration is the sweet spot: (I found that 190–192 us was my sweet spot.)
scope.glitch.ext_offset = 38017 <- could possibly change # when (5 ns cycle)
scope.glitch.repeat = 40 # Wide (5 ns cycle)
scope.io.glitch_lp = scope.io.glitch_hp = True # how strongAfter setting the glitch, try to ensure that the glitch is landed perfectly on the target.
Get Amadeus Pondera’s stories in your inbox
Join Medium for free to get updates from this writer.
Without Glitch:
Using Glitch:
The first chart shows no dip has occurred while the second chart shows a dip has occurred right after the glitch was shot. The dip indicates that the glitch has successfully landed and the power significantly drops but returns back to the line in order to keep the device alive.
Performing The Attack
Defining the Goal
As mentioned before that the main goal of this experiment is to collect information from SRAM which only accessible from STLink when RDP1 is reached. By default, when RDP2 is active, the device won’t communicate with STLink because RDP2 has no privilege to do and when STLink detects “IDCODE” then the glitch has successfuly downgraded the RDP2 to RDP1.
Analyzing the Output
After RDP1 has been bypassed we could extract SRAM from the device. STM32F205 has 128KB sram and 131072 Byte named sram.bin has been extracted from the device and is a perfect match.
Conclusion
After several weeks of conductiong the experiment with Trezor One and STM32F205, the conclusion that i’ve come to is that the MCU (hardware) remains vulnerable to a Voltage Fault Injection while the Firmware and bootloader (Software) have been patched, therefore even though SRAM has successfully Extracted but no seed or pin was disclosed. However, The STM32F205 Bootloader Readout Protection is proven to be bypassed using a Voltage Fault Injection attack during this experiment, allowing an attacker to gain privileged access, but a deeper analysis is needed to escalate the impact. As a future work, targeting a RDP0 is an interesting goal as well as performing Electro Magnetic Field Injection (EMFI) on the same target. Demonstrating a security on a Hardware level indeed have different difficulities and technical hurdles that can occur when replicating this attack. Hardware Hacking is a non-determenistic process and a successful glitch also can be influenced by a temperature, and light intensity.
This is not a Novel technique, this has been disclosed since 2019 by Colin o’ flynn, and i’m just replicating the attack.
References
- https://www.youtube.com/watch?v=4u6BAH8mEDw
- https://wallet.fail/
- https://chip.fail/
- https://colinoflynn.com/2019/03/glitching-trezor-using-emfi-through-the-enclosure/
- http://grandideastudio.com/wp-content/uploads/adventures_of_wallet_hacking_slides.pdf
- https://www.st.com/resource/en/datasheet/stm32f207vg.pdf
- The Hardware Hacking Handbook: Breaking Embedded Security with Hardware Attacks https://www.goodreads.com/book/show/39729632-the-hardware-hacking-handbook
