[HN Gopher] Mistakes Microsoft made in the Xbox security system ...
___________________________________________________________________
Mistakes Microsoft made in the Xbox security system (2005)
Author : davikr
Score : 99 points
Date : 2025-07-17 00:23 UTC (22 hours ago)
(HTM) web link (xboxdevwiki.net)
(TXT) w3m dump (xboxdevwiki.net)
| munchler wrote:
| This is from 2005.
| dang wrote:
| Added above. Thanks!
| Scaevolus wrote:
| 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/
| zaptheimpaler wrote:
| 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..
| samplatt wrote:
| 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.
| gonzalohm wrote:
| 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
| maxloh wrote:
| 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.
| rep_lodsb wrote:
| 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.
| gonzalohm wrote:
| That's the problem. My automatic updates are disabled and
| yet somehow that happened
| john01dav wrote:
| 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.
| Kudos wrote:
| I was the same. This year I found new motivation and
| switched my Pixel to GrapheneOS to take back control of my
| device.
| haunter wrote:
| > 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
| extraduder_ire wrote:
| That's a previous generation console released in 2017.
| ChocolateGod wrote:
| 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.
| spookie wrote:
| Yup, it's just a compuper.
| badsectoracula wrote:
| 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.
| FirmwareBurner wrote:
| _> 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.
| twoodfin wrote:
| Broadly, what can you do in Xbox "developer mode" that you
| can't do with a similar Apple developer account & their
| SDK?
| xandrius wrote:
| Not sure but one requires you to keep on paying the tax.
| badsectoracula wrote:
| 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.
| mjg59 wrote:
| 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
| exikyut wrote:
| I have a vague idea the A20 gate was also used to defeat Intel
| SGX a couple years back, if I'm remembering correctly?
| ethan_smith wrote:
| 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.
| rep_lodsb wrote:
| >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.
| rep_lodsb wrote:
| (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.
| userbinator wrote:
| Alternatively: Paths to Freedom.
| dang wrote:
| 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)
| jojomodding wrote:
| Arguably discussed never, since no conversation happened, since
| that requires more than one participant.
| Smaug123 wrote:
| 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.
| 9991 wrote:
| All of this nonsense because they underpriced the console to
| overcharge on games.
| wang_li wrote:
| 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.
| colejohnson66 wrote:
| 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.
| saghm wrote:
| >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.
| joe_guy wrote:
| 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.
| extraduder_ire wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-17 23:02 UTC)