[0:07]The room should probably fill up for this one. This is one you do not want to miss. This is quite literally a world first exclusive, um, uh talk. So, uh, this is this is exciting. There were security reps from multiple companies emailing like, wait, is this a public bug? Is this reported? Um, please tell us more info. I don't want to spoil the surprise. If you were here last year, even if you saw the talk online, you know, this was our high highest rated talk we had last year was the previous version of this talk from Marcus. And it has only gotten better. You don't need much of an introduction. This will be one of the best talks, if not the best that you're going to see this week, I promise you. Please welcome Marcus Gastellen. Okay. Um, hi, everybody. Uh, my name is Marcus Galen, and yeah, as Jordan said you're in for another really special talk this year. So, last year I gave a talk at Reverse about the original Xbox from 2001. Um, to me, that talk was actually more about passion than Xbox, but if you want to know more about me and my story, go watch that talk first. Um, it's a beautiful kind of part one to this talk and will help fill in the blanks for how we got here. So, this year, we're going to be talking about hacking the Xbox One. Uh, the Xbox One was Microsoft's third major game console. Um, it was a it was a highly anticipated successor to the Xbox 360, but it's unveiling at E3 in 2013 was notoriously unpopular. Um, Microsoft had basically tried to push an always online model for DRM and position the Xbox One as a living room media center first and a game console second, alienating the core audience. And the brand's kind of been bleeding out ever since. Um, but Microsoft did get at least one thing right, because, uh, hacking game consoles is kind of a, uh, to run arbitrary code is kind of a rite of passage for each generation. But in 2013, some kind of iron curtain came down on security of the Xbox ecosystem, and the Xbox One never got hacked, nor did any of its successors. And even as recently as 2020, seven years after its launch, Microsoft described the Xbox One as the most secure product Microsoft has ever produced and maybe the most secure device out there, the Xbox One. I'm not sure I totally agree with that, but it is, um, they did a great job. Uh, so this is a console I bought a decade ago while I was still in college. And here I am asking myself 12 12 years later, why did it never get hacked? What kind of black magic could Microsoft possibly have put into this thing? Um, why is it that Sony PlayStation and Nintendo consoles all over keep getting hacked? Uh, what made the Xbox One so special? So, if you want some idea of the top-down strategy Microsoft employed to harden the platform, I strongly recommend you watch the 2019 talk by Tony Chen, who helped architect the Xbox One security stack. Um, he broadly described the Xbox One security stack in layers leaning heavily on compartmentalization, virtualization, and revocation. Um, while they hardened every layer against compromise, Tony also stressed that the entire chain of trust really hinges on them being able to maintain control of the bootrom. Um, he said, the only software mistake we cannot recover from is a bug in bootrom. And this is a kind of funny diagram that one of my friends made, uh, in 2024, about our progress in hacking, uh, the Xbox One as a scene or community. Um, and basically, nothing had been accomplished, uh, but this talk, we're going straight to the top. Um, and so I said if I'm going to come back to hack the Xbox One, I'm not coming back for 30%, I'm coming back for everything. Um, and so this talk explores what it's like to hunt dragons and take on a task that many wrote off as impossible. Uh, by the end of the talk, we're going to obtain code execution on the Xbox One bootrom. This is basically a god mode hardware hack that cannot be patched. Um, so again, I'm going to be flying through content because we have so many slides. And so I'm sorry if I'm clicking through stuff a little fast, but, uh, you can watch this later. I'm going to go to it's up online. Um, so some of the data, this work actually dates back to early 2024, which, um, I was working on but pretty abruptly stopped for personal reasons. Um, I've kind of been doing a lot of AI for the past couple of years now instead. Uh, but some very kind and inspiring people convinced me to come back, do a little bit of hardware, complete this work and give this talk. Uh, so this is the first time I've spoken publicly about the technical specifics behind this hack. Uh, I wanted to premiere it at a conference and community that is near and dear to me, so that's why we're here. Um, and yeah, uh, I'm not going to talk about anything except the bootrom. So there's a lot of layers to the Xbox One, I only care about the bootrom. Uh, that's what I studied. Um, and if we compromise the bootrom, we compromise everything. So, it's time to tear down the console. Uh, so it's pretty standard console, um, for 2010s, hard drive, optical disc drive. Uh, this is the motherboard, uh, the SOC, and this is actually what we're going to be trying to hack. This chip. Um, and so, this is a custom SOC developed between Microsoft and AMD. It's 28 nanometer technology. It's both CPU and GPU, and then it has this entire security subsystem. We're, uh, primarily going to be talking about the platform security processor. Um, but this is a shot of the silicon die, and you can see all the shit in here. Right? Um, and just down on the bottom right corner is the bootrom. Um, and so if you zoom into that, uh, this little array is, uh, essentially what contains the bootrom. There's two bootroms in there. We're only going to be talking about the secure state bootrom. Uh, I'm not going to describe the process of optically extracting the bootrom from Silicon because frankly we don't have the time, and it's the least interesting part of this talk. Um, and I also want to be clear that these are Microsoft bootroms. Um, there has been research into AMD PSP historically, but that's mostly AMD, uh, code. Um, and there's some misinformation that I had hacked some leftover AMD bootrom or code or something, uh, which is not the case. These are completely written by Microsoft. Tony Chen even said it in his 2019 talk. Um, his team wrote the firmware for the security co-processor on Xbox One. Um, so let's talk about the platform security processor. So, the PSP is the hardware root of trust for the Xbox One. It's actually an ARM Cortex R4, um, squeezed into the corner there between all those GPU cores and CPU cores. Um, it's supported again by the CCP and SCP, so the Crypto co-processor and security co-processor, uh, streaming crypto processor. Um, uh, and then it's got this 12-region MPU, which we'll talk about a little bit later, um, which it it uses for hardware enforced memory isolation among a shitload of other mitigations that they crammed in there. Uh, so again, we're only going to be talking about the bootrom. Uh, there's other phases of execution of the security co-processor, but we are trying to attack the immutable bootrom because if we get through that, we get everything that comes after. Um, and so this is just a high-level diagram of the, uh, boot flow for the Xbox One. Uh, the left side is essentially, uh, the security complex, uh, the arm core comes up first before everything else, and it actually then will, um, read in later stages of its boot, as well as X86, the X86 side, decrypt it, place it securely into X86 memory, and release X86 reset. Um, again, we're only interested in attacking this. I didn't have to study any of that other stuff because if we can break this in the mitigations in this, then we get everything that comes after. Um, so the Xbox One bootrom, the code is simple, uh, it's linear and it's super well reviewed. Um, they audited the hell out of this, there's no software bugs. Um, and but it it there's a really important distinction to make here, is that there's a huge difference between writing bug-free code versus designing security-conscious, fault-tolerant code. Um, some of the stuff that Microsoft was doing 2012, 2013 while designing this was, uh, potentially a decade ahead of, uh, what people were thinking about with fault injection and defending against it, um, and whatnot. So, we have to go immediately to hardware attacks. Um, and so, uh, this is me pulling out the motherboard for the first time, putting it on my bench. Uh, I had never glitched anything before in my life. And I chose to glitch the one thing that nobody's been able to glitch before, uh, as my first target. And so, I was going back to kind of like reason about, um, how is glitching done historically on Xbox, just because I was curious. Obviously, I've I've read all the papers on glitching, uh, voltage injection, uh, or or fault injection, uh, EMFI, whatnot. The Xbox 360 was primarily hacked, um, using like these three kind of key points. Um, post codes helped with measuring progress through boot. Um, they inserted their glitch on the reset pin specifically, which is kind of interesting. Uh, we're not going to talk too much about this stuff because actually we don't have time. So, uh, I got to keep moving. Um, Xbox One, uh, so this is kind of what some of the Xbox 360 wiring looked like when people were glitching it. Xbox One glitching, Microsoft kind of learned their lesson. They got rid of post codes. So the bootrom and the first stage bootloader, SP1, uh, they have post codes compiled in, but it's actually disabled by eFuses. And so eFuses are one-time programmable fuses, uh, buried in the SOC that they can program kind of per chip if they want. Um, there's no reset pin. uh, so Microsoft was like, okay, uh, we're not letting people inject faults potentially on this reset pin, which I think is kind of interesting and funny. Um, and then there's no way to slow the clock, which just helped reliability. Um, but I basically have no hardware introspection. Uh, actually I have some idea of what we're attacking because we have an optical extraction of the bootrom. But there's no UART on this thing. There's no post, no JTAG debugging, no datasheet, no dev or test chips that I could try running my own code on and reasoning about how the chip behaves, no debugging, no prototypes, nothing. And so, one of my friends that said to me from the I said, without a power trace, we were glitching totally blind. Uh, when describing what it's like to try to, you know, glitch targets that maybe you're not as familiar with. And so, a power trace, uh, kind of gives you some insight maybe into the, uh, the phases of execution of some chip that you're looking at. Um, this is you can kind of see how the power trace varies a little bit here. It's like a side channel to tell how much, uh, power the chip is using. Um, and so I enumerate all the SOC power rails, uh, there's actually a lot of them. Uh, and I don't exactly know what I'm looking for. I have no idea what rail the security co-processor could be running on. Um, so I picked the 1.8 volt rail thinking maybe it's regulated down off that. I'm not completely sure. Uh, and I started trying to collect power traces. Um, but I've never done a power side channel before. I don't know what looks good or what looks bad, but I started getting a little bit better at it. Um, this is just a very simple implementation of a power side channel, uh, essentially using a shunt resistor. There's several ways that you can do differential power analysis, but this is what I chose, it's cheap and effective. Um, but essentially, uh, I started getting power traces. They started looking a little bit better. You can start to see some kind of structure. Uh, this blue signal is what I was using to kind of roughly analyze the boot of the security co-processor or the larger APU, I guess. Um, it's the power okay signal and then the green is kind of the power trace. Um, but I kept looking at these power traces. I kept fiddling with the setup, trying to change the noise and, um, trying to look at like different filters available to me. And I just I I couldn't make sense of anything. I could see some structure, but it didn't really align with what I was expecting based on the reverse engineering I had been doing of the bootrom already. And so, I started hunting around for more signals. Uh, this is my board, me just, uh, labeling things out, trying to probe things. Uh, and I found this other signal, which is an interrupt signal that the PSP will send to the Southbridge or SMC. Uh, and this is essentially, um, I I started looking at this. I'm like, okay, we have a new signal early into boot. You can kind of see some correlation on the power trace. Maybe it's hard to see on here, um, but it's that lower kind of blue thing. But as I kept taking more of these traces, I noticed that it kept varying every boot. And I was like, uh-oh. Um, and so essentially, what we're looking at is Microsoft inserted randomized stalls into, uh, the Xbox One bootrom. Uh, and I did a lot of data analysis on it to figure out, uh, uh, to help study the stalls. I was able to use different signals to isolate some of the stalls, um, such that I could see one stall, uh, as well as a region of two stalls and multiple stalls. Um, but this basically, I realized that there's 37 random stalls throughout the SP0 bootrom execution. Uh, super annoying because essentially, this is like ASLR for glitch timings. We can't just hard code glitch at 1.3872 milliseconds for this long, um, because every stall is at a random time and can last for a random amount. Uh, and we basically need to find ways to reliably anchor our glitches within the bootrom. Uh, and so, it's probably hard to see, um, up here, uh, but this is just a little front thing I did to visualize SP0 execution. Um, all of these orange bands are actually, uh, random stall loops. And so, the bootrom executes about 300,000 instructions on average, and almost about 150,000 of them are going to be in random stall loops doing absolutely nothing. Um, but the next thing I moved on to was I2C traffic. So, I2C's a simple two-wire chip, uh, serial bus. Um, basically, this is where I tapped it. On the left side, you can see some of the other signals that I've tapped so far. Uh, this is, uh, just a off my logic analyzer now, uh, of the different signals I'm kind of looking at to try to study the boot. You can see this burst of data coming out, um, on the I2C bus. And this is like some on-boot diagnostics data that comes out every single boot. Um, it's got your SOC ID in there, some voltage, thermal, and clock side channel monitoring bits. Um, memory and internal bus violation bits. There's a lot of really kind of interesting stuff in there. Uh, the TLDR, it actually didn't play too big of a role in this hack. Um, but a few other things can appear on this I2C bus. Uh, if enabled, progress-based post codes will come out on that bus, but they're actually fused off. Um, and then fatal error codes are enabled, um, but those only, uh, will be emitted if the console like crashes or something essentially during boot. Uh, and that kind of gives you a tease of kind of where we're going. But I decided, okay, I'm getting some insight into what's going on. Let's try glitching to see if maybe the I2C data will change. And so, we're going to do Crowbar Voltage Glitching. Um, and so voltage glitching, um, Crowbar glitching specifically is just a cheap and effective fault injection technique, where you try to collapse the voltage rail at a very precise moment. And that can destabilize a core, it can cause weird things to happen, such as instructions to get corrupted. Um, and this is me, that green wire is essentially, uh, the, uh, what I'm going to use to ground the rail. Um, and my first glitches are absolutely terrible. Like, these don't look like meaningful glitches at all. Um, a better glitch would look a little bit more something like this. Uh, so I learned a few lessons. Um, and I started building some automation around driving the board, so I could reboot it like hundreds or thousands of times. Um, and I have a Teensy basically to set up to kind of drive this attack in the automation and maybe trigger the glitches. Um, and this is kind of what it started looking like. You can see the power trace. The system is kind of like resetting, obviously. Um, it's it's just running in a loop and I'm trying to glitch, but I didn't really get anything useful happening. Um, I started, but I built up some hardware introspection. I'm starting to layer some signals together. And I've built some basic automation to get, uh, multiple runs going. I'm just not producing fatal errors or the kind of changes that I actually expected to see coming out of the system. Uh, and part of this was because I was actually glitching the the wrong rail. Because, again, I this is the first time I've ever glitched anything. So, um, I've moved on. I looked back at the list again, and I kind of tried to isolate some of the ones that I'm like, I don't think I'm supposed to be glitching on these. Uh, and I settled on the Northbridge Core Rail next. And so, I'm not going to explain the Northbridge too much, but basically, uh, the Northbridge is kind of like chip fabric, but it can also contain things like the, uh, system management like subsystems on it. Stuff that might execute pre-boot or connect different cores. But I started removing, uh, SMD caps from the Northbridge core rail under the APU, which is a common technique when you're doing, uh, voltage glitching. And I isolated the, uh, Northbridge core rail, such that and I removed all the caps from it, and I put my own shunt resistor on there, so I could do this power side channel. And I injected my own low-noise power into it. And it actually started to see some structure. Um, so zooming in kind of, uh, in particular, I actually started to see some structure around the reset. Um, and this kind of point in particular stood out to me, because my power trace is now, uh, when I zoomed out a little bit, they always kept varying after this point. And I was like, what's going on with this point? Um, and but I if you squint a little bit, you can start to see these little things in here. I'm like, are these stalls maybe? And I kept seeing these, but they didn't make sense. Um, they were not where I expected them to be stalls. And these are actually, uh, entropy collection from, uh, ring oscillators, uh, to seed the hardware RNG every one millisecond. Took me two weeks of staring at these T leaves to understand that, but it made me realize that this is actually where the crypto co-processor and RNG is being initialized by the bootrom. Um, and so, I have this kind of landmark now that I understand, and based on my analysis of the stalls, I actually know roughly how fast this processor is running, which is 100 megahertz. And I could calculate, okay, wait, this is about, uh, where the bootrom execution should be starting. Um, and so all this stuff before it, though, is pre-boot, which is also kind of interesting. Um, but we have some updates. Uh, our hardware introspection is improving. We are pretty sure we found the correct power rail for PSP, it's on the Northbridge core. Um, but one of the big issues is we actually, uh, still cannot differentiate the randomized stalls from execution at all. There's a lot of other stuff going on. Again, I'm sorry if I'm jumping through the slides here. People can look at this later. Um, but I start to move on to post codes. So, post codes are, uh, pretty standard in all computing. Uh, you have probably post codes in your phone, on your computer. Um, but it it's a standard way to try to measure boot indicators kind of across like, is your computer like pulling itself up from hardware properly? Um, some example post codes from the Xbox One, uh, think of it just as a byte that comes out. Um, and, uh, these are just status indicators, they're increasing, and they kind of are kind of document your way through boot. Um, on Xbox One, again, they fused off the post codes. And I know that because if they were actually enabled by fuses based on the ROM, we would have seen traffic for them coming out on the I2C bus. Uh, and Microsoft went through great lengths to ensure that those post codes were not supposed to get glitched on via fuse corruption and stuff like that. Um, but about 2,000 instructions after reset, so we're looking at the ROM now, uh, is where they initialize the GPIO pins in case post codes are actually enabled. And the post codes, if enabled, will come out on these unmarked, completely unmarked GPIO pads, um, which I've colored there for you. Uh, and so I was like, okay, let me just hook them up and see if there's anything. Uh, and sure enough, Microsoft did their job right. Uh, there's no post codes there. So, um, you can see post codes starting to wiggle out on those lines in SP2, the later bootroms, uh, bootloaders. They know that they can revoke those, so they don't care about maybe, uh, the security of those quite as much. Um, but there is actually something that we see. You see, when they initialize the GPIO, um, there is a, uh, when they when they do the GPIO initialization, the pins actually go from floating to to low. They essentially get grounded. Um, and this is an important signal, and I got pretty hyped about this. And so, I put this on my oscilloscope again. And so, we're kind of overlaying our signals again here. Uh, and we now can see literally where some instructions of the bootrom correlate to power trace, to digital signals, and whatnot. Um, and right after GPIO init, they do all this crazy logic to determine, oh, should we actually enable post codes? There's a bunch of branches, a bunch of reasoning, and I'm like, okay, this seems like super glitchable. Like, if we can land anything in here, like, post codes might just magically emerge. And so, I, with all the things I had learned, being stuck on the other rail, I soldered down my my MOSFET to do glitching. I have a little monitor on the side here to look at it on the oscilloscope. Um, and for the first time ever, we're actually getting glitches, oops. For the first time ever, we're actually glitching the core and doing something. And so, there's little yellow lines where you're seeing wiggle. Those are post codes being enabled. Normally, that line should just sit flat the entire time. You can see me zooming in on my voltage glitch. And then shortly after, you see post codes come wiggling out. I'm booting the system hundreds of times right now. Um, and so, this was a really critical, critical moment. Um, because it what it it made me realize here, we got stuck. Um, so it it was a really critical moment because it it made me realize that this core is going to be hackable. I'm actually influencing it for the first time. I've managed to demonstrate some hardware influence over it. Um, this is just zooming in on my glitch. Again, the voltage rail, as well as the GPIO init, and if glitched on, you see the first post code emerge soon after. This is zooming in, so you can see kind of maybe the shape of my glitch, not that I tried to tune it that much, but it's about 100 nanoseconds or so, 100, 200 nanoseconds. Um, and yeah, this is kind of the resulting output. So we're actually kind of starting to see post codes come off. This is what you would expect, post codes are fused off. Um, but then when we glitch them on, we now have all this new activity, and we can actually start setting the boot in a meaningful way. Um, and so this is me just hooking up all the post lines to the voltage shifter, so I can work with them on the teensy and my logic analyzer easier. This is kind of what my setup is looking like at this point. Um, and yeah, these are kind of our progress updates so far. So we demonstrated the first ever meaningful glitches to Xbox One. Nobody has ever done this. Um, and so it really broke the illusion that this chip would be unhackable, uh, that even gods can bleed, right, after all this time. Uh, so we're actually going to talk about the bootrom now at a more technical level. So, it's a 64 kilobyte immutable ROM, um, but only about 19 kilobytes of that is actual code. Uh, it's primarily thumb 2. Um, again, it's a straight line, one shot, no complex runtime. Uh, and every instruction is fetched from Silicon every time and ECC checked. Microsoft literally burned ECC bits into the silicon, um, which I think just kind of describes the great lengths that they were going to try to protect this thing. Um, but at a high level overview of kind of all the actions that it takes and does, uh, this is, um, you can look at this later. Again, uh, one of the things that really made me laugh is there's actually dual signatures when they're trying to load in and verify the next stage. They have both an RSA and an elliptic curve signature in the header, just in case RSA got broken, God forbid. Um, you know, the Xbox One boot chain would still be, uh, secure. Granted the rest of the world would be on fire. Um, so a lot of people looked at this, though, besides me and we're like, nobody can land eight glitches in a row. That's impossible. And yeah, they're probably right. So I was like, okay, I'm going to glitch something else. And so, specifically, what I glitched was when they're trying to fetch the, uh, header in of the next stage. Um, and so, the SP1 header read, uh, so SP1, the SP1 bootloader is essentially the first external bootloader. It's a 32 kilobyte ROM, um, and the, uh, bootrom will meticulously verify and signature check this thing. They go all out, uh, and it's kind of crazy. So, uh, just depicting the path that it takes. This is where the first external bootrom or bootloader lives. Um, it lives in a NAND flash, and it travels over essentially two buses here. Um, a standard kind of MM MMCSDIO bus, and then a faster PCIe bus through the Southbridge to the PSP. And if we look at the bootrom code, uh, it will fetch the SP1 header from flash over PCIe in these 64-byte bursts. Uh, and essentially, that's the red bus that you're seeing. That's kind of like the logic interfacing with that red bus on the right side. Um, but I was like, okay, let's take a look closer look at the slow bus, um, because that's something we can actually probe. This is about 25 megahertz versus maybe like gigahertz going on the PCIe bus. Uh, and so, if we tap just one of the flash signals, we can see, um, where the bootrom is actually reading, um, the next stages. Uh, and so, again, we're kind of getting some more introspection, we're building up all our signals. Uh, and then you can see where they read the header of the next stage, and then 80 milliseconds. They do all this stuff just to be annoying. They try to pack everything in there. They do some self tests. They try to verify the header. They do revocation checks. They do lots of stalling. They do key unwraps for the decryption. And then finally, they start reading the body and they'll decrypt the body and whatnot later. Um, but we need to zoom in. Um, so the SP1 header is actually read in two by in two different kind of bursts because, uh, it's it's almost 900 bytes. Uh, and so, if you know anything about disk and, uh, MMC and whatnot, uh, sectors are usually 512 bytes. Um, so you can see where the MMC bus is reading it, and then where we speculate it should be transferring over PCI. So, again, our green bus and our red bus. Um, we can't again, we have not probed the red bus, but we can speculate based on timings that this is what's happening. Um, and then it happens again. So there's again, two bursts because they're trying to read in this whole header. Um, because the header's so big because they wanted to put two signatures and all these kind of like validators in there. Um, and our goal is seeing if we can actually glitch, um, one of those PCI transfers. And so, what we're going to be targeting is the mem copy. Um, specifically, over the past decade, mem copy with regard to fault injection has become an extremely attractive target. Um, because the execution states within mem copy are highly polluted with attacker controlled data. Um, and so it's not that mem copy is unsafe or like there's a bug in mem copy. Um, it's that if something goes wrong within mem copy, there's a higher chance of things going wrong in your favor. So, think of mem copy as a pipe that attacker controlled data, um, frequently flows through. Um, but if you hit that pipe with a big hammer, water is just going to leak out, right? Some weird things can happen. Um, and so, a a glitch could corrupt an instruction decode within mem copy. And all of those registers containing attacker controlled data, that could turn into an arb right or a PC hijack. Um, and so what I did is I flashed, um, pattern data that I controlled into the EMMC or the flash, essentially, just like any good CTFer, uh, bytes that I could recognize. Um, and this is me essentially reflashing the the NAND chip on the board. Um, and I said, okay, let's hit that pipe with a hammer. And so, I need to talk about fatal error codes, though, because I knew what I was expecting to potentially see come out of the system if my glitches were working. Um, and so, they actually, in the bootrom, they hooked up, uh, the arm, uh, abort modes to, uh, essentially, uh, post out a fatal error code if some kind of like memory segmentation issue happens or a fault. Um, and so, uh, they specifically try to pack, um, the, uh, IFR and IFSR, so the fault state register, uh, status register, and the faulting address register, which are arm-based registers into just a D-word. Because the post codes are only a D-word, so they will emit this on the bus as some kind of diagnostic. You know, maybe the box goes back to the factory or they're trying to understand why it's broken for repair. Um, this maybe give can give some clue. But this is us like some sample of a 32-bit fault fault code that could potentially emerge, and kind of how the bits break down to, uh, whatnot. Uh, and so, the idea is, if we cause a seg fault, if we glitch a core and cause some kind of seg fault, I expect to see a fatal D-word come out over the I2C bus. Um, and, uh, and it might look something like that. And so, while glitching that region that I showed you, the pipe of about, you know, that red region, uh, where I expect the PCI transfers to be happening. Um, I'm getting, uh, essentially, 100 unique fatal codes sweeping that region with my glitch, trying different offsets and widths, essentially, over 100,000 runs. But what I'm looking for in my head is I'm looking at that top byte because that top byte is actually supposed to contain the top seven bits of whatever address the fault occurred at. So, if we jump somewhere, if we try to read in an invalid address or write to an invalid address. Um, and I'm looking for my pattern. And so, I I this this is not the best visualization. I had a shitload of data, but, um, the basic idea is like I had these hundreds of faults, and I filtered it down to just the ones containing some of my pattern bytes, and specifically I was looking at the pre-fetch one in this example. But I could see on some regular interval, my different bytes were popping out. And again, these 64-byte bursts is what I'm thinking about. And so, when you decode one of these post codes. Um, you can see that this actually decodes to PC jump to 58. 58 something. We can't see the rest of the address because they've compressed it into this little post code. But we know that this was a permission fault, and specifically instruction pre-fetch board. PC tried to go somewhere. Um, and so after a lot more analysis, um, you can kind of break down again, the the little outlines are essentially the 64 what you can imagine the 64-byte bursts that are going to be transferred over MMIO. But if I changed just those blue little boxes and glitched, then I would see I was essentially seeing control of PC. And the way this worked is at least from what I understand, what I can tell, and looking at the code and reasoning about it for a long time, we're skipping a pop at the very end of the mem copy routine, or something. Something, there's an instruction decode going wrong. Something happens, and that pop does not execute. And so, the registers, uh, when mem copy is trying to return to the parent, never get restored. And again, they're highly polluted with attacker controlled data, because mem copy's always super optimized, trying to use all the registers they can to copy data over. Um, and so, uh, this is the state when the fatal pre-fetch, um, occurs. So, that's pop being skipped, essentially left all of these red registers polluted with data I completely control, and we just jump to 58585858. Um, and so restoring registers failed, um, and we can jump anywhere in the bootrom. So, what's kind of amazing about this is it only took about a week from glitching post codes on to getting arbitrary control of the program counter.
[30:44]Um, and the glitches anchored off a signal, that zero, between two randomized stalls. So we bypass the randomized stalls in that regard. But we still have a problem because the MPU is enabled. Um, and we'll talk about that in a couple of minutes. But you have control of the program counter.
[31:00]Um, there's no read write X memory, so how do they normally, uh, get to the next stage? Well, you know, maybe we can jump there, I'm thinking. Uh, they, they would, you know, maybe we can jump to where they disable the MPU, and then transfer execution the next stage. But we get killed by a security checkpoint. Um, and so, security checkpoints, uh, there's about 13 of these checkpoints sprinkled across the bootrom. Uh, they emit a progress-based post code. They also maintain this running hash, which is really interesting. And that if any checkpoint is executed out of order, the system will reset. Um, so they also will during these checkpoints check for ECC errors, so they check all these MMIO registers to check if any of their, um, RAM regions, SRAM, the E fuses, uh, if there's any or the ROM, if there's any ECC errors that occurred during execution, they'll reset. Um, and so each checkpoint also ends with a randomized stall. And I think the main goal is trying to protect against large logic skips and whatnot. Um, but there's actually another thing that kills us, which is user jails. So Microsoft implemented essentially these unprivileged user jails to compartmentalize some of the really risky bootrom logic. And, uh, they use ARM supervisor mode and the MPU to create these little, uh, user jails. And each of these jails have a distinct like code page dedicated to just the logic that should execute within the kind of that specific user jail. And they try to wall off all other memory because they're trying to isolate you, minimize the amount of gadgets you could potentially, um, use, where you could jump, whatnot. And we're kind of stuck in this. There's four different user jails used 14 different times. Um, and we're stuck in essentially the jail with the permissions that is capable of copying data from flash to S RAM. Uh, and so this is another visualization of the SP0 execution, so the bootrom execution. Uh, and we're looking at a few different things here. So all the green bits that you can see, I know it's hard to see on here. But essentially, we're visualizing instructions executed over time and their addresses. So all the green bit is where, uh, the supervisor mode is executing. Uh, and then all these red bands, uh, and the red lines are actually, uh, the user mode execution, and orange is, uh, stalls.
[33:23]So, this was really annoying. Um, I could rop within one of these user jails. Uh, and so I I started playing around with rop a little bit just to demonstrate some control over the system, and I wrote a little rop chain. I actually managed to find enough gadgets within my constrained little jail to create arbitrary rop, and I I managed to rop out my own arbitrary post code. So, I got OX41414141 coming out of the I2C bus. Um, and so we've kind of established our first glitch. Uh, this glitch gives us arbitrary control of the program counter. Uh, and we can even turn into arbitrary rop. Uh, we anchor the glitch timing on dat0. Again, some signal that's kind of outside the scope of the randomized stalls to some extent. Um, but we're confined to this user jail. We don't have full access to the, uh, platform security processor or the memory, and it's, uh, and it's MMIO registers.
[34:34]So, the next stage is that we need to attack the MPU. Um, and, uh, if we look back to this diagram, uh, we are looking at, uh, essentially when we're trying to glitch the post codes on. Well, just before we glitch the post codes on is when they, uh, initialize the MPU. And the MPU is the memory protection unit. Um, and so this is essentially what they use to isolate, um, user mode and supervisor mode and these jails. Uh, and the supervisor mode, um, is essentially what manages and programs the MPU, uh, on the fly. And so, it's kind of like roll your own TrustZone because this is ARMv7. It's not, uh, ARMv8 and whatnot, or whenever they got the EL extensions and and whatever. Uh, and so, I'm thinking, if we can skip the MPU enablement, the jails will collapse and we could tamper with the supervisor with supervisor, uh, memory, essentially.
[35:36]And so, uh, looking at kind of how the MPU initialization works, uh, they, there's 12 MPU regions allowed on this platform. Um, and they essentially go through this loop, configuring the 12 regions with the different jails and, uh, parameters and regions. And then at the very end of that, they're going to turn on the MPU.
[35:59]Um, and, uh, essentially, the, if we look back at the, um, power trace that we have, uh, we know that we we know we we have the yellow line, which is where the GPIO init is supposed to happen. Um, we we can see where GPIO init happens, and we know that the MPU, based on the bootrom, is should be initialized just before that signal.
[36:25]Um, and so roughly this region, and we have this timing anchor now that we can plant, um, or, uh, essentially to to measure forward from to time exactly when we want to glitch. Um, and so, when I put this, uh, all through my setup, um, and I ran glitch campaigns, this is kind of what I started to see. And so, all these different colors are different kinds of crashes occurring at different point throughout boot. Because what we're actually doing is we're corrupting different, you know, iterations potentially of where they're configuring the different MPU regions. They may be configuring the supervisor stack at some point, or they may be configuring the GPIO region, so that we crash halfway through the the bootrom because now the GPIO region is no longer readable or something. Um, and so, all these different colors is kind of like illustrating that. But then there's these really interesting kind of pocket of crashes along these bottom here, where, uh, the GPIO init comes early. So, the top line, that descending line that you see, is me kind of sweeping the glitch offset closer and closer to the GPIO init. And so, the further we get to the right, um, the sooner we would expect to see GPIO, um, we're kind of getting closer to it. Um, but when we suddenly collapse down, um, we're skipping some kind of logic. Um, the GPIO init somehow came much earlier than we would have expected. Um, and what this indicates is that we're breaking out of the MPU loop early. Um, and so it's clear that we're breaking out of this loop. Um, but are we still turning on the MPU, is a question. And it actually took me a long, long time to verify this. Um, because the bootrom, the bootrom is behaving much weirder after doing these loop break out glitches. Um, so it would crash in kind of like slightly different ways, almost silently in some extent or it seemed like it was hanging. Um, and I, you know, I thought to myself, if the MPU was getting enabled with only let's say one to two regions enabled or something, if we had glitched out within the first loop iteration or two, we would never be making it so deep into the bootrom, um, if the MPU was actually enabled. It would have been horribly misconfigured, basically. And it was really weird because, yeah, testing my glitches in isolation worked fine. If I wanted to do try try my skip the MPU, uh, or this loop breakout, we could confirm that by the GPIO init coming early. Um, and if I wanted to test my my PC hijack, uh, we would get arbitrary rop. But if we tried to chain both those glitches into one run, it would the PC hijack just would not work.
[39:11]Um, it took a long time for me to, kind of, overcome, because we have to re-sweep now for new glitch parameters for that second glitch, the hijack glitch. Um, and it was grueling. Um, it was essentially we're combining two glitches, let's say one in 100 chance for skipping the MPU and one in 100 to then hit the PC hijack. Um, and so there's like, uh, you know, 10,000 boots per glitch parameter tested, uh, and I had to do millions of boots to rediscover the PC hijack parameters. And I was doing so many boots that I was literally burning out the EMMC chips because the SMC within the Southbridge is trying to keep up and understand what the hell I'm doing to the system. And it's trying to write error logs. So, if you saw like the Tesla recall a couple years ago, uh, where like they were burning out their name chips within the EMMC or within Teslas because they were writing error logs constantly. And so, I actually had to swap out, uh, doing my research these EMMCs with industrial grade ones that could tolerate a lot more rights just to help with the research. Um, but finally, we kind of get to, uh, what is ultimately what I call the Bliss hack. And so, uh, I have a video. Um, and so this is, uh, essentially my lab, and we're streaming the first ever attack here. And so, what you're going to see is you're going to see something pop up on the the screen of the oscilloscope. Um, I've kicked off the glitch on the right side, this double glitch setup. The spooky lab. And essentially the glitch landed. The double glitch landed. And we dumped all of the E fuses. We have full code execution of, um, the, uh, bootrom, the SP0. So this is me just scrolling through the bootrom. Uh, or the the fuses. Um, but you'll see essentially, I start dumping the bootrom at the top here, a little message for me. Uh, you can see Microsoft's copyright string. Uh, they said, you know, do not unlawfully hack, circumvent, reverse engineer, or glitch. Um, and then all the things I'm scrolling through are essentially me driving the crypto engine to decrypt all of the later stages. So, we can decrypt one SP, two SP, um, the two BL, the streaming, uh, crypto processor firmware. Uh, we have access to everything. We can patch everything. We can decrypt everything. We can boot anything from the bootrom down. Um, and so this is just a picture in case it didn't, you know, the video didn't work for whatever reason.
[41:51]Um, and so, uh, the product impact specifically, this, uh, impacts the Xbox One fat from 2013.
[42:27]I'm like, if nobody's hacked the later consoles, I'm not going to go after them. I'd like to learn from the past and kind of build my way up. Um, and but there is a caveat here, is that in Tony's talk, he had this diagram describing the Xbox One security architecture within the SOC. Um, and there's something that Microsoft tried to sneak in for launch, but they couldn't quite get stable enough. Um, and this is something that I knew, so, uh, that it was fused off for launch because it was it was it was unstable. They weren't able to get it quite dialed in. Um, they actually tried to build in, um, side channel monitors to monitor the different voltage rails within the chip to detect potential influence on the Northbridge core, the memory rails, the clock. Um, and so the year one SOCs, um, had these anti-glitch monitors fused off. And by the end of 2014, uh, kind of like the year one revision, they were able to turn them on from my understand. But I strongly believe that this work can be ported across all of the fat consoles actually because looking at the logic where they do some reasoning about enabling the monitor, I think you could glitch past it. If the monitors are even effective in and of themselves of detecting these glitches. Um, so the Xbox One S and One X, uh, I've looked at them a little bit. Um, I don't know if I'll keep looking at them, but the boot continued to evolved, uh, it's been hardened even further. Um, there's now two cores. We have the reset processor and the security processor, so the plot thickens. Um, but I think the techniques that I've described here, uh, will have relevant application towards attacking these systems. Um, and so I actually think you will be able to potentially, um, rop, uh, on the security co-processor, using some of the stuff I described, assuming you don't get killed by similar glitch monitors. Um, Xbox Series S and Series X, I have not looked at those at all. I can't speak on them. Um, but is a mod chip possible? That's what everyone's going to be asking. Um, I saw someone joke about on Twitter like, if this is what you have to like, they were looking at all the wires and stuff and they're like, if this is what you have to do to hack the Xbox one, I'm pretty sure Microsoft won. Um, but like, uh, the reality is almost all of that was, uh, purely for me building introspection. It was my debug board, my research board. You only need maybe three wires here to, uh, build the E fuse side channel to tap the GPIO pin and then tap the dat zero line. And that, those are the anchors you need, um, to essentially, uh, time these glitches. Uh, for the Northbridge Core Rail, I showed you guys my whole injection, the the power side channel. Completely unnecessary. That was again for my own debugging and introspection. For that demo that I just ran, uh, I glitched that on the retail voltage. I had only removed a few caps under the board so I could put my MOSFETs down there. But that might not even be completely necessary. So, uh, people are asking and I'm sure there's a lot of people that are going to be watching this talk after the fact on YouTube, being like, oh, the Xbox scene glory days are coming back. We're going to be modding games and stuff like that. Um, I think it's 12 years too late. Um, I think the golden age is sorry is over, guys. Sorry. Um, but, uh, I would be curious if anyone is actually able to go through and replicate my work and kind of bring forth some of this. Um, it's not going to be me. Um, I haven't played games in years, and I didn't come back to the stage to hack the Xbox One to pirate a few games. Um, I only did it because nobody else could. Um, and so, that's kind of the conclusion. Um, again, uh, I had very similar conclusions last year, my talk. Uh, you have to be ambitious, um, you know, ignorance is bliss. Swallow the dragon and tackle really hard problems. And so, um, special thanks again to, um, uh, one of my good friends Grim, uh, and, uh, 404, Pulsoid, uh, and Lockbox. So, Jordan, you guys hopefully saw his talk yesterday. Um, because they're some of those folks that inspired me to come back and essentially give this talk.
[46:59]And so, uh, there's extra slides, but we'll probably stop there because I want to be conscious of time. So, um, yeah.
[54:12]Hey, Marcus, great talk, man. I wanted to ask about some of those awesome, uh, graphs that you had to help describe some of this stuff. Did you make a bunch of custom stuff to put that together or were there tools for that? Oh my gosh, okay, that's a great question. And so, if I had another hour, I'd tell you, um, about, uh, all the AI stuff I've been doing the past two, three years. And I actually had, um, AI, uh, help me build an emulator for the bootrom, uh, to help with my system and studying it. Um, and, uh, it helped, uh, emulate peripheral IO, MMIO, all this stuff. And so, that is, uh, those, uh, instruction visualizations and the the different measurements and me trying to simulate faults. Um, that is an emulator that I built with AI. And so, I also had to generate these nice visualizations for you guys and the community to look at and reason about and have fun with. So, uh, yep. Hey, Marcos. Hi. Very nice talk. So, my question is, how many consoles did you burn? Oh, yeah. Yeah. So, that's a good point. Uh, I meant to put in a picture. I'm sorry, Peter. Uh, I meant to put in a picture of, uh, essentially, I have my closet. I have a closet full of them. Um, maybe in the slide release, I'll tag it in there in the final picture. Um, so I probably, uh, killed about, only four or five boards, honestly. And I realized now it wasn't my glitching that was killing the boards. I was killing the EMMCs. And at first, I didn't realize that until much later, um, when I started being like, okay, what the, I need I need to figure this out because I can't keep doing these long glitch campaigns, you know, weeks on end, and the board just stops working. And so, um, I think it was probably about five boards. I think I have about five boards in my parts bin now. Um, yeah. Okay. And just another, another question, which is, uh, how many attempts, like, in a scale, uh, did you actually try? How many times, you know, if you can give like a figure. Uh, okay. So, the thing is, that glitch that I demoed, um, that landed in a minute.
[56:12]And that was a real thing. And I have not really optimized my setup.
[56:22]This was for researchers for me. Um, I think that, uh, properly, uh, distilled and refined that, uh, you could glitch a console in a second. Um, I think that I generally think within a few seconds, you could hit both glitches. Um, uh, I can hit it anywhere from, you know, a minute to 30 minutes. Like, it can vary, otherwise I would have done a live demo.
[56:59]Um, I actually have it streaming from my apartment right now. Uh, I would have, uh, put it on if I if I thought it it could have landed, um, reasonably within like a minute or two, but yeah.
