Get best of the week

Protecting and Hacking the Xbox 360 (Part 3)



In 2011, 6 years after the release of the Xbox 360 game console, the researchers discovered an interesting fact - if the signal “0” is sent to the RESET output of the central processor for a very short time, the processor will not reset its state (as it should be), but instead change your behavior! Based on this “feature”, Reset Glitch Hack (RGH) was developed , with the help of which it was possible to completely compromise the protection of the Xbox 360, run unsigned code, thereby opening the way to hacking the system itself and defeating the “unbreakable” DG-16D5S drives .

Let's take a closer look at how RGH worked, how the developers tried to patch a hole, and how these patches were able to get around!

What is a glitch attack?

The processor is pretty dumb, no matter what marketers say. All the high-level code written by programmers is reduced to the execution of simple commands - arithmetic with numbers, moving data, conditional and unconditional jumps. It is assumed that the processor always executes these commands without errors, and the result matches the documentation.

Indeed, compiling the code
i = i + 2;
you rely on the fact that the value of the variable i will increase by exactly 2, without even realizing how it could be otherwise.

Glitch attacks violate this confidence - their goal is to ensure that the processor is “buggy” and behaves wrong. There are several ways to “glitch” the processor, for example:

  • Draw down CPU voltage
  • To give an extra impulse to the reference frequency of the CPU
  • "Shine" on percent radiation

There are special devices for carrying out such attacks - for example, ChipWhisperer offers a wide range of attacks in frequency and power:



In the case of the Xbox 360, a “glitch” occurs as a result of exposure to the RESET line. The processor begins the reset procedure, but due to the very short duration of the signal, it does not have time to complete it and continues to work as if nothing had happened. But just for this brief moment, while the RESET signal is active, its behavior changes!

Glitch processor

Xbox 360 protection rests on bootloaders checking each other in a chain. Ultimately, the verification at each stage comes down to calling the function of comparing the hash sum with the “pattern”. It was then that they applied the glitch attack, forcing the processor to ignore the mismatch. An impulse to the RESET line immediately after calling the memcmp procedure forces the processor to “go” along another branch and continue loading, even if the hash sum is incorrect:


The best place to attack was found in the bootloader of the second stage, "CB". The later stages are harder to attack (and easy to fix), but at the first stage of loading ("1BL", ROM) the attack failed due to a slightly different construction of the program code.

It sounds simple, but in fact, when trying to carry out an attack, many nuances were discovered.

First, in order to successfully conduct a glitch attack, it is necessary to very accurately determine the point in time when a RESET pulse should be applied. If you make a mistake at least for a microsecond, send too short or long impulse, the attack does not work.

Fortunately, on Xbox 360, each boot step is accompanied by a change in value on the POST_OUT debug bus. Moreover, the debug output is so often arranged that a new POST value is set immediately before comparing the hash sum:


So close the location of the debug output from the attack site was an extremely convenient trigger. POST_OUT is a parallel bus and is output to 8 test sites on the printed circuit board, each of which is responsible for one of the bits of the value. It was even possible to simplify the connection scheme using only one bit and counting the number of changes in its state since the system booted up:


It also turned out that due to the high frequency of the processor, it is almost impossible to get to the right moment in terms of accuracy and duration. The exposure time should be very short, on the order of the execution time of one instruction by the processor. But the slower the processor runs, the longer the time interval suits us. Therefore, we take and slow down the processor!

On a regular PC, the CPU frequency is defined as the product of the external, “reference” frequency and multiplier:


So in the Xbox 360, external lines of the reference frequency are suitable for the processor, and inside this frequency is multiplied by PLL . And on the old, “thick” revisions of the set-top box, the PLL mechanism could be turned off, slowing down the processor as much as 128 times:


On the “Slim” versions, the PLL trick cannot be done (the line is not separated on the board), and since we cannot influence the “Slim” factor, we will reduce the “reference” frequency!

It is generated by the HANA chip, and it can be configured via the I2C bus:


Unfortunately, it was not possible to reduce much, “at low speeds” the final processor frequency began to “swim” strongly, which reduced the chances of success. The most stable option was a slowdown of 3.17 times. Not 128 times, but at least something.

All? No, not all. It is far from a fact that the attack will work the first time (especially on Slim). And if the start fails, the prefix reboots and tries to start again. Only 5 attempts are given to start, after which the prefix stops and starts blinking the “red ring of death”. Therefore, we also patch the south bridge firmware (SMC) so that it does not suffer from garbage and reboots the prefix until it turns blue:


So, we get the algorithm:

  1. patch SMC
  2. slow down percent (via PLL or I2C)
  3. waiting for a POST trigger
  4. waiting for N microseconds
  5. send impulse to RESET
  6. speed up percent back

For greater accuracy of calculations, we take the frequency from the same HANA (48 MHz):


And we get such a design based on the inexpensive CPLD Xilinx XC2C64A:


Do not forget to shamanize with the length and location of the wiring on the RESET (pay attention to the "coil" at the bottom of the photo) and forward, hope that the launch will work out within a minute.

But this is only on the hardware side. How do we patch the bootloader and stuff our code?

Patch loaders


As I mentioned, the second-level bootloader, “CB,” is being attacked. This bootloader is encrypted with a fixed key, the same for all consoles, but just “CB” cannot be modified, we only attack it. But the next one is already encrypted with a CPU key, unique for each set-top box. And to modify it, you need to know this key ...
Or not?

In the old "thick" revisions of the Xbox 360, the so-called "Zero-Pairing" mode, which is used at the stage of production of the console, was supported in the CB loader. Each bootloader's header at offset 0x10 contains a random Pairing Data set that is used as part of the key for decryption. And if this data set consisted entirely of zeros (“Zero-Pairing”), then the processor key was ignored and a fixed, zero key was used instead!


With this trick it was possible to assemble an image with the original “CB”, encrypt the next bootloader, “CD” (with its own code) with a zero key and run it using RGH!


In the consoles “Slim” wrapped this trick, removing the “Zero-Pairing” mode and dividing the “CB” into two parts. Here, “CB” was divided into a very simple and small “CB_A” and encrypted by the processor key “CB_B”:


But encryption with the RC4 algorithm (namely, CB_B is encrypted with this algorithm) has one peculiarity. In the process of encryption based on the key, a pseudo-random data stream is generated, which is binary “added up” (operation 'exclusive or', 'xor') with the source data. When decrypting, accordingly, the same thing happens, adding with the same pseudo-random stream returns the data to its original value:


But the binary addition operation is commutative and associative, which means that we can modify the encrypted data without knowing the key, just for xor 'and the encrypted code with the patch we need!


As a result, we can encrypt “CB_A”, patch the encrypted “CB_B” (so that it does not perform decryption at all) and put in plain text “CD” with its code!


In short, if you put it together, then the launch looks something like this:
(XeLL is the bootloader of homebrew, Linux, and it also shows the CPU keys)


Microsoft strikes back


Of course, Microsoft tried to patch everything up.

In the new system update, all old consoles were transferred to a “separate” boot from “CB_A” and “CB_B”, thereby finally closing the “Zero-Paired” mode. On Slim, bootloaders have also been updated. The new bootloaders have been seriously modified to protect against RGH, with the greatest emphasis being placed on the protection of CB_A:

  • Completely removed debug output in POST
  • The hash verification has been redone and duplicated for reliability
  • Throughout the code, sleep () was set for a random time (depending on the CPU key !!)
  • Added CBLDV fusion check to revoke CB_A


The list of innovations leaves no chance for RGH. But let’s pay attention to the last item on the list - before that, there was no fusion check in CB_A! Fatal flaw. Moreover, as we recall, the processor key is not involved in decoding “CB_A”. This means that the CB_A loader vulnerable to RGH can be launched on any console, and this cannot be prohibited.

But in order to start something with the help of this vulnerable "CB_A", you need to dodge a little. If we do not know the CPU key, all that remains for us is to patch the existing “CB_B”. But what if, instead of modifying individual sections, we completely overwrite the entire bootloader? And due to this, "write" the old bootloader, which we already know how to patch, to replace the new one? So they did:

  1. We encrypt the vulnerable CB_A in the same way as in the original image
  2. XOR our CB_B with the new, getting the “difference”
  3. We put it on the encrypted "CB_B"!


Everything, again, without knowing the key, we successfully replaced the encrypted content, and also put the vulnerable bootloader. Consoles hack, Microsoft are surprised.

The developers worked hard, and in the next system update ... slightly changed the encryption method "CB_B", now the encryption key has also become dependent on the version of "CB_A":


Now, when trying to xor 'and shove the data to the vulnerable "CB_A" of the old version, the bootloader decrypted the garbage due to differences in keys. And the new bootloader cannot be hacked, it is well protected from glich attacks. So far, victory for Microsoft!

Corona throws problems

Meanwhile, a new revision of the Xbox 360, Corona, entered the market, and it brought modders problems:


Not enough chips on the board, can you find it? That's right, the HANA chip was "hidden" in the south bridge. There is nowhere else to take the frequency of 48 MHz for the mod chip, the previous I2C slowdown commands do not work. But what is it, the 16 MB NAND flash, which has served as the Xbox 360 system storage all these years, was treacherously replaced with a 4 GB chip with an eMMC interface! (True, only in the cheaper version of the console, but still):


But nothing, everything was dealt with. We figured out how to read / write flash memory through a card reader:


Found new I2C slowdown commands, an external 48 MHz crystal oscillator replaced HANA:


Completed build scripts, added support for 4 GB NAND ...


But Microsoft continued to put sticks in the wheels. For example, on the new boards, some resistors disappeared, without which the mod chip stopped working:


True, this was fixed by installing jumpers with a soldering iron:


Things got more serious when the POST_OUT tracks disappeared from the board:


But here Microsoft was not lucky, the CPU “balls” needed for RGH were on the extreme row:


And, of course, they were able to connect to them. First, the most sleevey ones, slightly drilling up the edge of the processor and soldering directly to the ball with the wiring:



And then the Chinese released a framework with a spring-loaded needle, exactly resting on the ball, and the problem was solved for everyone else:


The Last Frontier


After we defeated the “crown”, there was one problem - new versions of the system did not give in to hacking. To start RGH, you need to know the CPU key, and to find out the CPU key, you need to run RGH at least once. The problem of chicken and eggs in general.

And then a thought arose - and let's not only check with “glitch” authentication, but we will also skip the decryption! If it works out, then we don’t need to know the key, put “CB_B” in the clear, that's all. This idea formed the basis of Double Glitch Hack (DGX):


This chip “buggy” the percent twice, the first pulse skipped the decryption phase of the bootloader, and the second pulse skipped authentication. It worked much less stable, since at least one successful launch was required - then we get the CPU key and proceed as before.

DGX was not relevant for long, after 3 months the Chinese threw in the release of “DGX RIP” with images that run on any set-top boxes, worked with standard RGH and, of course, started much more stable:


These images contained a special version of the CB_A bootloader used in the Xbox 360 production and, in fact, is a complete analogue of the good old “Zero-Pairing” mode. Instead of the processor key, this "CB_A_mfg" decrypted "CB_B" with a fixed null key:


And here Microsoft is. In this “service” version of “CB_A” there was also no fusion check and it was impossible to ban it. It was enough to record the image according to the revision of the Xbox 360, solder the chip - and everything worked.


Winchester!


RGH was fully fixed only in the new revision of the console, codenamed Winchester. For the first time, CPU and GPU processors combined in one chip, the board was simplified as much as possible:


POST_OUT tracks were not just removed. Even if you solder to the platform under the processor:



And even if you solder the processor to a special version of the board for developers, XDK, where these tracks are still there:


On POST_OUT, only one pulse is visible when the console starts. Bus locked:


Moreover, it is blocked only at the production stage. If you take a “clean” processor from a factory where you haven’t burned fuses yet, POST_OUT works on it!


But RGH on it no longer works. No matter how you try to give a RESET pulse, the processor correctly performs a reset, or ignores your signal due to its too short duration. Apparently, a special logic module was added to the processor, filtering the RESET line and thereby finally fixed the hardware error.

Post scriptum


It turns out that the latest revision of the Xbox 360 is impossible to hack?

Yes and no. At the moment, there is only one known way to run a modified system on Winchester revisions.

The software development kit (XDK) contains various private keys for signing compiled code. And so it turned out that among them the signature key “shadowboot”, a third-level bootloader for XDK systems, was cluttered. And with it, you can collect a legitimate signed image with modified firmware. Just work on ordinary, "store" consoles, he will not. We need a processor with the XDK version of the console, or a “clean” CPU with non-fused fuses (you could see it on Aliexpress):


And only then will you have the opportunity to contemplate such an inscription in the "system information" of the custom shell:


And that’s all! As usual, I’m ready to answer your questions in the comments :)

Xbox 360 Protection and Hacking, Part 1
Xbox 360 Protection and Hacking, Part 2
Xbox 360 Protection and Hacking, Part 3

More articles:


All Articles