MCPX and bootloader - JayFoxRox/xqemu-jfr GitHub Wiki

The xbox boot process

Read about it here: http://hackspot.net/XboxBlog/?p=1 Basicly execution flow is:

  • MCPX -> (Preloader -> Bootloader) -> XBOXKRNL.EXE

  • I consider the Preloader to be part of the Bootloader which has been deemed 2BL by the community

  • MCPX contains secret key to decrypt 2BL (xbox_preloader_key)

  • Preloader decrypts the 2BL and hashes it (xbox_bootloader_key)

  • 2BL contains secret key to decrypt and run XBOXKRNL.EXE (xbox_kernel_key)

    • 2BL also passes some keys to XBOXKRNL.EXE (xbox_kernel_keys)

Problem: Dumping the actual MCPX

Dumping the actual MCPX in software is still not possible. The 2BL is only in memory before the xboxkrnl.exe has been initialized. So homebrew is not able to dump it as it's encrypted with a key only to be found in the MCPX and (sometimes?) the 2BL itself. So if xbox owners want to use xqemu they should first create a private dump of their xbox code and use our custom HLE.

More MCPX documentation

The X3 has a 512-byte x86 boot ROM that overlays FFFFFE00-FFFFFFFF in x86 space. It contains the secret boot code used as the seed of trust for the Xbox boot sequence.

The X2 doesn't have that boot ROM. As a result, X2 systems boot directly from the flash's high 512 bytes.

I don't know of any other differences. After all, debug kernels work fine on a retail Xbox once you get past the MCPX ROM protection. Retail systems can even be upgraded to 128 MB.

I don't know the difference between "MCP X2" and "MCPX X2". Maybe "MCPX X2" actually has a 512-byte boot ROM for debug kits?

(https://www.assemblergames.com/threads/what-is-the-diference-between-the-mcpx-chips-big-images.41069/#post-608854)

Versions:

  • Rumored
    • MCP X2 = External ROM [Speculation: MCP should be the PC component but only an X0 should be a PC MCPX?]
    • MCP X-MODE 2 = External ROM [Speculation: X-MODE# and X# should also be the same]
  • Confirmed
    • MCPX X2 = External ROM
      • Proof: Photos on assemblergames
    • MCPX X3 = Internal ROM
      • Proof: Photos on assemblergames

Therefore:

  • X2 uses the interpreter from flash
  • X3 uses the internal interpreter (different commandset)

So if Microsoft wanted it they could also have an X2, Revision C3. Even though they mostly produced retails at that point this still could have happened.

X-Code version also reported by NV2A init vector (Always 0xFF000000) ?

  • +0x00
    • [31:1] Pointer to NV2A Init vector[31:1]
    • [0] 1=Boot from XBus; 0=Boot from LPC
  • +0x01
    • [31:1] Pointer to NV2A Init vector[31:1]
    • [0] Unused? Always zero?

NV2A init vector (Normally 0xFF000008)

  • +0x00
    • [31:0] Always 0x2B16D065 (Little endian) - Magic!?!

Solution: MCPX / 2BL HLE

Here is what the HLE has to do:

  • MCPX stuff (bootrom-mcpx-hle.c)
    • Switch to 32 bit mode and use GDT from MCPX rom
    • Run X-code [0xFF000080]
    • Setup MTRR with EXIT OP1
    • IF RC4 Key given THEN
      • Extract 2bl from flash if an RC4 key is given
    • ELSE
      • Go to 2bl HLE
  • 2BL stuff (Original 2BL also does memtest) [bootrom-2bl-hle.c]
    • Disable MCPX rom
    • Stop SMC timeout
    • Setup RAM slew [where do we get the table from?]
    • Setup LDT bus
    • Setup USB
    • IF RC4 Key given THEN
      • Decrypt kernel from flash
      • Extract kernel
    • ELSE
      • Load kernel to 0x80010000
      • Data section of kernel should be loaded from flash (0-0x200-0x6000) to wherever the datapointer points.. then again to kernel
  • Start kernel:
    • OptionalHeader.AddressOfEntryPoint(bldrargs,keys)
      • Arguments can be anywhere because they will be copied from kernel..
      • keys (EEPROM+CERT) = from keys.bin
      • bldrargs = qemu option, 64 byte char array (zero terminated?)

(Proposed) QEMU Command line

  • File = Original image Loaded from file (Most accurate)
  • Flash = Original image loaded from flash
  • HLE = Recreation of original in code (Least accurate)

Generally speaking, the less you have to specify the better ;) Ideally you'd want to give control to the "Flash" or MCPX ROM "File" as soon as possible.

From most accurate to least accurate:

  1. mcpx_xmode: MCPX XMode to select bootrom
  • =2: No MCPX ROM, start from flash, done: Boot
  • =3: Load or emulate MCPX ROM
  1. mcpx_rom: File to load as MCPX ROM
  • yes: MCPX from ROM image, done: MPCX=File, Boot
  • no: MCPX HLE
  1. xbox_bootloader_key: Key to decrypt real bootloader from flash
  • yes: 2BL from flash, done: MCPX=HLE, 2BL=Flash, Boot
  • no: 2BL HLE
    • Optional xbox_bootloader_128mb to use bootloader for 128MB xbox
  1. xbox_kernel_key: Key to decrypt real kernel from flash
  • yes: Kernel from flash, done: MCPX=HLE, 2BL=HLE, Kernel=Flash, Boot
  • no: Attempt to load kernel directly
  1. xbox_kernel+xbox_kernel_keys+xbox_kernel_arguments: Kernel image to load, key-file, argument-string to pass to kernel

  • yes: Kernel from file, kernel keys from file, kernel argument from command line, kernel data from flash done: MCPX=HLE, 2BL=HLE, Kernel=File+Flash, Boot

  • no: Nothing to boot from done: Error

  • You should also set mcpx_revision so the MCPX behaves properly (Regardless of mcpx_xmode or wether you HLE the MCPX). The bootloader also queries the MCPX revision All of the options above require -bios (not part of machine) to specify the flash image.

  • If you use the xbox_kernel or any of the HLE options make sure that your -bios is compatible/dumped from the same Xbox.

  • Also make sure you don't confuse xbox_kernel_keys (32 byte keyfile to pass to the kernel) and xbox_kernel_key (16 byte keyfile to decrypt kernel image from flash).