👨🏽‍🤝‍👨🏻 🏔️ 🐣 Protecting and Hacking the Xbox 360 (Part 1) 👨🏼‍💼 👎🏼 📊

You've probably heard about the Xbox 360 game console, and that it is “flashing”. By “firmware” here is meant a bypass of the built-in protection mechanisms for launching copies of games and proprietary software. And here questions arise! What mechanisms, how do they get around? What did the developers do, how did they manage to get around it? In fact, the topic is very extensive and interesting, especially for the Xbox 360 - here you can find software vulnerabilities, hardware flaws, and absolutely magical magic. Interesting? Drop in! In the first part, we are introduced to the hypervisor, drives and firmware ...

Meet the subject

The Xbox 360 game console was released in 2005 and has not undergone changes in the characteristics of iron since then. All the time that it was released, they were the same:

3.2 GHz PowerPC CPU, / 3 cores
500 MHz GPU
512 MB RAM
SATA DVD-ROM
SATA HDD (optional)

Yes, design changed over time, nanometers decreased:

Nevertheless, all games worked equally well on all “revisions” of consoles - this is exactly the case when modern games can be run on 2005 equipment.

At the time of the release, a loud statement was made that the console was developed as secure as possible - custom chips with protection at the hardware level, and in general, hackers have not seen this yet:

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

What did the developers come up with?

Firstly , they did everything so that the program code of the system could not be obtained . A 32 KB ROM containing a primary loader (1BL) and a 64 KB SRAM in which it was executed were built into the central processor. It is very, very difficult to get the contents of a ROM from a CPU chip:

Secondly , special fuses were put into the same processor - burned (literally, high voltage) jumpers, a kind of once programmable memory. The fuses included:

JTAG interface lock bits
bits determining the purpose of the prefix (retail / devkit / testkit)
unique 128-bit processor key
Lock-Down Value (LDV) counters to disable downgrade

Yes, the amount of fusion is limited. If you manage to update your console 80 times in a row, the CFLDV counter will end and ... I don’t know, I have not tried to do this. Probably, the prefix will no longer be updated.

Third , the developers have implemented a chain of trust . To verify the authenticity of bootloaders, a combination of modern (at that time) SHA-1 and RSA-2048 algorithms was used, which excluded the possibility of launching your own code or unauthorized modification of bootloaders even if you somehow got all the keys from the console and were able to rebuild the system .

Fourth , the developers decided to go further on the principle of "trust no one" and put a special hardware module for protecting RAM into the same unfortunate CPU ! With its help, all areas with program code were encrypted, and integrity monitoring was turned on for the most important areas (hypervisor)!

By doing this, the developers defended themselves against DMA attacks when, through external devices that have access to RAM, they modify the system program code in RAM.

Finally , the hypervisor dealt with the differentiation of rights into memory regions . Only he could make the pages executable, of course, before that he checked the digital signature, so it was impossible to download unsigned code or execute something from the data area even through a vulnerability in some driver or game (the axis and games were launched with kernel rights) .

As a result, the Xbox 360 operating system was well protected, and therefore, DVD-ROM was chosen as the first attack vector.

We start ... backups!

In the Xbox 360, a dual-layer DVD was chosen as the main media for games. Naturally, defense mechanisms were also present here:

data exchange with DVD-ROM was encrypted with a unique key
at the beginning of the disc there were special “Security Sectors” to confirm licensing
executable files on disk were digitally signed

But much less attention was paid to protecting the DVD drive than to the main system. The game console showed too much confidence to the DVD drive - it was the DVD-ROM that determined the licensing of the disc. Moreover, the firmware was stored in external memory and could be read by the programmer:

As a result, on May 14, 2006, commodore4eva (c4eva) released the first modified firmware to drive the TS-H943 model:

README for firmware release

— Xtreme firmware for TS-H943 Xbox 360
— Here it is, the long awaited World first Xbox 360 backup firmware modification to boot all game backups!

Features
— Boots all Xtreme Xbox 360 backups
Boots all Xtreme Xbox 1 backups
Boots all Xbox 360 originals
Boots all Xbox 1 originals on Xbox 360
Xtreme0800 extraction firmware enables drive to function natively under Windows without any hardware conversion/adaptors
Use on Xbox Live at own risk

Technical details
— Reads Xbox 360 security sector from PSN 04FB1F (Layer 0)
Reads Xbox 1 security sector from PSN 605FF (Layer 0)
Security sector must be extrated using Xtreme0800 360 firmware for Xbox360 games and Xbox 1 games
Will not boot Xbox 1 backups made with Xbox1 605b 0800 firmware (maybe in future release)

The firmware read security sectors from fixed areas on a DVD disc and tricked the console, making it think that a licensed disc was inserted.

At the same time, the 0800 firmware was released, designed to create copies of games and read security sectors. The Xbox 360 drive, flashed with such firmware, was detected on the computer and could fully read the sectors of the game disc.

README on using 0800 firmware

Extracting Security Sector
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following four custom cdb commands:

AD 00 FF 02 FD FF FE 00 08 00 01 C0
AD 00 FF 02 FD FF FE 00 08 00 03 C0
AD 00 FF 02 FD FF FE 00 08 00 05 C0
AD 00 FF 02 FD FF FE 00 08 00 07 C0

Then save hexadecimal display as bin file as SS.bin

Creating a game backup
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Extract Isobuilder.rar
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following custom cdb command to unlock drive: (game data visable)

FF 08 01 01

Run Isobuster
Right click on DVD and select Extract From-To
Click Length and enter number of LBAs as follows:

Xbox 1 Original Number of LBA to read 3431264 decimal
or
Xbox 360 Original Number of LBA to read 3567872 decimal
Select User Data (2048 bytes/block)
Click Start Extraction
Enter filename as game.iso and click Save
Upon read error dialogue box choose fill with blank zeros for sector and select use this selection for all errors
Copy game.iso and ss.bin to the relevent isobuilder directory (Depending on Xbox 360 or Xbox 1 game)
Run build360.bat (Xbox 360 game) or build.bat (xbox 1 game)
Ensure your burner will set the booktype of DVD+R DL to DVDRom
Burn with CloneCd and choose the image.dvd file

Another game could be partially copied with the following trick:

put in a computer DVD-ROM ordinary two-layer disc
wait until it calms down and stops spinning
with a paper clip, open the tray and change the drive to the game from the Xbox 360
close the tray and make a disk image!

(It didn’t work on all DVD-ROM models)

The most important thing is that the drive was flashed exclusively by software, with special ATA commands. The kit included a special program for reading the original firmware and writing modified. In the original firmware, the treasured key was stored, with which the drive was tied to the Xbox 360:

The loss of the key meant that even licensed disks could not be launched, so some wrote the key in a notebook, saved it wherever possible, this was the most cherished knowledge.

A separate topic was the panic about the game online. Everyone was afraid that Microsoft would find out that the drive was modified and remotely disable the console. Some even made a hardware mod to switch between factory and modified firmware:

They played on the original firmware “in license” and, with a connection to the network, shamefully disconnected them on the modified Internet cable. By the way, the panic was not in vain, but such mods were completely in vain, everything was logged without connecting to the network.

Exactly one month later (June 15, 2006) the firmware was ported to another drive model, which was installed in the Xbox 360 at that time - Hitachi GDR3120L. He also had an external flash drive containing firmware:

This drive was better protected:

firmware was stored in ROM in encrypted form
there was integrity control in the firmware
to overwrite the firmware, you had to go into a special “Mode B”

And if the researchers managed the first two points themselves, the feat of translation in “Mode B” was to be repeated by all the ~~young~~ flashers.

This action was proposed to be performed using a special boot disk with Slax Linux, or by shorting the wires at startup. It was necessary to short-circuit the contacts 0 and 9 of the drive power connector. For example, with pins!

In both cases, after such abuses, the drive was defined in Windows as a regular DVD-drive, where it was picked up and ~~raped~~ and stitched.

After the first release, custom firmwares were finalized, stability was improved, support for new games was added, in general, everything was as usual.

Microsoft answer

The developers to the allegations that the "unbreakable" console was hacked, answered simply:

The system was not hacked, we just learned how to launch copies of games, we are working on it

original answer

The core security system has not been broken. However, it is reported that the authentication protocol between the optical disc drive and the console may be attacked, which if accurate could allow people to play illegally copied games. Our security team is aware of this and we are investigating potential solutions to this issue. The Xbox 360 platform was designed to be updated, and we are prepared to respond appropriately should any unauthorized activity be identified.

What really was done to correct the situation:

Samsung TS-H943 began to come with ms28 firmware, which did not enter the firmware mode by the well-known ATA command
Hitachi GDR3120L appeared with firmware 0078 and 0079, not flashing even in Mode B
New BenQ-LiteOn VAD6038 Drives Appear
The first pointy "bans" of pirates on Xbox Live began, pirates were forbidden to play online forever

If everything was unambiguous and irreparable with the ban (at that point in time), then researchers soon figured out the drives:

For Hitachi found unlocking the firmware mode through a special audio disc
Samsung ms28 and BenQ VAD6038 went perfectly into the firmware mode via inexpensive SATA VIA 6421 controllers

Let’s leave the battlefield for drive firmware for a while, there wasn’t a very interesting period when researchers tried to make “Stealth” firmware, so as not to be banned from Xbox Live, adjust to new games with new “waves” - system update versions and port the results to everything an expanding variety of firmware and drives. All the same, everything was stitched, the “backups” were successfully launched, the Xbox 360 was gaining popularity among the people ...

Breaking the axis!

As you recall from the first part of the story, the Xbox 360 system had a hypervisor that controlled everything and everything. So here. In one version of the system, a vulnerability suddenly appeared in it! How exactly the researchers received the hypervisor code samples is not known to me for certain. But the fact is - at the end of 2006, researchers launched unsigned code on the Xbox 360, and in early 2007 the vulnerability was fixed by the developers:

Timeline:
Oct 31, 2006 — release of 4532 kernel, which is the first version containing the bug
Nov 16, 2006 — proof of concept completed; unsigned code running in hypervisor context
Nov 30, 2006 — release of 4548 kernel, bug still not fixed
Dec 15, 2006 — first attempt to contact vendor to report bug
Dec 30, 2006 — public demonstration
Jan 03, 2007 — vendor contact established, full details disclosed
Jan 09, 2007 — vendor releases patch
Feb 28, 2007 — full public release

The hypervisor had one feature - unlike the rest of the code, it was executed not in the virtual address space, but in the physical (Real Mode). The broadcast was not used, calls were made directly (addresses of the form 0x00000000'xxxxxx). Either this was done for speed, or for simplicity ... And here was one feature of the Xbox 360 address space.

The access mode to the memory was determined by its physical address. Namely, the most significant bits of the address had an official purpose. For example, the address 0x00000 0 00'0000201C meant direct access to the address 0x201C, and 0x00000 1 00'0000201C meant that you need to decrypt and verify the integrity on the fly when reading the same physical address 0x201C.

Accordingly, for execution to be carried out with encryption and protection enabled, you need to refer to addresses like 0x00000 1 00'xxxxxxxx. Only then the hardware module included protective mechanisms. Therefore, at the hardware level, the desired bit was added automatically (the special HRMOR register was responsible for this - Hypervisor Real Mode Offset Register)!

Once again - as soon as the hypervisor accesses an address like 0x00000 0 00'xxxxxxxx, the MMU automatically changes this address to 0x00000 1 00'xxxxxxxx, including encryption and protection! So any attempts to execute the code “directly” from physical memory, without protection and encryption, are doomed to failure ... or not?

Let's look at the vulnerable code of the hypervisor version 4532:

// %r0 – 13D8: cmplwi %r0, 0x61 // ID 13DC: bge illegal_syscall // 0x61, , ... 13F0: rldicr %r1, %r0, 2, 61 // 4 13F4: lwz %r4, syscall_table(%r1) // 13F8: mtlr %r4 // lr ... 1414: blrl //

See the gopher? But he is! Cmplwi instruction works with 32-bit values, but rldicr - with 64-bit ! That is, we can give the value 0x20000000'0000002A as a system call number, it will pass the test (because the lower 32-bit part is less than 0x61), and as a result, instead of the address 0x10EC, the address of the handler will be taken from 0x80000000'000010EC!

And then, as they say, watch your hands. The most significant bits of the address are not equal to zero, respectively, HRMOR is not added ! And since the real address space is 32-bit, the 63-bit set by us is simply ignored. We redirected the hypervisor to unencrypted and insecure memory, simply by submitting an incorrect system call number!

But wait, so that there is where to jump, we need to be able to write our data to the physical memory. How to achieve this?

This is where the second factor comes into play - the GPU on the Xbox 360 was smart, even too smart. He supported a special shader instruction, MemExport, for uploading geometry data to physical memory. That is, you could compile the shader, execute it on the GPU and thereby record anything anywhere! And most importantly, the shaders were not signed, if you modify the game disc in any way, you can easily replace the shader code.

One question remained. How to replace the shader code on the game disc? And here hacking the DVD drive of the console was very useful. We wrote a shader, replaced it in the image of the game, recorded it on a disc and launched Linux!

Yes, to run it, I had to start the game every time, wait for the exploit to work, put the boot disk with Linux, but that was at least something!

As already mentioned, Microsoft released a system update in which they fixed the vulnerability of the hypervisor. But what if you return a vulnerable kernel?

Downgrade!

In general, the architecture of the Xbox 360 was laid down protection mechanisms from downgrade. In the hardware fuses of the processor, every time a bit was burned during the update (Lock Down Value, LDV increased), and if this LDV did not match in the fuses and in the system, the console simply did not start.

Consider the Xbox 360 bootloader structure, namely, “Bootloader Sections”:

It can be seen that there are several sets of bootloaders in the image, each of which corresponds to some LDV. In the example, these are 1888 for LDV 0, 16767 for LDV 3 and 16756 for LDV 2

So, all updates of the system itself were recorded in sections 6BL / 7BL and simply “applied” as patches to the base “core” 5BL 1888 . But what set of patches to apply was selected according to the prescribed LDV in the fuses and bootloader headers! And just at 5BL the header could be modified, with one big BUT - the header was checked against the HMAC-SHA-1 hash sum recorded in it. And it was checked by ordinary memcmp .

If you still do not understand where things are going, here you managed to apply a time attack (Timing Attack). The standard memcmp function completes the comparison immediately after the first discrepancy. Therefore, by changing the first byte of the hash and detecting the runtime of memcmp, you can select the desired value (the verification time will increase with it). Continuing further, you can pick up all the bytes of the hash sum!

For measurement, the POST_OUT debug bus was used. It works like a PC, at different times of loading a single-byte value is displayed, by which you can judge where the processor is currently running and what error occurred. In fact, these are 8 points on the motherboard, each of which is responsible for a specific bit of value:

Having soldered to these points, you can just measure the execution time of each of the download stages and see if an error has occurred.

The whole process of hash selection takes about an hour:

As a result, we get an image in which the current LDV is installed for the core kernel, because of which no patches are applied and the oldest version of the 1888 system is launched! From where it is already possible to upgrade to the vulnerable version 4532:

Of course, Microsoft fixed this vulnerability by updating the very first updated bootloader (2BL, “CB”) and burning the CBLDV fuse, which made downgrade impossible again. Now instead of memcmp, its safe version was used, with the same runtime regardless of the input values.

JTAG Hack!

But here, the researchers did not give up and found a loophole. Yes, such that the developers could not even imagine.

In the normal mode of operation of the console, all bootloaders are connected to each other in a chain. As a result, the decryption of each bootloader depends on the data area in the header of the previous bootloader (Pairing Data). Additionally, the encryption of the code depends on the unique processor key, so you cannot take and assemble a working image without knowing CPU_Key. Or is it possible?

At the console production stage (when the processor key has not yet been burned in fuses), a special Xbox 360 launch mode is used when Pairing Data is zero (Zero-Pairing). And such an image (with a vulnerable kernel!) Can be run on any console without even knowing the processor key!
Unfortunately, there will be no full-fledged launch, this error will turn out like this:

That is, the King Kong game cannot be started, the exploit through shaders cannot be activated ... But the vulnerable kernel is already starting! Maybe there is another way to record the RAM? It turned out that there is.

For starters, we solder three free GPIOs of the south console of the console to the GPU JTAG pins:

Then we modify the firmware of the south bridge (it is encrypted, but not signed) and collect the image with the vulnerable kernel. Then the magic happens:

At startup, the south bridge on the JTAG GPU climbs onto PCI Express and configures the NAND controller
Now, when reading, the NAND controller will write data to the memory area we need
The core of the system starts and informs the south bridge that the system has started
The south bridge pulls the NAND controller, overwriting the RAM in the right place and exploits the vulnerability of the hypervisor!
Control is transferred to our code, do what we want

In short, they did everything the same as in King Kong Shader Exploit, but cooler - there is no need to start the game and change discs.

On the basis of JTAG Hack, modified versions of the system were created - XBReboot, Freeboot, with disabled signature verification, where pirates were already walking around. Games could be launched not only from USB drives and disks, but also via SMB protocol directly from a computer.

Importantly, a full-fledged system hack gave a chance to those who lost the DVD key and could not play - having the processor key, it was not difficult to extract the DVD key.

Of course, here Microsoft quickly closed the vulnerability, again updating 2BL and increasing the value of CBLDV. On this, the epic of the vulnerable hypervisor ended, people ran to buy the remnants of the "JTAG compatible" consoles in stores - everyone wanted to play with USB flash drives without any problems. Discussions were held on forums about which bundles with which release date are suitable for hacking ...

The topic of modifications to the Xbox 360 system stalled for almost two years, but the theme of firmware continued to develop. And just in the firmware of the LiteOn drives, the most extensive battle between researchers and Microsoft broke out. But more on that in the next article :)

Links:

GoogleTechTalks report
King Kong Hack
Timing Attack
JTAG / SMC Hack

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

PS Anyone interested in details, I will answer any questions on the topic in the comments!