Hacker News Reader

Comment by ThrowawayTestr | Hacker News Reader

Is there any mitigation against these kinds of power/timing attacks? I think the Switch was originally hacked this way.

No, not without changing microprocessors.

Essentially these chips are locked by setting certain flags in memory. Various flags control various peripherals, including a flag to disable read/write access to the firmware. Obviously once you disable access, it’s permanent because you don’t have access to reenable it.

This side channel attack takes advantage of a flaw in the actual silicon, where branches can be skipped if the power is altered momentarily. So if you skip that first check, the attacker has low level firmware control.

(This was also how the firmware was dumped on the Apple AirTags)

The only mitigation is to use a chip that doesn’t suffer from this flaw or change the software to prevent “root” access even if an adversary has access to the entire firmware (ie do things server side)

Xbox 360 had the reset glitch hack where if you powered cycled the chip at the exact right timing you could run unsigned code. It required a small mod chip soldered to some of the smallest points on the motherboard that I have ever soldered. Different versions of the 360 worked better but most worked even if it took a minute or so before the glitched worked and booted into custom firmware. Mine worked really well and booted first try almost every time. I was very proud to successfully install it and watch my 360 boot into fsd a custom OS that allowed me to play all my games from a HDD.

That's what I was thinking of, the 360 not the Switch.

Yep - the Switch had an issue in the mask ROM / first stage bootloader too, but it was a traditional software one, where the recovery mode bootloader passed an unverified length to a memcpy and smashed the stack.

I love that buffer overflows remain a tried and true method of hacking even with of all our modern technology.

The newest glitch hack v3 is really cool in that it uses the 360 southbridge to do the glitching without a external mod chip.

You can make the code more robust. For example, instead of a yes/no check, make the check come up with a symmetric crypto key to decrypt the next chunk of code (if it also passes a hash check). Glitches will end up generating garbage, and even if you successfully glitch the hash check, you're executing random garbage.

Of course, the challenge there is that you've merely eliminated one glitching candidate.

Stuxnet had code blocks that encrypted by a hash of target hardware identifiers. No way to know what all code is contained, until it happens to run on the target system.

https://blog.quarkslab.com/bradley-hash-and-decrypt-gauss-a-...

I don’t think you can eliminate them, just make them harder to exploit. Require multiple glitches to succeed etc.

Agreed, usually if they have hardware access it’s gonna be cracked eventually. Hard to imagine a system that was truly unhackable with infinite unrestricted physical access.

Usually equipment that has to be robust against this attack will have things like tamper switches that wipe storage keys and brick the device if it’s opened. I’d assume they also have software tripwires too if you manage to get the access you need (for instance if you drilled holes through the enclosure to access areas you needed without opening it - although if you really wanted to stop that you can do things like potting much of the board in epoxy that is extremely difficult to remove without destroying things).

New hardware revisions are required to fix usually. You can probably detect a compromised terminal on the network though.

This particular glitch seems to rely on Unix shells not differentiating between false test and failure. Implementing this in any other language would have avoided this particular glitch.

The article said SL already deployed one mitigation.

The problem with mitigations is that they are just speed bumps.

Reply on news.ycombinator.com