Xbox 360 Architecture

As the end of the article looms, I still haven't set out how this system was absurdly protected. This console has an incredibly long and diverse history involving interesting discoveries, unexpected methods of exploitation and aggressive forms of retaliation. Most importantly, this saga led to many third-party documents detailing the construction of the hardware and the peculiarities of the software. So, it's fair to say that half of the content in this article wouldn't have been possible without the countless hours that many hacking groups dedicated to researching and documenting their findings - a task not necessarily done to enable piracy.

Main targets

The first thing is to introduce the two main targets. As soon as the Xbox 360 reached the stores, Microsoft found itself defending two big fronts:

• The Hypervisor, which holds control of the CPU and enforces signed executables, both of which had to be tackled if Homebrew or booting another OS (i.e. Linux) were to ever be possible.
  • By extension, this also affects user data (i.e. profiles stored on the hard drive and/or Memory Unit) but they implement extra layers of security. These are not mentioned here so we can focus on the main targets.
• The DVD drive, which enforces the copy protection system and prevented burned discs from being executed as games. DVDs are inexpensive and most PCs of that era were equipped with a DVD RW drive, so cracking the drive looks extremely rewarding. Although, it would only lead to piracy, but not Homebrew (as the code is still signed). That is, unless someone discovers an exploit that depends on the DVD drive but once 'triggered' enables to execute Homebrew... we'll see!
  • Curiously enough, the hypervisor and the rest of the operating system have no awareness of the state of the copy protection , that's delegated to the disc drive, which has the upper hand on accepting the inserted disc as a valid Xbox 360 game or not.

The hypervisor front

We'll now learn how the hypervisor is protected and, in turn, how it protects the rest of the system.

A hidden cryptographic system

Remember how complex was the L2 subsystem within Xenon? Well, there's one more thing to explain, and that is the inclusion of a hidden cryptographic block in it. I define it as 'hidden' since it's not documented at all by Microsoft or IBM. I was made aware of it thanks to an incredibly insightful talk called 'The Xbox 360 Security System and its Weaknesses' by the Free60 group (lead by Michael Steil and Felix Domke, the former also did 'The ultimate Game Boy talk'!) and 'Security offence and defence strategies' by Mathieu Renard , which is where I rely on for a big part of the information described here.

Overview of the security components placed within Xenon. They are strategically placed so the PPEs don't need to be aware of them and/or perform any manual work.

Moving on, the cryptographic subsystem is split into distinct areas that perform unique functions:

Rand unit

The random number generator unit (or just 'rand') produces random sets of numbers without exposing a predictable pattern, or at least it attempts to. This is useful for supplying extra parameters to encryption routines, so they are difficult to trace back, and thus reverse engineer or replicate.

You may now ask 'Why can't this be done with software?' and, well, in the world of traditional computing, there's no such thing as 'pure randomness'. Computers can only generate pseudo-random numbers using arguments that may be potentially traced. So, having a dedicated unit for this task obfuscates its reverse engineering further and protects the CPU from possible snooping (as this block is hidden within the CPU and not scattered across the motherboard).

I guess the most optimal solution would be to connect the CPU to a quantum computer, but we are not there yet! (somewhat close though).

Extra storage

Furthermore, this subsystem provides two extra memory blocks.

Firstly, 32 KB of ROM, identical to the Secure ROM found in Cell. It's used for storing unencrypted data that the CPU can read without fear of being exposed or traced by a third party. As you've seen before, this is where the first boot stage is found.

Secondly, 64 KB of SRAM are provided as fast general-purpose memory that the CPU can use to work out a sensible operation (most probably cryptographically-related) without fear, again, of being spied on.

eFuses

Speaking of storage, we've got another special medium called 'eFuses' embedded within Xenon. eFuses are microscopic switches that the CPU reads as 0 or 1, such as any transistor. The peculiar thing about eFuses is that, once they are switched to 1, their state is unchangeable (as writing a 1 blows the eFuse, like traditional fuses). This enables Microsoft to encode permanent counters or store encryption keys which can't be changed once the console leaves the factory. Well, only 0 values may be changed, but their sequence is different on each console. Moreover, once the key is altered by a third party, the console can't decrypt its data anymore!

In total, there are 768 individual eFuses installed and each is treated as a 'bit' by the CPU, where 0 means 'active' and 1 means 'blown'. The block is grouped into 12 'fusesets', where each group contains 64 eFuses.

When eFuses are read or written to, they are done so in groups of 8 eFuses (like 8-bit/hexadecimal values) and not individually. Albeit, sometimes, information is only encoded in the form of binary values (0 and 1) as opposed to hexadecimal format (from 0x0 to 0xF). In those cases, the whole 8-bit word is blown at once and treated as a single binary value instead.

Cryptography unit

Next to the L2 cache, Microsoft and IBM added some hardwired logic to perform AES-128 encryption and hashing functions without requiring the CPU at all. Using the previous 64 KB of SRAM, the L2 block automatically decrypts or encrypts data as it enters or leaves Xenon, respectively.

The L2 block can also hash memory pages on their way to main RAM, store the hash on SRAM and then compare it against the new hash when the page is fetched back from RAM. If the check fails, the system locks up .

All of this is done to fend off any type of meaningful analysis on the memory buses (using encryption) and make sure RAM hasn't been tampered with (through hashing).

To prevent replay attacks (which rely on duplicating old but valid blocks of data to fake authenticity), the Rand unit generates an unpredictable value every time the console boots up. Then, the L2 block mixes it with its encryption logic .

Security implementations

Let's see what Microsoft came up with the use of all those components.

Chain of Trust

The convoluted boot process you've read before was designed to implement a sophisticated chain of trust. This makes sure that, once the hypervisor is ready to execute userland code, the latter is always encrypted and signed by none other than Microsoft.

To efficiently obfuscate the boot process, multiple types of cyphers are employed. For instance, The second bootloader (2BL/CB) is decrypted using RC4 (a fast algorithm), whose decryption key is constructed at run-time using HMAC-SHA. Then, the decrypted code is hashed (using SHA1 and ROT). Finally, to check that 2BL hasn't been tampered with, the calculated hash is compared against a stored hash pre-signed with Microsoft's private key (using RSA).

For increased protection, each console embeds a unique CPU key imprinted on the eFuses just before the console leaves the factory. At runtime, the CPU key is mixed with other parameters to devise part of the bootloader's keys. All in all, this means cracking one CPU key won't affect other consoles.

Once the Hypervisor is loaded into main RAM, the chain of trust is in place and no code will be executed without the Hypervisor's permission, especially since the latter possesses W^X abilities.

Irreversible and unique numbers

To further protect the chain of trust and prevent external alterations, boot stages also query the cluster of 768 eFuses to find the following information :

• The aforementioned CPU key, which is used to encrypt the other keys stored in the console.
• A flag that states whether the console is a retail model or a development kit, which affects the availability of many debugging pins on the motherboard (i.e. JTAG).
• Two update counters (one for the updates applied on 2BL/CB and the other for the updates applied on the Hypervisor and Kernel). Every time Microsoft releases a 'system update' and the user installs it, the updater blows an eFuse. During boot, the CPU compares the eFuses value with the patches applied, if the values don't match you get a famous 'Red light of Dead'. This has prevented users from downgrading to exploitable revisions of the system.
  • There are 5 fusesets reserved for the update counter. The counter is encoded in binary form, so eight fuses are blown after each update, which means the Xbox 360 can sustain up to 80 updates throughout its lifetime. Conversely, Microsoft only started blowing eFuses after the 2.0.4548.0 update shipped.
  • Furthermore, there are 16 eFuses available for updates on CB.

Secure communication

Xenon has a 64-bit address bus, yet, there're only 512 MB of RAM (and a lump of I/O) to be addressed, meaning it can be wasteful to make use of 64-bit addressing. As a result, one half of the address space is used for a more practical purpose: cryptography flags.

In essence, programs only use 32-bit virtual addresses. Then, the MMU uses a page table to convert virtual addresses into 64-bit addresses, where the lower 32 bits encode the virtual address and the upper half store flags that denote whether the selected memory address is (or needs to be) encrypted and/or hashed.

The flags are automatically read by the L2 block, which then carries out the encryption/hashing operations accordingly.

Because there's only 64 KB of SRAM to store the page table and hashes, all main RAM can be encrypted but only the hypervisor is hashed. This means that CPU-RAM communication is always protected, but the L2 block can only verify the integrity of the hypervisor. This seems like a good compromise, right?... we'll see how it pans out!

The hypervisor's duties

Once the hypervisor is fully running with Level 1 privilege, it dips into the internal SRAM of Xenon to provide the following functions:

• Act as a Memory Management Unit (MMU) by handling its private virtual memory page table, where it keeps track of the memory boundaries of every program and whether they are executable or not. This protects the hardware from buggy software producing buffer overflows.
• In cooperation with the L2 block, it ensures all executable code is encrypted when stored with RAM.

To execute any userland application, the Kernel copies the (unencrypted) code into memory and the hypervisor checks that it's been signed with Microsoft's private RSA key . If the signature is valid, the Hypervisor proceeds to duplicate the executable code in memory, and in doing so the L2 block automatically encrypts it. Finally, the Hypervisor marks the respective memory pages as 'executable' and the rest is history.

Protecting the DVD reader

Due to the choice of a highly popular and affordable medium for game distribution, concerns about piracy resonated at Microsoft's headquarters. The anti-piracy system became a joint project between Microsoft and their suppliers, with varying results depending on the manufacturer of the DVD reader.

First-party security

From Microsoft's control, DVD drives authenticate with the system using a unique DVD key that must match an internal key handled by the Hypervisor. The DVD key is derived from the CPU key . If the check fails, the reader still works but won't be able to launch Xbox 360 titles.

Additionally, to avoid being read by conventional DVD readers and preclude exact duplicates, games are mastered using the new Xbox Game Disc 2 (XGD2) data format, which engraves a couple of anti-piracy tricks :

• A misleading table of contents that deceives conventional DVD players into loading a static video, this asks the user to insert the disc into an Xbox 360 console.
• Within the file system, there's a database stored that contains multiple checks called challenges or 'security sectors' the driver performs to confirm that the current disc is valid. When referring to the DVD drive, these challenges simply enumerate faulty sectors deliberately made during mastering that the drive needs to find. As conventional burners don't account for them, a duplicate would never pass the verification process.
• The outer area of the disc exposes a burst-cutting area, although it doesn't appear to include meaningful data for copy protection.

Finally, add to the fact the hypervisor only launches executables signed with Microsoft's private keys.

Second-party security

In practice, the entity responsible for implementing Microsoft's copy protection protocols is not Microsoft but the DVD drive manufacturer. In most cases, manufacturers just altered the firmware of their off-the-shelf hardware to abide by Microsoft's requirements. In any case, the Hypervisor blindly trusts the drive on detecting which disc is genuine and which is not.

As the copy protection subsystem is subsequently delegated to a third-party, multiple concerns arise. For instance, drives still communicate using standard ATA commands , so they must find ways to obfuscate sensitive exchanges of data. Furthermore, drives must be prepared to overwrite their firmware in case Microsoft revises a new copy protection mechanism. All of this, while preventing unauthorised parties from accessing this functionality.

While going through each security measure of each manufacturer is beyond the scope of this article, it's important to note that during the cat-and-mouse games that ultimately emerged, Microsoft had little control over how they were protected and subsequently patched , and this evident gap cost the company an early wave of piracy distribution.

Fallback techniques

As it's obvious by now that anti-piracy measures can only protect for so much time. The Xbox 360 was designed to have a mostly-overridable operating system. Anything but the boot ROM could be updated as long as the correct encryption keys were used (for which Microsoft was the sole owner).

Thus, throughout the console's lifecycle, the company issued software updates that patched the CB (second-stage bootloader), the Kernel, Hypervisor and the DVD reader's firmware. You will soon see the reasoning behind each one of these areas.

Additionally, Microsoft promoted (or actually, enforced) such updates by only permitting Xbox Live access from consoles running the latest system. This discouraged users from holding on to old versions and, combined with the anti-downgrade eFuses, reduced the availability of exploitable consoles, even for research purposes.

Finally, in the event of a modified console having access to Xbox Live services, Microsoft implemented many protections behind the scenes to keep hacked consoles and/or cheaters out of their network, including the use of 'Phoning home' routines to help Microsoft to detect 'special' consoles; and the subsequent application of 'permanent bans' by console blacklisting.

Defeat

If you've been following the Xbox 360's scene for some years, you probably know by now that this console enjoyed one of the most creative exploits of its generation. What initially started as simple arbitrary execution techniques (although they aren't particularly simple), was soon followed by commercial hardware sold for these purposes.

I'll try to give a proper summary of events now, but if at the end you feel hungry for more, well-known hacker '15432' wrote a very informative three-part article that dives into every breakthrough until 2020 .

The DVD drive saga

History seems to impose that whenever a console includes a widely-adopted medium like the CD or DVD, it's just a matter of time before that area is cracked. Especially since piracy is easier to deliver than homebrew.

In May 2006 (before the PlayStation 3 reached the stores), user 'commodore4eva' released the Xtreme Firmware, a replacement DVD reader firmware for the Xbox 360s bundled with early Toshiba-Samsung drives . The new firmware instructed the drive to look for hardcoded security blocks instead, which pirated copies would have relocated.

The firmware was flashed through the use of ATA commands, but it required a computer with a spare SATA socket and special flashing software. Consequently, users had to open up the console and connect the SATA data cable to their computer, run the flasher while the console supplied energy to the drive and then re-assemble everything back. The act of flashing emerged from a hidden 'maintenance mode' that was discovered in the drive's firmware, this was subsequently reversed and re-enabled. If the process was carried out successfully, the Xbox 360 would now read pirated games just like any genuine one.

Example of a DVD drive flashing tutorial found on Youtube . Here, the Xbox 360's drive connects to the PC using SATA while the console still supplies power (as the power connector is proprietary).

That's pretty much how the DVD drive got cracked. As time went by, the techniques evolved but the fundamental idea remained the same (flash a custom firmware). Subsequent readers increased their security to seal backdoors and Microsoft helped by bundling DVD drive firmwares within their 'software updates' to undo any unauthorised work done by the user. In later years, readers levelled up to the point the user had to drill a hole into the drive's System-on-Chip to enable flashing .

From Microsoft's headquarters, a new disc format called XGD3 was devised to improve the collection of challenges. Additionally, XGD3 increased the data capacity by expanding the writing limits beyond the standard area (hindering duplication along the way) .

The hypervisor saga

The fundamentals of the hypervisor may seem flawless at first, however, there's a technical compromise hidden underneath it: external components (the southbridge, the GPU, etc) need access to main RAM too. Yet, they don't understand the hypervisor's encryption mechanisms (as that's a matter between the CPU and main RAM). So, how can the I/O make use of RAM? Simple, through direct access (DMA) and unencrypted data. This is not a security breach per se, as the hypervisor still enforces its security on CPU-executable pages.

XeLL-Reloaded, a Linux and Homebrew bootstrapper. Loading this program into the Xbox 360 will soon become the No. 1 goal of any modder.

Nonetheless, this is what the early intrusions focused on. In other words, can we inject unsigned code into main RAM and then trick the hypervisor into executing it? Well, in February 2007, an anonymous hacker published a privilege escalation exploit that relied on the 2005 game King Kong . In the report, a clever chain of events was outlined to get arbitrary code execution at the hypervisor level (meaning full hardware access). The way it works is not simple to explain, but I'll try my best. Let's see...

The compare flaw

To organise all the routines available, the hypervisor stores a syscall table in main RAM , along with a handler that traverses such table.

When a program invokes a syscall, the handler starts by making sure the requested syscall number is valid. This is done by checking that its value is less than 0x61 (meaning there are up to 96 syscalls available). Finally, the handler translates the syscall number to a virtual address in memory (where the routine is found) and the CPU continues execution there.

Another concept to remember is that the hypervisor is stored in RAM in an encrypted form, and by extension all syscalls routines are encrypted too. Consequently, the resulting virtual address pointing to a routine has the encryption flag set. Thus, the L2 block seamlessly decrypts the data fetched from RAM before handing it to the CPU.

With that in mind, hackers took a look at the assembly code of the syscall handler and found a major flaw. Essentially, the syscall number is passed through a register. Registers in Xenon are 64-bit long, yet the validity check is implemented with the cmplwi instruction (used for unsigned 32-bit values). This means that if a program (previously authorised by the hypervisor) were to request a syscall with a value greater than 0xFFFFFFFF, like 0x20000000.0000002A, the hypervisor would only verify 0x0000002A and that would pass the check.

Now, where am I going with this? Well, if you recall, the upper 32 bits on 64-bit virtual addresses are used as flags to instruct the L2 block to encrypt/decrypt or hash the memory values, and if the flags are all zeroes, the L2 will interpret the data as unencrypted and pass it right away. That being said, if by some chance an external piece of unencrypted code were to be inserted in RAM through external means, there might be a way to execute it through the flawed syscall handler...

A new syscall

The previous discovery seems promising, but there are still many loose ends. For instance, we still need a way to craft an arbitrary syscall that doesn't get corrupted by the L2's decryption block.

Well, to make a long story short, it was discovered that, while the syscall handler converts the syscall number into a virtual address, if the most significant bit of the resulting virtual address happens to be anything but 0, then the converter won't add the encryption flag. Thus, the L2 block won't mangle the syscall function fetched, whether it's encrypted or not.

This was the missing puzzle that would allow hackers to execute a crafted and unencrypted syscall number, leading to arbitrary code execution. But it's not over yet, as we still need:

• An entry point that enables to inject the arbitrary syscall routine into main RAM.
• Another entry point to request the crafted syscall number, so the arbitrary routine can be executed.

And that's what we'll discuss now.

King Kong exploit

Enter the famous King Kong title. Like any other typical game, its disc stores vertex and pixel shaders files which are loaded at some point during gameplay. However, for some unknown reason, these files are found in completely plain (unencrypted) and unsecured form.

If you combine this with the fact the DVD drive can be modified to load duplicates, you could now make it load a King Kong game with modified shaders. Why would this be worth it? Well, do you remember the 'memory export' function I mentioned in the 'Graphics' section? Shaders can DMA to main RAM! Oof.

I guess you see where I'm going with this, if you craft a special copy of King Kong with custom shaders and insert it in an Xbox 360 with a flashed drive, you can start filling main RAM with arbitrary values. Hence, you can inject custom syscalls into main RAM.

This solves the first task of filling main RAM, but we still need a way of invoking the custom syscall...

Privilege escalation

Recall that the Xbox 360's kernel provides a scheduler to handle multi-threading. This apparatus takes care of dispatching virtual threads to the CPU cores and saving idle threads into memory for later use. Well, for another unexplained reason, the scheduler stores thread states in RAM as unencrypted data!

Combining all explained, one could now craft a shader that corrupts an idle thread in RAM which, once restored, would continue execution with custom parameters. This process would carry on until all parameters are finally in the hacker's control so execution can be redirected to the syscall handler and, combined with the use of calculated parameters, would finally jump to the crafted (and unencrypted) syscall.

And this is pretty much how the hypervisor got hijacked by arbitrary code. A common payload bundled with this process consisted of a Linux launcher, as using Linux with full hardware privileges allowed users to extract sensitive information from their console, like the CPU key (which could come in handy in the future, you'll soon see).

Protecting King Kong

The King Kong exploit was a huge step for the Homebrew scene. I'm not sure if you noticed, but no encryption keys were needed whatsoever (so much for having a strong security system in place...).

Be that as it may, Microsoft was already made aware of it and subsequently patched it in January 2007 (one month before the report was published). Nonetheless, efforts continued in finding similar exploits for updated consoles. Additionally, hackers could now obtain an outdated console and make use of the King Kong exploit to expand their research.

As a result, throughout the same year of the King Kong events (2007), new discoveries were made:

A hidden maintenance mode

Once CB, the second stage bootloader, was reverse engineered, a new backdoor was discovered. One of the checks CB performs is comparing a string stored in CB's headers against checksums in NAND. Well, if that string (called 'pairing information') turns out to be all zeroes, then the check is skipped and the boot process continues while ignoring the CPU key. The only downside is that no update packets are applied and the Kernel ends up launching an alternative app called MfgBootLauncher (presumably used during manufacturing) instead of the Dashboard.

Initially, this discovery didn't attract attention as it didn't seem to lead to any interesting development. However, this changed after Microsoft noticed mentions of MfgBootLauncher and subsequently released a new system update, which ended up attracting too much attention, even to the point this special 'manufacturing mode' became an opportunity to homebrew!

Before we continue with this story, there's one more hack that needs to be explained...

The timing attack

For manufacturing reasons, the motherboard exposes many groups of headers that perform (undocumented) functions, some of which were reverse-engineered to work in the hacker's favour.

In August 2007, XboxHacker user 'Arnezami' published the timing attack method for downgrading any console to a King Kong-vulnerable firmware version .

This time (pun intended), the new attack expects the user to extract the contents of the NAND (a.k.a produce a dump) and use an automated script that merges console-unique information from the dump with a generic image of the system 2.0.1888 (the first revision of the operating system).

To get past the second-stage bootloader checks (which compares the update counter from the eFuses with the updates installed), the crafted firmware needs to match the value of the eFuses' counter. Yet, it's not that simple to tweak, as the counter in NAND is signed (with HMAC) using the CPU key , and the CPU key can't be extracted if the Xbox 360 is running a patched firmware...

Well, for manufacturing purposes, the motherboard exposes Serial Peripheral Interface (SPI) pins to write and read from NAND; and POST pins that output different values representing the current state of the boot process. It so happens that during the eFuses validation (implemented with C's memcmp()), the comparison is done on a byte basis. Most importantly, during each comparison, successful matches always take 0.22 ms to complete and failed ones take 0.21 ms .

Combining all this, one can automate a trial-and-error guesser until the whole signature is brute-forced. This is what the timing attack consists of. Once the secret code is extracted, it can be applied to the altered 2.0.1888 image which, once flashed into the console's NAND, the console will take as valid. From there, the user may update to a King Kong-vulnerable version.

In the end, Microsoft fixed this bug in early 2008 with a new software update that slightly changed the memcmp() function in CB.

More CB research

Once you manage to boot Linux (Gentoo, in this case, thanks to the efforts of the Free60 group) you can peek at Xbox's privileged areas in memory, like the eFuses (where the CPU Key is). Screenshot by .

One day, Microsoft published a new CB update (version 1920) that aimed to tackle the discovery of the then-harmless manufacturing mode.

In an obfuscation attempt, Microsoft decided to add the CPU key as a parameter for encrypting/decrypting 4BL (the stage responsible for loading and updating the Kernel and Hypervisor), making it impossible to reverse engineer it. However, thanks to the timing attack, CPU keys could be ultimately extracted. Thus, hackers were able to decrypt 4BL and proceed to find new holes in it. Luckily, they found a major change in the 'manufacturing mode': if the update packets have their pairing information zeroed out as well, then the updater will apply them.

All of this led to a very important milestone: it was now possible to boot arbitrary versions of the system without knowing the CPU key. Yet, this wasn't exploited until much later, which brings us to our next saga...

Setting King Kong free

As homebrew development kept evolving and the King Kong method became too cumbersome, the focus shifted to finding new techniques for automating the hypervisor exploit, and the results were astonishing, to say the least.

A suspicious update

Two years after the King Kong exploit publication, in August 2009, Microsoft released an unexpected software update 2.0.8498 that, once again, overwrote the CB (second-stage bootloader) and increased its respective eFuse counter . Not only this update surprisingly writes over crucial parts of the system (with the risk of breaking it irreparably), but it also caught the attention of many hackers to find out what was Microsoft trying to patch.

The Free60 group, in their continuous efforts to deliver Linux on the Xbox 360, advised users to hold on to their current system and not succumb to the update. Behind the scenes, they already knew about the implied exploit and were preparing to release a new technique that the public could take advantage of.

The JTAG/SMC hack

In November 2009, the Free60 group published their technical report which was later known as the SMC/JTAG hack . With this, the Xbox hacking community were made aware of two big discoveries.

The first one exposed the zero-pairing exploit that allowed to boot any system version, this is what I explained a couple of paragraphs before. The second one described how to automatically trigger the Hypervisor exploit and inject a payload in a console running a King-kong-vulnerable system version, meaning there would be no need to keep a modified copy of King Kong and a flashed drive anymore.

Because I've already explained the first exploit, let me go over the second one, as it's quite uncanny. Remember the System Management Controller (SMC)? That wee Intel 8051 running inside the Southbridge to handle I/O tasks? Well, during boot, the SMC loads up its firmware from NAND, and that's what Free60 exploited to take over the SMC.

As the motherboard exposes GPIO pins from the SMC and JTAG pins from the CPU and GPU, hackers found out that they could perform the following technique:

1. Make an image of the NAND's contents using a NAND reader.
2. Using the zero-pairing backdoor, modify the image to only apply updates leading to a King-Kong exploitable Hypervisor.
3. Modify the SMC firmware area (in the NAND's image) so, during boot, the SMC commands the GPU to DMA the same block of code used in the King Kong disc.
4. Flash the modified NAND image back into the console using a hardware NAND writer.
5. Solder two wires with switching diodes between the SMC's GPIO and the GPU's JTAG.
6. Turn on the console and wait for the payload to show up.

With this, a permanent and automatic homebrew launcher was obtained! (as long as you didn't update to 2.0.8498).

The dawn of Homebrew

Even though the aforementioned discoveries were outraced by Microsoft's updates, the homebrew community kept gaining momentum and new applications emerged to become a 'must have' for any modding enthusiast:

• XeLL (from Xenon Linux Loader), later forked as XeLL-Reloaded, is the de-facto payload used with the Hypervisor exploit . It sits as a second-stage bootloader with an amount of functionality analogous to a Victorinox for Scouts. XeLL enables to boot up Linux or an ELF executable written with libxenon, an alternative SDK designed for homebrew development. Furthermore, upon loading, its text interface automatically displays the eFuses data and other low-level information on-screen so the user can write it down if needed. If that's not enough, its self-hosted HTTP site provides extra controls to dump the contents of the eFuses and NAND on-the-fly.
• freeBOOT is a modification of the official operating system that disables the signature verification of the Hypervisor and removes hardcoded caps set by Microsoft (i.e. the Security sector checks preventing to use of third-party hard drives), among other things . freeBOOT is loaded from XeLL and proceeds to boot the official system as any other unmodified console, except that non-signed executables can be launched from the Dashboard from now on. At the time of this writing, applying Freeboot remains the main goal for most homebrew users.
  • To produce a 'freeBOOTed' image (eventually flashed into the NAND), the CPU key of the console is needed. This means the console needs to first load XeLL (using a previous exploit) so the key can be extracted. Then, a new NAND image with Freeboot's patches applied can be generated.
• FreeStyle Dashboard and Aurora are two replacements for the original Dashboard that provide enhanced controls for executing homebrew apps, loading up game dumps and tweaking low-level settings (i.e. fan speed). While they are meant to overtake the official Dashboard, they are still loaded as any other XEX executable.
• XeX Loader and XeX Menu are homebrew launchers that can be run from the official Dashboard.
• Dashlaunch is another program that provides a collection of patches for the official system , except they are loaded at runtime (avoiding the need for flashing NAND). One of Dashlaunch's functions includes the ability to automatically load an executable after the Dashboard boots, this is often used to quickly load the alternative homebrew-friendly FreeStyle Dashboard or Aurora.

FreeStyleDash running on my modified console, offering many controls and indicators not found on the official dashboard. For those veteran Xbox 360 users, you'll notice its interface resembles the iconic NXE era!

To facilitate the process of building a NAND image with XeLL and/or Freeboot, many Windows programs like XeBuild, J-Runner and AutoGG were developed to automatise this process as much as possible.

Outracing Microsoft's advantage

As joyful as the previous events may seem, I'm afraid to say that the SMC/JTAG trick was released just after Microsoft patched it! If you are curious, the software update blacklisted King-Kong vulnerable Hypervisors so they can't be loaded at CB. Moreover, the new CB also blew a new eFuse counter, so it was made impossible to fight back... unless a new unimaginable hack were to be published...

The glitcher

First demo showing the RGH hack on a Slim (Trinity) console .

After two idling years since the last major breakthrough, in August 2011, user 'GliGli' submitted a technical report outlying the discovery of a Reset Glitch Hack (RGH) . This new technique allowed any type of Xbox 360 (no matter its update installed) to run an arbitrary version of the Hypervisor, just like the SMC/JTAG hack, except that it will now need an external chip soldered in.

In a nutshell, RGH exploits a fundamental flaw in the CPU's circuitry: if the CPU receives a short pulse (4 to 60 ns long) on its RESET line, the CPU will not reset but continue execution in a corrupted state. In other words, if the CPU is in the middle of executing an mr (move register) instruction when the glitch happens, the destination value will be 0 instead of the content of the source register. This can work to the hacker's advantage if the CPU is in the middle of asserting something crucial, like verifying the bootloaders. Additionally, user 'cjak' found out that by latching a special line in the motherboard called CPU_PLL_BYPASS, the CPU is slowed down to ~25 MHz, thereby making room to glitch it.

With this, GliGli and a group of hackers grabbed a generic but fast CPLD board (similar to an FPGA), soldered it to many useful points on the motherboard and programmed it to:

1. Keep track of the Xbox's POST signals to know when and where to latch the buses.
2. Slow down the CPU when CB is about to validate CD's hashes.
3. Latch the RESET line when CB is in the middle of a memcmp() function (related to the hash verification).
4. Revert the CPU's original speed and hope that the memcmp() has magically succeeded.
5. If the process worked, a custom payload is executed.

With this, a board programmed to glitch the Xbox 360's CPU became known as a glitcher.

Because the process relies on correct timings (from a combination of POST inputs and hardcoded timers) and very precise signalling, success is not guaranteed anymore. Although to automate the process, the SMC's firmware is altered to keep rebooting the console if the boot stage has failed.

And with this, the homebrew community was gifted with an unfixable exploit to load homebrew.

Microsoft's retaliation

While the new 'Trinity' motherboard brought many long-awaited improvements - such as unifying the CPU and GPU into one package to reduce heat - it also complicated hackers' endeavours.

While the RGH hack attacks the fundamental construction of the CPU at an early stage (thereby making it impossible to tackle it with a software update), Microsoft never displayed any sign of weakness and released further updates of CB (the second-stage bootloader) and new motherboard revisions in an attempt to garble the glitching process.

For instance, the new Slim edition of the console released in 2010 (ironically, a year before the publication of RGH) codenamed Trinity moved the CPU_PLL_BYPASS point to a location hackers couldn't find (yet). Meanwhile, the RGH team found out they can fiddle with the PLL signal of the video encoder chip via I²C, and this will condition the speed of the CPU. Unfortunately, the video encoder can only slow it so much (just ~3 times ) so the precision and success rate is reduced. Nonetheless, it's still a huge accomplishment.

Additionally, Slim consoles split the CB stage into CB_A and CB_B, where CB_B is further encrypted with the RC4 algorithm and relies on the CPU key. To add more to the despair, the zero-pairing backdoor got completely removed. Finally, all of these changes would soon be extended to older models as Microsoft publishes more software updates. Be that as it may, hackers never gave up and found out they could modify CB_B in its encrypted form. Thanks to a mathematical flaw in RC4, encrypted information can be altered just by applying XOR with an unencrypted delta patch , thereby allowing to disable encryption routines on CB_B without knowing the CPU Key!

Selling RGH

The 'X360 Squirt 1.2' setup for Trinity motherboards. This was one of the many commercial glitchers available to hack your Xbox 360.

During the following three years, the resilience of the RGH hack managed to resist all of Microsoft's efforts to mitigate it. Meanwhile, what remained was a good-old cat-and-mouse game, with Microsoft trying to make the task unfeasible. And so, new variants of RGH were scattered across many forums to face the incoming wave of software updates. The variants shared the fundamentals of the RGH hack, but each used an alternative program for the glitcher and the modified SMC image to improve the success rates.

Initially, the RGH hack, as a program for the glitcher, materialised into two different variants: RGH1, which depended on the PLL line, and RGH2, which relied on the video encoder. The latter could be enjoyed by any motherboard revision and was continuously fixed to tackle Microsoft's attempts to break it; and while RGH1 couldn't get past old hardware (Trinity) and software (update 2.0.14699), it enjoyed greater reliability.

In any case, the success of RGH paved a wave of commercial glitchers and installation kits. These promised that, at a higher price point, would provide easiness of installation and better success rates. I believe Team Xecuter is one of the best examples that greatly capitalised on the RGH fever. The company sold customised versions of Xilinx's 'CoolRunner' development boards to compete against other programmable glitchers on the market. Most notably, Team Xecuter's boards came either pre-programmed or with support for their new variants of RGH:

• As a result of Microsoft's attempts to fix the XOR exploit with update 2.0.15572, in December 2012, Team Xecuter shipped a new board called DGX (Double Glitch Hack) to focus on extracting the CPU Key , and then proceeding like any other RGH method. In this way, Microsoft's update was addressed by flashing old unencrypted bootloaders and then using DGX to glitch the boot process twice to bypass both comparison and validation of the modified CB_B.
  • It was later found out that Team Xecuter's method was more of a brute-force attack. A more reliable procedure only requires to glitch when CB_A is preparing to copy data from NAND .
• The R-JTAG glitcher for non-Slim consoles . Released in May 2013, this new method for updated consoles attempts to approximate the old success rate of RGH1. Basically, R-JTAG glitches the CPU to load an old version of the Hypervisor vulnerable to the JTAG/SMC exploit, and then proceeds as the latter hack did.
• With their new flagship 'CR4 XL' glitcher, RGH2+ was presented as a new mode to improve over the classic RGH2. This time, the CPU slowdown process was delegated to the SMC .

For one reason or another, Team Xecuter didn't provide any documentation to replicate these new techniques on other devices. So users took matters into their own hands to deliver cheaper and/or better alternatives:

• First, 'DrSchottky' managed to create an open-source implementation of R-JTAG called R-JTOP for any glitcher to enjoy .
• Secondly, developer 'blaKCat' bundled the double-glitch routines in his flashing utility, so any board could be programmed without depending on the expensive DGX.
• Thirdly, in December 2014, hacker '15432' published the 'Speedy RGH' (S-RGH) as an alternative to CR4's proprietary RGH modes. S-RGH even gained faster speed by reducing the slowdown periods during the glitching process.
• Later on, in April 2015, 15432 did it again and published a new method called RGH 1.2, combining RGH2 and the use of the CPU's PLL line , achieving similar success rates to RGH1.
• Finally, in August 2021, engineer Josh Davidson managed to port RGH 1.2 to Slims by finding the missing PLL line on the new motherboards , resulting in a new variant named RGH 1.2 V2.

The endgame

With the approach of the Xbox 360's successor, Microsoft took one last breath and shipped a redesigned version of the console called 'E', and within it, another motherboard revision called Winchester. In retail models, Winchester finally disables the POST and PLL signals and filters the CPU RESET line from external disturbance . This rendered the RGH hack, after three years since its discovery, obsolete.

However, for the compatible motherboards (which are still found in abundance), only wonderful things awaited. Apart from the mentioned RGH variants, there was still a golden discovery to be uncovered. Fast forward to November 2021, 15432 surprised the community again by publishing RGH 3.0, a universal RGH variant to rule them all. Behind the scenes, the new technique is an evolution of RGH 1.2 V2 that doesn't require a glitcher anymore . This was done by implementing the glitching stage into the SMC, which now only needs two wires soldered on the motherboard (in particular, the newly located CPU_DBG1_POST1 and CPU_PLL_BYPASS) to execute the hack.