Glitching a microcontroller to unlock the bootloader | Hacker News Reader

Glitching a microcontroller to unlock the bootloader

grazfather.github.io

103 pointsGraziano_M23 comments

The author uses an FPGA, which is notoriously hard to program for. In the recent years, microcontrollers have become more and more capable: for example the Raspberry Pi Pico costs about 4 USD and can run at 250MHz and up. Thanks to PIO (programmable IO), which is basically a small programmable state machine running on the IO pins, it's possible to use this for voltage glitching attacks.

You realize that Intel and AMD and countless electronic engineers learned to program them right? How do you think those "capable" microcontrollers' main microprocessors are designed?

It's worth mentioning that there's the Raspberry Pi Pico W with integrated Wifi support, that makes it an alternative to the ESP32 in many projects (it's about 9 USD, though).

Glitching attacks are very cool, and I've never seen formal security research explaining how to defend against them.

Has anyone?

The simple example in the article is demonstrated: you have a fail safe condition, not a fail open condition. Since you only need to flip one bit, unlocking the bootloader is trivial. If you need to flip multiple bits, in a specific pattern, this makes the challenge exponentially more difficult.

For something like the reset glitch hack on the Xbox 360, for example, they were glitching a single opcode to do the compare with the checksum. Multiple ways to defend/harden against that attack (which, likely, were implemented on the Xbox One).

As also mentioned in the article, the glitch could've affected the branching or comparison part of the code, so you may still be able to glitch a chip with the proposed solution.

Another tactic is to run the check a bunch of times, maybe in parallel. If any of them don't match then assume locked or halt. Getting multiple glitches to each hit each check in the same way is very difficult.

Literally something like

   if (read_flash(0xdeadbeef) != 0x1234) {
       count += 1;
   }

   if (read_flash(0xdeadbeef) != 0x1234) {
       count += 1;
   }

   ...

but of course, then you have to worry about how `count` is being checked.

Quick search turns up this research paper that talks about glitch defense in software. It's a tough attack to completely mitigate just because it attacks the hardware directly but the timing is extremely difficult to hit even without active defenses so some basic fixes might be able to make the attack functionally unworkable just due to the difficulty of successfully executing it even if the underlying issue persists.

I completely forgot to actually link the paper I was talking about: https://sites.cs.ucsb.edu/~vigna/publications/2021_DSN_Glitc...

the problem is that glitching attacks target the specification approach that engineering has been based on for at least a century, where the vendor promises that if their component is operated under some set of nominal operating conditions, it will perform within some nominal performance range, but promises nothing about what will happen if operated under some other conditions, or where its performance will lie within that range

a bolt, for example, will have tensile strength and pitch diameter within a certain specified range as long as the temperature is within some given range (and it hasn't previously been exposed to excessive stress or temperature), and a resistor will have its resistance, temporal drift, physical dimensions, inductance, etc., within a certain specified range as long as the temperature is within some given range and it hasn't been previously overheated

the specifications for a microcontroller sometimes run to thousands of pages

vendors are free to include other features not documented in the spec, such as undisclosed debug ports, and to switch from one supplier to another whenever they like as long as the product still meets the spec

in glitching attacks the attacker operates the components outside their nominal ranges, where the vendor offers you no guarantees of what will happen. higher clock speeds, shorter write times, lower voltages, higher temperatures, shorter setup and hold times, etc. even if one vendor does try to offer such guarantees, generally their product includes parts and processes sourced from other vendors who don't

so i don't think it's yet something you can define crisply enough to mount a general defense; glitching attacks are enabled by a social system that creates new vulnerabilities much more rapidly than they are closed

To add on, there are a good amount of effort put in to defending against side channel attacks, including hardware IP like [1]. However, it's not a winnable game when your adversary has access to your hardware. If they're determined enough, they can use SEM microscopes and expensive equipment to physically rewire your chip, bypassing circuitry arbitrarily.

[1] https://www.agileanalog.com/ip-by-product-type/agilevglitch-...

side channel attacks attack the other side of the specification approach from glitching attacks, where the product is allowed to perform anywhere within the specified performance range as long as it's operated under nominal conditions

i think this is a much more feasible thing to defend against than glitching attacks, though still difficult for similar supply-chain reasons

what you are describing is, in my book, a glitching attack, not a side channel attack

I misspoke, you are correct.

they're very closely related tho

a solution has been around for ages: lockstep processors.

https://www.microcontrollertips.com/dual-core-lockstep-proce...

https://www.synopsys.com/designware-ip/processor-solutions/a...

1. Check more than 1 bit. 2. Add glitching detection circuitry. 3. Randomize when you do the check.

Have another circuit on-chip which is more sensitive to glitches than the CPU.

Whenever that circuit detects a glitch in the clock, the power supply, the reset line, electric fields or magnetic fields, it halts the CPU until the whole system is reset.

Not very hard to build - I don't know why every chip doesn't include it by default. As well as protecting against deliberate attacks, it would also protect against accidentally running a chip out of spec - for example not having decoupling capacitors on the power supply, causing intermittent behaviour.

It's often called "brown out reset." They are fiddly and frequently get disabled because they're in the way of development.

I'm confused. Don't iCE40 have a PLL?

I do not have that specific devboard, but I've run designs at ~70MHz.

It does, and I mentioned that I tried to use it but had issues, so I got it to work at its default clock rate.

Intuitively, I suspect running everything with the PLL clock would have been best, as crossing clock domains is itself a source of pains.

Also, I'd ensure I feed the clock network with the PLL output. Not using the clock network is also a potential source of issues.

Yeah, I've since learned about the metastability issues of that sort of thing and probably could get it to work by doing just that, but I've long put this project to bed.

This is incredibly cool. The FPGA allows such precision that I'd suggest it's not even technically glitching, and more of a hardware MITM

Reply on news.ycombinator.com