> Whether PC users, our core readership, will be interested in actually emulating Xbox One, looks unlikely. The 2013 system’s game library is largely overlapped in better quality on the PC platform.
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
The other major incentive for hacking the console Microsoft removed was for the first time on a modern mainstream home console to allow side loading of homebrew code/emulators etc. The console supported a developer mode that allowed side loading of third party applications, so folks could get emulators and other traditionally "banned" content on the console through an officially supported route.
There's a great presentation by Tony Chen on the Xbox One's security features:
The PS3 was incredible value dollar-to-flop, given that it was sold at a loss. This resulted in universities and other research institutes buying them en masse to create supercomputer clusters. Naturally buying thousands of consoles but not a single game puts sony in a difficult position. Although I think it's sad the hardware got locked down in later revisions, I fully understand why they did it.
The marketing win of being able to say "these are so poweful, the military literally uses them in supercomputers" certainly more than makes up for a hundredth of a percent of consoles having a zero attach rate.
The US Department of Defense went quite a bit further. They created the Condor Cluster in 2010 which was comprised of 1760 PS3s. At the time it was placed 33rd worldwide for a supercomputer.
I would be curious to know more precise numbers. My intuition suggests that when Sony sells millions of them, the number diverted for non-gaming purposes is maybe thousands or tens of thousands.
I've seen this argument, but I strongly suspect that it's a cope argument. "We couldn't get in... because... we didn't care to! Even though we've hacked literally every other object on the planet just because."
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."
I have my doubts. I suspect that Nvidia have made mistakes.
Anyway, situations like the one you describe are one to be solved by legislation requiring certain devices be sold as open devices that put power in the hands of the owner.
Well, and these systems are also designed with ratchet-type measures in place from the get-go, where holes are plugged, fuses are burned, and newly released titles will only decrypt/run on the latest OS.
So even if Switch 2 doesn't make it all the way to 2035 with zero cracks, there's a strong likelihood that any exploits found will be short-lived.
Which incentivizes people to hold on to exploits for as long as possible, ideally past the console life cycle, just to make sure it can be used, which already is a thing
> There was very little incentive to hack the system when the games are all playable on a PC.
There's a terrific incentive: Being able to play games without Steam or DRM in a portable format (possibly one file per game). Emulation is beautiful[1] and this time it may come at native speeds considering the Xbox One uses x86 architecture.
This is true, but it is also true that the Xbox One's security architecture and mitigations were ahead of its time. It would've taken a while to hack even with stronger incentives to hack it.
One thing PC does not have are the Xbox/Xbox 360 updated games. Microsoft did a great job of making the old games playable on Xbox One with better resolution, performance, etc. It would be nice to play the exclusive games of those consoles on PC through this.
>The 2013 system’s game library is largely overlapped in better quality on the PC platform.
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.
Yes, but the grandparent poster and I would agree that the parse is not that ambiguous/the meaning is easily inferred. The sentence states that the library is overlapped _and_ that overlap is available in better quality: it may seem contrived, but it reads as a rather natural collapse of an implicit conjunction to me.
Most of what was done on an original modded Xbox can be done on a retail stock Xbox One/Xbox Series with the exception of pirated Xbox games. Kodi (formerly known as XBMC) is just in the Xbox store, emulators and homebrew can be setup through dev mode with a little effort and $20. It's really just pirated versions of Halo 5 and a few others missing.
I know that's been dropping my level of interest for hacking consoles farther and farther. Why hack a console when it has almost no exclusives, even fewer of which I personally care about, and having a real computer hooked to a TV is no longer weird or difficult? I could fight to put an emulator on some locked down console or I can just install an emulator for almost everything ever made in like 10 minutes on my Steam Deck, so the choice is pretty obvious.
The Xbox One has been emulated though (well not emulated, it's a compatibility layer like Wine). Before this hack, there was Collateral Damage. We were able to dump games with the exploit.
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.
Also getting a dev account and loading up RetroArch/emulators in general is trivial. Best use of an Xbox one for sure. Well documented and exploited at this point.
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.
I was vaguely aware this is possible although the "sign-up for a dev account and boot it in dev mode all the time", even if free, was still enough of a barrier that I haven't done yet. I'm hoping this hack eventually leads to a simpler "one-click" way to run emulation, home brew and mods while still maintaining full original game and media playing functionality.
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').
How is this the first I’m hearing of it? Looks like I finally have a reason to own an x-box, aside from the best version of Perfect Dark (the HD release of the original with modern controls, I mean) being on the 360.
They used to charge too but now it’s free. I got mine set up after about 30min of work a few weeks ago just need to actually load it up now. It’s tedious and you have to share your personal ID but it’s not difficult.
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)
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!
> 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.
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).
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).
I'm not at all familiar with the Xbox One, but this is a feature that's generally available if you're designing "closed" hardware like a console. Most SoC these days have some sort of security processor that runs in its own little sandbox and can monitor different things that suggest tampering (e.g. temperatures, rail voltages, discrete tamper I/O) and take a corrective action. That might be as simple as resetting the chip, but often you can do more dramatic things like wiping security keys.
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.
This attack is on the early models that didn't have those protections enabled. The researcher surmised that later models do indeed have anti-glitching mechanisms enabled.
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.)
Basically if someone has physical access to device, its game over.
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.
> Basically if someone has physical access to device, its game over.
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.)
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.
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.
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.
I read this book last year and this application is spot on. There is a point in the narrative when the company automates a step in their manufacturing using an expensive machine and it has the effect developed here: the next step in the process is backed up further.
The points specific to software where it might not even be producing in-spec is also very good.
Comments that cite the solo dev/prototype case are of course not what this is getting at, but it's one good use of quick generation.
I would extend this article by saying what The Goal says, namely that the goal of every firm is to make money, and everything is intermediate to that. So whether or not software architecture is grade-A or grade-C, it's only ever in this subservient role to the firm's goal.
The presentation notes that this hack currently only works with the first revision of silicon. Later variants have more protections, like some anti-glitching tech that wasn’t quite debugged for the early units being enabled for later runs, and further changes with the security / reset subsystems being split into two separate cores with revised consoles like the the One X. So these would be more of a challenge, even if there’s now an angle of attack to investigate.
The new Xbox is going to be a specialized PC running Windows with full access to third party game stores (Steam, Epic, etc). It won't need to be "hacked" because anyone will already be able to run any software they want on it.
A conversation for another day and I can't wait to have it, but something about this seems seriously doomed, because Steam already owns this lane, owns it well, and these days I think Linux is objectively the better desktop for most personal, PC-style use cases.
Windows stopped feeling like it meant PC a long time ago, and there's a major risk of the whole Xbox identity disappearing into the PC computing. Probably a conversation for another day but when everything is an Xbox, nothing is an Xbox, and when an Xbox is a PC it might as well be fading away Marty McFly style from our plane of existence.
I suppose what would really impress me is a Roku-style omnivore approach that gives a first class console-style experience and interface to Epic, Steam, Itch.io, GOG and of course Xbox.
You can run steam in big picture mode, and there are ways to add links to games from other game stores to steam such as https://github.com/PhilipK/BoilR
I'm aware, but that is indeed a great thing Steam offers. I think it's janky enough that if there's one way to out-steam Steam it might be making the broader PC gaming universe as plug-and-play into a console experience as possible.
Every PC I’ve ever tried to repurpose as a gaming console of any sort has had way more jank to it than I’d ever tolerate in a console, in the 25ish years I’ve been hooking computers up to TVs. Even the Bazzite box I’ve got is pretty bad by comparison. Hell, my actual Steam Deck has a lot more undesirable “enthusiast” behavior to it, let’s say, than I’d want out of a Nintendo product for example, even though it’s just about the best I’ve seen (the actual best is Retroarch with a skin mimicking the PS3’s menu, on a dedicated distro that could take it from cold boot to interactive in like three seconds flat even on an rpi2… but that won’t play actual modern PC games, just emulated consoles and such, so it’s not a fair comparison)
A common failure is the controllers. It’s hard to get a combo of OS stack, Bluetooth chip, and controller that Just Works like they do on consoles. Something always needs fiddling-with.
Video or audio out are also often a problem. Glitched audio or audio mode-switching, trouble switching video modes, screwed-up HDR, all kinds of stuff. Maybe fine on your monitor with headphones. Not fine on a TV or projector with 5.1+ audio receiver.
The UIs also bug out or crash more often, and usually aren’t that great at being a TV UI in the first place (even Steam IMO is worse than most consoles, as far as the Big Picture UI)
It also gives devs a stable target with a known market, which is nice for both the devs and the owners of the devices.
The main goal is money, an Xbox branded windows PC has potential to drive sales.
Microsoft can also hopefully target a smoother user experience than a typical windows PC provides. They want this to be a valid console competitor, but just slapping xbox brand on a windows PC isn't enough to do that.
Having a first party hardware device to target for PC games can also help devs with having a clear performance target for PCs, similar to how the Steam Deck is currently a minimum spec performance target for a lot of games.
There's something to be said for having a standard, known SKU, both as something for developers to target if enough people own it, and for users to troubleshoot if they're e.g. having an issue running X game.
This kind of already exists with the "Deck Verified" label on Steam games.
That said, this sounds similar to Valve's upcoming Steam Machine and I'd much prefer that to be the standard console/PC hybrid to keep the Linux gaming momentum going, and perhaps one day I can ditch Windows for good.
If this is true then the reason that a console would be better than a custom PC is that it would also be designed to work better for that purpose. Turning on the device when the controller turns on and sending CEC commands are two huge things that aren't well supported outside of the console space. Also it would likely run a trimmed down version of Windows and would be set up to "just work" in a way that a system that can have any arbitrary set of hardware will never be able to do.
But the really nice thing about the concept of treating a PC and console as the same platform is that you don't have to worry about why people might prefer to go the route of buying the console. You can go with a regular gaming PC if that's what you prefer and your library will have all the same options.
It's a device with a fixed, known-good set of hardware for developers to target, which is all that any of the major consoles is. Your question applies just as much to the Steam Deck and upcoming Steam Machine.
I mean, at that point it is a pre-configured gaming PC. Hardware that's uniform across millions of units provides advantages, both for developers and users. IMO that's a big part of why the Steam Deck outsells more powerful competitors: there are so many of them that it gets targeted by developers, so more people buy them, in a virtuous cycle.
1. Console-like living room ready experience. It's surprisingly hard to get a PC made with off-the-shelf parts to integrate cleanly with a home theater system (think features like HDMI CEC, One Touch Play, etc). A custom SoC can solve this, something we are seeing Valve also do with the Steam Machine.
2. As the target hardware for basically all Xbox games, end-users who don't want to fret over system specs can easily just buy this and know they are getting the intended experience.
Whether that's enough to move units remains to be seen.
This is great news. Hopefully this opens the floodgates towards emulation and homebrew. Not that there are really any exclusives, but it would be interesting.
Xbox One homebrew has effectively always been supported. Anyone can register a development account and boot the system into dev mode. IIRC in a talk about console security, a Microsoft developer noted that this was an intentional deterrent against hacking. An effort to split the community so that pirates and homebrew enthusiasts wouldn't have a reason to collaborate.
They did dumb things like limit memory availability in dev mode, though. Also they require a government ID to enable dev mode (but at least the quit charging $100 for it!). And they made it so you can't enable dev mode on consoles that are banned from Xbox services.
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.
Seems unlikely. Someone would have to turn this into a modchip, set up physical distribution networks (all very illegal under the DMCA), and it'd only work on the 2013 machines - Chen's team clearly anticipated this type of attack and were already working on mitigations around the time the Phat released. So as he says at the end, later silicon already has more glitch mitigations built in and has done for a long time. Current gen Xbox isn't even investigated but we can assume it's even harder. They were clearly paying for red teaming. Remember: ZERO software bugs in the boot rom.
I had a friend who ran a side business installing mod chips on the original Xbox in the early 2000s. There was a robust community around it, and you could buy chips easily.
This was all after the DMCA was in effect. I don’t think that will stop this sort of activity.
They're pretty common and cheap on the used market, though. I bought mine from a thrifts store for $30, and the console itself regularly goes for ~$50 on eBay.
Physical possession of a machine is pretty hard to make secure. It's a different level of secure, an order of magnitude less secure than remote attackers. This is expected?
Tony Chen from Microsoft gave a talk called "Guarding Against Physical Attacks: The Xbox One Story" and he explains that they want any sort of physical attack to cost at least the price of 10 games ($600 at the time).
Depends on the size of the system you need to secure.
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.
When your hardware is in the physical custody of the attacker, the threat model changes significantly. Designing a console that takes years for attackers to crack is an impressive feat of engineering.
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.
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.
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.
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.
This is great news. I’ve actually been spending my weekends learning how to modify my old 360 and play great games to relive some of those younger days, while my Series X gathers dust.
Microsoft released a video that covers effectively all of the Xbox One security system, and it's referred to extensively in the talk. The specific methods of glitching don't require any insider knowledge.
They also told everyone they added more anti glitching to later hardware revisions; which by the process of elimination tells everyone they thought this was possible.
The whole initiative was a success when it gave them a year; an unqualified triumph when it gave them the whole generation; they really are not going to be to sad after 12 years.
Right, as Markus says - even gods can bleed. And he's right: Tony Chen's team did god-level work with the Xbox One security system, so what must have followed in the Xbox Series S is truly unknowable. I don't think there's even a tech talk on it. This talk is probably the most elite hacking talk I've ever watched. Everyone who worked on this stuff at MS can and obviously should be very proud of what it took - especially as this probably won't have any commercial impact on Xbox game devs or multiplayers.
I think this might be a good example of the fundamental misunderstanding of what "security" even is. It is never a binary state. Never was. And I think a lot of people don't really grok that and think that if a security block can be overcome in some manner then the thing is not secure.
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.
i find this statement is often used as an excuse to not think about security at all. which is probably not what you intended here (i hope, although you did say "pointless"...), but some people parrot it for that purpose.
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.
One of the DRM circumvention methods for the Xbox 360 involved precision drilling a specific depth into one of the chips on the board. Microsoft was very aware of the nature of physical access while designing this, haha.
I had many Xbox 360s with flashed DVD drive firmware back in the day. But as I never owned a slim console I had no idea the drill/Kamikaze hack was a thing until now.
This seems like an unqualified win for the security measure. The future value of Xbox One DRM is probably close to zero. They already got what they wanted out of it.
I can give you a piece of paper with a one time pad encoded secret, where the one time is physically destroyed. You can take all the time you want but you will not crack anything…
'pointless' is doing a lot of heavy lifting there.
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.
xbox is always trying to limit the users, when a person buys something, he clearly gets the ownership of the thing yet companies nowadays are trying really hard to sell some subscription while giving the illusion that the owner of the product is in control all the while keeping him in control. is there anyone else who feels the same way?
Thanks for the mention! I helped with the collateral damage exploit (wrote the PE loader).
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.
E-fuses are just write once memory with limited reads ability 10e6-10e7 read cycles after which it becomes unreliable.
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.
Given that it held up against 13 years of dedicated efforts by people with physical access to the device, many years after its successor was launched, it seems merited in this case.
I agree, but also find it funny that by that standard the DRM in the original Google video streaming product was not hacked before the service was shutdown, after about 2 years :)
To the community it was unhackable, until very recently.
It's security measures held up so long that it appeared to be unshakable. There were no obvious flaws.
In hindsight it was hackable, but keep in mind how long it took. This console has long been obsoleted.
It was unhackable while it mattered. It was hacked 5 years after it no longer mattered. And all but the effectively beta release remain unhacked even now.
"Extremely hard to hack" or "Hackable only after it's retired" don't exactly roll off the tongue, but they are not synonymous with "Unhackable".
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.
In the very strict interpretation probably nothing is unhackable, just not hacked yet. But one should also be pragmatic about what "unhackable" means in context. Without the power of hindsight, a consumer device that stayed unhacked for ~13 years can be reasonably called unhackable during this time.
We don't need to contribute to word inflation. There's "really hard," there's "nearly impossible," there's even "impossible – as far as we know." I don't think it shows a lack of pragmatism to assume a technological claim, made by a technology company, should't be taken at face value. On the contrary, I'd advise more pragmatism to anyone failing to disregard an "unhackable" claim made by Microsoft specially even after fixnum years without known exploits.
I think it's like calling a ship "unsinkable". Yes, you engineered it to not sink, in accordance with strict maritime standards no doubt, but just don't call it unsinkable. If you call it unsinkable you're just begging for a century of snickering at your hubris.
It has no relation to hubris whatsoever if the "unhackable" label is not something self-proclaimed at launch but something descriptively applied by other people who were unable to hack it. Nobody would have snickered if the Titanic were described as unsinkable by people who had been trying to sink it for 10 years.
> Nobody would have snickered if the Titanic were described as unsinkable by people who had been trying to sink it for 10 years.
Pedantic: I'm sure somebody would have snickered about "unsinkable" if the Titanic sank after 10 years. Pragmatic: if the "unsinkable" Titanic lasted 10 years (or at least to profitability) before being sunk by people intending to sink it, that might certainly count as being "unsinkable" for the time it hadn't sunk.
Hubris: Titanic was claimed to be unsinkable before it was launched.
I wish people would take statements in relative terms along with the whole context before attempting to refute them with a quick gotcha in absolute terms.
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.
This goes against information theory as a whole, and the point of words. How are you going to convey all this extra context to people who don't follow the space, and what word(s) do we use for something that is actually unhackable?
Firstly, who made the claim that it was guaranteed to be "unhackable"? Was it Microsoft themselves when they sold it, or slop journalists looking to create false contrarianism in order to legitimize their own PoV and drive traffic to their articles? If it's the latter the we're just wasting our breath ehre over made up BS.
Secondly, this is HN, not some generic town corner shop newspaper. It's assumed the readers who come here often and comment with no green profiles, have at least some basic technical know-how that nothing is ever unbackable, least of all a console from 2103, and therefore process information through that context lens, instead of feigning complete ignorance and arguing from the false pretext they gobbled up from editorialized titles created by slop journalists.
> Case in point, it took 13 years of constant community effort to hack it.
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.
>and remains the least popular major console (with an abysmally tiny market presence outside of the US).
TF are you on about? The xbox one of 2013(competitor of the PS4 who got hacked long before) had a ~46% market share in the US and ~35% globally. Hardly insignificant. And any Microsoft Product, even those with much lower market share, attracts significant attention from hackers since it's worth a lot in street-cred, plus the case of reusing cheap consoles as general PCs for compute since HW used to be subsidized. And of course for piracy, game preservation and homebrew reasons.
I again tap the sign of my previous comment, of uring people to stop jumping the gun to talk out of their ass, without knowing and considering the full context.
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:
> https://xboxdevstore.github.io/
Hence why PS3 Other OS no longer did hardware acceleration.
https://phys.org/news/2010-12-air-playstation-3s-supercomput...
Ya basic was only one front in that war.
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."
Anyway, situations like the one you describe are one to be solved by legislation requiring certain devices be sold as open devices that put power in the hands of the owner.
So even if Switch 2 doesn't make it all the way to 2035 with zero cracks, there's a strong likelihood that any exploits found will be short-lived.
There's a terrific incentive: Being able to play games without Steam or DRM in a portable format (possibly one file per game). Emulation is beautiful[1] and this time it may come at native speeds considering the Xbox One uses x86 architecture.
[1] https://100r.co/site/uxn.html
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.
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.
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').
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
https://en.wikipedia.org/wiki/Low-voltage_detect
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.
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.
Extremely impressive feat nonetheless!
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.
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.)
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.
[1] https://consolemods.org/wiki/Xbox_360:RGH/RGH3
Has anyone heard of notable earlier examples?
The points specific to software where it might not even be producing in-spec is also very good.
Comments that cite the solo dev/prototype case are of course not what this is getting at, but it's one good use of quick generation.
I would extend this article by saying what The Goal says, namely that the goal of every firm is to make money, and everything is intermediate to that. So whether or not software architecture is grade-A or grade-C, it's only ever in this subservient role to the firm's goal.
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...
Windows stopped feeling like it meant PC a long time ago, and there's a major risk of the whole Xbox identity disappearing into the PC computing. Probably a conversation for another day but when everything is an Xbox, nothing is an Xbox, and when an Xbox is a PC it might as well be fading away Marty McFly style from our plane of existence.
I suppose what would really impress me is a Roku-style omnivore approach that gives a first class console-style experience and interface to Epic, Steam, Itch.io, GOG and of course Xbox.
It's not automatic or perfect but it does work.
A common failure is the controllers. It’s hard to get a combo of OS stack, Bluetooth chip, and controller that Just Works like they do on consoles. Something always needs fiddling-with.
Video or audio out are also often a problem. Glitched audio or audio mode-switching, trouble switching video modes, screwed-up HDR, all kinds of stuff. Maybe fine on your monitor with headphones. Not fine on a TV or projector with 5.1+ audio receiver.
The UIs also bug out or crash more often, and usually aren’t that great at being a TV UI in the first place (even Steam IMO is worse than most consoles, as far as the Big Picture UI)
It also gives devs a stable target with a known market, which is nice for both the devs and the owners of the devices.
Microsoft can also hopefully target a smoother user experience than a typical windows PC provides. They want this to be a valid console competitor, but just slapping xbox brand on a windows PC isn't enough to do that.
Having a first party hardware device to target for PC games can also help devs with having a clear performance target for PCs, similar to how the Steam Deck is currently a minimum spec performance target for a lot of games.
This kind of already exists with the "Deck Verified" label on Steam games.
That said, this sounds similar to Valve's upcoming Steam Machine and I'd much prefer that to be the standard console/PC hybrid to keep the Linux gaming momentum going, and perhaps one day I can ditch Windows for good.
But the really nice thing about the concept of treating a PC and console as the same platform is that you don't have to worry about why people might prefer to go the route of buying the console. You can go with a regular gaming PC if that's what you prefer and your library will have all the same options.
1. Console-like living room ready experience. It's surprisingly hard to get a PC made with off-the-shelf parts to integrate cleanly with a home theater system (think features like HDMI CEC, One Touch Play, etc). A custom SoC can solve this, something we are seeing Valve also do with the Steam Machine.
2. As the target hardware for basically all Xbox games, end-users who don't want to fret over system specs can easily just buy this and know they are getting the intended experience.
Whether that's enough to move units remains to be seen.
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.
https://news.ycombinator.com/user?id=gaasedelen
https://www.youtube.com/watch?v=U7VwtOrwceo&t=715s
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.
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.
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.
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.
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.
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.
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.
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.
Pedantic: I'm sure somebody would have snickered about "unsinkable" if the Titanic sank after 10 years. Pragmatic: if the "unsinkable" Titanic lasted 10 years (or at least to profitability) before being sunk by people intending to sink it, that might certainly count as being "unsinkable" for the time it hadn't sunk.
Hubris: Titanic was claimed to be unsinkable before it was launched.
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.
Literally unhackable? XD
Secondly, this is HN, not some generic town corner shop newspaper. It's assumed the readers who come here often and comment with no green profiles, have at least some basic technical know-how that nothing is ever unbackable, least of all a console from 2103, and therefore process information through that context lens, instead of feigning complete ignorance and arguing from the false pretext they gobbled up from editorialized titles created by slop journalists.
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.
The person who hacked the original Xbox wrote a book on the topic, which they've since made free: https://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf
TF are you on about? The xbox one of 2013(competitor of the PS4 who got hacked long before) had a ~46% market share in the US and ~35% globally. Hardly insignificant. And any Microsoft Product, even those with much lower market share, attracts significant attention from hackers since it's worth a lot in street-cred, plus the case of reusing cheap consoles as general PCs for compute since HW used to be subsidized. And of course for piracy, game preservation and homebrew reasons.
I again tap the sign of my previous comment, of uring people to stop jumping the gun to talk out of their ass, without knowing and considering the full context.