The Amibox Project
Exploiting buffer overrun…
I promised a page on how the XBox exploits work, and here it is. This page does not tell you how to use or obtain these exploits, and is not required knowledge if you’re planning to make your own modified XBOX. It’s really here just because it’s something that I know about and can therefore share. If you don’t need this level of detail, you are welcome to skip this page.
Also, I’m assuming my reader for this page is the lay-person, and so the actual technical specifics may vary from what I write here, but the principal should remain.
In order to install the “soft mod” Dashboard on an XBox you still have to convince the XBox to run an installer program, which again, is unsigned code, which the stock Dashboard will not run!
Thankfully, us software developers often write these little things called “bugs” and if someone were to figure out how to use a bug to do something advantageous, they might call that an “exploit.”
There are a handful of XBOX games (which I’ll list in a later page), which have a bug known as a “Buffer Overrun” in them. Buffer Overrun is common in applications written using the C++ programming language, which happens to also be the most common programming language in use today. It has been for about 15 years or perhaps more.
(Side note: My employer makes and sells C++ and Delphi programming tools, and this kind of bug would be far less frequent in software written using Delphi! <- Delphi is my favorite of the two, so I couldn’t resist!)
Buffer Overrun is a bug that is caused by the programmer neglecting to do certain checks when “de-serializing” data, that-is, reading some data from the disk for example. The developer does not consider every condition under which the reading process should stop.
Lets say you’re writing some code to save a “saved game” to the XBox memory device. Every game being different, the save game data will be different too. One game may store inventory items that the player has collected along the way, while another game may not even have an inventory. This means that the data is written in a custom format on disk to reflect the specific needs of the game title. You as the software developer have to decide what that format looks like.
Still writing the save game code, but now thinking ahead, you know that when you come to write the code which loads the data back up (so that the player can restore to that saved state), it’ll be most efficient, and usually easier code to write, if you could just load the data in one big block.
Still thinking ahead, if you load the data as one big block, how do you know how large it is (in bytes)? Since saved game data could vary in size depending on say, how many inventory items the player has, how will you know how many bytes to read? Well, you could come up with some sequence of numbers that should not appear in the save game data normally, and append those numbers to the end of the data. That way, when you write the code which loads the save game, you just keep reading data until you encounter that number sequence.
Now lets say you’re writing the code to load a saved game back from disk. You know that there is a special sequence of numbers (for arguments sake, three zeros) which terminates the data. So you just keep reading until you find the three zeros right? Wrong. You must always set a limit to the number of bytes that get read, regardless of encountering the special terminating sequence. Why? I’ll come to that, but sometimes software engineers make the simple mistake of not setting a limit, and this creates the “Buffer Overrun” bug.
Most processors provide software engineers with access to a specialized memory system called a stack. This is a small piece of memory which is used primarily to control the flow of execution when the code is run. If the code needs to go off and perform some task, it can store the current state of the system on the stack, jump to the code for performing the task, then restore the state of the system from the stack and continue from where it left off. Lots of other types of data may be stored in the stack too, including data buffers used when writing data to, or reading data from the disk. Now, I said that the stack is a “small” piece of memory, and if it’s storing the read buffer for our aforementioned game loading code, which does not have a size limit check, the buffer could grow to be larger than the stack can support.
So what happens if you “overrun” the end of a data buffer which is stored on the stack? Well, you’ll remember that I said that the stack is primarily concerned with the flow of execution of a program – if you overload the stack you just might affect the flow of execution in unexpected ways, causing the processor to run code which you never originally intended.
Several XBox titles have a Buffer Overrun style bug in them. What the reverse-engineers (here-in ‘hackers’) were able to do, was modify a saved game file in such a way as to overload the stack, and therefore change the execution flow of the game. The execution flow is altered to find it’s way to some code written by the hackers.
So the whole soft-modding process now works a little like this. The XBOX boots from it’s BIOS to the Dashboard, which attempts to load a game from DVD. The Dashboard verifies that the game is digitally signed, and then starts running it. Then, you attempt to load a ‘customized’ save game from the memory disk which exploits the buffer overrun to begin running so code that we’ll call the ‘patch’. The patch does nothing more than to copy a replacement Dashboard (which is also stored on the memory disk), to the hard disk of the XBOX, overwriting the original Microsoft Dashboard. The patch is able to run, because the digital signature for that game has already been verified, and so anything it does (even if what it does is run the patch) is considered legitimate operations so far as the Dashboard is concerned.
Now, what I really wish had been done with this exploit, is that it copied a tool to the XBox for flashing the TSOP (replacing the BIOS), WITHOUT copying a Dashboard with the ability to run unsigned games.
This would have been legal and very useful for the modding community, but unfortunately, there’s little glory in it when compared to software piracy. *sigh* so this doesn’t exist.
Instead, we get a modified Dashboard that is capable of running unsigned games, but is also able to load tools from the DVD to flash the TSOP.