Full Report
The original XBox had many security problems that resulted in two mods bypassing all of the security checks to run unsigned code. First, the hardware mod required soldering on a modchip to the main board with a modified BIOS that disabled all security checks. Secondly, many video games had save files issues that allowed for code execution within the context of the game. There are several known exploits, such as 007, Tony Hawk 4 and a few others. For the software security, there are a fwe things to note. Most of the XBox code runs within the context of the kernel in order to run faster. Additionally, there is no Nx bit, making arbitrary code execution easy once a vulnerability has been found. The goal of this article was to write a save file exploit for the game Frogger in order to execute arbitrary code (ACE). On top of this, taking the ACE to development and run our own game. The first step was turning the hardware of the XBox into a debug kit. Using the SuperIO board, it is possible to get serial port connectivity and use a kernel debugger. Once this is setup, they disassemble the code of Frogger to look for issues. They extend the file format of the player name to not contain a null terminating string. Sure enough, editing the save file with this triggers a segmentation fault. The segmentation fault was writing the player name to a stack buffer without doing a sanity check on the name. As a result, part of the player name was overwriting a pointer and attempting to write to this location. However, this has even worse consequences: if this address is valid, we ACTUALLY control the RIP address on the stack, allowing for the hijacking of the control flow of the program. With the ability to execute arbitrary code, we want to build our own games. To recover the program to do this, a few things are done via shellcode. First, the author wants to disable the memory write protection by clearing the WP bit within the CR0 register. Once this is done, all memory (even read only pages) are now writable, making many more things possible. After this, the RSA public key is patched to allow for the usage of unsigned games. This can be done by searching for the key in memory, then changing it or referencing a kernel structure and editing that. Once we have taken care of business, we can launch an executable by calling kernel methods directly. Since this is more portable and will work for a multitude of games, this is the route they choose to go. Or, calling the XAPI methods directly can be used, by this comes with some restrictions. A few other things could be done to make the environment more friendly, such as invalidating the TLB and flushing CPU cache. The first attempt at the shellcode failed because of an extra question mark in the sprintf call. Nullbytes were becoming a problem here. Instead of writing the loader AFTER the copy, they wrote a smaller version BEFORE. By jumping to the smaller version (shellcode without nullbytes of course), they could reconstruct an arbitrary address to jump to that shellcode instead. This time, the small shellcode worked! Limitations on virtual address and nullbytes led them to try something else. The author went hunting for a second bug a few days later. They found a relative array write and another bad strcpy issue. By using an existing overflow from the previous bug (overwriting this pointer of the class), we can control the where we want to write. Of course, the string we want to write is controlled by us, giving us a WRITE-WHERE primitive. Using this primitive, they wrote the bootstrapped bootloader to an arbitrary address in physical memory (0x01010101). Since this write sits in physical memory and we have the previous vulnerability to jump to any location, the chaining of these two issues gives us a great primitive for getting things going. Overall, great post with many interesting insights.
Analysis Summary