Chapter 9 -
Sneaking in the Back Door

The full range of viable attacks on the Xbox are too numerous to describe in this book. The Xbox is based on the PC architecture, a complex, evolved architecture originally designed with no thought for security. Many of the classic hardware security holes exploited by smart card hackers, such as power supply modulation, sideband attacks, and clock glitching have not even been touched on the Xbox, to the best of my knowledge. (You can find more information on these security weaknesses in the proceedings of the Cryptographic Hardware in Embedded Systems (CHES) conference, in the Lecture Notes in Computer Science series (Springer-Verlag).

Unfortunately, console and secure PC manufacturers are not concerned about hardware security weaknesses, because hardware attacks are “too difficult for the average consumer to execute” and therefore of little threat. While it is true that researching an attack requires a skilled hacker with the correct tools, implementing an attack can be very cheap and easy. I’m reminded of the parable where a mechanic, called in to fix an important piece of broken machinery, spends an hour looking at the situation and repairs the machine by tapping on it at just the right spot. Upon receiving a bill for $1,000, the machine’s owners demand to know why a tap costs so much. The mechanic responds with, “The tap costs a dime. Knowing where to tap costs $999.90.” The corollary to this parable is that anyone could have executed the tap to repair the machine, given specific instructions.

Security attacks are often the same: difficult to figure out; easy to share and implement. Secure hardware manufacturers should also be concerned about adopting mainly reactive policies to hacker intrusions. Many hackers work in secret, and keep their methods and results quiet so that vendors cannot develop proper countermeasures. These hackers also maintain a library of known attacks and back doors, disclosing only one at a time, so that vendors with reactive hardware security policies are always playing catchup.

The previous chapter described my eavesdropping attack on the Xbox security mechanism that eventually yielded the RC-4 key hidden in a block of secret code. This chapter describes a few of the other attacks available on the Xbox that were devised by my colleagues, as well as the attack that was mounted on the revised Xbox security scheme, herein referred to as security version 1.1.

Back Doors and Security Holes

A class of back door attacks on the Xbox leverage a fundamental weakness in the way the hardware is initialized by the secret boot code. This weakness stems from the fact that hardware initialization is accomplished by way of a powerful jam table opcode interpreter that stores its commands in unverified cleartext.

Visor Jam Table Attacks

One class of attacks on the Xbox involves modifying the hardware initialization sequence. Recall that hardware initialization of the Xbox is accomplished by means of an opcode interpreter that retrieves its commands from an unencrypted portion of the FLASH ROM called the “jam table.” The relationship of the jam table entries to the rest of FLASH ROM is illustrated in Figure 9-1. Jam table entries are stored as <opcode, arg1, arg2> tuples near the lowest FLASH ROM addresses. The available opcodes include memory read and write functions to all the address spaces in the x86 architecture. Since the jam tables are stored unencrypted and never checked for modification, opcodes can be inserted into the jam table that can “seed” the Xbox memory with rogue instructions or modified hardware state before the RC-4 decryption of the FLASH ROM 2BL.

One application of jam table modification is to recover the plaintext of the kernel without knowledge of the RC-4 key. A hacker, known only as Visor, first described this approach to me. Here is a summary of Visor’s approach:

1. Boot the Xbox normally. Part of the normal boot process will place a decrypted kernel image into main memory.
2. While maintaining power to the Xbox, switch the contents of the FLASH ROM’s jam table to an alternate table that copies regions of main memory to an easily monitored location, such as the FLASH ROM’s bus.
3. Perform a soft-reset of the Xbox CPU. This forces a hardware re-initialization without erasing the main memory.
4. Record the contents of main memory as the modified jam table program is executed.

Figure 9-1: Jam table opcodes in relation to the rest of FLASH ROM.

Dynamic switchover of the FLASH ROM contents, required in step 2, can be accomplished by means of a ROM emulator, or by using an oversized ROM with the excess address bits wired to a bank of switches.

Visor also described how the jam table can be used as part of an elaborate hack to gain control over the Xbox’s instruction pointer (IP). To better understand this hack, we will further investigate how the secret boot code handles the case of an invalid FLASH ROM image.

After decrypting the 2BL in the FLASH ROM image, the secret boot code checks for a magic number at a location near the end of the 2BL. For an invalid FLASH ROM image, this number does not match, and causes the CPU to jump to a short sequence of instructions located at 0xFFFF.FFFA. This set of instructions continues all the way to the very last addressable location in physical memory, location 0xFFFF.FFFF. Once the CPU executes this last instruction of the invalid ROM image, it should crash and halt execution due to a code segment boundary error when the IP rolls over from 0xFFFF.FFFF to 0x0000.0000. However, this does not happen; rather, the CPU happily attempts to execute whatever instruction, valid or invalid, is located at location 0x0000.0000. Nominally, this instruction is invalid and the CPU halts anyway due to an instruction fault. However, a valid instruction can be placed there during the Xbox jam table initialization sequence using a jam table memory write opcode. Thus, by corrupting or erasing the encrypted FLASH ROM image and by modifying the jam tables to insert a jump instruction to your own unencrypted code in FLASH ROM, you can gain control of the Xbox CPU IP without ever touching a cipher or any similar technological measure that effectively controls access to a copyrighted work. Hence, this hack might be legal under the DMCA. I say might because the DMCA is an oftentimes vague piece of legislation, and there is little court precedent to clarify the ambiguities. The argument for the legality of this approach lies in the fact that no significant Microsoft copyrighted code is ever decrypted or executed. The only exception is the portion of the secret boot ROM that must execute because they are hardwired into the Southbridge’s silicon. See Chapter 12, “Caveat Hacker,” for a more in-depth discussion of the legal issues that are facing the hacking community today.

MIST Premature Unmap Attack¹

In order to protect the secret boot code in the event that a hacker gains control of the Xbox, the secret boot code in the Southbridge chip unmaps itself shortly before it exits. In other words, it hides itself permanently from the system when it is finished executing. Thus, a user program attempting to access any of the top 512 bytes in memory will see the decoy block in FLASH memory instead of the secret boot code. Michael Steil, the lead of the Xbox-Linux project, discovered a way to leverage this feature.

The unmapping process is accomplished by writing to 0x8000.8008, a hardware register in the PCI configuration space. The basic strategy is to include a jam table opcode that writes to 0x8000.8008 and unmaps the secret boot code before the initialization sequence is finished. Since the caches are off at this time, the processor will start fetching and executing instructions from the decoy block. Fortunately, since the decoy block can be freely modified since it is part of the FLASH ROM. The catch, however, is that the jam table interpreter blocks writes to location 0x8000.8008, so this shouldn’t work. However, a bug in the decoding of the PCI configuration space in the Southbridge chipset makes the unmap instruction respond to multiple aliased addresses. In particular, the “function” bitfield is ignored. Thus, a write to 0x8000.8X08 where X is not equal to 0 also does the trick, and these writes are not blocked by the jam table interpreter. Therefore, to gain control of the CPU IP using the MIST hack, you must modify the decoy block in FLASH to contain your code, then add the appropriate jam table opcode to unmap the secret boot ROM during hardware initialization.

Microsoft Retaliates

The discovery of security holes prompted many to speculate that Microsoft would be swift to rotate its security scheme. In August 2002, Xboxes with a new motherboard quietly started to appear in Australia. The first official word of the new security system came from an unlikely source: nVidia, the producer of the chipsets used in the Xbox. Following an unspectacular second quarter in 2002, an nVidia spokesperson cited this as the last of a few reasons why the quarter went poorly:

“What we said about Xbox was that we reached a volume discount milestone, further reducing the margins. And that we will be taking an inventory write off in Q2 related to the amount of Xbox MCPs that were made obsolete when MSFT transitioned to a new security code (by way of the MIT hacker) and excess in nForce chipsets that we built in anticipation of higher demand of Athlon-based PCs.” — Derek Perez, PR Director, nVidia ²

Reverse Engineering v1.1 Security³

The specifics of the security code changes were not revealed until October 2002, when a hacker named Andy Green began investigating the first version 1.1 Xboxes available in the United Kingdom. The outward physical differences between Xbox version 1.1 and 1.0 on the motherboard were subtle: the GPU traded its fan for a larger heat sink, the USB daughtercard was merged into the motherboard, and a PLL clock synthesizer chip was missing. Also missing were filter capacitors here and there, but nothing significant seemed to have changed. Further probing revealed that the hole leveraged by the MIST attack was patched, but the jam table opcodes were unchanged. The LPC bus, a key vector for gaining access to the Xbox, was also present and unchanged.

Andy was able to extract the MCPX ROM in one day using a procedure thought up by a fellow hacker named Asterisk. The procedure leveraged an undisclosed combination of previously identified security holes and back doors. The initial analysis of the ROM contents revealed that the security was implemented in a radically different fashion. A cursory overview of the version 1.1 Xbox revealed that the old security through obscurity scheme was tossed out, and replaced with a scheme that nominally gets its security from the strength of public-key ciphers.

Figure 9-2: Xbox Security Version 1.1. Regions that cannot be changed without replacing the MCPX silicon are shaded gray.

Microsoft’s implementation of the new security scheme was a bit counter-intuitive, though. Because the secret boot ROM within the MCPX remained the same size, 512 bytes, they could not fit the full public-key digital signature algorithm within the secret boot ROM. Instead, they chose to use a lightweight hash in the secret boot ROM to verify a region of FLASH ROM dubbed the Flash Boot Loader (FBL). The FBL contains the code (RSA cipher, SHA-1 hash, Microsoft’s public key, and the driver program) for digital signature verification of the FLASH ROM. The FBL is executed only if the FBL’s hash can be verified against a constant stored within the secret boot ROM. Thus, the FBL is in theory as immutable as the secret boot ROM, even though it is stored in the mutable FLASH ROM.

Although this scheme sounded fairly bulletproof, the hacking community did not give up so easily. They examined the secret boot ROM’s hash in detail and discovered that it is based on TEA, a Tiny Encryption Algorithm by David Wheeler and Roger Needham at the Computer Laboratory of Cambridge University. Franz Lehner, a collaborator in the effort, sent a query to the newsgroup sci.crypt regarding weaknesses in the TEA hash.

On Friday afternoon, October 11th, their query was answered. A paper written by John Kelsey, Bruce Schneier, and David Wagner, presented in CRYPTO 1996 pointed out that the TEA cipher has a weakness in its key scheduler where every key has three related keys that can be generated by inverting certain pairs of bits (this weakness, along with the TEA cipher, is discussed in more detail in Chapter 7). On Saturday, Andy Green posted this to XboxHacker.net:

Aw, I'm a mere mortal, my feet are definitely made of clay.  OK, I don't think its giving too much away to say the first 5 bytes of the region.  ffffd400: E9 83 01 00 00  This is a relative longbranch to 0xffffd588  If I flip b31 of that as a DWORD (and flip its friend at DWORD address +1 the same way) I branch instead to 0x7fd588.... Hmmmm that's, what, 8M up, where...  where there's RAM  Xcodes.. visor ram push method... (looks at MCPX for RAM Write X-Code)  X-Code opcode 3 ... unrestricted  Hold on to your hat, boys! Its testing time!  (mviz, a marvelous and well-timed revelation, I feel mysterious and invisble forces helping me along, for which I am grateful!)4

In other words, the related-key weakness of the TEA cipher means that every adjacent pair of double words in the FBL can be modified by one bit, the most significant bit, without any change to the resulting hash. This weakness gave Andy and his team enough breathing room to modify the target of a single jump instruction to point to a location in main memory.

That single location can be pre-loaded with a follow-up jump instruction back into any piece of user code using the previously discussed jam table codes. The Xbox hacking community had come together in a heroic effort and cracked Xbox security version 1.1 in three days. A separate effort, no less valiant, by Xecuter had also cracked the security in the same time frame.

The first moral of this story is that security is only as strong as its weakest link. While there is little doubt about the robustness of the RSA cipher and the SHA-1 hash for digital signature purposes, these were not the only elements of the security system. The TEA cipher used to extend the secure boot ROM’s trust sphere into the FLASH ROM had flaws that allowed hackers to walk around the strong digital signature algorithms. This leads us to our second moral: complexity breeds weaknesses. Complex systems are difficult to design, test, and analyze. The version 1.1 security for the Xbox was probably implemented on a short fuse, so there was insufficient time to analyze the system for weaknesses. Either that, or Microsoft knew about the TEA weakness and designed this back door into the system to mitigate the risk of locking their FBL into silicon. It seems rather doubtful that Microsoft intentionally included this back door, since modifying the MCPX silicon is a very expensive proposition (although the expense ended up on nVidia’s books). On the other hand, complexity is hard to avoid. My advisor at MIT, Tom Knight, once told me, “There are two kinds of designs in this world: those that are useful, and those that you can formally prove to be correct.” To some extent, the only way to ensure the security of a real-world system is to make its details open (no security through obscurity!) and subject the system to analysis from all angles. In a way, a thorough analysis of Xbox security is being conducted at no expense to Microsoft, thanks to the hacker community.

Отправить

krl0s

Gracias

jbhukujil

mn.,,m