Xbox Security

The Xbox is a sixth generation video game console produced by Microsoft Corporation. It was Microsoft's first foray into the gaming console market, and competed directly with Sony's PlayStation 2 and the Nintendo GameCube. It was released on November 15, 2001 in North America, February 22, 2002 in Japan, and March 14, 2002 in Europe and Australia. It is the predecessor to Microsoft's Xbox 360 console.

The remarkable success of the upstart Sony PlayStation worried Microsoft in late 1990s. The growing video game market seemed to threaten the PC market which Microsoft had dominated and relied upon for most of its revenues. Additionally, a venture into the gaming console market would diversify Microsoft's product line, which up to that time had been heavily concentrated on software.

The Xbox was Microsoft's first product that ventured into the video game console market, after having collaborated with Sega in porting Windows CE to the Dreamcast console. Notable launch titles for the console included Halo: Combat Evolved, Amped: Freestyle Snowboarding, Dead or Alive 3, Project Gotham Racing, and Oddworld: Munch's Oddysee.

Development

The Xbox was initially developed within Microsoft by a small team that included game developer Seamus Blackley (an agent with Creative Artists Agency representing video game creators). Microsoft repeatedly delayed the console, which was revealed at the end of 1999 following interviews of Microsoft CEO Bill Gates. Gates stated that a gaming/multimedia device was essential for multimedia convergence in the new times of digital entertainment. On March 10, 2000 the "X-box Project" was officially confirmed by Microsoft with a press release. The Xbox was originally to be named "DirectX-box", to show the extensive use of DirectX within the console's technology. "Xbox" was the final name decided by marketing, but the console still retains some hints towards DirectX, most notably the "X"-shaped logo, which DirectX is famous for, along with the "X" shape on the top of the system. As the console approached launch, Microsoft's J Allard (is a Corporate Vice President and the Chief XNA Architect at Microsoft) was responsible for the hardware and system software development, Ed Fries (was vice president of game publishing at Microsoft during much of the Xbox's lifecycle) was responsible for game development on the platform, and Mitch Koch was responsible for sales and marketing; all three reported to Robbie Bach (the President of Entertainment & Devices Division at Microsoft). This team was also primarily responsible for Microsoft's follow-up product, the Xbox 360.

Xbox launch price was pretty high ( Europe 479.99 € in 14.3.2002; North America 299 $ in 15.10.2001; Oceania 699 AU$ in 14.3.2002). With a price-dropped PlayStation 2 (more than 100 € or $ cheaper) and a comparatively inexpensive GameCube (even cheaper than PS2) as competition, many users were naturally reluctant to invest in the console. Microsoft countered with a 100 $ price drop (and its equivalent in the rest of world) on April 26, 2002, just a month and 12 days after its initial launch. To avoid frustrating early adopters, they offered any two current games and an extra controller for free to any purchaser who could provide a sales receipt showing the original higher price. By September 15, 2005, Microsoft reported a four billion dollar loss in selling the Xbox gaming system. The Xbox has been discontinued as of November 13, 2006.

Hardware

Xbox drives Xbox was the first console to incorporate a hard disk drive, used primarily for storing game saves compressed in ZIP archives and content downloaded from Xbox Live. This eliminated the need for separate memory cards ( older consoles must had featured built-in battery backup memory prior to this). Most of the games also use the hard drive as a disk cache, for faster game loading times. Some games support "custom soundtracks", another unusual feature allowed by the hard drive. An Xbox owner can rip music from standard audio CDs to the hard drive and play their custom soundtrack, in addition to the original soundtrack of Xbox games that support the feature. The Xbox is based on commodity PC hardware and runs a stripped-down version of the Windows 2000 kernel using APIs based largely on DirectX 8.1. however, it also incorporates changes optimized for gaming and multimedia uses as well as restrictions designed to prevent uses not approved by Microsoft. The Xbox does not use Windows CE (variation of Microsoft's Windows operating system for minimalistic computers and embedded systems) due to Microsoft internal politics at the time, as well as limited support in Windows CE for DirectX. The Xbox itself is much larger and heavier than its contemporaries. This is largely due to a bulky tray- loading DVD-ROM drive and the standard-size 3.5 inch hard drive. However, the Xbox has also pioneered safety features, such as breakaway cables for the controllers to prevent the console from being yanked from the shelf. To cut manufacturing costs, and to provide a more reliable DVD-ROM drive (some of the early units' drives gave Disc Reading Errors due to the unreliable Thomson DVD-ROM drives used). Later generation of Xbox units that used the Thomson TGM-600 DVD-ROM drives and the Philips VAD6011 DVD-ROM drives were still vulnerable to failure that rendered the consoles either unable to read newer discs or caused them to halt the console with an error code usually indicating a PIO/DMA identification failure, respectively.

Technical specifications •CPU: 32-bit 733 MHz Coppermine-based Mobile Celeron in Micro-PGA2 package. 180 nm process. •SSE floating point SIMD. 4 single-precision floating point numbers per c lock cycle. •MMX integer SIMD. •133 MHz 64-bit GTL+ front side bus to GPU. •32 KB L1 cache. 128 KB on-die L2 "Advanced Transfer Cache". •Shared memory subsystem •64 MB DDR SDRAM at 200 MHz; 6.4 GB/s •Supplied by Hynix or Samsung depending on manufacture date and location. •GPU and system chipset: 233 MHz "NV2A" ASIC. Co-developed by Microsoft and NVIDIA. •4 pixel pipelines with 2 texture units each •932 megapixels/second (233 MHz x 4 pipelines), 1,864 megatexels/second (932 MP x 2 texture units) (peak) •115 million vertices/second, 125 million particles/second (peak) •Peak triangle performance: 29,125,000 32-pixel triangles/sec raw or w. 2 textures and lit.[citation needed] •485,416 triangles per frame at 60fps[citation needed] •970,833 triangles per frame at 30fps[citation needed] •4 textures per pass, texture compression, full scene anti-aliasing (NV Quincunx, supersampling, multisampling) •Bilinear, trilinear, and anisotropic texture filtering •Similar to the GeForce 3 and GeForce 4 PC GPUs.

•Storage media •2x – 5x (2.6 MB/s – 6.6 MB/s) CAV DVD-ROM •8 or 10 GB, 3.5 in, 5,400 RPM hard disk. Formatted to 8 GB. FATX file system. •Optional 8 MB memory card for saved game file transfer. •Audio processor: NVIDIA "MCPX" (a.k.a. SoundStorm "NVAPU") •64 3D sound channels (up to 256 stereo voices) •HRTF Sensaura 3D enhancement •MIDI DLS2 Support •Monaural, Stereo, Dolby Surround, Dolby Digital Live 5.1, and dts Surround (DVD movies only) audio output options •Integrated 10/100BASE-TX wired ethernet •DVD movie playback •A/V outputs: composite video, S-Video, component video, SCART, Optical Digital TOSLINK, and stereo RCA analog audio •Resolutions: 480i, 576i, 480p, 720p and 1080i •Controller ports: 4 proprietary USB ports •Weight: 3.86 kg (8.5 lb) •Dimensions: 320 × 100 × 260 mm (12.5 × 4 × 10.5 in)

Microsoft wants the software monopoly on the Xbox platform. Nobody should be able to publish unlicensed software, because Microsoft wants to gain money with the games to amortize the hardware losses. Obviously it is important to Microsoft that it is not possible to run copied games on the Xbox. Microsoft decided to design a single security system that was supposed to make Linux, homebrew/unlicensed software and copies impossible. The idea to accomplish this was by simply locking out all software that is either not on the intended (original) medium or not by Microsoft. On the one hand, this idea makes the security system easier and there are less possible points off attack. But of the three consoles of its generation, Xbox, Playstation 2 and GameCube, the Xbox is the one whose security system has been compromised first, the one that is now easiest to modify for a hobbyist, the one with the most security system workarounds, and the one with the most powerful hacks. This may be, because the Xbox security is the weakest one of the three, but also because Open Source people, homebrew people and crackers attacked the Xbox, while the Open Source people did not attack the Playstation 2, as Linux had been officially supported by Sony, so the total number of hackers was lower and buying them some more time.

Security ideas and its mistakes

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. Microsoft's also use few tricks as RC-4 encryption, decoy code in the system's Flash ROM(non-working) and a "secret boot block" hidden within one of the system's application-specific integrated circuits (ASICs). But RC4 (also known as ARC4 or ARCFOUR) is remarkable in its simplicity, but is also vulnerable to attacks. Unlike a modern stream cipher (such as those in eSTREAM), RC4 does not take a separate nonce alongside the key. This means that if a single long-term key is to be used to securely encrypt multiple streams, the cryptosystem must specify how to combine the nonce and the long-term key to generate the stream key for RC4. One approach to addressing this is to generate a "fresh" RC4 key by hashing a long-term key with a nonce. However, many applications that use RC4 simply concatenate key and nonce; RC4's weak key schedule then gives rise to a variety of serious problems. There is short history of RC4 downfall.

Biased Outputs of the RC4

The keystream generated by the RC4 is biased in varying degrees towards certain sequences. The best such attack is due to Itsik Mantin and Adi Shamir who showed that the second output byte of the cipher was biased toward zero with high probability. Such bias can be detected by observing only 256 bytes. Souradyuti Paul and Bart Preneel showed that the first and the second bytes of the RC4 were also biased. The number of required samples to detect this bias is 225 bytes. Fluhrer and McGrew also showed such attacks which distinguished the keystream of the RC4 from a random stream given a gigabyte of output.

Fluhrer, Mantin and Shamir attack

In 2001 a new and surprising discovery was made by Fluhrer, Mantin and Shamir: over all possible RC4 keys, the statistics for the first few bytes of output keystream are strongly non-random, leaking information about the key. If the long-term key and nonce are simply concatenated to generate the RC4 key, this long-term key can be discovered by analysing a large number of messages encrypted with this key. This and related effects were then used to break the WEP ("wired equivalent privacy") encryption. This caused a scramble for a standards-based replacement for WEP in the 802.11 market, and led to the IEEE 802.11i effort and WPA. Cryptosystems can defend against this attack by discarding the initial portion of the keystream. Such a modified algorithm is traditionally called "RC4-drop[n]", where n is the number of initial keystream bytes that are dropped. The SCAN default is n = 768 bytes, but a conservative value would be n = 3072 bytes.

Klein's Attack

In 2005, Andreas Klein presented an analysis of the RC4 stream cipher showing more correlations between the RC4 keystream and the key. Erik Tews, Ralf-Philipp Weinmann, and Andrei Pyshkin used this analysis to create aircrack-ptw, a tool which cracks 104-bit RC4 used in 128-bit WEP in under a minute Whereas the Fluhrer, Mantin, and Shamir attack used around 10 million messages, aircrack-ptw can break 104-bit keys in 40,000 frames with 50% probability, or in 85,000 frames with 95% probability.

Xbox Hardware Cryptosystem Overview

The Xbox crypto protocol presents a strong defense in the face of unsecured FLASH ROM-based modifications. The Xbox boots from a 512-byte secret boot block that is hard-coded into the southbridge system ASIC (the “MCPX”). This boot block performs the following functions, in order: loads the “jam tables”, i.e., initializes the console chipset turns on the processor caches

decrypts the kernel bootloader, contained in FLASH ROM verifies that decryption was successful jumps to the decrypted kernel bootloader 3. The bootloader then performs some more system initialization, decrypts a kernel image from FLASH ROM, decompresses and verifies the decrypted image, and enters the kernel. The kernel decryption key is stored within the bootloader image. Note that the secret boot block code is structured so that the bootloader decryption key is never written to main memory, thus defeating an attack that involves eavesdropping on the main memory bus. The bootloader is encrypted with RC-4 using a 128-bit key. The decryption algorithm and key are stored in the secret boot block and executed by the Pentium CPU. The busses between the secret boot block and the CPU are not encrypted but assumed to be secure due to their high speeds. The decryption of the bootloader image is verified by checking for a 32-bit magic number near the end of the plaintext stream. This check only ensures that the ciphertext stream was not corrupted. One with knowledge of the secret key and the magic number can easily create original bootloader images. The magic number check might also confuse efforts to create original bootloader code based on a key obtained without full knowledge of the secret boot block’s contents, such as through a personnel leak or brute force. However, a brute force approach to recovering the bootloader is probably out of the question, since distributed.net’s “bovine” effort, running for over 4 years and currently capable of testing over 100 gigakeys/s, is still working on a 64-bit RC-5 cipher at the time of writing. Given this secure boot protocol, modifying the contents of the FLASH ROM alone will stand a very low chance of revealing anything useful about the console1. This is compounded by the fact that the FLASH ROM contains a decoy boot block with halfway reasonable looking decryption and initialization code. The algorithm in the decoy boot block is a bastardized RC-4, and of course applying this algorithm on the ROM contents yields nothing but white noise. But we still didnt know why a hidden ROM is needed. The Xbox, having an external (reprogrammable) 1 MB Flash ROM chip (models since 2003 have only 256 KB), would normally start running code there as well, since this megabyte is also mapped into the uppermost area of the address space. But this would make it too easy for someone who wants to either replace the ROM image with a self-written one or patch it to break the chain of trust ("modchips"). If the ROM image could be fully accessed, it would be easy to reverse-engineer the code; encryption and obfuscation would only slow down the hacking process a bit. A common idea to make the code inaccessible is not to put it into an external chip, but integrate it into one of the other chips. Then there is no standard way to extract the data, and none to replace the chip with one with different contents. But this way, it is a lot more expensive, both the design of a chip that includes both ROM and additional logic, and updating the ROM in a new version of the Xbox if there is a flaw in the ROM. A good compromise is to store only a small amount of code in one of the other chips, and store the bulk of it in the external Flash chip. This small ROM can not be extracted easily, and it cannot be changed or replaced. The code in there just has to

make sure that an attacker can neither understand nor successfully patch the bulk of the code he has access to, which is stored in Flash ROM. Microsoft decided to go this way, and they stored 512 bytes of code in the Xbox' Southbridge, the MCPX (Media and Communications Processor for Xbox), which is manufactured by nVidia. This code is supposed to be mapped into the uppermost 512 bytes of the address space, overriding the Flash ROM at this position, so that the CPU starts execution there. It includes x86 code for a decryption function with a secret key that makes the CPU decipher (parts of the) "unsafe" code in the Flash ROM into RAM and run it. Without knowing the key, it is practically impossible to understand or even patch the encrypted code in Flash ROM. But ROM in a multifunction IC is expensive, therefore it has to be small. Microsoft decided it to be only 512 bytes. Microsoft's implementation of the RC4 decryption algorithm fits well in about 150 bytes, so, at first inspection, this should be no problem. But it is. When the CPU starts up, we cannot simply start decrypting data from flash ROM into RAM. We have to • initialize the CPU (32 bit mode, caching, segmenting) • initialize the chipset and RAM so that the machine is in a stable state While the CPU initialization can be done in less than 150 bytes, the initialization of the chipset and RAM, if done completely, will require more than 1000 bytes of assembly code. Even at a minimum, Microsoft probably did not see a way to fit all this into these 512 bytes. Therefore it was decided to store some initialization tables in Flash ROM. The Southbridge was modified to read these tables even before the CPU starts running, and to pass these values to the Northbridge and Southbridge components. These tables are fetched from the very beginning of Flash ROM (FFF0_0000) and are 52 bytes long. But these tables are not enough for full hardware initialization. Tables are just not powerful enough - for memory initialization, memory stability tests have to be made. Putting some x86 code to do this into Flash ROM would weaken the security system, because a hacker could then easily put his own code there. Microsoft decided to create a simple virtual machine that was well-suited for running hardware initialization code, but not much else. They created a tiny interpreter that understands 12 statements, but is not supposed to be powerful enough to take over the machine. As it is secure, this bytecode, called Xcode by the hackers that discovered it, can then be stored in Flash ROM. So the hidden ROM initializes the CPU, interprets the Xcodes stored in Flash ROM to set up the machine and then decrypts and runs x86 code from Flash ROM. The Xcodes start at FFF0_0080 (at 128 bytes) in Flash ROM. As the Flash can be easily updated in newer revisions of the Xbox, their size needn't be constant; they are typically about 3000 bytes in size, which is about 330 statements. An Xcode consists of an 8 bit statement, always followed by two 32 bit operands. The virtual machine has a 32 bit accumulator. The following table summarizes possible instructions; all other codes are treated as NOP: 0x02 PEEK ACC := MEM[OP1] 0x03 POKE MEM[OP1] := OP2 0x04 POKEPCI PCICONF[OP1] := OP2 0x05 PEEKPCI ACC := PCICONF[OP1]

0x06 AND/OR ACC := (ACC & OP1) | OP2 execute the instruction code in OP1 with OP1 := OP2, 0x07 (prefix) OP2 := ACC 0x08 BNE IF ACC = OP1 THEN PC := PC + OP2 0x09 BRA PC := PC + OP2 0x10 AND/OR ACC2 (unused/defunct) ACC2 := (ACC2 & OP1) | OP2 0x11 OUTB PORT[OP1] := OP2 0x12 INB ACC := PORT(OP1) 0xEE END

So the interpreter, rewritten in C, looks roughly like this:

struct { char opcode; int op1; int op2; } *p; int acc;

p = 0xFFF00080;

while(1) { switch(p->opcode) { case 2: acc = *((int*)p->op1); break; case 3: *((int*)p->op1) = p->op2; break; case 4: outl(p->op1, 0x0CF8); outl(p->op2, 0x0CFC); break; case 5: ... case 0xEE: goto end; } p++; } end:

PEEK and POKE read from and write constants to main memory. OUTB and INB do the same with 8 bit I/O ports. (I/O ports are another address space, 16 bit wide, next to the 32 bit memory address space. While most other CPU architectures control

hardware by accessing their registers as if they were memory, the Intel architecture can access some older components through specialized in/out assembly instructions.) POKEPCI and PEEKPCI access the PCI configuration area, by sending the PCI config address to 32 bit I/O port 0xCF8 and accessing the value at 32 bit I/O port 0xCFC. (On PCI-equipped computers, every PCI device has at least 64 bytes of PCI config registers. On a PC, the BIOS or a Plug-and-Play operating system communicates through these registers to find out what resources (memory, I/O ports, interrupts) a device needs and then maps these resources. The I/O ports 0xCF8/0xCFC are the communication mechanism for the PCI config space on PCs.) The AND/OR instruction can do a 32 bit AND or OR or both at the same time with the accumulator. BNE branches if the accumulator is equal to a constant, BRA branches always. The prefix 0x07 can be used to execute any of the other statements with the accumulator as the second operand. This way, "POKE addr, ACC", "POKEPCI addr, ACC", "BNE PC+ACC", "BRA PC+ACC" and "OUT addr, ACC" are possible. The code 0x07 is handled by the interpreter, and uses a second accumulator, but this code is never used by the Xcodes. The code 0xEE ends the interpreter and makes the hidden ROM go on with the RC4 decryption. After the Xcodes have completed the hardware setup, the machine is in a stable state, so that it is possible to decrypt parts of the Flash ROM directly into RAM and run it there. As mentioned earlier, the RC4 code including the key is about 150 bytes in size. The Xcode interpreter is about 175 bytes, and CPU init about 145 bytes. This leaves only about 40 bytes for a check whether decryption was successful and halt the machine otherwise. This seems not to have been enough space for Microsoft's engineers to implement a small checksum routine, so they only checked for one 32 bit constant (0x7854794A) at the end of the decrypted data in RAM (0x0009_5FE4). If this is successful, the CPU jumps to 0x9_0000 in RAM, where the new code has been written. This code, the "second bootloader" ("2bl") is about 25 KB in size. It continues initializing the hardware and decompresses the kernel from Flash ROM. If the decrypted value is not correct, the CPU is supposed to halt. Simply using the "hlt" opcode would mean that the machine would remain turned on and idle with the hidden ROM visible in the address space. A hacker could then use some hardware attached to the chipset that extracts the data from ROM from a running machine. The designers therefore decided to always turn off the hidden ROM as soon as possible in both branches, when decryption was successful (then it is turned off as one of the first instructions in the "2bl" code), and if it wasn't. But making the CPU crash and turning off the ROM it is running in is a challenge. If we halt the CPU, we cannot turn off the ROM afterwards. If we turn off the ROM, we turn off the code that gets run and we cannot halt the CPU - even worse, the CPU would continue fetching its opcodes from the underlying Flash ROM as soon as the hidden ROM is deactivated. Microsoft's developers came up with a very interesting trick: They led execution to the absolute top of the address space, and as the very last instruction, they turn off the hidden ROM. Then the instruction pointer is supposed to overflow from FFFF_FFFF to 0000_0000 and an exception is supposed to be generated which in turn is supposed to halt the CPU because no exception handler is registered.

Security Issues

This system looks pretty secure. If we don't know what's going on, it is a lot of work to find out that there is a hidden boot ROM (but it's easy to prove because the Xbox still boots if you overwrite the upper 512 bytes of Flash ROM since they never get used). If we don't have access to the boot ROM, we cannot decrypt and thus cannot understand the code in Flash ROM. Because we don't know how to reencrypt, we cannot patch the code in Flash.

The Importance of the Secret Key

But what happens if someone finds out the hidden 512 bytes? Andrew Shane Huang (more known as BUNNIE after year in which he was born) did it at the end of 2001. He tapped the bus between the Southbridge (where the secret MCPX code is stored) and the Northbridge (the CPU's memory interface) where all secret data gets transmitted. The compromise to store the secret ROM in the MCPX instead of the CPU, so that data would travel over a bus, finally broke the system. Knowing the algorithm and the secret key, he could easily disassemble the whole code in Flash ROM, and he could have even patched and reencrypted the code - the decryption code won't notice the difference, as the Flash ROM is not hashed: Only a single 32 bit value is checked. Modchip makers, who used similar tricks to get hold of the hidden ROM, used this knowledge to create patched versions of the Flash ROM image and distributed them on boards that, soldered to the Xbox motherboard, overrode the onboard Flash ROM. So as soon as the encryption algorithm and the key are known, everything is possible? Not quite. In order to create a working Flash ROM image, you have to use Microsoft's secret key, which is considered illegal under certain jurisdictions. So for a completely legal replacement Flash ROM image that takes over the machine to be free to run any homebrew software or alternative operating systems, a complete security analysis had to be made. Since the hidden code depends in some way on external data, stored in Flash ROM, which can be quite easily changed by the user, it may be attackable through certain data stored there. Microsoft understood this danger and added some precautions so that the Xcodes could not be abused - supposedly - in case the secret ROM was known.

PEEK The Xcode language is powerful enough to easily read and write memory, the PCI configuration space as well as I/O ports. The user could easily add Xcodes that read the hidden MCPX ROM and send the data to some I/O ports, e.g. the I2C bus. Therefore all memory reads are limited to the lower 256 MB:

and ebx, 0FFFFFFFh ; clear upper 4 bits mov edi, [ebx] ; read from memory location op1 into di jmp next_instruction

POKEPCI Turning off the hidden ROM is done by the following statements:

mov eax, 80000880h mov dx, 0CF8h out dx, eax add dl, 4 mov al, 2 out dx, al

This code sets bit #1 in the PCI config space, device 0:1:0, register offset 0x80 (coded in 0x80000880). Using the POKEPCI instruction, it would be possible to disable the hidden ROM prematurely, so that the underlying Flash ROM, which is normally overlapped by the secret ROM, would be visible, and CPU would continue running there, where the hacker could simly store his code: POKEPCI 0x80000880, 2 Therefore the interpreter always clears bit 1 if the Xcode wants to write to 0x80000880:

cmp ebx, 80000880h ; ISA Bridge, MCPX disable? jnz short not_mcpx_disable ; no and ecx, not 2 ; clear bit 1 not_mcpx_disable: mov eax, ebx mov dx, 0CF8h out dx, eax ; PCI configuration address add dl, 4 mov eax, ecx out dx, eax ; PCI configuration data jmp short next_instruction

Halt

As described earlier, if the hidden ROM detects that decryption was unsuccessful, it halts the CPU and turns off the hidden ROM by turning it off as the very last statement in the CPU's address space, causing an address overflow exception and thus a CPU halt in the very next cycle. This is supposed to make it impossible for a hacker to extract the hidden ROM contents, because the hidden ROM is always turned off very quickly, even if the machine does not boot correctly.

mov eax, ds:95FE4h cmp eax, 7854794Ah jnz short bad_checkcode

mov eax, ds:90000h jmp eax ; jump to decrypted second bootloader in RAM bad_checkcode: mov eax, 80000880h ; prepare MCPX ROM disable mov dx, 0CF8h out dx, eax jmp far ptr 8:0FFFFFFFAh ; jump to end of ROM, wraparound [...] FFFA: ; this is address FFFFFFFA add dl, 4 mov al, 2 out dx, al ; ------this is address 00000000 ------

Security Flaws in the Hidden ROM

While these three security precautions that have just been described are indeed vital, two of them are faulty. The POKEPCI check is incorrectly implemented, and the somewhat clever "Halt" trick, which was supposed to lock out hardware sniffers, opened a software backdoor.

The Visor Trick

The roll over of the instruction pointer from FFFF_FFFF to 0000_0000 is supposed to generate an exception. Since no exception handlers are installed, this is supposed to halt the machine. But in reality, no exception is generated. Execution just happily continues at 0000_0000 - in RAM! Apparently the i386 CPU family throws no exception in this case, Microsoft's engineers only assumed it or misread the documentation and never tested it. By adding Xcodes to write a jump to some Flash ROM address, like FFF0_0000, into memory at location 0, and causing the decryption check to fail by just not including the 32 bit check value into the Flash ROM, one's own code will be run right after the RC4 decryption:

POKE 0x00000000, 0x001000B8 ; store "mov eax, 0xFF001000; jmp eax" POKE 0x00000004, 0x90E0FFFF ; at 0x00000000 in memory END ; now we can place our code at 0x1000 in Flash

The MIST Trick

POKEPCI's check for 0x80000880, the address of the configuration register to turn off the hidden ROM, is incorrect. The Southbridge, which decodes the 32 bit value into "bus", "device", "function" and "register" and sends the funcion and register numbers to the specific device on the specific bus, simply ignores the unused bits of that 32 bit value, so 0x88000880 or 0xF0000880 behave exactly the same as 0x80000880 - but POKEPCI's check does not detect them. So this check even gives the attacker a hint how to circumvent it. By adding the statement POKEPCI 0x88000880, 2 to the Xcodes, the interpreter will turn off the hidden ROM - where it is running itself! As soon as the CPU cache has run empty, execution will continue somewhere between FFFF_FE00 and FFFF_FFFF in Flash ROM. You can simply fill everything with NOPs and add a JMP to your own code at the very top.

More Attacks?

Since two methods to circumvent the Xbox hidden ROM security without touching any crypto both work equally well, there has been little need for further research, but there might very well be more than two security issues in these 512 bytes. There are two more approaches for attacks that we do not want to disclose yet, as Microsoft may still offer updated Xboxes in the future.

Microsoft's Fixes

In August 2002, Microsoft started manufacturing V1.1 Xboxes, which had been improved in many ways. In concerns of security, the hidden ROM and the MCPX' PCI config behavior had been updated (the MCPX revision is "C3" instead of "B2"): They now squeezed a TEA hash into the 512 bytes, replacing the old 32 bit test. The "2bl" code now couldn't be altered easily. And they changed the RC4 secret key. But although they had the possibility to patch their design, Microsoft again failed to make the Xbox secure this time: • They left both the MIST backdoor and the Visor backdoor wide open. • The TEA hash has been a bad choice. If they had even read Schneier's "Applied Cryptography" (the book on crypto), they would have known that TEA is insecure if used as a hash. This can be easily exploited so that 2bl changes remain undetected, leading to the third bug in the second implementation. It is pretty obvious that the changes had been made in reaction to Bunnie's hack, who retrieved the secret key for the RC4 decryption, and before the Visor or MIST bugs had been found. In May 2004, Microsoft started shipping Xboxes that had the ROM image, the video encoder and the security chip (SMC) integrated into a single package, so that it was no longer possible to overwrite the firmware. The secret ROM in the MCPX was still the same though. But as of November 2005, it is still possible to attach a

replacement ROM to the LPC bus ("modchip") of new Xboxes, as the verification weakness is still there.

Microsoft's Strategy

Microsoft's engineers first seem to have thought that the secret key would never be revealed: security by obscurity. This explains why the decrypted code did not get hashed. Once the secret key was known, anyone could decrypt, patch and reencrypt the flash contents. So when the secret key had been extracted, Microsoft understood that it could be done again with another key very easily, so they added a hash function over the decrypted code. If the new secret key was to be found out again, attackers should at least not have had the possibility to change the code. Changing the key introduced no security, but was easy to do and at least required attackers to repeat the ROM extraction process.

Our opinion

Microsoft wanted more money. More money is in console games. Microsoft also want to be better than SONY and their PlayStation and decided to make own console. This console must be cheap to made, better than PlayStation, which is well known and people like it. But these properties made big pressure on Microsoft. So Microsoft wants to do it very quick and quick work make mistakes. During making Xbox Microsoft wants quick results, so they implement there some useful hardware. But this hardware also allow to hackers broke security of Xbox. I think that Microsoft should invest more money into development and take more time. If it would be so, breaking security of Xbox would not be so easy. But Microsoft always do things in hurry. Milan Jacko

Microsoft made this console in hurry. I thin that in 2001 it was very good piece of hardware, but they underestimate hackers. They think, that most of them doing this for money (I think people who doing this for money aren´t so good as ones doing it just for fun) and that they work alone. Microsoft use just power and did not talk with people and didn´t invite them in testing process. Security ideas was not bad, but their implementation was poor and they also want save money, time and conquer console market. They still think about their program users as stupid money bank. I think when Microsoft change its politics and their programs will be more accessible for modifications and for non-Microsoft & his friends programs, hackers will be less inspired to crack all things for them. Vlado Fáber

I really enjoy work on this project, because I learned many new thinks around game consoles. Microsoft has too many unfinished projest´s and their beta-testers are worth not much. Many times they release unfinished products. When you are buying

some software from Microsoft, then is better wait few weeks until they repair major bugs. Now they show it on hardware too. I think Microsoft do everything what it thinks to be enough and it was not! Zuzana Schniderova

We hope you enjoy reading this as much as we enjoy doing it. All autors