From XenonLibrary
Jump to navigation Jump to search

The boot process of the Xbox 360 contains several bootloaders which are chain-loaded. Each bootloader is responsible for verifying the authenticity of the next bootloader, before loading it into memory and handing control over to it. Once all bootloaders have completed, control is handed to the hypervisor. The status of the boot process can be viewed via post codes.


The 1BL lives in the Secure ROM in the CPU, to ensure it can never be modified. Its primary purpose is to train the FSB interface between the CPU and GPU. Then, it copies the 2BL from flash into the CPU SRAM, verifies it, and jumps to it.


The Waternoose DD2/DD3 and Loki CPUs use the same 1BL. The Vejle CGPU in the Xbox 360 S introduced a modified 1BL due to the changes in the FSB. This 1BL was kept for the Oban CGPU on the Winchester Xbox 360 E.


There are 2 types of 2BLs. Originally it was a single 2BL, before becoming split with the launch of the Xbox 360 S. This was done in order to encrypt the important parts of the 2BL with the CPU Key, which required adding an intermediate bootloader, as the 1BL cannot decrypt this. Split 2BLs were added to the Original Xbox 360 with the 14717 update. Split 2BLs were never used on developer hardware.

Single 2BL

The single 2BL is called the CB for retail images, and the SB for developer images. The 2BL starts by initializing the system hardware and memory controller. On developer systems, it then then copies, decrypts, and verifies the 3BL into SRAM. The next step is to relocate itself from SRAM to system RAM. Lastly it copies, decrypts, verifies, and jumps to the 4BL.

Split 2BL

The split 2BL's bootloaders are called the CB_A and CB_B. The CB_A's purpose is to copy, decrypt, verify, and jump to the CB_B. The CB_B performs the same tasks as the single 2BL.


There is no 3BL on retail systems. On developer images, it is called the SC.


The 4BL is called the CD for retail images, and the SD for developer images. This bootloader is used to decompress the 5BL, which contains the base hypervisor and kernel, into memory. It also checks if there are any patches available in the patch slots. If there are, it jumps to the 6BL of the patchslot with the highest revocation value which will start the process of delta patching the base hypervisor and kernel in memory.


The 5BL is called the CE for retail images, and the SE for developer images. On retail images, this contains the LZX compressed base hypervisor and kernel (2.0.1888).

Patch Slots

Microsoft used delta patches for updating system software. These delta patches were contained in patch slots in the nand file system and were used purely to patch the base kernel and hypervisor in memory with the latest. These patch slots contained two separate bootloaders: CF and CG


The 6BL is called the CF for retail. It loads the 7BL, which contains an LZX compressed delta patch of the latest hypervisor and kernel, and proceeds to decompress and patch the base kernel and hypervisor in memory.


The 7BL is called the CG for retail. It contains the LZX compressed delta patch of the latest hypervisor and kernel.