Microsoft Xbox Roms

Standardized features available to all cores of this emulator: xbox.videomode, xbox.videomode, xbox.bezel, xbox.bezel_stretch, xbox.hud, xbox.hud_corner, xbox.bezel.tattoo, xbox.bezel.tattoo_corner, xbox.bezel.tattoo_file, xbox.bezel.resize_tattoo

If for some reason you aren't able to set the language from your Xbox, you can directly edit the EEPROM settings on the hard-drive image using Ernegien's Original Xbox EEPROM Editor. The EEPROM can be found at /userdata/saves/xbox/xemu_eeprom.bin.

I am unable to get Xemu working with launchbox. It works fine by itself but when I try to run a game through launchbox I get \"Your xbox cant recognize this disc....\" If I then go to Machine then Load Disc it freezes after a screen with the following pops up \"Guest has not initiated the display yet\"

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

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 withdisassembly 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 fillsfor code, etc) do not)2) some mid-range address bits are scrambled and/or inverted and/or an offset has been appliedI've gone through the decryption routine of the BIOSfinally, and it is a derivative of RC-4. It sets upan 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 :-)THIS CODE IS KNOWN TO BE BOGUS, AS THE BOOT SECTOR IN THE FLASH ROM IS BOGUS AND GETS OVERRIDEN BY A BLOCK IN THE MCPXOne 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; thekey is used to scramble up the order of the numbers. Youcan check if you did the S-box generation correctly byverifying that every number is in there exactly once.Now, RC-4 would then use this S-box to generate randomnumbers in a manner that evolves with the encryptionstream, but is independant of the ciphertext. The x-boxversion of this evolves the S-box with feedback fromthe 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; k++; }how is this significant well, 1) the above encryption scheme should work okay ifdata bits are permuted identically on byte reads andwrites (S-box integrity is still preserved)2) the above scheme should work okay if some of the mid-range address bits are permutedThe only bits that I know for sure are not permuted arethe lower 9 bits (because the code from 0xFFFF FE00 looksgood till the end of ROM, and because the copyrightsignatures at around cf0-d30), and enough high bits todifferentiate 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 dataat 0xFFFFA000, it seems to start and end in the middle of a large region of encrypted code (a histogram ofthe regions of the ROM indicate what areas might beencrypted or not). That seems a bit odd. Also, the factthat the cipher is a CFB-mode cipher--ie, the key dependson the ciphertext stream--means that any mutation of thedata going into the cipher is going to cause the rest ofthe cipher to yield garbage. Thus, if say, address bit10 were swapped, then the largest sequential block onecould recover from decrypting any region of the ROM withoutknowledge of the swap is 512 bytes--short enough to beinfuriating to try and figure out what data is \"the realdeal\" with dumb stastitical methods. It also seems likewhoever wrote the decryption code did it in pure assembly.I doubt any compiler could produce code of that quality anddensity...perhaps someone was trying to get everything to fit intoa 512-byte limit ;-)Things get even more interesting...I tried modifying code inthe 0xFFFF FE00 range, and the Xbox seems to ignore it. Ieven 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 thewall. Maybe this is where they're keeping the real time clock.2) There is an SMBUS connecting the Atmel, PIC and nVidia chipsettogether. (SMBUS is the Intel equiv. of Philips' I2C bus)3) DVD ejection is handled in some way by the PIC. (I didn't actuallycapture data on this, but when I hit the front panel eject button I sawhalf 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, sonone of the decryption stuff can be stored there. (Decryption is probablyhit 20k or 30k CPU instructions after power good... that's much much lessthan the 1.7sec I'm seeing before SMBUS activity.Update on ROM extraction and decryptionI 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 sectorin the FLASH ROM (no other conclusion can be drawn from the observedbehavior). Hence, the \"cleartext\" code that we see in the top 512 bytesof FLASH ROM are possibly bogus: the \"real\" code that the processor runscomes from some mask ROM or OTP ROM inside the MCP-X. Given the levelof paranoia that went into designing the Xbox, I am now assuming thatthe code extracted in the top 512 bytes of ROM are in fact bogus andplaced there as a red herring.2) I have considered the possibility of decapping the MCP-X and readingout the bits via microscopy. After doing some background research, Ithink that the MCP-X is done in a TSMC 0.18u or 0.25u process. This istoo fine a line geometry for the optical scopes I have available atmy disposal, and contacting Chipworks places the price tag of contracting the ROM content removal to be inthe $10k range (not to mention copyright issues associated with themtaking 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 asit enters the processor, or to stop the clock and somehow readthe RAM contents out. I think a method along this vein is most likelythe best way to extract the decrypted ROM contents. My thought du jouris to actually hack the LDT bus between the northbridge and southbridgechipsets. It's the smallest pin-count bus (it is 9 bits wide, differential,in each direction), and conveniently, all the tracesare 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 fairlysimple. The challenge is to build a bus tap that doesn't corrupt thedata moving at the 400 MHz DDR speeds (!) and capturing at these extremelyhigh 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 signallingat about 200 MHz DDR data rates. To tap it, you'd have to hit well over128 signals, since the data bus alone to the northbridge is 128 bitswide. Tapping the processor bus is similarly annoying: a stock Mobile Celeron uses AGTL I/Os for the northbridge bus, and you haveto tap over 100 signals running at 133 MHz. So...off to do someresearch.Correction to the above: an o-scope measurement of the LDT clockindicates 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 inflationby citing the full-duplex bandwidth of the bus. Well...okay, that'sfair, everybody does it, I just didn't consider it when doing my maththe first time through. I wasn't able to figure outdefinatively if they were really using both clock edges for thedata on the bus because I couldn't conveniently get a good enoughground near the signals I wanted to measure, but if their spec says800 MBytes/sec, I'd imagine it's using both clock edges. Bottomline: it's much easier than I thought to tap the LDT bus. Yay.

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 reallydidn'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 thesame pin pitch as the BGA2 but it has a hollowed out center in whichyou can stick decoupling caps. Maybe the pinout of the FCBGAjust wasn't optimal for the particular layout they were doing (withthe Nvidia northbridge on four layers) or the xbox was designed beforeintel had released the FCBGA specs but microsoft really really wanted a 133 MHz FSB device. Who knows...anyways, you can find a picof the motherboard without the Celeron on it below. Click on itfor a higher res version...the picture on the left is just theCeleron region, the pic on the right calls out the JTAG pins incase you have the toolz...click for image of pentium regionclick for image of JTAG pins 59ce067264

https://www.theartofconnection.com.au/forum/welcome-to-the-forum/black-shemale-cumshot