A number of tricks exist that can be used to make regions of memory appear different in some way than their physical representation would indicate. The two tricks relevant to the analysis of the Xbox boot sequence are aliasing and overlaying.
Memory locations are aliased when two addresses refer to the same memory location, typically accomplished by ig-noring a few address bits. To illustrate aliasing, consider a system using a 3-bit address. There are only 23 = 8 unique locations addressable in a 3-bit system: 000, 001, 010, 011, 100, 101, 110, and 111. Now suppose that you have a memory with four locations; it requires only two bits to distin-guish each of the four locations: 00, 01, 10, and 11. If you use our 3-bit address scheme to talk to this four-location memory, one of the address bits must be ignored. If the highest bit is ignored, then address 000 and 100 will both map to loca-tion 00 in memory. In other words, localoca-tion 00 is aliased to addresses 000 and 100.
Memory overlaying is a technique where out-of-band infor-mation is used to select between different banks of memory.
Let’s suppose that we wish to have a bank of secret memory.
To do this, we insert a selector between our public and secret memories, and the CPU. This selector can choose to present the CPU with data from either the secret memory or the public memory, as indicated in Figure 6-2. As a result, the program that controls the address selector also controls who has access to the secret block. If the computer starts up running code located in the secret bank of memory, a program in the secret code region can use this mechanism to hide itself by setting the selector to point at public memory before running programs located in public memory.
Figure 6-2: Memory overlaying to hide secret regions.
Public
Furthermore, the jam table opcodes seem to be corrupted. This phe-nomenon was corroborated by other hackers working on the problem, thus ruling out a code translation error. Clearly, there is more to the Xbox than meets the eye.
Theories and rumors started to emerge to explain this strange behavior.
Some of the popular theories included:
•
Address and/or data line scrambling. Somewhere, the address or data lines were being inverted or permuted with some 1:1 mapping function. The scrambling function could be programmed into the chipset as part of the initialization procedure, so that the initial boot block would read like plaintext while the rest of the data would be scrambled.•
Secondary crypto processor. Another processor on the Xbox was actually handling the Xbox’s initialization, and the boot code in the ROM is bogus.•
Boot code contained in the processor. The processor is actually initialized by a chunk of code sitting on the processor die, and the boot code in the ROM is bogus.•
Boot code contained in the chipset. The processorfunctions identically to a standard Pentium, but the chipset contains boot code that overrides the bogus code inside the ROM.
For almost all of these theories, the only way to prove or disprove them is to perform experiments on the hardware. For example, in order to ensure that the SMC (System Management Controller, an 8-bit self-contained processor that is always on when the Xbox is plugged in) played no role in the secure boot sequence of the machine, hackers captured traces of the waveforms on all of the SMC’s pins and analyzed them against the expected sequence of events if the SMC were to play a crucial role in machine
initialization.
A crucial observation from a fellow hacker was that the Xbox booted perfectly even when the reset vector code at 0xFFFF.FFF0 was changed.
One would expect that if the first instruction executed by the processor at 0xFFFF.FFF0 were corrupted, then the machine would crash. Rather, the machine operated flawlessly. This observation was verified by a set of experiments where various parts of the FLASH ROM were intentionally corrupted. The results were that corrupting surprisingly large regions of the FLASH ROM had no effect on the booting of the Xbox. In particular, the entire boot initialization sequence from 0xFFFF.FE00 to 0xFFFF.FFFF could be nulled out and the Xbox would boot just fine.
This finding alone strongly supported the theory of a bogus boot block in FLASH ROM. The question remained, however, about where the real boot code was stored. There were three options: in a secondary crypto-processor, in the processor, and in the chipset. The secondary crypto-processor theory was discounted on the basis that there were no chips on the motherboard that were powerful enough or active enough at boot time to play the role
of a crypto processor. Storing the boot block in the processor was also deemed a less likely option than storing the boot block in the chipset.
The rationale for this analysis is based on the economics of building chips. A Pentium III processor is very complex with many handcrafted blocks, and modifying the silicon to include a secure boot block would require significant engineering resources as well as an upfront investment of about a quarter of a million dollars just for the masks needed to produce the custom silicon. In addition, it was rumored that Microsoft had originally chosen an AMD processor for the Xbox, and switched to Intel at the last minute. If custom blocks were integrated into the processor core, Microsoft could not have switched between CPU vendors so easily. On the other hand, nVidia’s chipsets are designed modularly using silicon compilers, so it is technically easier to add warts like a secure boot block. Furthermore, the chipset in the Xbox is a custom build of the nForce made just for Microsoft, tailored specifically for an Intel front-side bus (FSB). As a result, the cost of adding a secure boot block could be rolled into the engineering resources and the mask sets already allocated to such a project.
Operating under the theory that the real boot code is located in a secret ROM overlay in the chipset, the challenges remaining were to determine in which chip (Northbridge or Southbridge) the code was stored, and how to extract this secret ROM. A few strategies for extracting the secret ROM presented themselves:
•
Use the JTAG “boundary scan” feature on the Pentium to try to capture the initial boot code. JTAG is a diagnostic bus that allows you to read and set the state of every pin on a chip through a special serial port. It is a very powerful and versatile debugging tool.•
Probe the processor FSB (Front Side Bus) to try and capture the boot code as it enters the processor.Figure 6-3: Missing JTAG via. Note how the filled in copper region (lighter area) has a hole where a via used to be. This is the result of a last-minute change to the board layout without recalculation of the fill regions.
•
Install a memory sniffer to try and capture the decrypted data stream as it is written into memory.•
Use microscopy to read out the contents of the secure boot area from the chip surface.•
Probe the bus between the Southbridge and theNorthbridge chips to try and capture the boot code being sent to the processor by the chipset. This would only work if the boot data is stored somewhere in the Southbridge chip.
None of these theories were trivial to test, so the Xbox hacking effort slowly ground down to a halt as frustrated hackers gave up trying to cryptanalyze the FLASH ROM image. I would have been one of the quitters (after all, I had a doctoral thesis to finish and write in just a few months) had it not been for the community of determined hackers feeding me encouragement.
Over Christmas break in December 2001, I kept in touch with my hacker friends via IRC channels and web fora. Hackers from all over the world and all walks of life pervaded the Xbox hacking IRC channel, and I enjoyed learning from them and chatting with them about their various experiences, both technical and personal.
Even though I was determined to spend all of January writing my PhD thesis6 and avoiding Xbox hacking, I was still pulled in by the intriguingly complex security employed by the Xbox. As time went on, the need for a hardware guy to join the small group of hardcore hackers hanging out on the IRC channel became increasingly clear. By the end of January, the reports I was hearing about the Xbox security scheme were too interesting to ignore.
I purchased a second Xbox and I started removing all of its key parts using a hot air gun. Stripping down the Xbox served many purposes. First, removing the chips exposed all of the traces and connections on the Xbox so that I could easily follow the connections between chips using the continuity test mode on my multimeter. Second, I was able to drop all of the interesting chips into a hot acid bath and remove their plastic encapsula-tion for analysis under a microscope. Finally, buying an Xbox and totally ripping it apart gave me a sort of peace of mind when it comes to probing and modifying a working Xbox. (Reverse engineering is like gardening.
Planting a garden is much more challenging if you’re trying to keep your hands and knees clean, so you might as well get over it and start rolling in the dirt.)
The results of the Xbox tear-down revealed some of the measures that Microsoft took to secure the box against hardware hackers. For example, I first checked the JTAG connections on the Pentium CPU. All of the JTAG signals were conveniently routed to a set of easy-to-tap resistors near the processor, except for one, the TRST# signal. TRST# plays a critical role in
6 For those interested in supercomputer architecture, data and thread migration, fault tolerance, high speed low-latency networks, or massively multithreaded machines, check out my thesis at http://www.xenatera.com/bunnie/phdthesis.pdf.
initializing the JTAG interface. Interestingly, TRST# was tied to the internal ground plane, in a difficult to access area, permanently deactivat-ing the JTAG mechanism. Further inspection of the Xbox motherboard revealed hints that the TRST# signal was stripped out at the last minute.
(The biggest hint of a missing via is a hole in a power trace perfectly sized for a via near a cluster of vias dedicated to JTAG signals, as shown in Figure 6-3.)
Another blow to the JTAG approach for extracting the secret ROM is the fact that Intel’s JTAG scan codes are proprietary. Reverse engineering the codes to a level where I could use them for extracting the secret boot data was a major project on its own.
Giving up on the JTAG approach, the next method for extracting the secret ROM was to strip the packaging off of the CPU, GPU, and MCPX and to inspect the bare die with a microscope and search for any candidate ROM structures. Package removal or “decapsulation” was accomplished by bathing the chips in fuming hot sulfuric acid. (I don’t recommend trying this approach at home; one time I spilled the toxic, corrosive solution all over myself and thankfully, my protective gear was consumed instead of my skin. Fuming sulfuric consumes organic material faster than a burning flame.) Fuming nitric, also very toxic and dangerous, can also be used. While I have not tried it myself, reports indicate that fuming nitric is more effective at removing the epoxy encapsulation, especially in situations where selective package removal is desired.
The manual inspection approach using a traditional visible light microscope offered some hope; however, the technique is limited by the physics of light. Not even the best visible microscopy technology can resolve a 150 nm transistor, since the shortest wavelength of light is 450 nm (corresponding to the color blue). I was hoping the secret code would be stored on the chips using a traditional array ROM structure, with the metal lines defining a 1 or a 0 etched into the top metal layers which can be identified with an optical microscope. The use of a hard-wired ROM structure is motivated by cost: FLASH ROMs and fuse-based PROMs require extra processing and manufacturing steps that can add significantly to the cost of the system, whereas the use of top metal layers would be motivated by risk manage-ment on the designer’s part. Top metal layers are the coarsest layers (so coarse that an optical microscope may resolve them), and are thus the cheapest layers to change if there is a bug in the ROM code. Also, during initial bring-up, the top layer is the easiest to cut and jumper using a chip repair machine knows as a FIB (focused ion beam) machine. Unfortunately, a quick glance at the chip under the microscope revealed no such structures.
At this point, the only remaining option for extracting the secret ROM was to probe the live Xbox hardware, in an effort to capture the code during loading into the Xbox processor. Eavesdropping for code upstream of the Southbridge chip and the FLASH ROM meant probing either the Front Side bus, the Northbridge-Southbridge bus, or the main memory bus. We’ll discuss the trade-offs of executing these probing approaches in Chapter 8, after a short introduction to basic security concepts in the next chapter.