October 27, 2008 at 09:42How to run unsigned code on the Xbox 360
They try to break every game console. Enthusiasts who want to run code written in it in all the most protected modes try to break it. Enthusiasts who want to “run backups of games on it” (or, if in Russian, engage in piracy) try to break down. Enthusiasts who want to install Linux and, in addition to the goal in themselves, try to break down more widely than the console manufacturer would like to do (since money is earned primarily from games, the console itself is sold with a minimal margin, or even minus the manufacturer).
In the vast majority of cases, enthusiasts succeed.
Here's how the most interesting part of the Xbox 360 hack was made - launching code not signed by MS.
Two years ago, the Xbox360 was smashed for piracy, that is, they learned how to launch copies of licensed games recorded on discs. I wrote a little about the details here . In short, the licensing of the disc was entirely determined by the firmware of the DVD-ROM and the xbox itself transmitted only one digit - a good disc or not. If the firmware is changed so that it always returns the number corresponding to the licensed disk - voila. In those versions, the firmware chip could simply be pulled out and changed.
Since then, much and little has changed at the same time - there was an excellent engineering solution for MS to fill in a chip with black epoxy firmware (you still need to find out whose solution it was, very Russian), but it turned out that you can change the firmware by hooking up a DVD-ROM from xbox to PC. In each update, the firmware corresponded, but it was enough to reload it again. And it continues to work with Live.
On the other hand, they began to ban for pirated firmware, in partisan ways. That is, in the new updates there is some code that, by indirect signs, determines the firmware and sends this information to the server. At one point, accumulated consoles are banned from Xbox Live (namely consoles, not accounts). In this software way, MS managed to turn the game into cat and mouse - you can install the latest firmware, but this does not guarantee that MS will not find indirect signs of its detection and that it will not ban the console in the end. Both hacking tools are being improved, that is, they provide fewer indirect effects, and software detection tools.
Nevertheless, the vulnerability is very serious, as they could have left one - I do not understand. My only version is that they were in a hurry to bring the console to the market.
However, from release to launch of a pirated game - 4 months.
That was all already two years ago, but this hack did not allow you to run your code on the box, only an exact copy of the game code. But we understand that a certain part of humanity does not agree to consider any piece of iron as a worthwhile existence until Linux is launched on it, and is ready to work on it. And for this, you must inevitably be able to run your code.
Firstly, the binary on the hellish disk is encrypted, the public key is flashed somewhere in the silicone of the console, and the private key is stored deep in the bowels of the home office. All binaries of all games are encrypted with a super secret key in a super-sector laboratory before release. Getting the key is unrealistic.
The code that decrypts and verifies the binary sits deep in the ROM console and is encrypted / verified and double-checked by hardware. Each update knows how to register a new code there, because it was originally prepared in the same top-secret laboratory. Replacing this code is unrealistic.
The game itself always runs in unprivileged mode, with read-only access on the memory pages with the code and the absence of execute-flag on data and stack, that is, it is impossible to write the code in the data and transfer control there (classic case of buffer overflow), or replace it already uploaded code by its own (because read-only). Moreover, all executable code also constantly hangs in memory, encrypted with a key that is randomly generated every start-up (hardware feature of the processor) in order to protect itself from being torn out by physical methods (roughly speaking, with a soldering iron).
Everything related to encryption and decryption is performed in hypervisor mode, in which there is never a game code, but only a firmware code. As I understand it, he is just engaged in decrypting the binary and other security stuff. He has no such restrictions, but of course the code of the game in this mode never breaks through and does not record anything there.
It would seem that everyone backed up. The game code cannot be faked, even if something is coolly corrupted in the data, neither buffer overrun nor code modification will help. Even from a physical attack, they were saved.
The main document describing the vulnerability is here .
In short, in one of the firmware versions there was an incorrect check in the most important syscall command - calling a system function from the game code. This command is given the number of the function and its arguments, and it takes its address from the protected plate and transfers control to it in all powers. The problem was that when checking the function number for validity, a 32-bit command was used, and in the offset calculation - 64-bit. And then you can transfer the number of the function, which has some nonzero upper bits, the number will go into the offset calculation, and thus will indicate a memory that is treated as data and is not encrypted by hardware protection. The function address will be taken from this memory and called in hypervisor mode, even if this address is in the data. If there is a pointer to your own code in the right place in memory - voila.
This is not a vulnerability, we need to figure out how to put this data there. This is not so trivial - you cannot modify the code, but change the game data on disk so that it writes the necessary bytes to the correct addresses with its code and calls syscall - a very long and complicated analysis of luck.
Do you know how they did it? It delights me the most in this whole story.
Made shaders.
All shaders are, of course, resources on the disk and, like all resources, are not encrypted, but at the same time remain shaders, that is, the microcode of the video card. But on the xbox360 is a smart GPU, it can read and write to memory from a shader. Moreover, the CPU and GPU have a common memory, which means you can register the CPU memory from the shader at the desired address. Knowing where the code often happens, you can also tweak the stack so that it ret does it already on syscall with the correct arguments taken from the same stack.
It turned out to be done in practice with King Kong Demo ( http://www.xbox-scene.com/xbox1data/sep/EEZklEuAkAzUotmeVt.php )
I note that this requires knowing very deep details about the game code, i.e. It’s hardly possible to know which place on the stack to stack without access to the game code and devkit.
At first, it all worked only on strictly defined firmware versions, where there was a bug with syscall (the current ones aren’t already), but six months later they dug up the possibility of downgrading the console to the original firmware version, from where you can upgrade to a version with a vulnerability.
As a result, the exploit works by replacing the shader in King Kong, which writes executable code to memory, and corrects the stack in a strictly defined place to execute a call to a system function that, due to a bug in the firmware, will transfer control to the very code with system permissions. Get fucked up. Survived a hack from a shader. Reached for the GPU.
And so it turned out to make the first hello world your own code, and after that Ubuntu was not far from working , and to assemble the community a matter of technology ( http://www.free60.org ).
Actually, that's all. For good measure - let it last a year and a half before launching a third-party code. And after all, damn it, they designed everything correctly and sanely, and everywhere they propped up. One most important command for the whole system - and it has a critical bug.
What the hell is this, huh? ..
In the vast majority of cases, enthusiasts succeed.
Here's how the most interesting part of the Xbox 360 hack was made - launching code not signed by MS.
Hacking for piracy
Two years ago, the Xbox360 was smashed for piracy, that is, they learned how to launch copies of licensed games recorded on discs. I wrote a little about the details here . In short, the licensing of the disc was entirely determined by the firmware of the DVD-ROM and the xbox itself transmitted only one digit - a good disc or not. If the firmware is changed so that it always returns the number corresponding to the licensed disk - voila. In those versions, the firmware chip could simply be pulled out and changed.
Since then, much and little has changed at the same time - there was an excellent engineering solution for MS to fill in a chip with black epoxy firmware (you still need to find out whose solution it was, very Russian), but it turned out that you can change the firmware by hooking up a DVD-ROM from xbox to PC. In each update, the firmware corresponded, but it was enough to reload it again. And it continues to work with Live.
On the other hand, they began to ban for pirated firmware, in partisan ways. That is, in the new updates there is some code that, by indirect signs, determines the firmware and sends this information to the server. At one point, accumulated consoles are banned from Xbox Live (namely consoles, not accounts). In this software way, MS managed to turn the game into cat and mouse - you can install the latest firmware, but this does not guarantee that MS will not find indirect signs of its detection and that it will not ban the console in the end. Both hacking tools are being improved, that is, they provide fewer indirect effects, and software detection tools.
Nevertheless, the vulnerability is very serious, as they could have left one - I do not understand. My only version is that they were in a hurry to bring the console to the market.
However, from release to launch of a pirated game - 4 months.
That was all already two years ago, but this hack did not allow you to run your code on the box, only an exact copy of the game code. But we understand that a certain part of humanity does not agree to consider any piece of iron as a worthwhile existence until Linux is launched on it, and is ready to work on it. And for this, you must inevitably be able to run your code.
Let's take a quick look at how the xbox360 has a security model in place to describe roughly why this is difficult.
Firstly, the binary on the hellish disk is encrypted, the public key is flashed somewhere in the silicone of the console, and the private key is stored deep in the bowels of the home office. All binaries of all games are encrypted with a super secret key in a super-sector laboratory before release. Getting the key is unrealistic.
The code that decrypts and verifies the binary sits deep in the ROM console and is encrypted / verified and double-checked by hardware. Each update knows how to register a new code there, because it was originally prepared in the same top-secret laboratory. Replacing this code is unrealistic.
The game itself always runs in unprivileged mode, with read-only access on the memory pages with the code and the absence of execute-flag on data and stack, that is, it is impossible to write the code in the data and transfer control there (classic case of buffer overflow), or replace it already uploaded code by its own (because read-only). Moreover, all executable code also constantly hangs in memory, encrypted with a key that is randomly generated every start-up (hardware feature of the processor) in order to protect itself from being torn out by physical methods (roughly speaking, with a soldering iron).
Everything related to encryption and decryption is performed in hypervisor mode, in which there is never a game code, but only a firmware code. As I understand it, he is just engaged in decrypting the binary and other security stuff. He has no such restrictions, but of course the code of the game in this mode never breaks through and does not record anything there.
It would seem that everyone backed up. The game code cannot be faked, even if something is coolly corrupted in the data, neither buffer overrun nor code modification will help. Even from a physical attack, they were saved.
How, in this situation, could everything be profitable?
The main document describing the vulnerability is here .
In short, in one of the firmware versions there was an incorrect check in the most important syscall command - calling a system function from the game code. This command is given the number of the function and its arguments, and it takes its address from the protected plate and transfers control to it in all powers. The problem was that when checking the function number for validity, a 32-bit command was used, and in the offset calculation - 64-bit. And then you can transfer the number of the function, which has some nonzero upper bits, the number will go into the offset calculation, and thus will indicate a memory that is treated as data and is not encrypted by hardware protection. The function address will be taken from this memory and called in hypervisor mode, even if this address is in the data. If there is a pointer to your own code in the right place in memory - voila.
This is not a vulnerability, we need to figure out how to put this data there. This is not so trivial - you cannot modify the code, but change the game data on disk so that it writes the necessary bytes to the correct addresses with its code and calls syscall - a very long and complicated analysis of luck.
Do you know how they did it? It delights me the most in this whole story.
Made shaders.
All shaders are, of course, resources on the disk and, like all resources, are not encrypted, but at the same time remain shaders, that is, the microcode of the video card. But on the xbox360 is a smart GPU, it can read and write to memory from a shader. Moreover, the CPU and GPU have a common memory, which means you can register the CPU memory from the shader at the desired address. Knowing where the code often happens, you can also tweak the stack so that it ret does it already on syscall with the correct arguments taken from the same stack.
It turned out to be done in practice with King Kong Demo ( http://www.xbox-scene.com/xbox1data/sep/EEZklEuAkAzUotmeVt.php )
I note that this requires knowing very deep details about the game code, i.e. It’s hardly possible to know which place on the stack to stack without access to the game code and devkit.
At first, it all worked only on strictly defined firmware versions, where there was a bug with syscall (the current ones aren’t already), but six months later they dug up the possibility of downgrading the console to the original firmware version, from where you can upgrade to a version with a vulnerability.
As a result, the exploit works by replacing the shader in King Kong, which writes executable code to memory, and corrects the stack in a strictly defined place to execute a call to a system function that, due to a bug in the firmware, will transfer control to the very code with system permissions. Get fucked up. Survived a hack from a shader. Reached for the GPU.
Total
And so it turned out to make the first hello world your own code, and after that Ubuntu was not far from working , and to assemble the community a matter of technology ( http://www.free60.org ).
Actually, that's all. For good measure - let it last a year and a half before launching a third-party code. And after all, damn it, they designed everything correctly and sanely, and everywhere they propped up. One most important command for the whole system - and it has a critical bug.
What the hell is this, huh? ..