crtasmMicrosoft's 'unhackable' Xbox One has been hacked by 'Bliss'
Created a voltage drop that exactly occurred to be timed to the key comparison, then a spike at the continuation.
Irl noop and forced execution control flow to effectively return true.
B e a utiful
The earliest example I know of for this is CLKSCREW, but security hardware (like for holding root CA private keys) was hardened against this stuff way before that attack.
Has anyone heard of notable earlier examples?
In terms of fault injection as a security attack vector (vs. just a test vector, where it of course dates back to the beginning of computing) in general, satellite TV cards were attacked with clock glitching at least dating back into the 1990s, like the "unlooper" (1997). There were also numerous attacks against various software RSA implementations that relied on brownout or crowbar glitching like this - I found https://ieeexplore.ieee.org/document/5412860 right off the bat but I remember using these techniques before then.
It's fascinating - how does one defend against an attacker or red-team who controls the CPU voltage rails with enough precision to bypass any instruction one writes? It's an entirely new class of vulnerability, as far as I can tell.
This talk https://www.youtube.com/watch?v=BBXKhrHi2eY indicates that others have had success doing this on Intel microcode as well - only in the past few months. Going to be some really exciting exploits coming out here!
m0leCon 2025 - Federico Cerutti - Voltage Glitching Intel Microcode
You can't. Console makers have these locked-down little systems with all the security they can economically justify... embedded in an arbitrarily-hostile environment created by people who have no need to economically justify anything. It's completely asymmetrical and the individual hackers hold most of the cards. There's no "this exploit is too bizarre" for people whose hobby is breaking consoles, and if even one of those bizarre exploits wins it's game over.
And if you predict the next dozen bizarre things someone might try, you both miss the thirteenth thing that's going to work and you make a console so over-engineered Sony can kick your ass just by mentioning the purchase price of their next console. ("$299", the number that echoed across E3.)
> You can't
It's a moot point, they are not trying to prevent it. They only need to buy enough time to sell games in the lifespan of the hardware, which they did.
> all the security they can economically justify...
It seems like they did a perfect job, it lasted long enough to protect Microsoft game profits.
> how does one defend against an attacker or red-team who controls the CPU voltage rails
The xbox does have defences against this, the talk explicitly mentions rail monitoring defences intended to detect that kind of attack. It had a lot of them, and he had to build around them. The exploit succeeds because he found two glitch points that bypassed the timing randomisation and containment model.
I hope Apple is paying attention, since their first gen AirTags are vulnerable to voltage glitching to disable the speaker and the tracking warning.
It's pretty trivial to just open it up and disconnect the speaker too. I took one apart to make a custom wallet card out of it and broke the speaker in doing so; the rest of it worked perfectly fine (though obviously the warning would still work).
I don't see much motivation for fixing that when I can purchase a nrf52xx Bluetooth Beacon on aliexpress for €4 and flash it with firmware that pretends to be 50 different airtags, rotating every 10 minutes, and therefore bypassing all tracker detections.
What's the battery life like on one of those?
> It's an entirely new class of vulnerability, as far as I can tell.
It is know as voltage glitching.
If you're interested our research group applies to Intel CPUs.
https://download.vusec.net/papers/microspark_uasc26.pdf
It's not new - fault injection as a vulnerability class has existed since the beginning of computing, as a security bypass mechanism (clock glitching) since at least the 1990s, and crowbar voltage glitching like this has been widespread since at least the early 2000s. It's extraordinarily hard to defend against but mitigations are also improving rapidly; for example this attack only works on early Xbox One revisions where more advanced glitch protection wasn't enabled (although the author speculates that since the glitch protection can be disabled via software / a fuse state, one could glitch out the glitch protection).
The Xbox 360 was hacked in a simpler but nearly identical way [1]! Amazing that despite the various mitigations, the same process was enough to crack the Xbox One.
RGH/RGH3
RGH 3 is a modern method of the Reset Glitch Hack that uses the SMC in the Xbox 360's southbridge instead of an external glitch chip in order to boot unsigned code. MrMario2011 has video guides for RGH 3 on Falcon/Jasper, Trinity, and Corona motherboards respectively. The guides from Larvs on Xbox 360...
But it took them 4x as long to be successful against the xbone.
I think the security team would call their mitigations a success.
No? It is crowbar voltage glitching, but you're significantly underselling it here. The glitching does not affect key comparisons.
It's a double-glitch. The second glitch takes control of PC during a memcpy. The first glitch effectively disables the MMU by skipping initialization (allowing the second glitch to gain shellcode exec). (I am also skipping a lot of details here, the whole talk is worth a watch)
This sounds like a way less crude version of the way many unlicensed NES cartridges got around the lockout chip. Just charge a capacitor and blast it at boot time.
Amazing talk. Here's a quick writeup if you don't want to watch the full hour or don't have enough hardware knowledge to follow what Markus is talking about, as he goes very fast, in some cases too fast to even let you read the text on his slides. It's mandatory to use the pause key to understand the full details even if you have a deep understanding of every relevant technology, of which he explains none.
The Xbox uses a very advanced variant of the same technologies that also exist on smartphones, tablets and Secure Boot enabled PCs. When fully operational the Xbox security system prevents any unsigned code from running, keeps all code encrypted, proves to remote servers (Xbox Live) that it's a genuine device running in a secure state, and on this base you can build strong anti-piracy checks and block cheating.
The Xbox has several processors and what follows applies to the Platform Security Processor. When a computer starts up (any computer), the CPU begins execution in a state in which basically nothing works, including external communication and even RAM. Executions starts at a 'reset vector' mapped to a boot ROM i.e. the bytes are hard-wired into the silicon itself and can't be changed. The boot ROM then executes instructions to progressively enable more and more hardware, including things like activating RAM. Until that point the whole CPU executes out of its cache lines and can't use more memory than exists on-die.
Getting to the state where the Xbox can achieve all its security goals thus requires it to boot through a series of chained steps which incrementally bring the hardware online, and each step must verify the integrity of the next. The boot ROM is only 19kb of code and a few more kb of data, and can't do much beyond just activating RAM, the memory mapping unit (called MPU on the Xbox), and reading some more code out of writeable flash RAM. The code it reads from flash RAM is the second stage bootloader where much more work gets done, but from this second stage on it can be patched remotely by Microsoft. So if bugs are found there or in any later stage, it hardly matters because MS can issue a software update and detect remotely on Xbox Live servers if that upgrade was applied, so kicking out cheaters and pirates. The second stage boot loader in turn loads more code from disk, signature checks and decrypts it, sets up lots of software security schemes like hypervisors and so on, all the way up to the OS and the games.
Therefore to break Xbox security permanently you have to attack the boot ROM, because that's the only part that can't be changed via a software update. It's the keys to the kingdom and this is what Markus attacked. Attacking the boot ROM is very, very hard. The Xbox team were highly competent:
• Normally the bringup code would be written by the CPU or BIOS vendors but MS wrote it all in house themselves from scratch.
• The code isn't public and has never leaked. To obtain it, someone had to decode it visually by looking at the chip under a scanning electron microscope and map the atomic pictures to bits and then to bytes.
• Having the code barely helps because there are no bugs in it whatsoever.
So, the only way to manipulate it is to actually screw with the internals of the CPU itself by "glitching", meaning tampering with the power supply to the chip at exactly the right moment to corrupt the state of the internal electronics. Glitching a processor has semi-random effects and you don't control what happens exactly, but sometimes you can get lucky and the CPU will skip instructions. By creating a device that reboots the machine over and over again, glitching each time, you can wait until one of those attempts gets lucky and makes a tiny mistake in the execution process.
Glitching attacks predate the Xbox and were mostly used on smartcards until the Xbox 360, which was successfully attacked this way. So Microsoft knew all about them and added many mitigations, beyond "just" writing bug free code:
1. The boot ROM is full of randomized loops that do nothing but which are designed to make it hard to know where in the program the CPU has got to. Glitching requires near perfect timing and this makes it harder.
2. They hardware-disabled the usual status readouts that can be used to know where the program got up to and debug the boot process.
3. They hash-chain execution to catch cases where steps were skipped, even though that's impossible according to program logic.
4. They effectively use a little 'kernel' and run parts of the boot sequence as 'user mode' programs, so that if sensitive parts of the code are glitched they are limited in how badly they can tamper with the boot process.
And apparently there are even more mitigations added post-2013. Markus managed to bypass these by chaining two glitch attacks together, one which skipped past the code that turned on the MMU, which made it possible to break out of one of the the usermode 'processes' (not really a process) and into the 'kernel', and one which then was able to corrupt the CPU state during a memcpy operation, allowing him to take control of the CPU as it was copying the next stage from flash RAM.
If you can take control of the boot ROM execution then you can proceed to decrypt the next stage, skip the signature checks and from there do whatever you want in ways that can't be detected remotely - however, the fact that you're using a 2013 Phat device still can be.
Thank you, sincerely. My main question now is, what degree of repeatability has Markus achieved so far?
On Phat consoles? You could turn it into a modchip, if for some reason you wanted to. It'd be repeatable on every boot but might take a while.
The hard work comes after this though. There are lots of software level mitigations MS could use to keep the old devices usable with Xbox Live if they really wanted to. Just because you can boot anything you want doesn't mean you can't be detected remotely, it just makes it harder for MS to do so reliably. You'd be in a constant game of catch-up.
> It's mandatory to use the pause key to understand the full details
I was going to say I disagreed but the rest of your comment reminded me that I've accumulated a lot of domain-specific knowledge.
What I meant is that at points he skips past slides so quick even very fast readers can't absorb every bullet point. I read at ~2-3x the average speed, have lots of domain knowledge and couldn't read fast enough to get every word on every slide. So the pause key is very useful for that even if you know what's coming.
I read at Normal speed but I didn't feel that way when watching. I believe you though, I was just having an XKCD 2501 moment.
Thanks for this writeup as I haven't had time to review the video yet :)
So, the only way to manipulate it is to actually screw with the internals of the CPU itself by "glitching", meaning tampering with the power supply to the chip at exactly the right moment to corrupt the state of the internal electronics. Glitching a processor has semi-random effects and you don't control what happens exactly, but sometimes you can get lucky and the CPU will skip instructions. By creating a device that reboots the machine over and over again, glitching each time, you can wait until one of those attempts gets lucky and makes a tiny mistake in the execution process.
Considering that the PSP is a small ARM processor that presumably takes up little die space, would it make sense for it to them employ TMR with three units in lockstep to detect these glitches? I really doubt that power supply tampering would cause the exact same effect in all three processors (especially if there are differences in their power circuitry to make this harder) and any disrepancies would be caught by the system.
The Nintendo switch 2 uses DCLS (Dual-core lockstep) in the BPMP and PSC (PSC is PSP-like but RISC-V). So yes, it helps - I'm unsure if/where msft uses it on their products.
DCLS actually makes sense for this scenario as the fault tolerance gained from having three processors isn't needed here. The system can halt when there's a mismatch, it doesn't have to perform a vote and continue running if 2 of 3 are getting the same result.
Also I just thought of this but it should be possible to design a chip where the second processor runs a couple cycles behind the first one, with all the inputs and outputs stashed in fifos. This would basically make any power glitches affect the two CPUs differently and any disrepancies would be easily detected.
Just wanted to say this is an amazing technical writeup, thanks for sharing.
Could this technique be used to reverse-engineer end-of-life Nvidia GPUs to improve Noveau on them?