Xbox-Scene

Hi @glitchgod Thanks for the feedback. We are currently finalizing the layout for 360 Topics and hope to have them go live shortly.

Thanks for your feedback. We have taken that on board & have purchased Light theme as well. Along with that we have enable an additional background as well that users can choose from. We hope you enjoy your stay & look forwards to your contributions

Rocky5, the dedicated developer behind XBMC-Emustation, has recently unveiled a new test build, version 1.4.007, featuring several important fixes and enhancements. This update addresses various issues reported by the community, promising a more streamlined and improved user experience. Let's take a closer look at the key fixes included in this update: 1) FTP 4GB File Transfer Issue Resolved: One of the prominent issues resolved in this test build is the FTP file transfer problem with 4GB files. Thanks to the collaborative efforts of Team Resurgent and EqUiNoX, users can now transfer large files seamlessly without encountering any hindrances. 2) Fix for Returning to ROM List: A significant bug related to returning to the ROM list has been fixed in this update. Users will now be taken back to the ROM list when exiting a game/rom, enhancing the overall usability of XBMC-Emustation. 3) Homebrew and Ports Menus Issues Rectified: Rocky5 has diligently worked on fixing all the issues associated with the Homebrew and Ports menus. Users can now access the XBE edit mode. 4) Comprehensive Scanning of Xbox Games: An issue related to game scanning has been addressed in this update. Previously, XBMC-Emustation was unable to scan all Xbox games. However, with the introduction of version 1.4.007, the scanning process has been improved, ensuring that all games are properly detected and displayed within the application. 5) Streamlined Backend Enhancements: Additionally, this update includes back-end changes aimed at streamlining the XBMC-Emustation application. These changes optimize the performance and functionality of the software, leading to a more efficient user experience. Users eager to try out the latest improvements can download the test build from within XBMC-Emustation Downloader. It is important to note that test builds may still contain undiscovered bugs, so users are encouraged to provide feedback and report any issues encountered during testing. View full article

Identifying Your Xbox Revision The first step to modding your Xbox is determining which revision you're working with. This chapter from Black Art of Xbox Mods, The should help you to determine which Xbox you're buying, or which one you have if you've already purchased one. Here are the key points covered in this chapter: Revision notes Methods of identification Special/limited edition exceptions This chapter will help you to perform the all-important step of identifying which version of the X Author Xbox-Scene Category OGXbox Modding Submitted 07/16/23 01:47 AM  

This writeup was done by Paul Bartholomew This document will describe the Xbox’s boot process, from RESET vector to KERNEL execution. In the process, the data structures/encodings used by the Xbox will be described. It is not the intent of this document to describe methods of breaking any of the Xbox copy-protection mechanisms. I am a software developer, and respect the rights of copyright holders. Furthermore, there are already several ‘mod chip’ BIOS’s available on the net – someone interested in bypassing copy-protection mechanisms would be using one of them – and would most likely not be interested in the details presented in this document. The primary reason for this document is for the purpose of writing interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA. Xbox boot Flash ROM The standard retail Xbox uses a 1-Megabyte Flash ROM as the boot device. The Flash contains a bootloader (known as ‘bootloader2’ or ‘2bl’) which will decrypt/decompress a KERNEL image (also stored in Flash) and execute it. The KERNEL contains hardware initialization code, and low-level hardware-access functions used by Xbox applications. The Xbox’s MCPX chip decodes the top 16-Megabytes of the CPU’s address space (F0000000-FFFFFFFF) as the boot ROM memory region. Because the Flash chip is only 1-MByte, its contents will “mirror” 16-times throughout this region. The standard retail Xbox’s 1-Mbyte Flash chip actually contains 4 (identical) 256-Kbyte images (we’ll call this image the “Xbox OS image”). So, the same 256-Kbyte image is repeated 64 times throughout the 16-MByte Flash memory region. When making modifications to the Xbox Flash image, it is important to keep in mind that some data structures are accessed relative to the top of the chip, and others from the bottom of the chip (different 256-KByte regions of the 1-MByte Flash). It’s easiest to just start with a 256-KByte image, make your modifications to that, then replicate it throughout the Flash chip. Xbox OS image layout Below is the basic layout of the Xbox OS image: +-------------------+ (top of image) | "Decoy" | | Boot sector | +-------------------+ | Encrypted 2BL | | (bootloader2) | +-------------------+ | KERNEL | | initialized | | data segment | | (not encrypted) | +-------------------+ | | | | | Encrypted / | | compressed KERNEL | | | | | +===================+ | | |Unknown3 - believed| | to be unused | | | +===================+ | MS copyright | +-------------------+ | Unknown2 | +-------------------+ | X-code | +-------------------+ |Unknown1 - believed| | to be MCPX init | +-------------------+ (bottom of image (offset 0)) Using the standard (unmodified) retail Xbox kernel 3944, the locations of these structures within the image are as follows: 000000 Unknown1 – believed to be MCPX init (fixed size = 000080)(B) 000080 X-code (variable size = 000BAC)(B) 000C2C Unknown2 (size = 0000CE)(B) 000CFA MS copyright string (size = 000039)(B) 000D33 Unknown3 – believed to be unused (filled with random values) (size = 005469)(?) 00619C Encrypted/compressed KERNEL (variable size = 0332B0)(T) 03944C KERNEL Initialized data segment (uncompressed/non-encrypted) (variable size = 0009B4)(T) 039E00 Encrypted bootloader2 (2BL) (fixed size = 006000)(T) 03FE00 “Decoy” boot sector (internal MCPX ROM replaces this) (fixed size = 000200)(T) (B) denotes items that are addressed from the ‘bottom’ of the image (offset 0), (T) denotes items that are addressed from the ‘top’ of the image. The Xbox boot process MCPX boot sector functionality At RESET time, it is believed that some hardware chipset initialization is done by the MCPX (by reading some data from the first 000080 bytes of Flash (CPU addresses F0000000-F000007F – based 16-MBytes below top of memory)). Once this is complete, CPU execution begins at the RESET vector (CPU address FFFFFFF0) in the MCPX ‘boot sector’. The MCPX boot sector is a small ROM image that’s ‘hidden’ inside the MCPX chip. It replaces the top 000200-bytes of the address space, overlaying the “Decoy” boot sector in the Flash image. The MCPX boot sector code does some basic hardware initialization/configuration by reading ‘X-codes’ from the X-code area starting at offset 000080 in the Flash (CPU address base FF000080 – note that this is approximately 1-MByte from the top of memory, not the full 16-Mbytes from top that the MCPX chipset allows). X-code processing has been fully documented in other places, so I won’t repeat it here. Once X-code processing is finished, the boot sector code decrypts the ‘bootloader2’ (2BL) image into RAM at CPU addresses 090000-095FFF. A standard RC4 decryption is used, with a 16-byte key stored at CPU address FFFFFFA5-FFFFFFB4 (inside the ‘hidden’ MCPX boot sector). After decryption, it verifies a ‘magic number’ at offset 005FE4 in the decrypted 2BL image is equal to 7854794A. If so, fetches a DWORD stored at CPU address 090000 (offset 000000 into decrpyted 2BL) and jumps to that address. 2BL functionality The 2BL (bootloader2/secondary boot loader) is responsible for decrypting/decompressing the main KERNEL image and ‘jumping’ to it. When 2BL starts, it is executing in a CPU address region from 090000-095FFF. It first sets up some simple page-tables (with what appears to be a one-to-one mapping of virtual to physical addresses), copies itself to CPU address region 400000-405FFF, enables paging, then ‘jumps’ to the copy of 2BL that it created based at 400000. Next, the MCPX internal boot sector is ‘hidden’ (since it is no longer needed), and the PIC ‘watchdog reset’ is disabled (without doing this, the PIC chip will force a CPU reset after approximately 200ms of execution). The original decrypted copy of 2BL at CPU addresses 090000-095FFF is erased. Some unknown initialization of video registers (memory-mapped based at CPU address FD000000) is done next, followed by some unknown PCI initialization. Now for the ‘guts’ of 2BL: validation/decryption/decompression of the KERNEL. The encrypted/compressed KERNEL image is located in Flash, “below” the KERNEL initialized data segment, which is located just “below” the encrypted 2BL (which starts at CPU address FFFF9E00). The size of the compressed KERNEL image is stored at offset 005FD8 into the 2BL, and the size of the KERNEL initialized data segment is stored at offset 005FDC into the 2BL. Using this information, the 2BL can find the start address/size of the encrypted/compressed KERNEL image. First, a SHA-1 hash validation is done on the encrypted KERNEL image. The hash also includes some other items, like the RC4 key used to encrypt/decrypt the KERNEL, the unencrypted KERNEL initialized data segment, and the beginning of the Flash image up-to/including the MS copyright message (MCPX initialization, X-code, etc). The hash is compared against a 20-byte stored digest at offset 005FEC-005FFF into the decrypted 2BL image. Next (assuming SHA-1 has was valid), the KERNEL image is decrypted to a temporary RAM buffer using an RC4 key stored at offset 00008C-00009B into the decrypted 2BL image. Note that this is not the same RC4 key that was used to decrypt the 2BL. The KERNEL image is then decompressed to RAM starting at CPU address 80010000. The compression used for the KERNEL is a modified “.cab” (Microsoft CABinet) compression. See the Microsoft CABinet SDK for more detailed information (http://msdn.microsoft.com/library/en-us/dnsamples/cab-sdk.exe). CAB compression allows for different types of compressions. The compression used for the KERNEL is “tcompTYPE_LZX” (Microsoft LZX). The CFHEADER, CFFOLDER, and CFFILE structures have been eliminated (since it’s a single ‘file’) – only the CFDATA section is used. A slight modification to the CFDATA structure has been made: the 32-bit checksum (“u4 csum”) stored at the start of each block has been eliminated. What remains are “cCFData” blocks of compressed data: each block starts with a 16-bit size of compressed data (“u2 cbData”), 16-bit size of uncompressed data (“u2 cbUncomp”), followed by a stream of “cbData” compressed data bytes. The 2BL knows the value for “cCFDATA” (number of compressed CFDATA blocks) by adding-up the “u2 cbData” values from each CFDATA block header, until the total is equal to the total compressed KERNEL size (found at offset 005FD8 into the 2BL). The decompressed kernel is a PE-format executable (‘xboxkrnl.exe’). Once decompressed, the 2BL grabs the entry point address from the PE header and jumps to it. Two arguments are passed to the kernel entry point function: a pointer to string ‘arguments’ to the KERNEL (only used in debug kernel), and the base address of two 16-byte encryption keys. One of the keys is the EEPROM key (offset 00006C into 2BL), the other is the certificate key (offset 00007C into 2BL). Kernel initialized data segment The KERNEL initialized data segment has been mentioned several times in this document. This is simply a second copy of the section of the uncompressed KERNEL image that contains the initialized variables/etc. When the KERNEL is running, and wants to re-initialize itself, it does a block-copy direct from the Flash KERNEL initialized data section into the corresponding RAM locations, and then zeros-out the BSS section. Keeping this second copy uncompressed/unencrypted in Flash makes it easier/faster for the KERNEL to be able to re-initialized its data segment. Making modifications to the KERNEL It will be useful to be able to make small modifications to the KERNEL. An example would be in the case of trying to understand the Xbox hardware in order to port another OS to it (since the Xbox hardware isn’t fully documented). Adding ‘debug output’ to the KERNEL at key places could help in understanding what certain code is doing. The process for making a KERNEL modification would be: Decrypt 2BL (in order to get KERNEL decrypt key, size, other info) Decrypt/decompress KERNEL Make modifications to decompressed KERNEL image Make modifications to start of Flash image (X-codes, etc) Extract KERNEL initialized data segment from new KERNEL image Compress/encrypt new KERNEL image Re-calculate SHA-1 hash of KERNEL, initialized data segment, start of Flash image (X-codes, etc) Update 2BL with KERNEL info (size, hash, etc) Encrypt modified 2BL Reassemble all the pieces into a new Xbox OS image Important data structure locations Below are all of the locations of data structures needed in order to unpack/re-pack an Xbox OS image. TOP top of memory (CPU address FFFFFFFF)/end of Xbox OS image file MCPX 512-byte ‘hidden’ MCPX boot sector 2BL Decrypted secondary bootloader/bootloader2 KERNEL Decrypted/decompressed KERNEL MCPX+0001A5 16-byte RC4 key to decrypt 2BL (inside ‘hidden’ MCPX ROM image)(NOTE: This key is not easily found, and is a major stumbling block to moving forward) TOP-0061FF Base of encrypted 2BL (size=006000 (24k)) (CPU address FFFF9E00) TOP-0061FF-{nKD} Base of KERNEL initialized data segment (nKD = sizeof(initialized data segment)) TOP-0061FF-{nKD+nKZ} Base of compressed KERNEL image (nKZ = sizeof(compressed KERNEL image)) 2BL+00008C 16-byte RC4 key to decrypt compressed KERNEL image 2BL+005FDC DWORD containing size of KERNEL initialized data segment (nKD) 2BL+005FE0 DWORD containing number of bytes @ start of Flash (X-code/etc) to include in SHA-1 hash 2BL+005FE8 DWORD containing size of compressed KERNEL image (nKZ) 2BL+005FEC 20-byte SHA-1 digest of KERNEL, initialized data segment, Flash start KERNEL+00002C DWORD containing size of KERNEL initialized data segment KERNEL+000030 DWORD containing pointer to base of KERNEL initialized data segment in Flash KERNEL+000034 DWORD containing pointer to where initialized data segment gets copied to in RAM Standard algorithms used The encryption/hashing functions are standard/fairly straightforward, and the code for the algorithms can be found on the net. I won’t try to describe the details here.It is necessary to know the specific use of the SHA-1 hashing functions in order to correctly generate a valid hash on a new image. Below is a code sample showing how this is done: // Initialize hash context // sha1_init(&sha1_ctx); // start with rc4 key used to encrypt KERNEL (@2BL+00008C) // sha1_update(&sha1_ctx, KERNEL_RC4_key, 16); // include size of compressed kernel image, then the compressed kernel // image itself (size is value stored @2BL+005FE8) // sha1_update(&sha1_ctx, (void *)&size_kernelZ_image, 4); sha1_update(&sha1_ctx, p_kernelZ_image, size_kernelZ_image); // include size of kernel initialized data image, then kernel // initialized data image itself (size is value stored // @2BL+005FDC and @KERNEL+00002C) // sha1_update(&sha1_ctx, (void *)&kernel_dataseg_size, 4); sha1_update(&sha1_ctx, p_kernel_dataseg, kernel_dataseg_size); // include size of ROM-header/xcode image, then the image itself // (size is value stored @2BL+005FE0) // sha1_update(&sha1_ctx, size_flash_base_hash, 4); sha1_update(&sha1_ctx, p_flash_base, size_flash_base_hash); sha1_final(sha1_digest, &sha1_ctx); // re-init // sha1_init(&sha1_ctx); // start with rc4 key used to encrypt KERNEL (@2BL+00008C) // sha1_update(&sha1_ctx, KERNEL_RC4_key, 16); // include digest computed above // sha1_update(&sha1_ctx, sha1_digest, sizeof(sha1_digest)); // Compute new digest - this should be stored @2BL+005FEC // sha1_final(sha1_digest, &sha1_ctx); Acknowledgements A large amount of the information in this document was discovered by others, specifically those posting at www.xboxhacker.net forums. I have figured out some of this information myself, assisted others in their research, and put it all together into a single document to make the information more easily accessible. I wouldn’t know how to begin to list/give credit to all of the people involved – and I’d be sure to miss someone. I think that everyone in the Xbox community knows who these people are.

This writeup was done by Matt Borgerson The original Xbox is, to me, an iconic piece of gaming history and I have many fond memories playing its games. It wasn't long after its release however, that its security system was completely broken and unsigned software (e.g. Linux!) was able to run on it. I recently wanted to do a bit of reverse-engineering and so I decided to deconstruct the boot ROM to better understand the Xbox security system. In this article, I will present the high-level boot flow of the system, the disassembled ROM code, pseudocode for the disassembly, along with some thoughts. It should be known that there is essentially no new information presented in this article. The many flaws of the Xbox security system have already been well documented years ago by some really smart people. That said, I am not aware of a similar disassembly of the ROM, so perhaps this article will serve as a guide for others who are interested. Please note that this article does not cover how to dump the ROM image. For clues on how to do that, please see Bunnie's excellent bus tap work or the A20-line hack described in 17 Mistakes Microsoft Made in the Xbox Security System. Legal Disclaimer: This article was written for educational purposes only and is not intended to promote copyright infringement. Sensitive information including the RC4 key and decrypted 2bl signature are redacted. Thanks Before getting into it, I would like to extend a very special thanks the following people and groups who made all of this possible: Bunnie for sharing his excellent work on the Xbox. Michael Steil for his talk at 22C3 and paper, which partly inspired me to do this work. Evan Amos for the great high-resolution Xbox photos you see here. The Xbox Linux Project for their many contributions, including Cromwell. The NASM project for their excellent disassembler, ndisasm. Assumptions I'm assuming that the reader has at least a basic familiarity with PC architecture and the C programming language. Xbox Hardware Before looking at the software, let's take a quick look at the Xbox hardware. Perhaps unsurprisingly, the original Xbox Alpha development systems were essentially PCs. The Xbox that eventually landed on retail shelves carried over much of this PC legacy. Major Components For the time of its release, and for the money it cost to buy one, the original Xbox has fairly impressive specs: Processor: Intel Pentium III "Copermine-based" @ 733 MHz (seen in blue below) Memory: 64 MiB DDR SDRAM @ 200 MHz (seen in green below) Storage: DVD-ROM Drive (above, left), 8 or 10 GB HDD (above, right) Graphics: 233 MHz nVidia NV2A Graphics Controller Networking: 100 MBit Ethernet Source: Wikipedia Some other components relevant to discussion of the bootflow include: Non-Volatile Storage MCPX ROM In addition to its documented features, the MCPX (seen in red above) contains a ROM which stores the very first instructions executed by the processor when the Xbox is switched on. These instructions make up what is called the First-Stage Bootloader. The 512 bytes at addresses 0xfffffe00 through 0xffffffff are connected to the ROM. Reading from these addresses will not read from system memory but instead read from the boot ROM. Flash The Xbox also has a 1 MiB flash memory chip (seen in yellow above) that contains the Second-Stage Bootloader, the Kernel, and the X-codes (more on that in a moment). The 16 MiB from 0xff000000 through 0xffffffff are connected to flash and so reading from this region will read from the flash device. Note that the flash device is actually only 1 MiB in size and repeats throughout the 16 MiB range. A keen observer will notice that the ROM and flash ranges overlap. If enabled, the ROM will take precedence in the overlapping region. Overview of the Xbox Boot Process Now that we have a basic understanding of the hardware, let's look at the overall boot process; that is, what happens from an "off" state to running a game. First-Stage Bootloader Upon system startup (typically called "reset"), the first-stage bootloader is executed. This bootloader will perform basic system initialization, then decrypt and transfer control to the Second-Stage Bootloader. Second-Stage Bootloader The Second-Stage Bootloader (sometimes called "2bl"), will decrypt, decompress, and transfer control to the kernel. Kernel The kernel is always present in system memory and is responsible for managing system resources and providing a hardware-abstraction layer for the dashboard and titles (executables). If there is no disc present in the DVD-ROM drive on the Xbox, the kernel will launch the dashboard (stored on the HDD). If a disc is present, the kernel will launch the title (executable) located on the disc. Dashboard The dashboard is the application that presents the primary user interface for the Xbox. The dashboard also has a music player that can play/rip CDs, a video player that can play DVDs, a storage manager, and a settings manager. Title The Title is the main application, typically a game, on a DVD-ROM disc. First-Stage Bootloader Steps With the high-level boot overview in mind, let's break down the first-stage. These are the major steps, in-order, of the First-Stage Bootloader: Switch to Protected Mode Perform Basic System Initialization (X-codes) Initialize MTRRs Setup Caching Decrypt the Second-Stage Bootloader Jump to the Second-Stage Bootloader Switch to Protected Mode Reset Vector On x86 systems, CPU execution begins at the Reset Vector. The Reset Vector is located at the physical address 0xfffffff0. Translating the Reset Vector to an offset in the ROM yields 0x1f0. This is a good place to begin disassembling the ROM. 000001F0 EBC6 jmp short 0x1b8 The first instruction is a short jump to offset 0x1b8 in the ROM. This offset translates to the physical address 0xffffffb8. Load the GDT/IDT Following the control flow at offset 0x1b8 in the ROM: FFFFFFB8 662E0F0116F4FF o32 lgdt [cs:0xfff4] FFFFFFBF 662E0F011EF4FF o32 lidt [cs:0xfff4] These two instructions first load the Global Descriptor Table (GDT) then the Interrupt Descriptor Table (IDT). The offset specified in each of these instructions is the offset in the physical address space. In the ROM, this offset translates to 0x1f4. 00001f0 eb c6 8b ff 18 00 d8 ff ff ff 80 c2 04 b0 02 ee ^---^ ^---------^ Limit Base Accounting for little-endian encoding, this reveals: Table Base Limit GDT 0xffffffd8 0x0018 IDT 0xffffffd8 0x0018 Now, lets read the table. Located at 0x1d8 in the ROM. 0001d8 00 00 00 00 00 00 00 00 ff ff 00 00 00 9b cf 00 00001e8 ff ff 00 00 00 93 cf 00 ... I will spare you the breakdown and just say that these bytes encode a table which sets up a flat address space model where all 4 GiB of address space is addressed linearly and can be read/written/executed. See the Intel Software Developer Manuals for more information about address space models or how to decode these bytes. Notice that both the GDT and IDT are the same table. While the above encodes a valid GDT, it does not encode a valid IDT. It's unclear why this was done. Switch to Protected Mode Continuing the disassembly, the next few instructions set the Protected Mode Enable flag (bit 0) in CR0, then jump to physical address 0xfffffe00 completing the entry to Protected Mode. FFFFFFC6 0F20C0 mov eax,cr0 FFFFFFC9 0C01 or al,0x1 FFFFFFCB 0F22C0 mov cr0,eax FFFFFFCE 66EA00FEFFFF0800 jmp dword 0x8:0xfffffe00 Now, executing at 0xfffffe00, the Data, Extra, and Stack Segment Registers are loaded. Each Segment Register is loaded with the value 0x10 which is the offset into the GDT of the data segment (which is still 0-4GiB). xor eax,eax FFFFFE02 B010 mov al,0x10 FFFFFE04 8ED8 mov ds,eax FFFFFE06 8EC0 mov es,eax FFFFFE08 8ED0 mov ss,eax Notice that Code Segment Register CS is not loaded here. That is because it is loaded automatically by the far jump into protected mode. Basic System Initialization Because complete system initialization requires significantly more size than the 512 bytes the boot ROM provides, and because the boot ROM cannot be updated in the field, Microsoft devised a clever solution. Instead of putting the instructions to initialize the system in the boot ROM, and instead of simply putting the instructions in flash (which would compromise security), an interpreter was added to the First-Stage Bootloader providing a limited number of operations. This interpreter understands twelve basic commands which are read from flash at 0xff000080 (offset 0x80 in flash). The commands read by the interpreter have been dubbed X-codes. Interestingly, no authentication is performed on the X-codes and they can easily be overwritten by reprogramming the flash device. Knowing this, some precautions were taken in the interpreter to limit exploitability of the interpreter. Interpreter Command Format Each command is 9 bytes in length and has the following encoding: Offset Size (Bytes) Value 0x00 1 Opcode 0x01 4 Operand 1 0x05 4 Operand 2 Start of Interpreter The code of the interpreter begins at offset 0x0a in the ROM, physical address 0xfffffe0a on the system. The first instruction sets up the interpreter command pointer. FFFFFE0A BE800000FF mov esi,0xff000080 Pseudocode: op_ptr = 0xff000080; Note the following register usage convention for the following interpreter assembly code: Register Usage AL Opcode EBX Operand 1 ECX Operand 2 EDI Operation Result ESI Pointer to Current Operation EBP Scratch Register Main Loop Next, the main loop of the interpreter is entered. At the top of the loop, the Opcode, Operand 1, and Operand 2 are loaded into AL, EBX, and ECX, respectively. FFFFFE0F 8A06 mov al,[esi] FFFFFE11 8B5E01 mov ebx,[esi+0x1] FFFFFE14 8B4E05 mov ecx,[esi+0x5] In the loop, the opcode is checked to see which command should be executed, then that command is executed. If the opcode is unknown, it is simply skipped over. At the end of the loop, the operation pointer is incremented and control returns to the top of the loop. FFFFFEB4 83C609 add esi,byte +0x9 FFFFFEB7 E953FFFFFF jmp dword 0xfffffe0f Pseudocode: while (1) { opcode = *op_ptr; operand_1 = *((uint32_t *)(op_ptr+1)); operand_2 = *((uint32_t *)(op_ptr+5)); switch (opcode) { /* ... */ } op_ptr += 9; } What follows in the disassembly are the instructions to detect and execute each command. Opcode 0x07: Chain Command This command allows re-using the result of the last operation as operand 2 to another command specified in operand 1. FFFFFE17 3C07 cmp al,0x7 FFFFFE19 7508 jnz 0xfffffe23 FFFFFE1B 8BD1 mov edx,ecx FFFFFE1D 8AC3 mov al,bl FFFFFE1F 8BDA mov ebx,edx FFFFFE21 8BCF mov ecx,edi Pseudocode (context: before the switch statement above): if (opcode == 0x07) { opcode = operand_1; operand_1 = operand_2; operand_2 = result; } Opcode 0x02: Read from Memory Simply read a double word from memory. The value is stored in the result register. FFFFFE23 3C02 cmp al,0x2 FFFFFE25 750D jnz 0xfffffe34 FFFFFE27 81E3FFFFFF0F and ebx,0xfffffff FFFFFE2D 8B3B mov edi,[ebx] FFFFFE2F E980000000 jmp dword 0xfffffeb4 Pseudocode: case 0x02: result = *(operand_1 & 0x0fffffff); break; Notice here that special care is given by the interpreter to prevent reading from any address above 0x0fffffff (255 MiB). This was likely done to prevent "malicious" X-codes from reading the contents of the boot ROM region directly. Opcode 0x03: Write to Memory Likewise, a command to write to memory is available. FFFFFE34 3C03 cmp al,0x3 FFFFFE36 7504 jnz 0xfffffe3c FFFFFE38 890B mov [ebx],ecx FFFFFE3A EB78 jmp short 0xfffffeb4 Pseudocode: case 0x03: *((uint32_t *)operand_1) = operand_2; break; Opcode 0x06: AND then OR Result Allows modifying the result register directly. Bits can be cleared using the mask in operand 1 and bits can be set with the mask in operand 2. E3C 3C06 cmp al,0x6 FFFFFE3E 7506 jnz 0xfffffe46 FFFFFE40 23FB and edi,ebx FFFFFE42 0BF9 or edi,ecx FFFFFE44 EB6E jmp short 0xfffffeb4 Pseudocode: case 0x06: result = (result & operand_1) | operand_2; break; Opcode 0x04: Write to PCI Configuration Space A command is available that can write to PCI Configuration Space registers. This is useful for device initialization. FFFFFE46 3C04 cmp al,0x4 FFFFFE48 751A jnz 0xfffffe64 FFFFFE4A 81FB80080080 cmp ebx,0x80000880 FFFFFE50 7503 jnz 0xfffffe55 FFFFFE52 83E1FD and ecx,byte -0x3 FFFFFE55 8BC3 mov eax,ebx FFFFFE57 66BAF80C mov dx,0xcf8 FFFFFE5B EF out dx,eax FFFFFE5C 80C204 add dl,0x4 FFFFFE5F 8BC1 mov eax,ecx FFFFFE61 EF out dx,eax FFFFFE62 EB50 jmp short 0xfffffeb4 Pseudocode: case 0x04: if (operand_1 == 0x80000880) { operand_2 &= 0xfffffffd; } outl(operand_1, 0xcf8); outl(operand_2, 0xcfc); break; Notice here that special care is given by the interpreter to the PCI register at address 0x80000880 (0xcf8 index mechanism), preventing the setting of bit 1 of PCI Bus 0 Device 1 Function 0 Register 0x80. It was discovered (not by me) that this bit would "turn the ROM off" or otherwise disable address decoding to the ROM whenever set. Of course, working around this limitation is trivial. This bit could very easily be set by using opcode 0x11 (Write to I/O) to write to 0xcf8/0xcfc directly. Indeed this is known as the "MIST" hack. Opcode 0x05: Read from PCI Configuration Space Likewise, there is a command to read from PCI Configuration Space. FFFFFE64 3C05 cmp al,0x5 FFFFFE66 750F jnz 0xfffffe77 FFFFFE68 8BC3 mov eax,ebx FFFFFE6A 66BAF80C mov dx,0xcf8 FFFFFE6E EF out dx,eax FFFFFE6F 80C204 add dl,0x4 FFFFFE72 ED in eax,dx FFFFFE73 8BF8 mov edi,eax FFFFFE75 EB3D jmp short 0xfffffeb4 Pseudocode: case 0x05: outl(operand_1, 0xcf8); result = inl(0xcfc); break; Opcode 0x08: Branch (JNE) A simple branch mechanism that allows optionally modifying the command pointer by adding the value in operand 2 if the value in operand 1 matches the current result value. FFFFFE77 3C08 cmp al,0x8 FFFFFE79 7508 jnz 0xfffffe83 FFFFFE7B 3BFB cmp edi,ebx FFFFFE7D 7435 jz 0xfffffeb4 FFFFFE7F 03F1 add esi,ecx FFFFFE81 EB31 jmp short 0xfffffeb4 Pseudocode: case 0x08: if (result != operand_1) { op_ptr += operand_2; } break; Opcode 0x09: Jump A simple jump mechanism that allows modifying the command pointer by adding the value in operand 2. FFFFFE83 3C09 cmp al,0x9 FFFFFE85 7504 jnz 0xfffffe8b FFFFFE87 03F1 add esi,ecx FFFFFE89 EB29 jmp short 0xfffffeb4 Pseudocode: case 0x09: op_ptr += operand_2; break; Opcode 0x10: Read/Write Scratch Register The interpreter allows for modifying a very small scratch pad using this one command. Bits can be cleared using the mask in operand 1 and bits can be set with the mask in operand 2. FFFFFE8B 3C10 cmp al,0x10 FFFFFE8D 7508 jnz 0xfffffe97 FFFFFE8F 23EB and ebp,ebx FFFFFE91 0BE9 or ebp,ecx FFFFFE93 8BFD mov edi,ebp FFFFFE95 EB1D jmp short 0xfffffeb4 Pseudocode: case 0x10: scratch = (scratch & operand_1) | operand_2; result = scratch; break; Opcode 0x11: Write to I/O Port A command to write to an I/O port. FFFFFE97 3C11 cmp al,0x11 FFFFFE99 7507 jnz 0xfffffea2 FFFFFE9B 8BD3 mov edx,ebx FFFFFE9D 8BC1 mov eax,ecx FFFFFE9F EE out dx,al FFFFFEA0 EB12 jmp short 0xfffffeb4 Pseudocode: case 0x11: outb(operand_2, operand_1); break; Opcode 0x12: Read from I/O Port Likewise, a command to read from an I/O port. FFFFFEA2 3C12 cmp al,0x12 FFFFFEA4 7508 jnz 0xfffffeae FFFFFEA6 8BD3 mov edx,ebx FFFFFEA8 EC in al,dx FFFFFEA9 0FB6F8 movzx edi,al FFFFFEAC EB06 jmp short 0xfffffeb4 Pseudocode: case 0x12: result = inb(operand_1); break; Opcode 0xEE: Exit Interpreter When executed, the interpreter stops processing and jumps to 0xfffffebc. FFFFFEAE 3CEE cmp al,0xee FFFFFEB0 7502 jnz 0xfffffeb4 FFFFFEB2 EB08 jmp short 0xfffffebc Pseudocode: case 0xee: goto enable_caching; Undefined Opcodes Opcodes 0x00, 0x01, 0x0A-0x0F, 0x13-0xED, and 0xEF-0xFF are undefined and will be ignored by the interpreter. Pseudocode: default: break; Summary of Opcodes Opcode Operation Argument 1 Argument 2 0x02 Read Memory Address N/A 0x03 Write Memory Address Value 0x04 Write PCI Config Space Address Value 0x05 Read PCI Config Space Address N/A 0x06 AND then OR AND Bitmask OR Bitmask 0x07 Chain Command Next OP Next Arg 1 0x08 Branch (JNE) Condition Offset 0x09 Jump N/A Offset 0x10 Read/Write Scratch Reg AND Bitmask OR Bitmask 0x11 Write IO 16-Bit Port 8-Bit Value 0x12 Read IO 16-Bit Port N/A 0xEE Exit Interpreter N/A N/A Initialize MTRRs Clear Variable MTRRs (MSR 0x200-0x20F) Referencing the Intel Software Developer Manuals Chapter System Programming Guide Chapter 35.1, MSRs 0x200-0x20F are the Variable MTRR Mask/Base 0 through 7. FFFFEBC 33C9 xor ecx,ecx FFFFFEBE B502 mov ch,0x2 FFFFFEC0 33C0 xor eax,eax FFFFFEC2 33D2 xor edx,edx FFFFFEC4 0F30 wrmsr FFFFFEC6 41 inc ecx FFFFFEC7 80F90F cmp cl,0xf FFFFFECA 76F8 jna 0xfffffec Set Default MTRR Type (MSR 0x2FF) FFFFFECC B1FF mov cl,0xff FFFFFECE 8BC3 mov eax,ebx FFFFFED0 0F30 wrmsr Notice here that EBX is not being set before writing to the MSR. It is left over from the last operand 1 of X-code processing. This has the flexibility of letting the X-codes decide what the default type of caching is. I'm not sure yet if this was the intended behavior. Enable Caching From the Intel Software Developer Manuals: If the NW and CD flags are clear, write-back is enabled for the whole of system memory, but may be restricted for individual pages or regions of memory by other cache-control mechanisms. Clear CD flag (bit 30) and NW flag (bit 29) of CR0. FFFFFED2 0F20C0 mov eax,cr0 FFFFFED5 25FFFFFF9F and eax,0x9fffffff FFFFFEDA 0F22C0 mov cr0,eax Load the Second-Stage Bootloader After the X-code interpreter has finished running and caching has been enabled, the Second-Stage Bootloader is read from flash then decrypted and saved into memory using the RC4 stream cipher. RC4 Key-Scheduling Algorithm (KSA) The RC4 Key-Scheduling Algorithm is used to initialize the RC4 "S" array. Register Usage EAX Scratch Register ECX S Iterator (i) EDX S Cursor ESI S Pointer (0x8f000) FFFFFEDD B800010203 mov eax,0x3020100 FFFFFEE2 B940000000 mov ecx,0x40 FFFFFEE7 BE00F00800 mov esi,0x8f000 FFFFFEEC 8BD6 mov edx,esi FFFFFEEE 8902 mov [edx],eax FFFFFEF0 83C204 add edx,byte +0x4 FFFFFEF3 0504040404 add eax,0x4040404 FFFFFEF8 49 dec ecx FFFFFEF9 75F3 jnz 0xfffffeee Pseudocode: uint8_t *s = (uint8_t *)0x8f000; uint32_t i; for (i = 0; i <= 255; i++) { s[i] = i; } It may not be immediately obvious, but the assembly code is optimized to write double words instead of writing each byte. Register Usage: Register Usage EBP Key Pointer (0xffffffa5) ECX Key Iterator (i % keylength) ESI S Pointer (0x8f000) EDI S Iterator (i) EBX j EAX Scratch Register EDX Scratch Register FFFFFEFB 33C9 xor ecx,ecx FFFFFEFD 33FF xor edi,edi FFFFFEFF BDA5FFFFFF mov ebp,0xffffffa5 FFFFFF04 888E00010000 mov [esi+0x100],cl FFFFFF0A 888E01010000 mov [esi+0x101],cl FFFFFF10 33DB xor ebx,ebx FFFFFF12 33D2 xor edx,edx FFFFFF14 33C0 xor eax,eax FFFFFF16 8A1437 mov dl,[edi+esi] FFFFFF19 8A440D00 mov al,[ebp+ecx+0x0] FFFFFF1D 02D8 add bl,al FFFFFF1F 41 inc ecx FFFFFF20 02DA add bl,dl FFFFFF22 47 inc edi FFFFFF23 8A0433 mov al,[ebx+esi] FFFFFF26 884437FF mov [edi+esi-0x1],al FFFFFF2A 83F910 cmp ecx,byte +0x10 FFFFFF2D 881433 mov [ebx+esi],dl FFFFFF30 7502 jnz 0xffffff34 FFFFFF32 33C9 xor ecx,ecx FFFFFF34 81FF00010000 cmp edi,0x100 FFFFFF3A 72D6 jc 0xffffff12 Pseudocode: uint8_t *key = (uint8_t *)0xffffffa5; /* ROM offset 0x1a5. */ uint8_t j, t; /* It is unclear why values s[0x100..0x101] are being set to 0. They are * not modified by the code, but later these will be be used as the initial * i, j values in the PRGA. */ s[0x100] = 0x00; s[0x101] = 0x00; for (i = 0, j = 0; i <= 255; i++) { j = j + s[i] + key[i%16]; /* Swap s[i] and s[j] */ t = s[i]; s[i] = s[j]; s[j] = t; } Pseudo-Random Generation Algorithm (PRGA) Register Usage: Register Usage EAX Scratch EBP Remaining Length of Message (0x6000) EDI Message Iterator ESI S Pointer (0x8f000) ECX i EDX j FFFFFF3C 33C9 xor ecx,ecx FFFFFF3E 33D2 xor edx,edx FFFFFF40 33FF xor edi,edi FFFFFF42 33C0 xor eax,eax FFFFFF44 BE00F00800 mov esi,0x8f000 FFFFFF49 BD00600000 mov ebp,0x6000 FFFFFF4E 8A8E00010000 mov cl,[esi+0x100] FFFFFF54 8A9601010000 mov dl,[esi+0x101] FFFFFF5A FEC1 inc cl FFFFFF5C 8A040E mov al,[esi+ecx] FFFFFF5F 02D0 add dl,al FFFFFF61 8A1C16 mov bl,[esi+edx] FFFFFF64 881C0E mov [esi+ecx],bl FFFFFF67 880416 mov [esi+edx],al FFFFFF6A 02C3 add al,bl FFFFFF6C 8A9F009EFFFF mov bl,[edi-0x6200] FFFFFF72 8A0406 mov al,[esi+eax] FFFFFF75 32D8 xor bl,al FFFFFF77 889F00000900 mov [edi+0x90000],bl FFFFFF7D 47 inc edi FFFFFF7E 4D dec ebp FFFFFF7F 75D9 jnz 0xffffff5a Pseudocode: uint8_t *encrypted = (uint8_t*)0xFFFF9E00; /* 2bl */ uint8_t *decrypted = (uint8_t*)0x90000; /* Decrypted 2bl Destination */ uint32_t pos; /* As noted above, s[0x100..0x101] were set to 0 earlier, but have not been * modified since. The RC4 algorithm defines i and j both to be set to 0 * before PRGA begins. */ i = s[0x100]; j = s[0x101]; for (pos = 0; pos < 0x6000; pos++) { /* Update i, j. */ i = (i + 1) & 0xff; j += s[i]; /* Swap s[i] and s[j]. */ t = s[i]; s[i] = s[j]; s[j] = t; /* Decrypt message and write output. */ decrypted[pos] = encrypted[pos] ^ s[ s[i] + s[j] ]; } Check Signature Now that the Second-Stage Bootloader has been loaded, a quick sanity-check is performed: a "magic" signature is verified. If the signature doesn't match, control goes to the error handler (see below). (Signature redacted.) FFFFFF81 A1E45F0900 mov eax,[0x95fe4] FFFFFF86 3D________ cmp eax,0x________ FFFFFF8B 7507 jnz 0xffffff94 Pseudocode: if (*((uint32_t *) 0x95fe4) != MAGIC_SIGNATURE) { goto error_handler; } Otherwise, control goes to the 2bl entry point. The entry point address is located at the start of the decrypted 2bl code in memory at 0x90000: FFFFFF8D A100000900 mov eax,[0x90000] FFFFFF92 FFE0 jmp eax Error Handler FFFFFF94 B880080080 mov eax,0x80000880 FFFFFF99 66BAF80C mov dx,0xcf8 FFFFFF9D EF out dx,eax FFFFFF9E EAFAFFFFFF0800 jmp dword 0x8:0xfffffffa ... FFFFFFFA 80C204 add dl,0x4 FFFFFFFD B002 mov al,0x2 FFFFFFFF EE out dx,al Notice that the PCI Configuration Space register at Bus 0, Device 1, Function 0, Register 0x80 is again given special care: the bit that was not supposed to set with the 0x04 opcode is now being set in the error condition. Setting this bit in the error condition was presumably done to prevent reading the ROM in case of an error. Cleverly, this error handler is split across the ROM such that the last instruction is located at the highest-most address. When EIP rolls over to 0x00000000 it is then expected that the CPU halt. This is the behavior on AMD processors but, on Intel processors that shipped with the Xbox, execution happily continues at 0x00000000. Observing this behavior, it would be possible to replace some existing Xcodes with ones that program new x86 instructions and then intentionally cause the 2bl to fail the signature check. The system will eventually begin executing the modified code. Indeed, this is known as the "Visor" hack, after the person who discovered it. End So that is how the Xbox Boot ROM works. It's not very complicated, but it was fun to deconstruct. This article only briefly touched on a couple of the vulnerabilities of the Xbox. For a much more in-depth security analysis, please refer to Michael Steil's 17 Mistakes Microsoft Made in the Xbox Security System.

LED Error Codes 1.0 Xbox systems never display error codes in their video output, but they do have LED error codes. Any Xbox may experience issues that cause them to not output video. In these cases, look at the LED around the eject button to determine possible problems and solutions. An LED code described with percentages next to each color indicates how long each color is on. For example, "Flashing Red 75% and Green 25%" means that red stays on for 75% of the time, and green is on for the remaining 25% of the time. Note that modified consoles may have a custom LED color set. So, if the console is working normally, then a non-green light should not be interpreted as an error code. LED Code Reason Solution Solid Green (Coma Console) Corrupt BIOS bank or unseated video cable. Try another video cable. If 1.0 or 1.1 motherboard, solder A18 and/or A19 to ground. If all else fails, install a modchip. Solid Red Bad EEPROM or improper modchip install. Flash EEPROM or install modchip. Flashing Green Bad EEPROM. Flash EEPROM or install modchip. Flashing Orange Damaged trace or solder splashed on components. Try cleaning the inside of your Xbox and inspect the motherboard to find the issue. Flashing Red Bad EEPROM. Flash EEPROM or install modchip. Flashing Orange, fan speed increases to 100%, console eventually turns off Overheating, or there may be an issue near the temperature sensor chip at location U6F1. Verify that fans are working. Replace the old thermal paste under the CPU and GPU heatsinks. Clean and inspect the temperature sensor. Flashing Orange 50% and Green 50% Missing or broken video cable. Try reseating or replacing the video cable. May be bad video hardware. Flashing Red 50% and Orange 50% General system failure. Often caused by an improper modchip install. May indicate a RAM error. Try cleaning the inside of your Xbox and inspect the motherboard to find the issue. Flashing Red 50% and Green 50% (FRAG) General system failure. Often caused by an improper modchip install. Try cleaning the inside of your Xbox and inspect the motherboard to find the issue. Clock capacitor may be leaking. Flashing Red 75% and Green 25% (FRAG) HDD error. See error codes 5, 6, 7, 8, and 9. Flashing Red 25% and Green 75% (FRAG) DVD error. See error codes 10, 11, and 12. Tries to Boot 3x then FRAG (Christmas Lights) Usually due to a failed or improperly installed modchip or the IDE cable being plugged in upside down somewhere. Check modchip wiring and IDE cables. If you did not do any soldering, it could be a bad PSU. Tries to Boot 3x then FRAG (Christmas Lights) and Turns Off Corrupt EEPROM. Usually wrong EEPROM version flashed to Xbox. Also can be caused by wiping the EEPROM or not hashing it properly. Other Likely bad EEPROM. Likely need to flash EEPROM or install modchip. Error Code 01 Problem: General motherboard issue. Cause/Solution: Cause is unknown; it is recommended to replace the motherboard. Error Code 02 Problem: EEPROM check failed. This error is triggered by the bootloader and as a result does not display an error code on screen. You will see the Xbox rebooting and flashing red and green lights (FRAG). Cause/Solution: You flashed something wrong or caused a short somewhere on your motherboard (possibly while soldering). If you’re using a modchip and you just flashed it, try again using a different BIOS. If you recently did some soldering to your Xbox, check for any stray solder balls that may be present and carefully remove them. Error Code 03 Problem: General motherboard issue. Cause/Solution: Cause is unknown; it is recommended to replace the motherboard. Error Code 04 Problem: RAM check failed. This error is triggered by the bootloader and as a result does not display an error code on screen. You will see the Xbox rebooting and flashing red and green lights (FRAG). Cause/Solution: RAM chip failure. This could be from pins on the RAM chip(s) becoming bridged, possibly from an accidental splash of solder or a failed 128MB RAM upgrade. Remember, electrostatic shock can sometimes damage integrated circuit chips like RAM chips, so even if you can’t see a problem, the RAM could still be fried. Replacing the RAM chips could be a solution but is risky and time consuming. Error Code 05 Problem: Hard disk drive (HDD) not locked. Cause/Solution: If you have not replaced your Xbox’s BIOS via a modchip/TSOP flash, then your HDD needs to be locked using a special password that is generated based on your Xbox’s EEPROM, which is unique per each individual Xbox. Microsoft designed it this way to prevent people from being able to plug the drive into a computer and have access to its contents and thus hacking it. Virtually all non-retail BIOSes (including modchip/TSOP) will not require the hard drive to be locked in order to start. If you’re seeing this error on a non-retail BIOS, then chances are your modchip/TSOP flash process had issues and for some reason you are now using a stock BIOS which is now requiring a password-locked hard drive again. If you’re seeing this error and your Xbox has been softmodded (through gamesave/font/audio exploits), then you just need to lock your drive again. Hopefully you have your EEPROM backed up at this point because if not, things get a lot more complicated. If you unlocked your HDD on the Xbox itself (using ConfigMagic for example), chances are the app you used made a backup of your EEPROM for you and it’s now sitting on your E: drive called "eeprom.bin" or something similar. You can plug the HDD into a computer at this point and use an Xbox hard drive explorer program like "Xplorer360" (Windows only) to view its files to copy your EEPROM backup. There are multiple ways to lock a HDD, one of which is by using XboxHDM by author ldotsfan. XboxHDM runs on a PC and one of its features is the ability to lock hard drives if you have an EEPROM backup. Choose option "3" from XboxHDM and follow the on-screen instructions to lock the HDD. Error Code 06 Problem: Incorrect hard drive password. Cause/Solution: The hard disk drive (HDD) is locked but it is locked with a password that belongs to a different Xbox. You will need to unlock the HDD and then re-lock it using the correct password. As stated above, each Xbox is locked using a password that is generated based on each Xbox’s unique EEPROM. Assuming you have the EEPROM of your Xbox backed up, you will just need to unlock the drive and re-lock it using your EEPROM backup. See the solution for Error Code 05 for more info. Error Code 07 Problem: Hard drive timeout / HDD took too long to become ready. Cause/Solution: The Xbox seems to know the HDD is present but it times-out waiting for the drive to become ready and respond to commands. This is probably due to a loose connection or faulty wire. See the solution for Error Code 08. If you’re using a SATA to IDE adapter, it’s possible that the adapter you’re using is not compatible with the drive you’re using or isn’t compatible with the Xbox at all. Try another SATA to IDE adapter / HDD combination. Some "green" drives are temperamental with certain SATA adapters. This error may also be caused if you have a SATA to IDE adapter and you are not using an 80 wire IDE cable (by default, they are 40 wire cables). Or, the console’s DVD drive is bad preventing access to the hard drive via the IDE bus. Swap the DVD drive with one from a different Xbox. They are all interchangeable. Error Code 08 Problem: No hard drive found. Cause/Solution: The Xbox can’t find the hard disk drive (HDD) while booting up. Try the following: If you are using a SATA to IDE adapter, you will need an 80 wire IDE cable. By default, it will be a 40 wire cable. Make sure the IDE ribbon cable (flat grey cable) is securely connected to the HDD, the DVD drive, and the motherboard itself. Check the IDE cable for signs of damage. If the cable looks like it has been scraped or has evidence of any damage then replace it. Check the HDD’s power cable and make sure it’s securely plugged in. If you can wiggle the HDD power cable around and make the Xbox work at certain times, then the leads coming from the power supply are loose and the power supply should be replaced. Take the HDD out and make sure the jumper is set correctly. There should be a diagram printed on the drive’s label that shows how the jumper should be connected. Make sure its set to Cable Select (CS), Master, or isn’t present at all. If the drive is set to Slave then you will run into issues! If all other cables are in fact securely connected and not damaged, you can try replacing the IDE cable anyway. It’s possible that it is damaged in a way that isn’t visible and IDE cables are cheap to come by. If all else fails, your hard drive is probably to blame and is faulty and needs to be replaced. Error Code 09 Problem: Hard drive parameters are missing or incorrect. Cause/Solution: Very uncommon error. The hard drive power cable may be unplugged, it might be in the wrong transfer mode (PIO/DMA), or the jumper is set to slave instead of master. If it’s a debug console, the size may be incorrect (minimum size is required for debug). Replace the hard drive otherwise. Error Code 10 Problem: DVD drive timeout. Cause/Solution: Similar to error codes 07 and 08, this is usually caused by a loose/faulty cable. The Xbox seems to know the DVD drive is present but it times-out waiting for the drive to become ready and respond to commands. Check the yellow cable running from the motherboard to the DVD drive. If all else fails, replace the DVD drive. Error Code 11 Problem: No DVD drive found. Cause/Solution: The Xbox cannot find the DVD drive. Similar to Error Code 10, this is usually from a loose/faulty cable. See solutions for Error Code 10. Note that many non-retail BIOSes can be configured to skip using a DVD drive entirely. Error Code 12 Problem: DVD drive parameters are missing or incorrect. Cause/Solution: This is an uncommon error. Try solutions for Error Code 10. Error Code 13 Problem: Dashboard failed to launch due to missing/bad key, or anything else that would prevent it from running and the dashboard didn’t specify why it failed. Cause/Solution: This can be caused by a kernel version issue but is a lot less common in recent years. Make sure you’re running the latest kernel. If you’re using a softmod, make sure your dashboard and softmod files are installed correctly. It is recommended to use JCRocky5’s Xbox Softmodding Tool as your softmod installer, if you’re using something else currently. If you are receiving this error only when launching games, try deleting E:, if it exists. Error Code 14 Problem: Dashboard failed to launch (generic error). Cause/Solution: Similar to Error Code 13. This can also result from changing names of files or messing with files on the HDD without knowing the repercussions. A common cause is from changing the boot orders or names of startup files on the HDD. It can also happen when you are rebuilding your HDD with a Slayer CD and the power was cut, or if your DVD drive is going bad when attempting to load a disc that uses PBL, such as Hexen. Error Code 16 Problem: Internal clock cannot be set. Cause/Solution: This happens when the Xbox tries to boot to the stock dashboard in order to have you set the current date/time. but fails to load the menu. This happens if you: Just replaced the HDD and are missing your clock capacitor or left your Xbox unplugged for a few hours. Erased the Microsoft dashboard files (which contain the clock setting) and are missing your clock capacitor or left your Xbox unplugged for a few hours. Have a revision 1.6 Xbox and an old (before 2004) BIOS installed without a clock loop patch and are missing your clock capacitor. Try starting the Xbox with the Eject button instead of the power button in case it has a dual-boot configuration. If that fails, but you do have a modchip installed, boot into AID or Slayers and try installing the stock dashboard back on your HDD’s C: partition. You can also hotswap your HDD with another Xbox to reinstall the Microsoft dashboard. After the Xbox boots up and is able to set the clock successfully, update your BIOS or softmod to a more recent version to avoid this in the future. Error Code 20 Problem: Dashboard failed to launch. Cause/Solution: It was a cold boot, and the dashboard didn’t specify why it failed, but it needed to be noted that the DVD passed the challenge/response authentication during boot. Error Code 21 Problem: Unspecific/generic error. Cause/Solution: The Xbox was instructed (possibly by an XBE you launched) to reboot the Xbox and display this error. This occurs frequently when the Xbox is unable to boot due to dashboard changes being made (i.e. an XBE hasn’t been signed correctly or parts of the stock dashboard are missing). Also, if you’re using XbeShortcutMaker and seeing this error code then you might try regenerating the shortcut XBE file as it could be corrupted. If you are receiving this error only when launching games, try deleting E:if it exists. If you are trying to softmod, it may be a bad USB device. In very rare cases, a failing clock capacitor on 1.0-1.5 Xboxes may cause this issue, so removing it would be a wise path to explore as it is also a great risk to the health of your Xbox. Information provided by Consolemods.org

Cant miss out this classic...