The fundamental problem was that x86 had no mechanism for verifying first instruction at the time (Boot Guard and Platform Secure Boot provide that now), and the only way to try to deal with this was by adding immutable storage - but given where they put it, that was expensive, so small. And that led to making poor tradeoffs, influenced by having what was clearly not a great level of adversarial security analysis, but even implementing that perfectly they'd still have been fucked by the gate A20 thing which is maybe the absolute funniest legacy design failure that perpetuated well into the 21st century.
(The Intel/AMD difference on IP rollover is also funny but given the number of other ways to circumvent things...)
I actually use this as a teaching example - it's a great way to talk about how CPUs actually work and interact with other hardware, and a good understanding of this gives a lot of insight into low level platform design
Never read about this before, but the explanation in the wiki seems made up to me. The way it's described makes it sound like yet another legacy "feature" that's been there forever, but older x86 CPUs did not (generally) behave like this.
The 8086 (and 186) did wrap around of course, because they had no memory protection and only 20 address lines. But I know for a fact that the 286 would fault and invoke interrupt 0Dh [1][2]. I'm fairly certain the 386 did so as well. Segment limits are enforced even in real mode, and at reset they are initialized to 64K. Or is the CPU already in protected mode, and segment limit set to 4G? In that case Intel and AMD might differ. (The 286 was 16-bit, so 64K was the maximum there. Arguably, the "correct" behavior for 386+ would be to do the same thing when the limit is 4G)
What it says about opcode FFFFh however is even more likely to be wrong. That opcode has always been undefined, only the original 8086/8088 ("1970s stuff") would execute it, but as PUSH DI instead of NOP. It's not impossible that Intel made the decision to interpret it as NOP in some later generation, without ever documenting it. But I just tried this on my modern-ish Intel machine, and it aborted with "Illegal instruction".
[2] also note it isn't a double fault (interrupt 8). And shutdown occurs on a "triple fault", i.e. when the CPU fails to invoke the double fault handler.
I should have read the entire article first - of course we are in protected mode, and with no exception handlers defined in the IDT it would triple fault. I stand by my comment about FFFFh, this isn't a NOP on older or newer CPUs, so almost certainly not on the Pentium III either.
As to what happens on 4G wraparound, I could only find this in the Intel manual (SDM Vol. III, 5.3 Limit checking):
>When the effective limit is FFFFFFFFH (4 GBytes), these accesses [beyond the segment limit] may or may not cause the indicated exceptions. Behavior is implementation-specific and may vary from one execution to another.
The Xbox 360's security was also compromised despite Microsoft's improvements, with the hypervisor eventually being defeated through clever timing attacks and hardware modifications like the JTAG/RGH exploits.
AFAIK a big reason for this is that the developer mode (as mentioned elsewhere) removed a large incentive for trying - people can run whatever code they want (after paying $20 or so to enable the developer mode, though supposedly Microsoft is planning on making that free now) on their console (with some limits but for things like getting emulators or homebrew to work those weren't important).
However there have been some efforts last year or two to break the security. I remember reading about some exploit some time ago that would work from the original Xbox One to the current Series X devices though it relied on some program on the store that it was removed. However (supposedly, i do not own an Xbox One) the files were archived and one is still able to modify and compile the program (so it wont be caught by whatever automation MS has), use dev mode to put it on the store or device, then use that to apply the exploit.
I expect the Xbox One (and later) to be cracked open pretty much as soon as Microsoft abandons the whole thing as recently their interest in Xbox seems to be waning.
Imagine that. The computer you bought and own can run the code you want. Wild.
Now what's Apple's excuse?
> removed a large incentive for trying
I'm not entirely buying this, there's a big difference between running any code you want and the Xbox dev mode. If I look at jailbroken consoles of the past, people do way more stuff on them than what you can do on an Xbox with dev mode, like implementing various ways of self hosting and playing a huge library of pirated/backup games off local network storage, which Xbox dev mode can't do.
So I don't think incentive is gone, just that the barrier is too high for your common hackers in their homelabs. I'm sure private companies with six figure side channel analysis equipment and unlimited hours can crack them no problem but there's nothing to gain from that.
While pirated/backup games can be an incentive, they are far from the only one and for many who actually tried to crack open the consoles, being able to run their own software like emulators is a much higher priority and this is possible with the dev mode. In fact AFAICT the main thing that is impossible is pirated games.
And in practice there isn't that much of an incentive for pirated games on Xbox One and later either since nowadays pretty much all of the games there are also available on PC where piracy is much easier.
That Xbox One exploit is quite funny, it relies on delisted Game Script app that uses Ape programming language made by me and submitted here on HN a few years back.
The Xboxes after the 360 have developer mode built in to allow people to run their own user space software (including emulators) so the attraction to look for exploits is reduced.
Yeah, the hackers had a good run on jailbreaking every device for decades but the corpos won in the end. Most of the latest iOS devices/versions and consoles no longer have any meaningful jailbreaks. The end of an era..
A big part (I feel) of that for both iPhones and xbox is their ecosystems finally arriving at a point that's "good enough"; the store offers enough games with enough security with low barriers to "fun" that few people WANT to hack it.
Same with Android - from 2008 to ~2018 I was rooting and putting custom ROMs on my phone before I'd even got it home. These days I rarely bother because the functionality that I required is finally provided out-of-the-box.
In exchange for less control of your device though... The other day my phone updated without my permission and replaced Google assistant with Gemini, also without my permission.
It's no longer my phone If I can't decide what gets installed and what shouldn't
Both Gemini and Google Assistant are parts of the Google App. They were introduced or deprecated with app updates.
It is possible to reject the update. Just disable automatic updates of the Google App in the Play Store. You could even return to Google Assistant by reverting Google App to an older version.
Just disable automatic updates, so you can then instead yell at them about how they're compromising security?
What is really needed is being able to choose what updates to install, and more generally, being able to get rid of all the crapware that uploads everything you do on your device to your corporate overlords. Not just particular "apps", but the operating system itself.
The fact that most people in 2025 simply accept carrying around 24/7 a device with GPS, microphone, camera and wireless network connection, which they cannot control or even know what it does at all, is dystopian.
Imagine if this was the norm with PCs back in the 1990s. Linux would never have existed, since there would have been no way to replace the pre-installed Microsoft OS with something else.
The features that you use may be there, but I don't want all of my everything getting hoovered up to Google. On Apple some functionality (termux and ad blockers in native apps come to mind) isn't even available in the closed ecosystem.
I do take issue with this fluffy statement at the top:
> If the reader finds the mistakes in the design, this proves that Microsoft has weak developers.
(The article even goes on later to say basically "don't attribute all of these to stupid engineers", and the explicit 17 mistakes are almost entirely not related to the technical content of the security breakages, so there's a sleight of hand being performed here already between "mistakes in the design" and "mistakes in organisational software engineering practice"!)
While I have no love of Microsoft software, and clearly the Xbox was woefully insecure, the statement ignores the fact that knowing there is something to find is often enough to find it. I am failing to find the definitive article about this, but there's something about this by Michael Nielsen or Andy Matuschak or similar. One of its examples is a quote by Kasparov or Magnus Carlsen or similar, to the effect that the single word "now" at the right time would be enough to win a game, because it would announce that there was a discovery to be found. This article is entitled "17 Mistakes…", and it also presents the relevant details of the design rather than all the details of the design, so the problem of finding the mistakes given the description is much, much easier than the problem of reviewing a complete design spec.
>Keeping this in mind, the attack on the Xbox is pretty straightforward: If we connect the CPU's A20# pin to GND, the Xbox will not start from FFFFFFF0, but from FFEFFFF0 - this is not covered by the secret ROM, but is ordinary flash memory, because flash is mirrored over the upper 16 MB. So by only connecting a single pin, the secret ROM is completely bypassed
This is interesting to me because it sounds remarkably similar to my admittedly very naive understanding of how jailbreaking the Nintendo Switch (original console, not sure about the recent Switch 2) works, just inverted; there's a single pin under where the right joycon slots in that seems to be responsible for ensuring that the OS (or firmware? my understanding of what step this is in the boot process is pretty fuzzy) is properly loaded, so shorting it is enough to allow injection of pretty much whatever you want to boot instead. The entirety of what you need to do from a hardware perspective even as a complete novice is access to a desktop/laptop, the USB-C cable that comes with the console, and a plastic nub people 3D print and sell on Amazon for like $8 to slide into the joycon slot, and you're done.
All this makes me wonder how hard it should actually be for console makers to catch these sorts of things ahead of time. Shouldn't be be fairly straightforward to just look at every single pin and consider what happens if it's turned on or off? Assuming the others are in the default state would be sufficient to have noticed both the issue with the Xbox and the one I describe in the Switch, so it's not like there's some insanely high number of combinations you need to consider to at least make it twice as hard to hack. It's understandable that in 2005 maybe this wasn't something that Microsoft would have thought of in their first time making a console, but the Switch came out over a decade after that, and Nintendo has been pretty vigorously going after "piracy" since before then, so it's hard to imagine that this was due to indifference.
What you're thinking of on the Nintendo switch is a recovery mode. Every (most?) modern systems have something like this. It's a lower level area that allows you to fix issues in the higher level areas, even when that's broken (ie, a failed system update). Your iPhone, android, and smart TV all have this.
That being accessible wasn't the mistake. It was all properly secured. It rejected your commands and everything has to be signed by Nintendo's private key. But Nvidia firmware had a buffer overflow bug inside of it that allowed arbitrary code execution.
Shorting that pin in the joycon rail to ground is only done to put the device into recovery mode. Logically, it's pressing the "home button" which doesn't exist elsewhere on the console, along with the volume-up button while powering the console on. The actual exploit relied on a software bug in verifying what was sent to the device.
Similarly, getting into the recovery mode on one of the DS consoles involved pressing a button combination on startup with the screen closed.
It wasn't that RSA was "too big", but that RSA wouldn't fit in the remaining space — especially when you consider the complex RAM initialization routine they implemented.
The fundamental problem was that x86 had no mechanism for verifying first instruction at the time (Boot Guard and Platform Secure Boot provide that now), and the only way to try to deal with this was by adding immutable storage - but given where they put it, that was expensive, so small. And that led to making poor tradeoffs, influenced by having what was clearly not a great level of adversarial security analysis, but even implementing that perfectly they'd still have been fucked by the gate A20 thing which is maybe the absolute funniest legacy design failure that perpetuated well into the 21st century.
(The Intel/AMD difference on IP rollover is also funny but given the number of other ways to circumvent things...)
I actually use this as a teaching example - it's a great way to talk about how CPUs actually work and interact with other hardware, and a good understanding of this gives a lot of insight into low level platform design
>Intel/AMD difference on IP rollover
Never read about this before, but the explanation in the wiki seems made up to me. The way it's described makes it sound like yet another legacy "feature" that's been there forever, but older x86 CPUs did not (generally) behave like this.
The 8086 (and 186) did wrap around of course, because they had no memory protection and only 20 address lines. But I know for a fact that the 286 would fault and invoke interrupt 0Dh [1][2]. I'm fairly certain the 386 did so as well. Segment limits are enforced even in real mode, and at reset they are initialized to 64K. Or is the CPU already in protected mode, and segment limit set to 4G? In that case Intel and AMD might differ. (The 286 was 16-bit, so 64K was the maximum there. Arguably, the "correct" behavior for 386+ would be to do the same thing when the limit is 4G)
What it says about opcode FFFFh however is even more likely to be wrong. That opcode has always been undefined, only the original 8086/8088 ("1970s stuff") would execute it, but as PUSH DI instead of NOP. It's not impossible that Intel made the decision to interpret it as NOP in some later generation, without ever documenting it. But I just tried this on my modern-ish Intel machine, and it aborted with "Illegal instruction".
[1] third post in https://forum.vcfed.org/index.php?threads/286-cpu-experiment...
[2] also note it isn't a double fault (interrupt 8). And shutdown occurs on a "triple fault", i.e. when the CPU fails to invoke the double fault handler.
(can't edit anymore)
I should have read the entire article first - of course we are in protected mode, and with no exception handlers defined in the IDT it would triple fault. I stand by my comment about FFFFh, this isn't a NOP on older or newer CPUs, so almost certainly not on the Pentium III either.
As to what happens on 4G wraparound, I could only find this in the Intel manual (SDM Vol. III, 5.3 Limit checking):
>When the effective limit is FFFFFFFFH (4 GBytes), these accesses [beyond the segment limit] may or may not cause the indicated exceptions. Behavior is implementation-specific and may vary from one execution to another.
The Xbox 360's security was also compromised despite Microsoft's improvements, with the hypervisor eventually being defeated through clever timing attacks and hardware modifications like the JTAG/RGH exploits.
I have a vague idea the A20 gate was also used to defeat Intel SGX a couple years back, if I'm remembering correctly?
Microsoft clearly learned from their Xbox and Xbox 360 mistakes, leading to unhacked (?) Xbox One and Xbox Series X consoles: https://www.platformsecuritysummit.com/2019/speaker/chen/
AFAIK a big reason for this is that the developer mode (as mentioned elsewhere) removed a large incentive for trying - people can run whatever code they want (after paying $20 or so to enable the developer mode, though supposedly Microsoft is planning on making that free now) on their console (with some limits but for things like getting emulators or homebrew to work those weren't important).
However there have been some efforts last year or two to break the security. I remember reading about some exploit some time ago that would work from the original Xbox One to the current Series X devices though it relied on some program on the store that it was removed. However (supposedly, i do not own an Xbox One) the files were archived and one is still able to modify and compile the program (so it wont be caught by whatever automation MS has), use dev mode to put it on the store or device, then use that to apply the exploit.
I expect the Xbox One (and later) to be cracked open pretty much as soon as Microsoft abandons the whole thing as recently their interest in Xbox seems to be waning.
>people can run whatever code they want
Imagine that. The computer you bought and own can run the code you want. Wild.
Now what's Apple's excuse?
> removed a large incentive for trying
I'm not entirely buying this, there's a big difference between running any code you want and the Xbox dev mode. If I look at jailbroken consoles of the past, people do way more stuff on them than what you can do on an Xbox with dev mode, like implementing various ways of self hosting and playing a huge library of pirated/backup games off local network storage, which Xbox dev mode can't do.
So I don't think incentive is gone, just that the barrier is too high for your common hackers in their homelabs. I'm sure private companies with six figure side channel analysis equipment and unlimited hours can crack them no problem but there's nothing to gain from that.
Broadly, what can you do in Xbox “developer mode” that you can’t do with a similar Apple developer account & their SDK?
Not sure but one requires you to keep on paying the tax.
While pirated/backup games can be an incentive, they are far from the only one and for many who actually tried to crack open the consoles, being able to run their own software like emulators is a much higher priority and this is possible with the dev mode. In fact AFAICT the main thing that is impossible is pirated games.
And in practice there isn't that much of an incentive for pirated games on Xbox One and later either since nowadays pretty much all of the games there are also available on PC where piracy is much easier.
[flagged]
[flagged]
One finger pointed to other and four fingers pointed to self.
> - HN users
For a moment I thought I was on Facebook. Good job you made it clear.
That Xbox One exploit is quite funny, it relies on delisted Game Script app that uses Ape programming language made by me and submitted here on HN a few years back.
The Xboxes after the 360 have developer mode built in to allow people to run their own user space software (including emulators) so the attraction to look for exploits is reduced.
Yup, it's just a compuper.
Yeah, the hackers had a good run on jailbreaking every device for decades but the corpos won in the end. Most of the latest iOS devices/versions and consoles no longer have any meaningful jailbreaks. The end of an era..
A big part (I feel) of that for both iPhones and xbox is their ecosystems finally arriving at a point that's "good enough"; the store offers enough games with enough security with low barriers to "fun" that few people WANT to hack it.
Same with Android - from 2008 to ~2018 I was rooting and putting custom ROMs on my phone before I'd even got it home. These days I rarely bother because the functionality that I required is finally provided out-of-the-box.
I was the same. This year I found new motivation and switched my Pixel to GrapheneOS to take back control of my device.
In exchange for less control of your device though... The other day my phone updated without my permission and replaced Google assistant with Gemini, also without my permission.
It's no longer my phone If I can't decide what gets installed and what shouldn't
Both Gemini and Google Assistant are parts of the Google App. They were introduced or deprecated with app updates.
It is possible to reject the update. Just disable automatic updates of the Google App in the Play Store. You could even return to Google Assistant by reverting Google App to an older version.
That's the problem. My automatic updates are disabled and yet somehow that happened
Just disable automatic updates, so you can then instead yell at them about how they're compromising security?
What is really needed is being able to choose what updates to install, and more generally, being able to get rid of all the crapware that uploads everything you do on your device to your corporate overlords. Not just particular "apps", but the operating system itself.
The fact that most people in 2025 simply accept carrying around 24/7 a device with GPS, microphone, camera and wireless network connection, which they cannot control or even know what it does at all, is dystopian.
Imagine if this was the norm with PCs back in the 1990s. Linux would never have existed, since there would have been no way to replace the pre-installed Microsoft OS with something else.
The features that you use may be there, but I don't want all of my everything getting hoovered up to Google. On Apple some functionality (termux and ad blockers in native apps come to mind) isn't even available in the closed ecosystem.
> and consoles no longer have any meaningful jailbreaks. The end of an era..
Switch 1 all models are jailbreakable regardless of the system software but that’s because the the HW bug in the Tegra SoC
That's a previous generation console released in 2017.
I do take issue with this fluffy statement at the top:
> If the reader finds the mistakes in the design, this proves that Microsoft has weak developers.
(The article even goes on later to say basically "don't attribute all of these to stupid engineers", and the explicit 17 mistakes are almost entirely not related to the technical content of the security breakages, so there's a sleight of hand being performed here already between "mistakes in the design" and "mistakes in organisational software engineering practice"!)
While I have no love of Microsoft software, and clearly the Xbox was woefully insecure, the statement ignores the fact that knowing there is something to find is often enough to find it. I am failing to find the definitive article about this, but there's something about this by Michael Nielsen or Andy Matuschak or similar. One of its examples is a quote by Kasparov or Magnus Carlsen or similar, to the effect that the single word "now" at the right time would be enough to win a game, because it would announce that there was a discovery to be found. This article is entitled "17 Mistakes…", and it also presents the relevant details of the design rather than all the details of the design, so the problem of finding the mistakes given the description is much, much easier than the problem of reviewing a complete design spec.
>Keeping this in mind, the attack on the Xbox is pretty straightforward: If we connect the CPU's A20# pin to GND, the Xbox will not start from FFFFFFF0, but from FFEFFFF0 - this is not covered by the secret ROM, but is ordinary flash memory, because flash is mirrored over the upper 16 MB. So by only connecting a single pin, the secret ROM is completely bypassed
This is interesting to me because it sounds remarkably similar to my admittedly very naive understanding of how jailbreaking the Nintendo Switch (original console, not sure about the recent Switch 2) works, just inverted; there's a single pin under where the right joycon slots in that seems to be responsible for ensuring that the OS (or firmware? my understanding of what step this is in the boot process is pretty fuzzy) is properly loaded, so shorting it is enough to allow injection of pretty much whatever you want to boot instead. The entirety of what you need to do from a hardware perspective even as a complete novice is access to a desktop/laptop, the USB-C cable that comes with the console, and a plastic nub people 3D print and sell on Amazon for like $8 to slide into the joycon slot, and you're done.
All this makes me wonder how hard it should actually be for console makers to catch these sorts of things ahead of time. Shouldn't be be fairly straightforward to just look at every single pin and consider what happens if it's turned on or off? Assuming the others are in the default state would be sufficient to have noticed both the issue with the Xbox and the one I describe in the Switch, so it's not like there's some insanely high number of combinations you need to consider to at least make it twice as hard to hack. It's understandable that in 2005 maybe this wasn't something that Microsoft would have thought of in their first time making a console, but the Switch came out over a decade after that, and Nintendo has been pretty vigorously going after "piracy" since before then, so it's hard to imagine that this was due to indifference.
What you're thinking of on the Nintendo switch is a recovery mode. Every (most?) modern systems have something like this. It's a lower level area that allows you to fix issues in the higher level areas, even when that's broken (ie, a failed system update). Your iPhone, android, and smart TV all have this.
That being accessible wasn't the mistake. It was all properly secured. It rejected your commands and everything has to be signed by Nintendo's private key. But Nvidia firmware had a buffer overflow bug inside of it that allowed arbitrary code execution.
More details: https://blog.gistre.epita.fr/posts/victor-emmanuel.provost-2...
Bunny, the person who originally hacked the Xbox also wrote a great book on the subject they've since made free: https://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf
If you enjoyed that book they have written others.
Shorting that pin in the joycon rail to ground is only done to put the device into recovery mode. Logically, it's pressing the "home button" which doesn't exist elsewhere on the console, along with the volume-up button while powering the console on. The actual exploit relied on a software bug in verifying what was sent to the device.
Similarly, getting into the recovery mode on one of the DS consoles involved pressing a button combination on startup with the screen closed.
Discussed once (and I do mean once):
17 Mistakes Microsoft Made in the Xbox Security System - https://news.ycombinator.com/item?id=781036 - Aug 2009 (1 comment)
Arguably discussed never, since no conversation happened, since that requires more than one participant.
Alternatively: Paths to Freedom.
RSA doesn’t take that much code. The Atari lynx would initialize all the hardware, perform RSA, and load the next step from the cart in 512 bytes.
It wasn't that RSA was "too big", but that RSA wouldn't fit in the remaining space — especially when you consider the complex RAM initialization routine they implemented.
All of this nonsense because they underpriced the console to overcharge on games.
This is from 2005.
Added above. Thanks!