Within a few months of its release the initial layer of security on the Xbox BIOS (which relied heavily on obfuscation) was broken by MIT student Andrew Huang and the contents of the "hidden" boot ROM was extracted using some custom built hardware. Once this information was available, the code was soon modified so that it would skip digital signature checks and media flags, allowing unsigned code to be run.
The book written by Andrew Huang, Hacking the Xbox: An Introduction to Reverse Engineering., you will find the story of when an MIT student, extracted security keys from the Xbox. Then crushing disappointment of receiving a letter from MIT repudiating any association with the work, effectively leaving him to face Microsoft.
There were limitations to the console to prevent abuse. However, there is an intense desire from multiple groups, legitimate and illegitimate, to get the Xbox to run code from arbitrary sources without hardware modifications. The Xbox is also a popular target for pirates because of the ease of porting legacy game emulators, and because of its high profile and ease of obtaining compatible debugging and testing hardware.
Additionally, the similarity of the Xbox architecture to the PC architecture makes the Xbox a good educational vehicle.
Xbox Developer Kit (XDK):
In order to allow only licensed and authentic code to run, it is necessary to build a TCPA/Palladiumlike chain of trust, which reaches from system boot to the actual execution of the game. The first link is from the CPU to the code in ROM, which includes the Windows kernel, and the second link is from the kernel to the game.
There are several reasons that the operating system is contained in ROM (256 KB) instead of being stored on hard disk, like on a PC. First, it allows a faster startup, as the kernel can initialize while the hard disk is spinning up, furthermore, there is one link less in the chain of trust, and in case verification of the kernel gets compromised, it is harder to overwrite a ROM chip than modify data on a hard disk.
When turned on, x86-compatible CPUs start at the address 0xFFFFFFF0 in the address space, which is usually flash memory. For the Xbox, this is obviously no good idea, as flash memory can be:
Thus, the machine must not start from flash memoery.
To make two of the attacks impossible, by using ROM (Read Only Memory) chips instead of flash. There would be no way to reprogram them, and it would be possible to disable the LPC override functionality in the chipset, because it is not needed for the manufacturing process any more.
There is a solution between flash memory and ROM that combines advantages of both these approaches.
This trick is rather old and had already been used in the Nintendo 64. Use a tiny non-replaceable startup ROM, and put the bulk of the firmware data (i.e. the Windows kernel) into flash memory. The “internal” ROM checks whether the contents of the flash memory are authentic, and if yes, it passes execution to it.
This way, there will be another link in the chain of trust, but the ROM code can be trusted (if it is nonreplaceable), and if, in addition, it is non-accessible, an attacker may not even have a clue how verification works.
But where can this ROM be put? It cannot be a separate chip, as it would be replaceable. It would have to be included into another chip. The CPU would be ideal, as the ROM contents would not travel over any visible bus, but then it would be impossible to use cheap off-the-shelf Celerons. Including it in any other chip would make it nonreplaceable, but data would travel over a bus. It seems to be a good compromise to store the ROM data in the Southbridge (”MCPX”), as it is connected via the very fast HyperTransport bus, so it is very hard to sniff. A former Microsoft employee confirmed that the developers tought that nobody was able to sniff HyperTransport.
This secret ROM stored in the Southbridge must verify the Windows kernel in the external flash memory before executing it.
One idea would be to checksum (hash) the flash contents using an algorithm like MD5 or SHA-1, but this would mean that the hash of the kernel has to be stored in the secret ROM as well, which would make it imposible to ship updated versions of the kernel in future Xboxes without also updating the ROM contents - which would be very expensive.
A digital signature algorithm like RSA would be better. It would be possible to update the kernel without changing the ROM, but an RSA implementation takes up a lot of space, and embedded ROM in the Southbridge is expensive. It would be ideal if the algorithm fit in only 512 bytes, which is impossible for RSA.
A solution for this problem is again to introduce another link in the chain of trust. The ROM only hashes a small loader (”2bl”, “second bootloader”) in flash memory, which can never be changed.
It is then the job of this loader to verify the rest of flash, and as the second loader can be any size, there are no restrictions.
The final chain of trust looks like this: The CPU boots from the secret ROM embedded into the Southbridge, which cannot be changed. The secret ROM verifies the second bootloader in flash memory using a hash algorithm, and if it is authentic, runs it.
Second bootloader checks the kernel, and if authentic, runs it.
Now the second bootloader and the Windows kernel would be stored in flash memory in plain text, which is a bad idea. An attacker can immediately see how the second bootloader verifies the integrity of the kernel, and even analyze the complex kernel for possible exploits.
Encrypting all the flash contents will not solve possible vulnerability problems, but it will buy us time until the decryption of the flash contents is understood by hackers.
The decryption key would have to be stored in the secret ROM, and the 2bl verification code would also have to decrypt the flash contents into RAM while reading it.
Decrypting flash memory contents into RAM is a challenge if we are living inside the first few hundred bytes of code after the machine has started up. At this point, RAM might not be stable yet.
The type of ROM used in the Xbox is an electrically erasable and programmable variety known as FLASH ROM. Typically comes in one of a few package types, and the Xbox uses one of the most popular packages, the TSOP (Thin Small Outline Package).
It is located in sector U7, on the top side of the Xbox motherboard.
The reference designator for the part is U7D1. The TSOP package is very recognizable because it is one of the few chip packages that is rectangular and has pins only on the narrow edges of the package.
Most other packages put pins on the long edge or all edges to maximize connectivity, but FLASH ROM has relatively low I/O requirements per silicon area. A quick check on the base part number, 29F080, with a Web search engine verifies that this part is indeed an 8 Mbit FLASH ROM.
It is write protected by default, but disabling the write protection is as easy as soldering a single bridge on the motherboard. After all, this bridge has to be closed temporarily during manufacturing when programming flash memory for the first time.
Using this hack, it is possible, only with a USB stick, one of several games (007 Agent Under Fire, MechAssault, Splinter Cell) and a soldering iron, to permanently modify the Xbox.
Only early Xbox Motherboards had a 1 MB flash chip. You could flash multiple ROM images!
What data do games load? Graphics data, audio data, video data... - but we cannot alter them, because it is not easily possible to create authentic Xbox DVDs, and the Xbox won't boot originals from DVD-R.
But most games can load savegames, and these can easily be changed. The Xbox memory units are more or less standard USB storage devices.
It is possible to use most USB sticks with the Xbox, and just store hacked savegames on them.
Plenty of Xbox games had buffer vulnerabilities in their savegame handlers. It was often as easy as extending the length of strings like the name of the player, and the game would overwrite its stack with our data and eventually jump to the code we embedded in the savegame.
The procedure for the user was then to simply copy a hacked savegame from a USB stick onto the Xbox hard disk, run the game and load the savegame.
After a buffer exploit, we would normally only be in user mode - not on the Xbox, as all Xbox games run in kernel mode. The reason for this is probably a slight speed advantage, or, less likely, a simpler environment for the game, but Microsoft tried to make the environment as similar to the Windows/DirectX environment as possible, so user mode would have actually made the environment “simpler” for many Windows/DirectX developers.
The problem with the savegame hack was that, if you didn't want to overwrite the flash memory chip, you had to insert the game and load the savegame every time you wanted to run unsigned code. Having full control of the machine using the savegame exploit also meant we could access the hard disk without opening the Xbox.
This way, it became interesting to closely examine the hard disk contents for vulnerabilities.
The Dashboard is the main program on hard disk, executed every time the Xbox is started without a game in the DVD drive. While the settings menu and savegame management on the Nintendo GameCube fit well into 2 MB of ROM, the Xbox Dashboard, which is roughly comparable in its functionality, occupies more than 100 MB. So the original idea why to include a hard disk might have been initiated by the inability to compress the Dashboard into typical ROM sizes.
The dashboard loads its data files, like audio and graphics, from hard disk. With the savegame exploit, we can now alter the hard disk contents, even without opening the Xbox.
The dashboard executable is signed and can therefore not be altered, and all data files are hashed, with the hashes stored inside the dashboard executable. Well, all files, except for two font files.
There was an integer vulnerability in the font handling routines, so that we could run our own code by replacing the font files. Combined with the savegame exploit, it was as easy as transferring the savegame and loading it, which would run a script that modifies the fonts.
