bunnie's adventures hacking the Xbox

Attention: This webpage is moving

bunnie has graduated from MIT, so now he has to do his own web hosting. Please update your bookmarks to http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html This URL will be deactivated within six months.
You should be auto-forwarded in about 2 seconds.

For the benefit of repeat visitors, click here to go to the most recently added stuff.

Other items of interest:

  • hey! I'm finally done with my PhD thesis on supercomputer architecture...I can finally spend some more time playing with the Xbox.
  • socket your flash
  • ROM decryption (deprecated)
  • JTAG pinouts
  • serial EEPROM
  • die shots
  • memory locations in the Xbox (updated)
  • aerogel capacitor and the real time clock
  • hacking and copyrights
  • The real truth about the Xbox game controllers, their engineers and about Halo (humorous)
  • LDT (Hypertransport) bus tap
  • LPC Multi-I/O expansion card (coming soon)
  • ROM testpoint map

    Xbox(TM) is a trademark of Microsoft Corporation

    Socket for your TSOP FLASH (29F080A-70) in the Xbox)

    I figure there are a lot of great software hackers out there going at the xbox to put linux on it (okay so this is written within a week after its intro, so give me a break if this is out of date). I'm more of a hardware-type, so here's my tiny contribution to the effort.

    An interesting anecdote, btw, is that when Microsoft came by MIT to give the X-BOX/recruiting presentation to the students here, we asked the guy (I forget his name, but he was important--I do recall he claimed to help define the DHCP spec :-P) if they had any plans on making it tough to hack the boxes and run linux. They dude looked honestly surprised and it hadn't even crossed his mind. This was about six months or so before the X-BOX launch. There's some commentary at the bottom of this page on the legal aspects of reverse engineering.

    Anyways, something useful during the reverse engineering phase is always having the ability to pull out the BIOS ROM and stick your own in. Except on the X-BOX it ain't socketed. My recommendation is to install an Emulation Technologies S-TS-SM-040-A (if they don't have those in stock, the bigger sockets work too--I put a 48 pin socket on my board 'coz that's what I had on hand tonight). It's a pretty economical device, $12 or so and it goes right in the original footprint on the board.

    This is what the socket looks like when in the "open" position:

    When it's closed, it looks like this:

    You need the following to do this: tongs-style soldering iron (to remove the existing flash device), a fine-tipped soldering iron, a microscope, flux, and some solder paste is always nice, but you can use just plain old fine solder too. If you don't have tongs-style soldering iron, you can just cut the device off the board if you have extras laying around (presumably you also have a ROM burner--I use the Needham's Electronics EMP series) or you can build your own (I built an improved version but I haven't got the docs on the web yet...)

    Be sure to clean and recondition the board after removing the ROM before attaching the socket. Be careful about bridging on the socket pins, too, while soldering. If you have a bridge, some flux and chem-wik will usually take care of it. You also have to recondition the ROM before using it in the ROM burner (this is probably the hardest part). Use a fine-tipped soldering iron to remelt the solder on every pin, and clean the device off with some defluxing agent.

    For those of you looking to get the ROM contents of the Nintendo gamecube, it's not as easy as the Xbox. Their motherboard has no generic FLASH or recognizeable ROM part on it; my current suspicion is that it's part of a multi-chip package (or maybe even integrated into the same die--that's unlikely, though, due to the volatility of ROM code as the console matures). I'm guessing the "ARAM" chip contains the ROM (probably a synchronous interface ROM so it can share a common bus easily with an SDRAM) and the "slow" SDRAM in a combo package...maybe I'll sacrifice a GameCube for the sake of curiosity and dissolve the package with hot sulfuric or better yet try and shave the package down so I can extract the pinout through visual inspection. I also noticed that the same pins that go to the "high-speed expansion port" appear to go straight from the ARAM chip to a connector, so perhaps an o-scope plus a peripheral that plugs into the port will lend clues...if anyone has any info, I'd be curious to hear it.


    I'm just your basic yokel poking at a console...so...caveat hacker... use all the following knowledge at your own risk! Sorry about the formatting. It's pretty much an as-it happens running account of my experiences with the console. More recent stuff is near the bottom.

    A tip for those who are trying to extract the ROM images--there are in fact four identical 256k copies of the ROM image in the 1 MB flash ROM. It threw me off at first, I thought perhaps my top two address pins were stuck, but I re-burned the image I obtained into the ROM (same ROM, no copies were made, ftr ;-) and the Xbox boots just fine. A friend (whose identity I'll keep anonymous) insightfully points out that this is quite a reasonable thing to do for adding robustness to the process of FLASH upgrades in the field, and for keeping multiple versions of the BIOS around in case different games rely on features or even bugs found in previous BIOS versions.

    Another tidbit on the BIOS image is that with winzip compression, the BIOS image (originally 1024k) compresses down to 1004k. This indicates that a large part (but not necessarily all) of the data in the BIOS is either compressed and/or encrypted (executeable binaries usually compress pretty well). It is also my opinion upon cursory inspection of the ROM images that no address/data pins were swapped or scrambled on the ROM.

    A fellow at U Texas (identity kept anonymous) points out to me that MS gave a talk at their university, and the speaker said that they did implement some security measures to foil hackers that try to run a different OS on the Xbox. The speaker mentioned something about desoldering three chips. One is most likely the FLASH. My guess is if this information is true, there is a PIC 16LC63A microcontroller right next door to the FLASH...I wouldn't be surprised if the PIC microcontroller monitors the FLASH to make sure the right sequence of operations happens, and halts the processor if something is amiss. The third chip...well, no guesses on that one yet. Hopefully it's not the nVIDIA MCPX. :-) The speaker at this talk also indicated that the kernel on the Xbox is a much-stripped-down Win2k derivative (from 12 MB to around 23kB). note: it is now known that the PIC does not monitor the FLASH during boot and does little more than coordinate system management activities.

    Early BIOS extraction and disassembly

    There's an issue with the BIOS decryption that we've encountered-- data in the BIOS does not decrypt by just running the code on a conventional machine using the straight Xbox binaries.

    Thanks to Roastbeef for theory (1) and for providing help with disassembly and interpretation of the code.

    The two current theories in progress are:

    1) byte accesses have their data bits scrambled (while DWORD accesses (cache-line fills for code, etc) do not)
    2) some mid-range address bits are scrambled and/or inverted and/or an offset has been applied

    I've gone through the decryption routine of the BIOS finally, and it is a derivative of RC-4. It sets up an S-box similar to RC-4:
    caveat hacker: this code may or may not be correct (but let me know if you do find a bug :-)
    One can tap the LDT bus to find the "proper" code.

      unsigned char K[256]; // 0xFFFFC80 in flash
      unsigned char S[256]; // 0x10000 in SDRAM
      // initialize keys similar to RC-4
      for( i = 0; i < 256; i++ ) {
        S[i] = i;
      j = 0;
      for( i = 0; i < 256; i++ ) {
        j = (j + K[i] + S[j]) % 256;  // RC-4 would do j = (j + K[i] + S[i]) % 256
        // swap S[i], S[j]
        temp = S[i];
        S[i] = S[j];
        S[j] = temp;
    The S-box is a permutation of the numbers 0-255; the key is used to scramble up the order of the numbers. You can check if you did the S-box generation correctly by verifying that every number is in there exactly once.

    Now, RC-4 would then use this S-box to generate random numbers in a manner that evolves with the encryption stream, but is independant of the ciphertext. The x-box version of this evolves the S-box with feedback from the ciphertext:

      unsigned char cipherText[16384]; // 0xFFFFA000 in FLASH
      unsigned char plainText[16384];  // 0x400000   in SDRAM
      for( index = 0x4000, i = 0, k = 0; index > 0; index-- ) {
        // xbox version
        t = (S[i] ^ cipherText[k]) % 256;
        plainText[k] = t;
        // swap( S[i], S[t] );
        temp = S[i];
        S[i] = S[t];
        S[t] = temp;
        i = (i + 1) % 256;
    how is this significant? well,

    1) the above encryption scheme should work okay if data bits are permuted identically on byte reads and writes (S-box integrity is still preserved)
    2) the above scheme should work okay if some of the mid-range address bits are permuted

    The only bits that I know for sure are not permuted are the lower 9 bits (because the code from 0xFFFF FE00 looks good till the end of ROM, and because the copyright signatures at around cf0-d30), and enough high bits to differentiate the major memory regions of the machine. It is quite possible that any number of bits between say, bits 10-20 are swapped around. Now begins speculation: decryption happens in 16k blocks. If you look at the data at 0xFFFFA000, it seems to start and end in the middle of a large region of encrypted code (a histogram of the regions of the ROM indicate what areas might be encrypted or not). That seems a bit odd. Also, the fact that the cipher is a CFB-mode cipher--ie, the key depends on the ciphertext stream--means that any mutation of the data going into the cipher is going to cause the rest of the cipher to yield garbage. Thus, if say, address bit 10 were swapped, then the largest sequential block one could recover from decrypting any region of the ROM without knowledge of the swap is 512 bytes--short enough to be infuriating to try and figure out what data is "the real deal" with dumb stastitical methods. It also seems like whoever wrote the decryption code did it in pure assembly. I doubt any compiler could produce code of that quality and density...perhaps someone was trying to get everything to fit into a 512-byte limit? ;-)

    Things get even more interesting...I tried modifying code in the 0xFFFF FE00 range, and the Xbox seems to ignore it. I even put NOP's over the whole region, and the Xbox still boots-- even when NOP's are in each of the four copies of the ROM's high 512 boot bytes. Something...very...strange...is going on.

    Roastbeef has also provided me with these insights on the PIC:

    1) The PIC is powered all the time that the system is plugged into the wall. Maybe this is where they're keeping the real time clock.
    2) There is an SMBUS connecting the Atmel, PIC and nVidia chipset together. (SMBUS is the Intel equiv. of Philips' I2C bus)
    3) DVD ejection is handled in some way by the PIC. (I didn't actually capture data on this, but when I hit the front panel eject button I saw half the activity indicators on the TLA light up)
    4) There's some type of SMBUS heartbeat every 2ms.
    5) There is no SMBUS or PIC activity in the first second of boot, so none of the decryption stuff can be stored there. (Decryption is probably hit 20k or 30k CPU instructions after power good... that's much much less than the ~1.7sec I'm seeing before SMBUS activity.

    Update on ROM extraction and decryption

    I guess it's been a little while since I've updated this page. (trying to write a thesis has been getting in the way of having fun :-) The thoughts du jour are as follows:
    1) I am certain now that the MCP-X on the Xbox overrides the boot sector in the FLASH ROM (no other conclusion can be drawn from the observed behavior). Hence, the "cleartext" code that we see in the top 512 bytes of FLASH ROM are possibly bogus: the "real" code that the processor runs comes from some mask ROM or OTP ROM inside the MCP-X. Given the level of paranoia that went into designing the Xbox, I am now assuming that the code extracted in the top 512 bytes of ROM are in fact bogus and placed there as a red herring.
    2) I have considered the possibility of decapping the MCP-X and reading out the bits via microscopy. After doing some background research, I think that the MCP-X is done in a TSMC 0.18u or 0.25u process. This is too fine a line geometry for the optical scopes I have available at my disposal, and contacting Chipworks places the price tag of contracting the ROM content removal to be in the $10k range (not to mention copyright issues associated with them taking on the work). (ouch)
    3) A number of people on forums and BBSes have suggested using the JTAG boundary scan to try and capture the decrypted data as it enters the processor, or to stop the clock and somehow read the RAM contents out. I think a method along this vein is most likely the best way to extract the decrypted ROM contents. My thought du jour is to actually hack the LDT bus between the northbridge and southbridge chipsets. It's the smallest pin-count bus (it is 9 bits wide, differential, in each direction), and conveniently, all the traces are right there in one spot on the motherboard: some are even labelled. Plus, LDT is a semi-open standard and the protocol seems to be fairly simple. The challenge is to build a bus tap that doesn't corrupt the data moving at the 400 MHz DDR speeds (!) and capturing at these extremely high data rates. The Xilinx Virtex-II FPGA can actually keep up with these speeds and has an LDT interface capability built into them. The SRAM bus, BTW, uses 2.5V SSTL-2 signalling at about 200 MHz DDR data rates. To tap it, you'd have to hit well over 128 signals, since the data bus alone to the northbridge is 128 bits wide. Tapping the processor bus is similarly annoying: a stock Mobile Celeron uses AGTL I/Os for the northbridge bus, and you have to tap over 100 signals running at 133 MHz. So...off to do some research.

    Correction to the above: an o-scope measurement of the LDT clock indicates that the bus is moving at 200 MHz speeds (that's so slow, it's almost DC!). Count on nVidia and microsoft to do spec inflation by citing the full-duplex bandwidth of the bus. Well...okay, that's fair, everybody does it, I just didn't consider it when doing my math the first time through. I wasn't able to figure out definatively if they were really using both clock edges for the data on the bus because I couldn't conveniently get a good enough ground near the signals I wanted to measure, but if their spec says 800 MBytes/sec, I'd imagine it's using both clock edges. Bottom line: it's much easier than I thought to tap the LDT bus. Yay.

    JTAG pins 'n' stuff

    For the curious and the hardware-minded: the xbox motherboard is a 4-layer board. so most signals ought to be on the outside of the board, and you sholud be able to read it like a book. A Mobile Celeron in BGA2 package is used, although I really didn't find a Mobile Celeron that runs at 733/133 in a BGA2 package... the FSB is always 100 MHz for the BGA2 packaged devices. A mystery... the FCBGA package almost looks nicer to lay out too, it has the same pin pitch as the BGA2 but it has a hollowed out center in which you can stick decoupling caps. Maybe the pinout of the FCBGA just wasn't optimal for the particular layout they were doing (with the Nvidia northbridge on four layers) or the xbox was designed before intel had released the FCBGA specs but microsoft really really wanted a 133 MHz FSB device. Who knows...anyways, you can find a pic of the motherboard without the Celeron on it below. Click on it for a higher res version...the picture on the left is just the Celeron region, the pic on the right calls out the JTAG pins in case you have the toolz...

    I've had a request to trace the JTAG wires out to the nearest convenient holes or resistor pads. The image on the left shows the key JTAG pins broken out to a set of resistors near the processor. Unfortuneately, the TRST# signal is permanently tied to ground, at least on the board I have. I'm not too familiar with the JTAG spec, but this "optional" pin seems to cause the JTAG state machine to go into its reset state. It needs to be pulsed low on power-on, but pulling it permanently low (as it is on the Xbox) should permantently disable the JTAG bus. Perhaps this was intentional? Who knows....but near the JTAG pads I had called out in the left image, on the flip side of the board, there is this mysterious "hole" in a poured polygon plane which looks like someone deleted a test point or via at the last minute...perhaps Microsoft put some thought into making the box more hack-proof than first thought. You can see this "hole" on the right hand side image below. If you would like to use the JTAG bus, you could just drill out the TRST# signal (it's connected directly to an internal ground plane). This would disconnect the TRST# signal from ground; perhaps the JTAG state machine comes up in a recoverable manner upon power up even if TRST# is not pulsed low. ...good luck JTAG hackers...

    Also of note in the above picture to the left (above) is that one pin (so far as I've noticed...I haven't gone through and tracked through every pin!) nominally called out as "no connect" on the celeron pinout is actually connected to something. Note that on the Pentium III, the pin is known as "TESTP". This hints that perhaps the die used in the Xbox is a closer relative to the Pentium III perhaps???? The reason why I speculate on this is that there is no "official" Celeron with a 133 MHz FSB in a BGA2 package according to the Intel website.

    For the record, I have now recovered two FLASH ROM images from two different Xboxes. They are identical. This is significant because there were some theories that each ROM image was uniquely encrypted and/or downloaded into the box by microsoft at burn-in time (some forums have noted that Xbox field service centers plug the boxes into the net and some mysterious data is sent to or from (assumedly) Microsoft). So, at least, there is *some* evidence that the ROMs may all be identical on all the xboxes...

    Die Shots 'n' stuff

    My girlfriend and I spent friday night in the lab together (so romantic--she's cool like that :-) and have now decapsulated three of the chips on the xbox: the southbridge (MCPX-1), the GPU (NV2A), and the Celeron. They all look like...very modern chips (unfortuneately). In other words, the high-level metal power busses criss-cross the entirety of the chip, obscuring most of the otherwise "interseting" features underneath. I don't really feel like removing the passivation and metallization, so I'll leave them as such. I haven't looked too closely yet but I don't see too many candidate regions for the high-level metal (and thus coarse pitch and easier/cheaper for mask iterations in case of code changes) ROM structure that I was hoping for. The overlay ROM that is currently foiling efforts at decrypting/modifying the BIOS ROM is probably buried in the M1 or poly layers of the chip. Ah well...it was fun taking them apart anyways. Next step: tap the LDT bus...going for the minimum path of resistance with maximum enjoyment/fun factor... although tapping the SDRAM busses might be a more direct way of getting to the decrypted code, I really don't feel like soldering hundreds of wires to the board :)

    Die shots, for the curious:

    MCPX full die shot

    MCPX logo

    NV2A logo
    Unfortuneately, I have yet to find any neat easter-eggs on the chips.

    Die stats for the econmically minded:

  • NV2A GPU core: 11.9mm x 11.9mm x 0.18mm (142 mm^2) EDHSBGA, 1mm pitch, 4-layer organic substrate with die-up wirebond, similar to Siliconware Precion Industries Co. package. I believe it is fabricated on a 0.18u TSMC process (a reliable anonymous source has informed me that it's actually made in a 0.15u process), has 60 million transistors...runs at 233 or 250 MHz, depending on whose rumors you wish to believe today. Interpolating off of graphs, one might believe the raw die cost for this chip is around $50 +/- $10; keep in mind nVidia takes a cut when selling to microsoft.
  • MCPX southbridge: 5.4mm x 5.4mm x 0.32mm (29 mm^2), FBGA, 1mm pitch, die-up wirebond. I also believe this is fabricated on a 0.15u TSMC process.
  • Celeron: 8.78mm x 10.97mm x 0.74mm (96 mm^2), Intel BGA2 package, 1.27mm pitch, flip-chip high performance package. This is, of course, fabricated on an Intel process. Not sure which process generation off the top of my head...some rumors say 0.18u / 42 million transistors. The estimated manufacturing cost of a Pentium III in 0.18u / PGA-370 package is $36 (source: MDR). The list price of a mobile celeron-800 is $91, while a Celeron-1000 is $74 (1/2/02--MDR).

    Serial EEPROM

    There is a 256, maybe 128 byte EEPROM on the Xbox which stores, among other things, your serial number, time zone settings, MAC address, and there is some speculation that hard drive keys and encryption keys are stored there as well. The EEPROM is located on the motherboard below the PIC. The EEPROM is a Rhom BR24C02 device (runs on Vcc = 3.3V), and its I2C address code is 0xA8 (that's already shifted left to compensate for the LSB r/w bit, the "real" device code is 0x54). The I2C address was set in part by the address pin straps on the Xbox motherboard. Using an Opencores wishbone-compliant I2C interface by Richard Herveille and my flashburn rev 2 board, I managed to snarf the contents out. (getting the core to compile to my Xilinx Spartan FPGA sucked, btw. Lots of hairy issues with the use of a tristate-buffer with input tied to zero to do wired-OR bus signalling and an overzealous synthesis optimizer :P) I made an ugly little jig for the EEPROM on the back of the fb2 board using a spare "magic" connector I had sitting around. Here's what I got:

    00000000: e31c 5c23 6a58 6837 b712 266c 9911 30d1  ..\#jXh7..&l..0.
    00000010: e23e 4d56 f773 2b73 85fe 7f0a 08ef 153c  .>MV.s+s.......<
    00000020: 77ee 6d4e 932f 28ee f861 f794 171f fc11  w.mN./(..a......
    00000030: 0b84 44ed 3130 3535 3831 3131 3430 3033  ..D.105581114003
    00000040: 0050 f24f 6552 0000 0a1e 3533 7185 314d  .P.OeR....53q.1M
    00000050: 5912 3848 1c91 5360 0001 4000 0000 0000  Y.8H..S`..@.....
    00000060: 7561 57fb 2c01 0000 4553 5400 4544 5400  uaW.,...EST.EDT.
    00000070: 0000 0000 0000 0000 0a05 0002 0401 0002  ................
    00000080: 0000 0000 0000 0000 0000 0000 c4ff ffff  ................
    00000090: 0100 0000 0000 0000 0000 0000 0000 0000  ................
    000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
    000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
    000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
    000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
    000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
    000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

    105581114003 is my Xbox serial number (say hello to big brother--he can track your Xbox wherever you may be!). You can see the "EST" and "EDT" settings as well. I am thinking it's okay to post this (I hope)...I didn't see any copyright notices...

    The ugliness! but it worked. :P

    Aerogel Capacitor

    Did anyone else notice the aerogel capacitor on the Xbox? There is a 1 Farad 2.5V cap on there at location C7G10. What...the heck. When I unplug my xbox for longer than a few minutes, I still have to reset the time. Why not use a battery? It's not like the Xbox is going to outlast the shelf-life of a lithium battery. Maybe I'm wrong, but I thought aerogels are relatively new and expensive...yeah, I'm probably wrong. I've never priced out an aerogel, so mabye they are cheap. But damn, that's the first I've ever seen an aerogel in a consumer electronics product. A brief analysis of the rationale for this capacitor is provided at this forum link.

    Also, there is a resistor that's not populated at R7R4 on the backside of the motherboard. It seems to connect the FLASH ROM's WE line to the MCP. Perhaps by jumpering this you can enable in-system ROM flashing...of course, you'd need to find software that does it first.

    LDT bus tapping

    Well, it's been about three months since I've posted anything significant. Half of that is I've been finishing my PhD thesis, and the other half is that I've been dealing with legal issues versus my work on the Xbox. Well, last week, I finished both my thesis, and I got a grudging thumbs up, so to speak, from Microsoft on my Xbox reverse engineering work. so...here I am, again.

    In late February, I built a device to tap the LDT bus. The LDT bus is the link between the Southbridge MCPX and the Northbridge NV2A chip. The reason why this bus is of interest, as noted above, is because any secret boot code contained in the MCPX would traverse this bus on its way to the processor. And indeed, I did find the secret boot code. I wrote a paper about my findings, which I have submitted to CHES (Cryptographic Hardware in Embedded Systems) 2002 for review and I have also submitted to the AI Lab at MIT as a lab technical memo. Here is the memo, for more details. Here is an alternate link to the paper. Please use the alternate link, the MIT AI publications server turns out to be just an aging UltraSparc 5; I don't think the sysadmins were anticipating this kind of traffic to the pubs server...the alternate link is hosted by MIT's primary web server, a much beefier Sun Fire(tm) 280R. Well, at any rate, we've got a new pubs server on order for the AI lab. :)

    LPC Multi-I/O expansion card

    I am working on an LPC Multi-I/O expansion card, currently out to board fabrication. The card features a FLASH ROM, a 16 Mbit development NVRAM, a real time clock, a 9-pin RS-232 serial port, a PS/2 keyboard port, and a PS/2 mouse port. This card will, if I'm lucky, provide users with the ability to write their own ROMs and code for the Xbox, and only require users to solder on a single 16-pin header.

    Other features that I could add include a floppy drive, parallel port, and another serial port. If you think any of these could be useful for your development work, drop me a line and let me know. However, there may be some issue getting interrupts to work over the LPC header because the type included on the Xbox seems to be the "debug" type instead of the "legacy expansion" type. Once I have tested its basic functions, I will release the schematics board layouts, and bill of materials for free, and perhaps produce a few for people to buy. I will probably step the board at least one more time before releasing it, or possibly producing them with Xenatera Partners. If I do go to production, the boards will be sold strictly as LPC Multi-I/O cards, as they can be used with any PC chipset that supports an LPC header. No code or ROM will ship with the cards--you can probably buy the ROM from someone else if you need it.

    I will post more info as soon as I have it! Stay tuned...

    For those of you who have tried to email me lately, I haven't been responding because I just got back from a vacation in Europe...Ibiza, Barcelona, Amsterdam...lots of fun...in the meantime, it looks like some really good stuff has been coming out of the collective free-lance engineering talent of the world. For example:

  • visor now has a webpage documenting his work. He has a working LPC-FLASH interface. For those of you who don't know, visor is the guy who figured out the jamtable backdoor in the Xbox. Clever guy...
  • Andy has a project called milksop that also looks very successful, he too has a working LPC-FLASH interface. His work is GPL'd, so I'm looking forward to taking a look at it! :-) In addition, his project provides a method for FLASHing the BIOS ROM in-circuit by simply overdriving the signals. mui cool.

    Given these developments, I'm going to focus more on the serial port and keyboard functionality of my multi-I/O LPC card. It's not been a huge priority for me lately though, as I've been short on free time to do hacking :(. Perhaps someone will come out with a Xbox USB port driver that will also make the multi-I/O aspect of the card a moot point as well--actually would be a welcome thing, as I've got too much on my plate these days...

    For more info on the LPC port, check out Andy and Luke's page. These guys are great hackers...

    ROM Testpoints

    Some people have been wondering what the meaning of all the silver dots on the back of the Xbox motherboard is. These dots are testpoints that are used in a "bed of nails" tester to rapidly find faults and test components during Xbox production. As a result, almost every important signal has a silver dot. In particular, the FLASH ROM has test points for all of its signals. You can see where they are in the picture below.

    Important addresses in the Xbox, according to the "boot sector"
    in the FLASH:  (thanks again, Roastbeef!)
    00010000 - S-box
    00400000 - destination of plaintext
    FFF00000 - start of flash
    FFFC0000 - jam tables
    FFFFA000 - beginning of ciphertext (4000h bytes)
    FFFFFC80 - key (256 bytes)
    FFFFFE00 - subroutine to program jam tables
    FFFFFEB4 - subroutine to setup MSRs
    FFFFFFB8 - subroutine to switch to flat mode
    FFFFFFF0 - IA32 boot vector
    Note: the above "important locations" are based on the "decoy" boot block in the FLASH.
    Updated "important locations" according to the "real" code:
    0008F000 - S-box temp storage
    00090000 - destination of plaintext (bootloader code that decrypts/decompresses a larger kernel image from FLASH)
    FFF00000 - start of flash
    FFFC0000 - jam tables
    FFFF9E00 - beginning of ciphertext (6000h bytes / 24 kbytes)
    [code below contained in MCPX, not visible in FLASH]
    FFFFFE00 - subroutine to program jam tables
    FFFFFED2 - turn on the caches
    FFFFFEDD - start of RC4/128 decrypt routine
    FFFFFFA5 - key (16 bytes, RC4/128)
    FFFFFFF0 - IA32 boot vector

    Good luck, and thanks for the comments everyone!

    00000cf0: 0e0e 080b 0e0e 0800 0300 436f 7079 7269  ..........Copyri
    00000d00: 6768 7420 2863 2920 4d69 6372 6f73 6f66  ght (c) Microsof
    00000d10: 7420 436f 7270 6f72 6174 696f 6e2e 2041  t Corporation. A
    00000d20: 6c6c 2072 6967 6874 7320 7265 7365 7276  ll rights reserv
    00000d30: 6564 2e82 04d4 2ebe 341d 57dc d848 fc55  ed......4.W..H.U

    If you are looking for the FLASH ROM contents of the Xbox, you won't be able to download them even though I've extracted them. I got a call [recording edited to protect sensitive info] from Microsoft within 12 hours of posting this page regarding the binaries...I fear...

    However, for those of you who want to extract the FLASH ROM contents of the Xbox for your own purposes, see the case of "Sony Computer Entertainment, Inc. v. Connectix Corp." You are actually allowed by law to reverse engineer copyrighted code so long as it is necessary to discover the ideas or functional elements behind the code (still, I'm not allowed to post copyrighted code for free distribution). Hey, microsoft...what are the ideas and functional elements behind your BIOS ROM? ... hmm...patent search turns up nil on the Xbox...guess we'll just have to reverse engineer it. (FTR, Nintendo has patented what looks to be the entirety of the N64 console, thus perchance making reverse engineering an N64 illegal--not yet court tested.)

    his loving girlfriend

    more game box hacking...

    This page has been accessed at least several times since the counter was last reset, or December 8, 2001 whichever is more recent.