How the Xbox 360 security was hacked

“There are going to be levels of security in this box that the hacker community has never seen before.”

– Chris Satchell (Microsoft Engineer)

Introduction

The Xbox 360 is a very well-known system. It sold about 84 million consoles, and powered generations of gaming. Microsoft will likely never reach the success of the console ever again.

Despite the lovely nostalgic feeling of the 360, there was also another scene focused on something other than gaming – hacking the console to run unsigned code.

This wasn’t an easy task. The quote I put at the beginning, while it seems infamous now, was correct at the time. Microsoft learned from the Original Xbox and beefed up security significantly on the 360, to the point where there is no way to softmod a 360 currently, like you can with a Wii or a PS3.

Microsoft secured their hardware well – and hackers faced a tough challenge, but eventually they prevailed.

However, Microsoft could’ve almost avoided this situation entirely – they did not open up their console. The Playstation 3 came out of the box with a Linux distribution called “Other OS”, giving hackers what they wanted without having to hack the console. When Sony removed Other OS, there was a targeted push on the PS3’s hardware that led to its downfall. MVG’s video covers a lot of this in good detail.

Specifications of the Xbox 360

Unlike the original Xbox, which ran an x86-based CPU and a modified Windows 2000 kernel, the Xbox 360 uses a PowerPC-based CPU with a custom OS and security measures.

The motherboard uses a NAND chip to hold firmware instead of IDE storage like the Original Xbox, and uses a custom SMC (System Management Controller).

How the Xbox 360’s security worked

The Xbox 360’s OS uses a hypervisor-based environment. In other words, the dashboard OS is only what’s called a Guest OS and the hypervisor itself is the Host OS. You can think of this similar to Hyper V, expect there is no virtual machines and the hypervisor is something else entirely.

The 360’s hypervisor checks all code that runs on the system for a digital signature, to which the private key is only known by Microsoft. The PS3 uses a similar approach, but it was cracked because Sony can’t figure out random numbers, which left their private keys deeply flawed and they were obtained by hackers.

The hypervisor also acts as a hardware abstraction layer, which is basically a layer that obfuscates direct hardware access with API calls, which are handled by the hypervisor itself. The dashboard OS does not have access to hardware directly.

The Xbox 360 uses a secure chain-of-trust style boot process, with the initial bootloader being embedded in the SoC itself. Microsoft did this because the Original Xbox had its secret ROM hacked by bus sniffing, but you can’t do bus sniffing if there’s nothing being sent over the bus.

Here is a layout of the 360’s boot process (courtesy of TheSpecialist):

• The initial bootloader/1BL (stored in CPU ROM) will load, decrypt, and starts CB.
• The second bootloader/CB (stored in NAND) will load, decrypt, and starts CD.
• CD, which loads, decrypts, and decompresses CE, which contains the base kernel and base hypervisor. It also loads CF.
  • The base kernel is shipped with all Xbox 360s. The version will always be 2.0.188.0 (check the Xbox 360’s About menu to see it, K = kernel version and BK = base kernel)
• CF, which loads, decrypts, and decompresses CG, which contains patches for the kernel and hypervisor. The patches are applied and the system boots up dashboard.
  • This is how the 360’s updates worked. They were never completely new revisions of the kernel, they were appended to the base kernel as “patches”

Throughout the boot process, multiple cryptography hashes are used, such as RSA, SHA1, and SHA1-HMAC, which further help secure the system against unsigned code.

Here is a summary of some protection methods used by the 360:

• Secure chain of trust on the boot process, with the 1BL being embedded in the CPU.
• The Xenon CPU has a unique CPU key, tied to the console itself.
• efuses are used to stop downgrading, a common practice
• The hypervisor, which prevents unsigned code execution, snooping, and tampering of memory.

So what’s the first exploit that was used?

The King Kong Shader Exploit

This was the first exploit that let you run unsigned code on your Xbox 360. This is genuinely quite an embarrassment to Microsoft – as it’s basically a save game exploit. To be fair, it didn’t technically come from them – however, it’s still bad.

Let’s talk about this exploit. The game Peter Jackson’s King Kong was a launch title with the Xbox 360 – it was a fun title, but it also had other implications, that being unsigned code execution.

The 360 uses DVDs to store game data. These DVDs have their own piracy-prevention methods, but were quickly defeated by the DVD firmware hacks (perhaps I’ll cover that eventually) that allowed using pirated games. These DVD firmware hacks did nothing for homebrew, however.

The game executables themselves (default.xex) are signed and will not boot if they are unsigned, however game data like shaders, images, and resources are not signed. This is a serious oversight in my opinion, as it allows for potential save game exploits.

This is exactly what happened with Peter Jackson’s King Kong – it can load an unsigned shader and start code execution on the 360.

This hack only works on kernel 4532/4548 and requires a hacked DVD Firmware so the 360 will accept the game disk. Let’s go over the hack process:

1. Make a backup of the game
2. Patch the shader file in question with XELL (Xenon Linux Loader)
3. Write a DVD
4. Insert the DVD into the 360
5. Profit

JTAG Exploit

This is the first real exploit that defeated the hypervisor and allowed unsigned code execution. It is a complex process compared to the KK Shader exploit. Let’s discuss in detail how it worked:

The Xbox 360 has JTAG (a debugging interface) ports for the CPU and GPU:

This may seem like an oversight, but these JTAG ports are quickly disabled at boot-time. This exploit specifically involves the SMC and GPU JTAG.

Here’s a brief overview of the hack:

1. The SMC is exploited to re-enable the JTAG ports
2. efuses are bypassed and the kernel is downgraded to 4532, the King Kong exploit version (this process is the main bottleneck and is described below).
3. In this, the GPU will become unstable so the system is soft-rebooted and the SMC is patched to control code for the GPU.
4. Then, the King Kong exploit is launched, defeating the hypervisor at boot-time.

Sub-Section: JTAG Timing Hack (for downgrading)

The NAND cannot just be flashed with a different kernel version because of both efuses and something called the lockdown value. In this case of this exploit, the lockdown value is important:

The lockdown value is a hashed 16-byte entry stored in CB that is used to check the current kernel version and efuses. It is the main stopping point of the exploit. It is specific to the BK, and will not boot if incorrect. Normally, this could not be bruteforced, but there’s a timing exploit used (hey, that’s the title of this section)

There’s a flaw in the memcmp function which is used to check the HMAC hash of the lockdown counter – this function goes byte-by-byte and compares the lockdown counter’s hash to another hash.

The memcmp function has a noticeable timing bug though – there’s about a 2200 microsecond gap between a valid/invalid byte. By using special hardware and measuring each byte, the correct hash can be found in only 4096 tries at max.

The downgrade exploit works like so:

1. The base kernel is extracted from the NAND, patched with SMC exploit and bootloaders from the current kernel.
   • This would not boot, as the kernel version is checked by the lockdown counter, and in this exploit, the lockdown counter was zeroed.
2. A timing attack was used to find the lockdown counter’s value needed to boot the BK with the kernel.
   • Note: This doesn’t actually break the hypervisor. The lockdown counter just allows you to downgrade, but custom kernels don’t work.
3. The kernel is updated to a vulnerable 4532/4548 kernel via public updates
4. Downgraded successfully. From here you can load a KK disc and boot Gentoo, and to get your CPU key you can dump efuses and combine the 3 and 5 lines.

Custom hardware was used to perform this bruteforce, and then the JTAG hack was given out to the public.

This exploit did not last long, however, as Microsoft quickly patched it in another version (only dashboards of <7371 are vulnerable).

Reset Glitch Hack (RGH1)

This exploit is the be all end all for Xbox hacking – it is still used today, and is just being improved on.

This hack is a bruteforce attack on the Xenon CPU’s thread management system. By specifically monitoring the CPU’s pins, it is possible to send a pulse to the CPU’s reset line during bootloader hash verification (note that the bootloader version being exploited like CB/CD relies on the type of Xbox being used, phat/slim – more detail in the process) .

The base idea of the reset glitch hack is to slow down the CPU to a crawl and reset it at just the right time so that the hash verification succeeds when it should not.

The reset glitch hack has a flaw however – it takes time to do. The pulse can never be 100% accurate every time, so it brute-forces it until the system will boot. The boot process might be delayed up to a minute in bad cases.

Here’s how RGH1 works on Phat Xbox 360’s:

1. The NAND is flashed with a custom CD (the thing which patches the base kernel, slims are different for this hack). The system would normally not boot since CD is cryptographically verified.
2. A signal is sent to CPU_PLL_BYPASS which slows down the CPU by 128x for higher preciseness
   • Normally, the system will detect a problem and will restart 5 times (and after do a RRoD), so the NAND image contains modified SMC code to negate this problem.
3. The glitch chip waits for a “POST 39 start” log (POST = Power On Self Test, and POST 39 is the memcmp between the stored hash/image hash), and a counter is started.
4. When the counter reaches a precise value (~62% of the entire POST 39 length), a 100ns pulse is sent to CPU_RESET.
5. The chip waits a bit and then it deasserts CPU_PLL_BYPASS
6. CPU speed returns to normal and you get one of two outcomes – either you get POST error AD (fail), or the boot will continue and the modified CD is ran.

RGH1 affects Zephyr, Opus, Falcon, and Jasper motherboards with dashboard versions <14699.

However, multiple versions of RGH were created – let’s go over them:

RGH2

Originally designed to be an RGH1 substitute for slims (because slims do not have CPU_PLL_BYPASS), it was later ported to Phat models. RGH2 is compatible with all console models and all dashboard versions, but it comes at a cost – the boot times are much worse than RGH1.

RGH2 differs from RGH1 in a few ways:

• CPU_PLL_BYPASS cannot be used because slims do not have it, so after a bit of poking it was discovered the scalar chip (known as HANA) could be used to control CPU clock speed
  • However, it can only do this over i2c, meaning it can only slow the Xenon CPU down by about 8x, making boot times much slower
• Glitch chips must be much more sophisticated for the exploit.

R-JTAG

R-JTAG is a combination of the JTAG exploit and the RGH exploit. It uses the same glitch method as RGH, but rather than booting the console it uses virtual efuses to allow the console to load a JTAG exploitable kernel. Usually has boot-times of between RGH1 and RGH2.

RGH1.2

RGH1.2 is an actually good Phat port of RGH2 that works on dashboard versions >14699. There was a port of RGH2 for Phats that was done by Team Xecuter, but it doesn’t use PLL for some reason (probably because they’re a money hungry company who couldn’t get over the success of the OG Xbox)

However, RGH1.2 also comes with something very good – a dynamic timing file. A glitch chip can be programmed with this file and automatically test different settings to find the best for your console.

RGH1.2 boot times are about the same of RGH1.

RGH3

This is the latest Xbox 360 exploit that doesn’t need a glitch chip. It uses two wires and a resistor (though the resistor is optional) to perform the hack, therefore making it a chipless install.

Conclusion

The Xbox 360 hacking scene has seen a lot over the years. Microsoft’s millions invested into security couldn’t save them from a well-trained group of hackers who just wanted more freedom in the console.

To Microsoft’s credit, the 360 was well-secured in the ways it needed to be, and it has stood the test of time, for the most part. But there will always be a way to break code. You just have to look hard enough.

Sources

• se7ensins’ forum page on the science between these hacks
• The IVC wiki pages on Xbox hacking
• free60’s page on the Reset Glitch Hack
• Modern Vintage Gamer’s video on the console