How to run unsigned code on Xbox 360
Every game console trying to break. Enthusiasts who want to run self-written code on it in all the most secure modes try to break. Enthusiasts who want to “run backups of games on it” (or, in Russian, engage in piracy) are trying to break. Enthusiasts who want to install Linux and, besides an end in themselves, try to use more widely than the console manufacturer would like (since money is earned primarily from games, the console itself is sold with a minimum markup, or even minus to the manufacturer).
Overwhelmingly, enthusiasts succeed.
This is how the most interesting part of the Xbox 360 hacking was done - running code that was not signed by MS.
Two years ago, Xbox360 broke for piracy, that is, they learned how to run copies of licensed games recorded on discs. I wrote about the details here . In short, the licensing of the disk was entirely determined by the DVD-ROM firmware and the xbox itself transmitted only one digit — a good disk or not. If the firmware is altered so that it always returns the figure corresponding to the license disk - voila. In those versions, the firmware chip could simply be pulled out and altered.
')
Since then, much has changed at the same time and not much - MS had a great engineering solution to fill in a chip with black epoxy firmware (we still need to know whose solution was very Russian), but it turned out that you can change the firmware by hooking up the DVD-ROM from the xbox to PC. In each update, the firmware was rewritten, but it was enough to re-upload. 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 indirectly determines the firmware and sends this information to the server. At one point, accumulated consoles are banned from Xbox Live (namely, consoles, not accounts). With this software, MS managed to turn the game into cat and mouse - you can install the latest version of the firmware, but this does not guarantee that MS will not find indirect signs of its detection and in the end will not ban the console. Both hacking tools are being improved, that is, they give less indirect effects, and software detection tools.
Nevertheless, the vulnerability is very serious, as such could leave - I do not understand. My only version - was in a hurry to bring the console to the market.
Nevertheless, from the release to the launch of the pirated game - 4 months.
All this was already two years ago, but this hack did not give an opportunity to run its 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 hardware worth living until Linux is running on it, and is ready to work on it. And for this you must inevitably be able to run your code.
First, the binary on the hellish disk is encrypted, the public key is stitched somewhere in the silicone of the console, and the private key is stored deep in the depths of the home office. All the binaries of all games are encrypted with a super secret key in the super-sector lab before release. Get the key is unrealistic.
The code that decrypts and checks the binary sits deep in the ROM console and is encrypted / checked and double-checked with iron. Each update is able to register a new code there, because it was originally prepared in the same super-secret laboratory. To replace this code is unreal.
The game itself always starts in unprivileged mode, with read-only access on memory pages with code and the lack of an execute-flag on data and stack, that is, it is impossible to either write code in the data and transfer control there (the classic buffer overflow case) or replace the downloaded code is yours (because read-only). Moreover, the entire executable code is also constantly hanging in the memory of an encrypted key, which is randomly generated by each launch (hardware feature of the processor) in order to protect against memory scratching by physical methods (roughly speaking, with a soldering iron).
Everything related to encryption and decryption is performed in the hypervisor mode, in which there is never a game code, but only the firmware code. As I understand it, he is just engaged in decoding the binary and other security stuff. It has no such restrictions, but of course the code of the game in this mode will never break through and nothing will be written there.
It would seem that all backed up. The code of the game cannot be faked, even if something is cool to screw up the data, neither buffer overrun nor code modification will help. Even from a physical attack - and 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 - the system function call from the game code. This command is given the number of the function and its arguments, and it pulls out its address from a protected sign, and transfers control to it in all authorities. The problem was that when checking the function number for validity, the 32-bit command was used, and in the offset calculation, the 64-bit command was used. And then you can pass the number of the function, which has some non-zero upper bits, the number will go to the offset calculation, and thus will point to memory, which is interpreted as data and is not encrypted with hardware protection. The address of the function will be taken from this memory, and called up in hypervisor mode, even if this address is in the data. If in the right place of memory there will be a pointer to your own code - voila.
This is not a vulnerability, it is necessary to figure out how to put this data there. This is not so trivial - the code cannot be modified, but the game data can be changed on the disk so that it writes the necessary bytes with the necessary addresses and calls syscall - a very long and complicated analysis at random.
Do you know how they did it? This most fascinates me in this whole story.
Made shaders.
All shaders - of course, the resources on the disk and, like all resources, are not encrypted, but they remain shaders, that is, the microcode of the video card. And on the xbox360 is a smart GPU, it can read and write to the memory from the shader. Moreover, the memory of the CPU and the GPU is shared, which means that the CPU memory can also be assigned from the shader to the correct address. Knowing where the code is often happens, you can also stack the stack so that it ret ret already on syscall with the correct arguments taken from the same stack.
This happened 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 code of the game, i.e. to know what place to stack the stack is hardly possible without access to the game code and the devkit.
At first, this all worked only on strictly defined versions of the firmware, where there was a bug with syscall (no longer current), but six months later, the possibility of console downgrade to the original firmware version was discovered , 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 the executable code into memory, and the stack in a strictly defined place to call the system function, which, because of a bug in the firmware, will transfer control to that code with the system's permissions. Fuck up Lived, the hacker from the shader. We've been behind the GPU.
And so it turned out to make the first hello world with its code, and after that, even before working Ubuntu was close , and to collect the community technology business ( http://www.free60.org ).
Actually, everything. For even counting - let him hold out for a year and a half before launching a third-party code. And after all, damn it, everything was correctly and sanctioned, and they were propped up everywhere. One most important command for the entire system - and in it a critical bug.
What the fuck is that, huh? ..
Overwhelmingly, enthusiasts succeed.
This is how the most interesting part of the Xbox 360 hacking was done - running code that was not signed by MS.
Hacking for piracy
Two years ago, Xbox360 broke for piracy, that is, they learned how to run copies of licensed games recorded on discs. I wrote about the details here . In short, the licensing of the disk was entirely determined by the DVD-ROM firmware and the xbox itself transmitted only one digit — a good disk or not. If the firmware is altered so that it always returns the figure corresponding to the license disk - voila. In those versions, the firmware chip could simply be pulled out and altered.
')
Since then, much has changed at the same time and not much - MS had a great engineering solution to fill in a chip with black epoxy firmware (we still need to know whose solution was very Russian), but it turned out that you can change the firmware by hooking up the DVD-ROM from the xbox to PC. In each update, the firmware was rewritten, but it was enough to re-upload. 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 indirectly determines the firmware and sends this information to the server. At one point, accumulated consoles are banned from Xbox Live (namely, consoles, not accounts). With this software, MS managed to turn the game into cat and mouse - you can install the latest version of the firmware, but this does not guarantee that MS will not find indirect signs of its detection and in the end will not ban the console. Both hacking tools are being improved, that is, they give less indirect effects, and software detection tools.
Nevertheless, the vulnerability is very serious, as such could leave - I do not understand. My only version - was in a hurry to bring the console to the market.
Nevertheless, from the release to the launch of the pirated game - 4 months.
All this was already two years ago, but this hack did not give an opportunity to run its 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 hardware worth living until Linux is running 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 security model is arranged on the xbox360 to describe roughly why this is difficult.
First, the binary on the hellish disk is encrypted, the public key is stitched somewhere in the silicone of the console, and the private key is stored deep in the depths of the home office. All the binaries of all games are encrypted with a super secret key in the super-sector lab before release. Get the key is unrealistic.
The code that decrypts and checks the binary sits deep in the ROM console and is encrypted / checked and double-checked with iron. Each update is able to register a new code there, because it was originally prepared in the same super-secret laboratory. To replace this code is unreal.
The game itself always starts in unprivileged mode, with read-only access on memory pages with code and the lack of an execute-flag on data and stack, that is, it is impossible to either write code in the data and transfer control there (the classic buffer overflow case) or replace the downloaded code is yours (because read-only). Moreover, the entire executable code is also constantly hanging in the memory of an encrypted key, which is randomly generated by each launch (hardware feature of the processor) in order to protect against memory scratching by physical methods (roughly speaking, with a soldering iron).
Everything related to encryption and decryption is performed in the hypervisor mode, in which there is never a game code, but only the firmware code. As I understand it, he is just engaged in decoding the binary and other security stuff. It has no such restrictions, but of course the code of the game in this mode will never break through and nothing will be written there.
It would seem that all backed up. The code of the game cannot be faked, even if something is cool to screw up the data, neither buffer overrun nor code modification will help. Even from a physical attack - and they were saved.
How in this situation could all profkapit?
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 - the system function call from the game code. This command is given the number of the function and its arguments, and it pulls out its address from a protected sign, and transfers control to it in all authorities. The problem was that when checking the function number for validity, the 32-bit command was used, and in the offset calculation, the 64-bit command was used. And then you can pass the number of the function, which has some non-zero upper bits, the number will go to the offset calculation, and thus will point to memory, which is interpreted as data and is not encrypted with hardware protection. The address of the function will be taken from this memory, and called up in hypervisor mode, even if this address is in the data. If in the right place of memory there will be a pointer to your own code - voila.
This is not a vulnerability, it is necessary to figure out how to put this data there. This is not so trivial - the code cannot be modified, but the game data can be changed on the disk so that it writes the necessary bytes with the necessary addresses and calls syscall - a very long and complicated analysis at random.
Do you know how they did it? This most fascinates me in this whole story.
Made shaders.
All shaders - of course, the resources on the disk and, like all resources, are not encrypted, but they remain shaders, that is, the microcode of the video card. And on the xbox360 is a smart GPU, it can read and write to the memory from the shader. Moreover, the memory of the CPU and the GPU is shared, which means that the CPU memory can also be assigned from the shader to the correct address. Knowing where the code is often happens, you can also stack the stack so that it ret ret already on syscall with the correct arguments taken from the same stack.
This happened 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 code of the game, i.e. to know what place to stack the stack is hardly possible without access to the game code and the devkit.
At first, this all worked only on strictly defined versions of the firmware, where there was a bug with syscall (no longer current), but six months later, the possibility of console downgrade to the original firmware version was discovered , 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 the executable code into memory, and the stack in a strictly defined place to call the system function, which, because of a bug in the firmware, will transfer control to that code with the system's permissions. Fuck up Lived, the hacker from the shader. We've been behind the GPU.
Total
And so it turned out to make the first hello world with its code, and after that, even before working Ubuntu was close , and to collect the community technology business ( http://www.free60.org ).
Actually, everything. For even counting - let him hold out for a year and a half before launching a third-party code. And after all, damn it, everything was correctly and sanctioned, and they were propped up everywhere. One most important command for the entire system - and in it a critical bug.
What the fuck is that, huh? ..
Source: https://habr.com/ru/post/43285/
All Articles