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!
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.
Its more that its really hard to do security when the attacker has unlimited physical access.
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
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.)
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.
It's reassuring that the owner of a device will always own it, in the end.
Low-voltage detection is usually implemented as simple comparator which should trigger instantly, but often only on a single Vcc pin, and due to the decoupling caps found on a typical circuit design there is effectively an RC circuit that filters short fluctuations of supply voltage. So most low-voltage detection implementations only trigger on 'longer' periods of low voltage.
Traditionally low-voltage detection features (like brown-out detection) are there to guarantee functionality of the uC itself or the device the uC controls. It is typically not intended as a defence measure against these types of attacks. In fact, 15 years ago it may not have been much of a concern.
Defend against it one way by voltage monitoring or physical intrusion detection, and another way by droop and such detection and countermeasures on the device. Both probably just increase the cost of hacking it by some orders of magnitude, but that may be enough.
You can do things like efuses that basically brick devices if something gets accessed, but that becomes a matter of whether the attacker falls for the trap.
If your argument is that you can't hope to close every door, then AI will make it easier to close all the doors in the future.
AI could also make it easier to open the doors too.
It took more than a decade to exploit this vulnerability and even then there are fairly trivial countermeasures that could have been used to prevent it (and that are implemented in other platforms.)
Nothing is unhackable, but it requires a very peculiar definition of "game over".
(And as others have pointed out: only early versions of this Xbos One where vulnerable to this attack.)
When it comes to SOC security, the past is not a good predictor of the present. The previous Nintendo SOC was designed 15 years ago. A lot has been learned since. It's become increasingly harder to bypass these mechanisms.
The fact that it took 13 years to hack the Xbox One is not because it's not an attractive platform: because of its high profile, it has been a popular subject for security research grad students from the moment it was released. And if anything, the complexity of the current hack shows how much SOC security has progressed over the years.
But this exploit shows that it's still almost impossible to protect yourself from motivated attackers with local access. All of that security stuff needs to get initialized by code that the SoC vendor puts in ROM, and if there's an exploit in that, you're hooped.
Extremely impressive feat nonetheless!