Released in November 2001, the original Xbox was Microsoft’s first venture into the game console industry. With its hardware closely resembling a cheap but versatile PC of the early 2000s, the device came under the immediate scrutiny of technical hobbyists looking to run ‘homebrew’ code and alternative operating systems on it.

Over the course of its lifetime, the Xbox was unilaterally hacked through a broad range of both hardware and software attacks. But at 20 years old, this Intel-based Pentium III system holds up as an amazing platform to learn or explore a plethora of security and computer systems engineering topics that are still relevant to this day.

As a fun departure from our usual content, this post exploits some nostalgia to tackle a challenge put forth by some of the earliest musings of the original Xbox researchers: “hacking” the original Xbox via Intel’s x86 CPU JTAG.

About the Original Xbox

Unlike some of the other early 2000s game consoles, the original Xbox was a remarkably straight-forward hardware platform built around an Intel CPU + NVIDIA GPU with a unified memory architecture. Microsoft designed a system that would be easy to transition existing PC game developers onto, tapping into their dominance of the PC market.

But the security of the Xbox leaned heavily on a “secret” 512 byte bootrom that was carefully hidden within the system’s custom NVIDIA MCPX Southbridge to establish a chain of trust. Within three months of launch, this secret bootrom was infamously dumped by Andrew “bunnie” Huang blowing the console wide open to further research.

Bunnie dumped the secret ROM using an FPGA to sniff the ROM on the HyperTransport bus as it left the MCPX on its way to the Northbridge / GPU, before traveling over the Front-side bus to the CPU. This attack (among others) is described in great detail in bunnie’s 2003 book: “Hacking The Xbox” (now free.)

Looking back at the race to dump secret ROM, there was some amount of discussion which weighed trying to use Intel’s CPU JTAG functionality to probe the system and read out this elusive bootloader:

“The JTAG boundary scan approach was rejected on the grounds that the TRST# pin, used to hold the JTAG chain in reset, was tied active in a manner that was difficult to modify without removing the processor.”

– Excerpt from Keeping Secrets in Hardware: The Microsoft Xbox (TM) Case Study, by Andrew Huang, 2002

Microsoft had intentionally tied the TRST# pin to ground underneath the Xbox CPU in an effort to disable the Intel JTAG interface and dissuade anyone from poking around.

More importantly, blackbox reversing Intel’s private JTAG instructions in order to query memory, registers, or perform other debugger-like actions was considered non-trivial:

“Removal and socketing of the processor was considered to be prohibitively expensive and time consuming; the cost of a BGA socket for the Pentium III is estimated to be in the hundreds to thousands of dollars. In addition, the JTAG boundary scan codes for the Pentium III are largely proprietary and would have to be reverse engineered as well…”

– Excerpt from Keeping Secrets in Hardware: The Microsoft Xbox (TM) Case Study, by Andrew Huang, 2002

But as the Xbox homebrew ecosystem flourished over the next several years, a slew of other methods were discovered to cheaply break, dump, or escape the chain of trust Microsoft had tried to establish with the secret ROM. There was little incentive pursuing these more challenging hardware attacks, so they were left behind and largely forgotten.

Intel x86 JTAG

While there is little else to be gained from new methods to dump or bypass secret ROM today, the ability to hardware debug the Xbox CPU would still provide unrivaled introspection to further study and preserve the rich history of the platform. Some of the benefits of JTAG debugging the CPU includes:

• Debug the system from the very first instruction executed (a.k.a the reset vector)
• Non-intrusive debugging without modifying the OS or any software running on the hardware
• Debugging retail BIOS images and other runtimes without native kernel debugging capabilities
• If it runs on the CPU, you can debug it – the Xbox Kernel, Linux, a custom RTOS, Windows (etc.)
• JTAG surpasses emulators in fidelity for studying hardware-specific behavior and un-emulated peripherals

Yet, twenty years later there is zero open-source hardware or software solutions privy to Intel’s private JTAG instructions… which seem odd given how ubiquitous x86 is. The alternative, locating a semi-complete “highly proprietary” hardware debugger (and its software components) from days past, is almost equally as challenging:

From my research, the best Pentium III debuggers (maybe even the only ones) of the early 2000s were made by American Arium and Applied Microsystems. These ranged from as low as $9k to over $40k USD for some of the Arium units. Allegedly, Intel bound these firms by 10-15 year NDAs when developing these solutions.

The main customer of these debuggers would have primarily been OEMs performing hardware validation or BIOS/firmware development while stabilizing new motherboards. With a pretty narrow market, there’s no more than a few thousand hardware debuggers of this period produced by either company.

In 2023 these vintage hardware debuggers seldom pop up, and aren’t bought for much more than $25-75 USD.

Rolling Your Own CPU JTAG

One of the more challenging aspects of tackling JTAG on Xbox is the fact that TRST# was tied to ground under the CPU. While yes, in theory drilling out the connection to release TRST# may allow us to drive the JTAG state machine, I had no clue how the CodeTAP / hardware debugger might respond to TRST# not operating as expected.

I began reviewing old Intel processor datasheets, hardware developer manuals, motherboard reference designs, and platform recommendations of the era to start piecing together a better understanding of how these hardware debuggers are meant to physically interface with the CPU.

As predominantly a software researcher by trade, manipulating the physical integration of an Intel CPU is not something I wanted to cut corners on. In order to remove all hardware ambiguity, I decided it would be best to design a CPU interposer PCB to cleanly breakout the JTAG signals, adapting from Intel’s specifications to rebuild an ITP port.

A dedicated CPU interposer would allow me to isolate the JTAG signals (and other CPU control signals) while skipping reverse engineering anything else the Xbox motherboard may have been doing to them. This would also enable me to neatly collect the relevant signals into a physical port the debugger normally expected to tap.

The large majority of CPU signals simply plunge through the 4-layer CPU interposer PCB 1-for-1. This interposer was originally designed simply as a 2 layer PCB, but was bumped up to 4 layers after some peer-review and negligible cost differential of hobbyist PCB production today.

The JTAG / CPU control signals of interest are pulled out using an internal routing layer (green), with the second internal layer (hidden above) simply serving as a ground plane. The breakout is a 30 pin SMT System 50 connector per Intel specs – the header alone cost $15 USD.

The minimum order of five 4-layer ENIG PCBs from JLCPCB cost $20 USD, and $20 for DHL shipping. While waiting on the JTAG interposer PCBs to arrive, I reballed a loose Xbox CPU or two I had leftover from a separate project.

Eight days after ordering, I had the JTAG breakout CPU interposers in-hand and a board ready for the install attempt.

Installing the JTAG breakout CPU Interposer

Even with semi-professional equipment, installing the JTAG breakout interposer is a tedious process that will be unforgiving of errors. The following image series depicts the rough sequence of steps for removing the original CPU and installing the JTAG interposer.

The most critical part of the install was nailing the alignment and reflow of not just one, but BOTH ball-grid-arrays for welding over a single rework profile. While I had some kapton to help better ensure alignment of the bottom array (interposer to motherboard), the top ball array (CPU to interposer) was done by eye.

Some “supports” (no-op SMD resistors) were put underneath the header portion of the interposer prior to reflow. While these supports are not visible and do not serve any electrical purpose, they provide some mechanical strength to help prevent stress or cracking of BGA balls when plugging or un-plugging the JTAG ribbon.

As a prototype, I wasn’t even sure this JTAG interposer (or the install) would be without error so I wasn’t too concerned about ideal construction or longevity for this attempt at a proof-of-concept.

The interposer is populated by hand after completing the reflow process. I did not trust the 30-pin header to not melt under the heat required to solder the CPU and JTAG interposer. Given the complexity of this install and using an un-vetted design to interpose 150 sensitive CPU signals, things went remarkably smooth.

With the CPU interposer installed, thankfully the Xbox boots as one would normally expect. But would JTAG work?

Dumping Secret ROM

Testing the JTAG setup for the first time was difficult because I had zero clue what a “normal” attach sequence would look like for both the hardware and software and no documentation. I had acquired the CodeTAP “AS-IS” and struggled to find a Pentium II / III motherboard with an ITP port (usually rare engineering boards) to test it against.

Plugging the hardware debugger into my JTAG interposer and connecting the software (CAD-UL XDB) to it, the Xbox would “FRAG” (flashing-red-and-green, a general system fault state) when trying to boot.

The debugger software kept failing to attach stating “Target RESET asserted” while the CodeTAP hardware wasn’t even indicating it could sense power from the target (TGTPWR). I had a slight suspicion of what the issue could be, but triple checked my schematics, pinout, and probed across the motherboard to verify that the CPU was indeed being RESET.

The source of the problem is that System Management Controller (a PIC16 MCU) on the original Xbox expects the CPU to pass a set of system integrity tests within about 200ms of boot or it will reset the entire device chain. I had configured the debugger to resume on system attach, but apparently this was not working, or not the way I expected it to.

I put together a small sketch for an Arduino Uno and placed it on the I2C bus that normally runs between the SMC and MCPX. This way, I could fulfill the SMC’s system integrity challenges in lieu of normal CPU execution.

All at once, everything had suddenly clicked into place and the JTAG debugger attached – I had glimpsed the CPU reset vector of the Xbox’s original 1.0 secret ROM, in all its glory:

After fighting to get acquainted with the debugger and a few system resets, I was able to navigate the XDB memory view to the top 512 bytes of system memory (around the reset vector) - dumping the complete, original 1.0 secret bootrom, from a retail Xbox motherboard, using JTAG.

Finally, one of the oldest theoretical attacks against the system - put to rest.

Continued Discovery

Blending nostalgic curiosities with a fun opportunity for establishing a deeper appreciation of computer hardware was the real purpose of this research. Further, the ability to hardware debug the Xbox CPU opens up several new tangential projects that I find personally interesting towards further research of the platform and general OS internals.

While insufficient, Microsoft made active effort to layer security mechanisms in the Xbox. Having released TRST# via the interposer, satisfied SMC security challenges with an arduino, and dumped secret ROM using JTAG… they hid one last trick to bind an abnormal CPU startup with a forced reset from MCPX a few seconds after boot.

Identifying the origin of this final reset, its history within the system, and ultimate disablement could be its own separate blogpost, highlighting that perhaps there are a few mysteries within the Xbox still worth contextualizing.

With Intel JTAG on Xbox now fully functioning, there is less uncertainty in refining this work by eliminating the arduino and likely even the CPU interposer. Over the longer term, this Pentium III JTAG setup provides a good basis for studying the private Intel JTAG instructions as a derivative of this work with broader application.

If you are interested or familiar with bespoke Intel JTAG technologies, please consider contributing (what you can) to the fledgling open knowledgebase being established here on GitHub. This is one of the only modern resources aimed at preserving or documenting x86 JTAG, which proved important in the work described by this post.

Conclusion

This blogpost revisited an old idea that the original Microsoft Xbox could have been hacked through Intel’s x86 CPU JTAG interface. A custom CPU interposer PCB was created to breakout the JTAG signals to a CodeTAP hardware debugger. The secret Xbox bootrom was successfully dumped via Intel JTAG, with real debug capabilities from the very first instruction of execution - closing the chapter on a 20 year old theory.

Hardware CPU debugging can offer unique system introspection over more traditional software and OS-based kernel debugging technologies. These types of hardware solutions used to be highly proprietary and very little public information exists for them, making this a challenging but equally rewarding research experience.