And this explains why it's stayed unhacked so long. There was very little incentive to hack the system when the games are all playable on a PC. Pirates, cheaters, archivists, and hackers could just go there. Microsoft's best security measure was making something nobody cared enough about to hack in the first place
There's a great presentation by Tony Chen on the Xbox One's security features:
> https://www.platformsecuritysummit.com/2019/speaker/chen/
Examples of the kinda software you can put on the Xbox One in developer mode:
A lot of the early hacking focused on trying to breach the hypervisor from otheros. The hypervisor turned out to be quite secure, people smashed their heads against it for years until it finally fell to a memory glitching attack.
But turns out it was so much easier to just attack gameos with a USB exploit. The hypervisor did nothing to prevent it, and would then just decrypt games for you (because gameos was trusted)
The proof in the pudding of this will be when the Nintendo Switch 2 reaches 2035 with no cracks. That's my prophecy; that this time around the cat actually will catch the mouse. Between NVIDIA's heavily revised glitch-resistant RISC-V security architecture and Nintendo's impeccable microkernel, there's nowhere left to hide. DRM may turn out to have been a very slow long battle to "victory," not a "this will always be defeated."
Instead, they keep stripping stuff off the console. I'm still so annoyed that PS5 doesn't even have an integrated web browser anymore (especially trying to troubleshoot network issues from the console itself).
But hey, Sony can leave bullshit exploit vectors open like PPPoE clients on the console itself (why? just use a router?)...
My series x, combined with gamepass, is by a very large margin the most at-home-entertainment bang I have gotten for my buck.
Before then I had what could be regarded as a "vintage" gaming PC: 1st gen i7 (nehalem?), a gts 450 and some amount of ram. An upgrade (read: full replacement) was desperately needed. This was in the middle of the crypto gpu boom, so a decent GPU alone would've wiped my budget. I settled for an xbox as it was cheaper than a ps5.
I've always seen myself as part of the pc master race, and thought consoles to be very limited. But man, it just worked, the games just worked, and gamepass made it all a total steal.
Even now, when our 3 month old baby is settled for the night, me and my wife's preferred entertainment is a session of bg3 over watching tv.
Doing the math i can't find this to be true. As some one that has honed my taste in games, and have a large steam library, I don't spend as much money on games as game pass cost.
Seemed a credible comment till that point! (/s)
Congrats :-)
I get what this essentially means, but for those of us with a certain amount of love of language (or pedantry), it's fascinating to try and parse this literally because I don't quite think it works as intended.
Clearly the intended meaning is something like eclipsed in quality. And it may be overlapped in the sense that the same games are separately available on PC. But overlap isn't a relation of quality; quality is generally better or worse when it's comparative. So it's like a smushed together way simultaneously saying the selection of games on Xbone overlaps with what's available on PC and is also better quality on PC.
examples:
The 2013 system’s game library is largely overlapped, in better quality, on the PC platform.
The 2013 system’s game library is largely overlapped (in better quality) on the PC platform.
One of the reasons the Wii U was slow to be hacked was because Android TV boxes had come along plus things like Ouya/Nvidia shield, and it basically took away a lot of demand for a console turned into TV unit to use hacked software.
It still happened but not so quiclkly. Not like the original Wii which didnt really have much similar to it at the time.
Not the same as emulating its titles, but a lot of interest in the Xbone/series line (outside of actual console users) is the dev accounts. So I imagine a lot more effort went there first.
Then I'll finally hook up the XBOne I have again and put it to some use on the downstairs TV. I already have a 'retired' PS4 filling similar role on the upstairs TV (although it must stay offline to remain 'liberated').
Minecraft: Xbox One Edition (the Legacy version) was of keen interest to our community as it would be playing LCE natively on a PC if you used a compatibility layer which never happened before.
So a few of my LCE cult friends contributed to WinDurango which was pretty much dead before they joined, and got Minecraft: Xbox One Edition to work.
Of course, you'd ask "why don't you just play Minecraft on PC normally?" Legacy Console Edition has so many minute differences and details that it's impossible to discuss all of them--things as big as the Minigames and as small as the mipmaps.
And then LCE source code from 2014 got leaked and that had a native PC port. Oh well.
The parenthetical is not needed. It is OK to call Wine an emulator. The "Wine Is Not an Emulator" thing came about later and was essentially a marketing change. How it came about is interesting.
The first suggestion to change the meaning of the word from a shortening of "windows emulator to the not an emulator backronym was in 1993 over concern that "windows emulator" might run into problems with Microsoft trademarks, but no action was taken.
Over time the not an emulator usage became an accepted alternative. The Wine FAQ in late 1997 for example said:
The word Wine stands for one of two things: WINdows
Emulator, or Wine Is Not an Emulator. Both are right.
Use whichever one you like best.
This is release 981108 of Wine, the MS Windows emulator.
This is release 981211 of Wine, a free implementation of
Windows on Unix.
1. Wine was useful for more than just running Windows binaries on Unix. It could also be used as a library you could link with code compiled on Unix as an aide to porting Windows programs to Unix.
2. Hardware emulators that emulator old systems like GameBoy or Apple II had become popular. Many people were only familiar with that kind of emulator, and those (the emulators, not the people!) tended to be slow.
That was fine when your emulator is running on a machine with a clock speed 300x that of the machine you are emulating and that has a much more efficient CPU, but when you tried to use a hardware emulator for something comparable to your machine it was usually unbearably slow.
People only familiar with such hardware emulators might see Wine described as a Windows emulator and think it was doing hardware emulation and not even give it a try. By dropping calling it an emulator Wine sidestepped that problem.
Maybe that's what they're trying to achieve with Windows as well.
The people that MS hired to make and break this were top notch, and there is definitely incentive to maintain control over a content platform. This dude has been at this for /years/. I’ve been a fly on the wall on all sides to observe this.
There has been a lot of interest in underground / pirate communities to hack this, but that’s not the only reason why people hack things.
Irl noop and forced execution control flow to effectively return true.
B e a utiful
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 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 reassuring that the owner of a device will always own it, in the end.
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.
Extremely impressive feat nonetheless!
I think the security team would call their mitigations a success.
Has anyone heard of notable earlier examples?
I wonder if, assuming they continue making Xbox, they find a way to mitigate this in the next generation.
It sounds like that's the plan:
https://news.xbox.com/en-us/2026/03/11/project-helix-buildin...
I understand it's still more than most console makers do, having dev mode at all, but it's maddening to me that Microsoft made dev mode so annoying and limited. I'd honestly just rather a hack be available so we have the option of using the entire memory or repurposing banned consoles.
This was all after the DMCA was in effect. I don’t think that will stop this sort of activity.
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.
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.
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.
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.
The xbone's weakest security lasted nearly double the product's market life, and that's several times longer than security on the 360 lasted, if you don't count DVD firmware attacks, (which was also several times longer than the OGXB security lasted)
Xbox security has gone from lasting months -> years -> decade+. On top of that, the later revisions with better security have not been cracked.
BTW, what would be the specs for a Xbox 360? I remember the PS3 was a rather limited Linux workstation because it lacked RAM (and tge hypervisor limited access to the GPU - a limitation gone when jailbroken), but I haven’t read much about the 360 and its own weird PowerPC.
If kilobytes of storage and very limited computing power works for your use case, you can get very secure (smartcards and secure elements remain essentially undefeated at the hardware level; all attacks I know happened via weak ciphers).
For an entire current-gen gaming console, you'll have a much harder time.
Hardware you own should be yours to understand.
https://github.com/exploits-forsale/collateral-damage
What's new here is that this compromises the entire system security giving access to the highest privilege level.
I didn't ask but Emma -- who wrote the kernel-mode exploit -- and I would probably agree that Collat is not really what we would consider a proper hack of the console since it didn't compromise HostOS. Neither of us really expected game plaintext to be accessible from SRA mode though.
I think it was tuxuser, Torus, and Billy(?) who accomplished that. Hopefully not forgetting anyone critical.
Eventually Fort Knox will succumb to the unrelenting arrow of time and some future visitors will simply step over the crumbling wall and into the supposedly "secure" area.
a) this was a security win. millions and millions of people had physical access to the device for over a decade
b) as others have said, security is not all-or-nothing. the xbox one is extremely secure, despite not being perfectly secure.
c) just because something eventually gets hacked does not mean security was pointless. delaying access is a perfectly reasonable security goal. delaying access until the product is retired and the successor is already out on the market is a huge win.
This console went completely unhacked for 12 years, with this coming a solid 4 years after the hardware was discontinued. They kept piracy off the console for its whole lifespan, which was the entire point of these security measures. This is a massive success for the Xbox security team.
If hacking the xbox goes wrong, the hacker will short out the console. If hacking Azure goes wrong, the hacker will get shot.
Secure boot that can't be controlled by the user should be illegal, though. You should get some secret code along with a device, that allows you as the buyer to tamper with it. So much hardware out there can just serve as something else, or can be supported by people on a voluntary basis, sans the completely arbitrary lockdown of ability to install your own code to the device.
For something like a game console, that’s annoying, for a phone or laptop, that’s highly desirable if something like a TPM bug is fixed, without efuses the system would forever be vulnerable.
Who believes that ?
Yeah Apple does have "secure enclave" on some devices, and maybe in many cases it would wipe itself before you got in, but maybe that just means a more careful-hand is needed? (Again, physical access and extreme care/caution when debugging/investigating the chip should work eventually I think!) - I am not a hardware hacker, just have read about it quite a bit!
This talk about some of what went into it is fascinating: https://youtu.be/quLa6kzzra0
In many cases the truth is simply that its not worth the time/effort to hack it, so only the most dedicated perverts(with a positive connotation) keep trying.
Obviously nothing is ever unhackable, not even Fort Knox, given infinite time and resources, and Microsoft never made such claims, this is just media editorializing for clicks and HN eating the bait, but Xbox One was definitely the most unhackable console of its generation. Case in point, it took 13 years of constant community effort to hack a 499$ consumer device from 2013. PS4 and iPhones of 2013 have also been jailbroken long ago.
Therefore, even the click-bait statement with context in relative terms is 100% correct, it truly was unhackable during the time it was sold and relative to its peers of the time.
Can you attempt to quantify this effort in comparison to other game consoles? I'm not very familiar with the Xbox scene, but I would assume that there was a lot less drive to achieve this given that Xbox has never really had many big exclusive titles and remains the least popular major console (with an abysmally tiny market presence outside of the US).
As an aside, I wonder if Microsoft's extra effort into securing the platform comes from their tighter partnership with media distributors/streaming platforms and their off-and-on demonstrated desire to position the Xbox as a home media center more than just a gaming console.
Literally unhackable? XD
Most hacks are about cost, not possibility, and the economics for attacking consoles change when resale value, nostalgia, tooling, or side projects make the upside worth the work. People overestimate the "nobody succeeded" part and underestimate the "nobody cared enough yet" part.