xboxdevwiki - User contributions [en]

Exploits

2024-01-09T23:40:39Z

Lowtolerance:

== MCPX ==

=== LDT (Hypertransport) bus tap ===

See [http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html#ldt bunnie's adventures hacking the Xbox].

=== Visor hack ===

Exploits incorrect rollover of memory address. Microsoft's strategy for halting the system in the event of a "panic" event during the boot process (i.e., the hash for decrypting 2bl is incorrect) was to put the code to hide the MCPX ROM at the very end of the ROM itself, which is mapped to the top of addressable memory, and rely on the CPU to halt when the instruction pointer rolls over from 0xFFFFFFFF to 0x00000000. Incredibly, Microsoft missed that this behavior was specific to AMD's x86-compatible CPUs, which were used during the development process. In fact, the Intel CPU that ended up in retail units will happily continue execution at 0x00000000.

Visor's hack used Xcodes to write a jump into a location in flash memory at the very beginning of the address space and forced the MCPX ROM to panic by rewriting bytes at the end of 2bl. When the MCPX attempts to validate the 2bl, it will fail and attempt to "fall through" the memory space until the system halts, which never actually happens and the CPU will continue to execute the injected code that jumps into flash.

=== MIST hack ===

Exploits error in xcode interpreter security check. MCPX 1.0 contains code intended to prevent an attacker from using Xcodes to turn off the Xcode interpreter, which is normally accomplished by setting a bit in memory used by the PCI bus to set device configuration, directing the mapping of memory to the top of memory from the MCPX's ROM to flash. The interpreter will reject Xcode that attempts to modify data at this address, but neglects to consider the behavior of the PCI controller, which only utilizes the lower 24 bits of a memory address. Consequently, it is still possible to toggle the necessary bit and turn off the MCPX's secret ROM by using a "fake" address -- the desired address with the upper bits modified so that the interpreter's check will not catch that we are hiding the secret ROM.

A similar attack is possible by abusing the Xcode interpreter's ability to outputting the necessary code to hide the secret ROM to the appropriate I/O port, which the interpreter does not attempt to stop.

=== A20M# hack ===

[[File:Haxar-a20m.jpg|thumb|200px|A jumper wire hack to enable A20]]

Uses a legacy x86 feature (beginning with 286 CPUs) that relied on a gate on address line 20 (A20) to determine whether the code execution should roll over to the lower 64kb or continue on into higher memory addresses. This feature still existed in the CPU used in the Xbox. By pulling down the A20 gate, an attacker can effectively modulate an address so that the system will point to a location in memory below the addressed location. For instance, with the A20 gate pulled down, the address 0xFFFFFFFF would be translated to 0xFFEFFFFF, which on the Xbox would continue code instruction at a location in flash.

=== RC4 attack (MCPX 1.0 only) ===

Microsoft uses the last bytes of the decrypted 2BL to check the integrity of the 2BL.
However, RC4 does not have any feedback which means changes in the 2BL will not reflect in the last couple of bytes which are checked.
As such, the 2BL can be freely modified, as long as the last couple of bytes still match what the MCPX ROM expects.

This can be used to take over the 2BL entry point.

When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.

''This attack is described by Michael Steil in his Google talk, “[https://www.youtube.com/watch?v=9NqLljaHc80 Hacking the Xbox Security System].''

=== TEA attack (MCPX 1.1 only) ===

TEA, which is only used in MCPX 1.1, can not be used as a hash in Davies-Meyer mode [http://www.tayloredge.com/reference/Mathematics/VRAndem.pdf][https://www.schneier.com/academic/paperfiles/paper-key-schedule.pdf]. And yet, Microsoft used it that way.

The original attack uses the 5 bytes at 0xffffd400 (FBL entry point) which are <code>E9 83 01 00 00</code>.
This is <code>jmp 0xffffd588</code> (which is a jump within the flash region).

When flipping the highest bit of the operand DWORD (at 0xffffd400, mind your endianess) this will become: <code>E9 83 01 80 00</code>.
This is <code>jmp 0x7fd588</code> (which is a jump into the RAM region).
For the attack to be successful, the highest bit in the DWORD at 0xffffd404 also has to be flipped.

The RAM can be controlled using the x-code command to write to RAM.
So the idea is to copy a program from Flash to RAM using x-codes.
Then the FBL / 2BL is modified to jump into said RAM region by flipping a bit of a jump operand (as described above).
The 2 bit flips will not change the hash of FBL / 2BL as TEA is broken.

As such, the FBL verification will succeed, the MCPX ROM will hand control to the FBL which will then jump into the attacker controlled RAM.

When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.

''The TEA algorithm and exploit are also described in more detail in Bunnie's book (Page 109 and Page 142).''

== Dashboard ==

=== Audio hacks ===
=== Font hacks ===

[http://archiv.sega-dc.de/phoenix.maxconsole.net/docs/berternie.inc.htm Analysis of "Bert & Ernie" font-exploit].

==== Easter-egg exploit ====

== Savegames ==
Savedgames can be used as an exploit method, but care must be taken for most games are verifying digital signatures of savedgames {{citation needed}} [http://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf]
=== [[007: Agent Under Fire]] ===

[https://web.archive.org/web/20031003093240/http://xbox-linux.sourceforge.net:80/docs/007analysis.html Analysis of this savegame-exploit].

=== [[Frogger Beyond]] ===
Not much is known why this game was in the list, [https://events.ccc.de/congress/2005/fahrplan/attachments/674-slides_xbox.pdf 22C3, page 85]
The game isnt shown in the final presentation at 22C3 (neither are Mechassault nor SplinterCell).

In 2022, Artem Garmash published a blog post describing an approach to [https://agarmash.com/posts/xbox-frogger-beyond-exploit/ exploiting Frogger Beyond].

=== [[MechAssault]] ===

Exploit runs a modified version of Xbox Live Update to execute a paylaod.

=== [[Tom Clancy's Splinter Cell]] ===
=== [[Tony Hawk's Pro Skater 4]] ===
Grimdoomer discovered a savegame exploit in THPS4, shared it on Discord and was later included with the Rocky5 softmod installer.
[https://drive.google.com/file/d/0B9WVULxHOmNkQVBCMHMtVGhqVVU/view a video demonstrating the game trigger (custom skatepark)]

''10-4-2017 it's just shell code I injected into the game save/ granted this save is slightly more complicated than the others and requires a small "loader" that is just a memcpy basically it's literally as simple as a buffer overflow...I just looked for null terminated strings and fuzzed them then when I got a crash I looked in teh xbe to figure out what was going on. yeah it's literally just a stack overflow'' - grimdoomer

another website talking about his exploit.
[https://www.xbmc4xbox.org.uk/forum/viewtopic.php?t=7310 xbmc4xbox.org.uk]

== Attack ideas ==

{| class="wikitable"
! Purpose || Author || Description || Status
|-
|Xbox DVD Movie Playback Kit Dongle ROM manipulation || Xbox-Linux wiki
|As the dashboard presumably downloads the code from the ROM into the memory of the Xbox, this could be a hardware hack requiring no hardware modifications. The XBE loader for the DVD image is different from the usual XBE loader. However, the XBE is still signed and checked for security.
| XBE loader seems to be secured, although no full analysis has been done.
|-
| Preserving memory across boot || JayFoxRox
| Confirm behaviour described in the coldboot paper (https://jhalderm.com/pub/papers/coldboot-cacm09.pdf). This can be used to transfer code / setups for other exploits across a boot (such as preparing memory for A20 attack).
| Success: We have marked memory and rebooted the Xbox (through SMC warm and cold, and manual reboot using power switch). At room temperature, and the Xbox pre-heated, hundreds of markers can still be found after 10 seconds. Within the first 5 seconds, no loss of data was measured at all (although not many bits have been marked to begin with). We have confirmed the memory persistence not only for the main RAM, but also MCPX APU DSP memory banks. Other memory or register banks were not tested yet.
|-
| Early boot control || JayFoxRox
| Xcodes allow writing PCI config space. This can be used to set PCI BARs to random page-aligned addresses. Some devices like the NV2A or MCPX APU contain large register banks which can be read and written like RAM. So effectively we can probably overlay the flash memory or MCPX ROM with a temporary PCI mapping. To fill the memory, the PCI device can be mapped to a lower region, and be filled through Xcode memory writes.
This can be used to take control over code contained in RAM (FBL / 2BL), flash or possibly even the MCPX ROM during boot. This attack could be used to avoid unmapping the MCPX ROM and is therefore quite powerful. However, it requires knowledge of the Xcodes.
| This has not been tested during real-mode or early boot yet, but is assumed to work. It was tested from protected mode by mapping USB1 over the Flash and MCPX ROM region (main RAM has not been tested yet). Mapping the overlay pages without caching resulted in crashes. However, the PD was not reviewed at the time and might have been broken (through unconventional use of MmMapIoSpace).
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain:
* Map PCI devices over the MCPX ROM region
* Schedule a reset
* Keep reading MCPX ROM memory with CPU to persistent page
* If we are lucky, the CPU would now copies the MCPX ROM to RAM in it's last cycles with a broken LDT (this depends on how LDTs work and if they can recover)
| Failed: I've tried reading MCPX ROM memory for as long as possible using the CPU. I've tried resets using PM26 (assumed PWRBTN), SMC Soft (0x01) and SMC Hard (0x40).
Memory was read based on observing value changes (in PCI regions, signalling reset), and timing alone (X cycles after starting reset).
The MCPX ROM region access always crashed. Shadowing the MCPX ROM with a PCI device does not help: The CPU never observed the PCI devices being remapped / lost.
As MCPX and CPU are both reset by the SMC directly, this is not surprising.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain:
* Map PCI devices over the MCPX ROM region
* Check if NV2A can access the mapped PCI device
* Configure NV2A to continously stream from MCPX ROM region to RAM - Reset system using SMC (idea: this resets the PCI device mappings in the MCPX and should re-enable the MCPX ROM)
* If we are lucky, the NV2A would now stream the MCPX ROM to RAM in it's last cycles with a broken LDT (this depends on how LDTs work and if they can recover)
| Concept only: No interest in experimenting with NV2A DMA.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain: On a warm boot, the x86 might do a bad boot (the following is a theory, someone please measure pins). Theroy: PWRGD is provided, but CPURST is still high from the previous run; CPURST might only go low once NV2A reboots:
* Map device in NV2A to MCPX ROM region (note: mapping MCPX device would not work, because that gets reset with PWRGD)
* Warm reset using SMC
* Code in NV2A device should now jump to lower memory and unmap the MCPX ROM region (by moving itself for example)
* Delay by X cycles [probably in the range from 1ns to idk.. 500ms] to avoid reading the MCPX ROM before MCPX reset
* Code in lower region should copy MCPX ROM region to persisting pages
| Concept only: Someone should measure the pins and possibly look into the memory signals. This is too time consuming for me.
|-
| Unknown || JayFoxRox
| Partial system reset using 0xCF9 I/O register
| Resetting through 0xCF9 lands us on a black screen and the LED flashes as if the DVD tray was being opened. It's currently assumed that 0xCF9 only resets peripherals and NV2A / CPU, but it does not seem to reset the MCPX itself (hence issues booting and PCI activity which causes LED to flash). This has not been tested yet. An idea to confirm this, might be to map a device at 0xFFFFFFF0 which places an x86 jump to a good memory page. If the MCPX really isn't reset, then the CPU would boot from the MMIO / known page.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain. The SMC takes a couple of milliseconds to reset the system. Parts of the peripherals might stay alive for long enough. So chances (extremly unlikely) are, the peripherals could be programmed to do DMA where the DMA is only executed after the reboot.
| Failed: An attempt was made to use the APU GP DSP DMA to continuously store x86 code where 2BL would unpack. The system was then reset using the SMC. It booted normally. It is assumed that the DMA is probably long dead by the time that the 2BL is being unpacked / ran.
|-
| Unknown || JayFoxRox
| Resetting from wrong address. The errata for the CPU states that a warm-reset might occur from the wrong address.
| Concept only: Needs more research
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to access MCPX ROM through peripherals in the southbridge. If the address logic is broken, parts like the OHCI, APU or AC97 might be able to access it still.
|
* AC97: Lots of crashes / hangs. Sometimes crackling noise. Sometimes does not crash. Also can access some non-existing memory regions without any crashes. Data read from invalid addresses seemed to be 300 Hz square wave. While crashing the hardware output will have exponential falloff (measured on PCM line-out).
* APU: Mapping GP DSP Scratch memory from 0x00000000 to 0x7FFFFFFF reveals mirrors of physical RAM. Setting the highest bit (addresses over 0x80000000) will result in a crash of the Xbox.
* OHCI: Untested
* Others: Untested
|-
| Dumping Kernel INIT || JayFoxRox
| INIT is free'd right before passing execution to the first XBE. Depending on what the XBE allocates, the INIT section might still be in memory when a dumper is run.
| Probably doesn't work. Would need the dumper to directly run after cold-boot. Softmods unfortunately reboot the Xbox and during this warm-boot the INIT section is (in at least most cases) lost.
|-
| Dumping Kernel INIT || DaveX || An extension to JayFoxRox dumping idea. Instead of running a dumper-XBE through a softmod, the softmod itself could do the dumping. This means creation of a custom softmod, just for dumping. This depends on the used softmod entry-point (font-exploit (signed target xbe), audio-exploit, ..) to gain execution as early as possible. This strategy might be slightly risky as harddisk contents have to be modified for the temporary softmod.
| WIP as of 2018-09-12
|-
| rowspan="13" | Homebrew entry point || rowspan="13" | Community
| rowspan="13" | Some movie DVDs contain default XBEs signed to run on original Xbox from DVD-ROM. The XBE extracts the actual game XBE (which is signed to run from HDD) onto the cache drives. If we can find a vulnerability in one of them (loaded files), we could possibly take over the entire system and run a softmod from DVD+R. In order to make a bootable DVD+R, you must have a DVD burner that - either natively, or by custom firmware - can set booktype to DVD-ROM. From a small sample size, it appears that the drive must also be capable of setting the layertype on the disc to "read-only", which is a very rarely used security feature apparently only present for Xbox, Xbox 360, and an Audi navigation system. Layertype is a rather unknown thing, and it appears DVD burners were accidentally set with this from factory, but regular burner drives could potentially have the layertype modified using custom firmware (as the Burnermax payload does for dual layer DVDs).
|-
|'''Hulk (Special Edition)'''

UPC 2519224892

[[The Hulk]]

This DVD is unique and contains a partial dashboard (5860 with 4831 libraries) with an xboxdash.xbe signed to run from DVD-ROM. The default.xbe calls this dashboard XBE with parameters to play a video on the disc. By swapping this XBE with the default.xbe, you can boot the dashboard to a blank sphere. By placing dashboard 4920's mainmenu5.xip in the xboxdash folder, you can restore the orb and menu options, but selecting an option will show a blank sphere after the zoom animation. All xips are loaded from DVD and are hash checked. Font/audio files are loaded from HDD and hash checked. Aside from xboxdash.xbe, default.xbe will load video_ts.ifo and an audio file from cdrom, so a vulnerability could be found in those.

Untested
|-
|'''Star Wars: Clone Wars - Volume One'''

UPC 2454317005

[[Republic Commando]]

Untested
|-
|'''Star Wars: Clone Wars - Volume Two'''

UPC 24543214137

[[Battlefront II]]

Untested
|-
|'''Star Wars: Episode III - Revenge of the Sith (Widescreen Edition)'''

UPC 5039036023238

[[Battlefront II]]

Untested
|-
|'''Star Wars Trilogy (Widescreen Edition with Bonus Disc)'''

UPC 24543123415 or 5039036017374

[[Star Wars Battlefront]]

Untested
|-
|'''Star Wars Trilogy DVD (Widescreen theatrical edition)'''

UPC 24543559856

[[Lego Star Wars 2]]

Untested
|-
|'''The Chronicles of Riddick (Widescreen Unrated Director's Cut)'''

UPC 5050582274639

[[Chronicles of Riddick]]

Untested
|-
|'''Doom (Unrated Widescreen Edition)'''

UPC 25192031229

[[Doom 3]]

Untested
|-
|'''King Arthur - The Director's Cut (Widescreen Edition)'''

UPC 786936265262

[[King Arthur]]

Untested
|-
|'''Robots (Widescreen Edition)'''

UPC 24543193845

[[Robots]]

Untested
|-
|'''Van Helsing (Widescreen Edition)'''

UPC 25192326622 or 25192586125

[[Van Helsing]]

Untested
|-
|'''The Godfather'''

UPC not 5014437812834 nor 14633165401 nor 014633165401

SPPV and Atreyu187 claim this exists and contains an XBE capable of chainloading any signed game XBE. No evidence exists of this actually existing on the DVD or game bonus disc, but it is listed here for posterity.

[[The Godfather: The Game]]
|}

== Notes ==

* [https://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf 17 Mistakes Microsoft Made in the Xbox Security System]
* [http://toogam.bespin.org/xboxmod/site/xbehacks.htm A list of some exploit implementations]

Exploits

2024-01-09T02:43:44Z

Lowtolerance: Added a blurb about the MechAssault exploit.

== MCPX ==

=== LDT (Hypertransport) bus tap ===

See [http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html#ldt bunnie's adventures hacking the Xbox].

=== Visor hack ===

Exploits incorrect rollover of memory address. Microsoft's strategy for halting the system in the event of a "panic" event during the boot process (i.e., the hash for decrypting 2bl is incorrect) was to put the code to hide the MCPX ROM at the very end of the ROM itself, which is mapped to the top of addressable memory, and rely on the CPU to halt when the instruction pointer rolls over from 0xFFFFFFFF to 0x00000000. Incredibly, Microsoft missed that this behavior was specific to AMD's x86-compatible CPUs, which were used during the development process. In fact, the Intel CPU that ended up in retail units will happily continue execution at 0x00000000.

Visor's hack used Xcodes to write a jump into a location in flash memory at the very beginning of the address space and forced the MCPX ROM to panic by rewriting bytes at the end of 2bl. When the MCPX attempts to validate the 2bl, it will fail and attempt to "fall through" the memory space until the system halts, which never actually happens and the CPU will continue to execute the injected code that jumps into flash.

=== MIST hack ===

Exploits error in xcode interpreter security check. MCPX 1.0 contains code intended to prevent an attacker from using Xcodes to turn off the Xcode interpreter, which is normally accomplished by setting a bit in memory used by the PCI bus to set device configuration, directing the mapping of memory to the top of memory from the MCPX's ROM to flash. The interpreter will reject Xcode that attempts to modify data at this address, but neglects to consider the behavior of the PCI controller, which only utilizes the lower 24 bits of a memory address. Consequently, it is still possible to toggle the necessary bit and turn off the MCPX's secret ROM by using a "fake" address -- the desired address with the upper bits modified so that the interpreter's check will not catch that we are hiding the secret ROM.

A similar attack is possible by abusing the Xcode interpreter's ability to outputting the necessary code to hide the secret ROM to the appropriate I/O port, which the interpreter does not attempt to stop.

=== A20M# hack ===

[[File:Haxar-a20m.jpg|thumb|200px|A jumper wire hack to enable A20]]

Uses a legacy x86 feature (beginning with 286 CPUs) that relied on a gate on address line 20 (A20) to determine whether the code execution should roll over to the lower 64kb or continue on into higher memory addresses. This feature still existed in the CPU used in the Xbox. By pulling down the A20 gate, an attacker can effectively modulate an address so that the system will point to a location in memory below the addressed location. For instance, with the A20 gate pulled down, the address 0xFFFFFFFF would be translated to 0xFFEFFFFF, which on the Xbox would continue code instruction at a location in flash.

=== RC4 attack (MCPX 1.0 only) ===

Microsoft uses the last bytes of the decrypted 2BL to check the integrity of the 2BL.
However, RC4 does not have any feedback which means changes in the 2BL will not reflect in the last couple of bytes which are checked.
As such, the 2BL can be freely modified, as long as the last couple of bytes still match what the MCPX ROM expects.

This can be used to take over the 2BL entry point.

When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.

''This attack is described by Michael Steil in his Google talk, [Hacking the Xbox Security System][https://www.youtube.com/watch?v=9NqLljaHc80].''

=== TEA attack (MCPX 1.1 only) ===

TEA, which is only used in MCPX 1.1, can not be used as a hash in Davies-Meyer mode [http://www.tayloredge.com/reference/Mathematics/VRAndem.pdf][https://www.schneier.com/academic/paperfiles/paper-key-schedule.pdf]. And yet, Microsoft used it that way.

The original attack uses the 5 bytes at 0xffffd400 (FBL entry point) which are <code>E9 83 01 00 00</code>.
This is <code>jmp 0xffffd588</code> (which is a jump within the flash region).

When flipping the highest bit of the operand DWORD (at 0xffffd400, mind your endianess) this will become: <code>E9 83 01 80 00</code>.
This is <code>jmp 0x7fd588</code> (which is a jump into the RAM region).
For the attack to be successful, the highest bit in the DWORD at 0xffffd404 also has to be flipped.

The RAM can be controlled using the x-code command to write to RAM.
So the idea is to copy a program from Flash to RAM using x-codes.
Then the FBL / 2BL is modified to jump into said RAM region by flipping a bit of a jump operand (as described above).
The 2 bit flips will not change the hash of FBL / 2BL as TEA is broken.

As such, the FBL verification will succeed, the MCPX ROM will hand control to the FBL which will then jump into the attacker controlled RAM.

When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.

''The TEA algorithm and exploit are also described in more detail in Bunnie's book (Page 109 and Page 142).''

== Dashboard ==

=== Audio hacks ===
=== Font hacks ===

[http://archiv.sega-dc.de/phoenix.maxconsole.net/docs/berternie.inc.htm Analysis of "Bert & Ernie" font-exploit].

==== Easter-egg exploit ====

== Savegames ==
Savedgames can be used as an exploit method, but care must be taken for most games are verifying digital signatures of savedgames {{citation needed}} [http://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf]
=== [[007: Agent Under Fire]] ===

[https://web.archive.org/web/20031003093240/http://xbox-linux.sourceforge.net:80/docs/007analysis.html Analysis of this savegame-exploit].

=== [[Frogger Beyond]] ===
Not much is known why this game was in the list, [https://events.ccc.de/congress/2005/fahrplan/attachments/674-slides_xbox.pdf 22C3, page 85]
The game isnt shown in the final presentation at 22C3 (neither are Mechassault nor SplinterCell).

In 2022, Artem Garmash published a blog post describing an approach to [exploiting Frogger Beyond][https://agarmash.com/posts/xbox-frogger-beyond-exploit/].

=== [[MechAssault]] ===

Exploit runs a modified version of Xbox Live Update to execute a paylaod.

=== [[Tom Clancy's Splinter Cell]] ===
=== [[Tony Hawk's Pro Skater 4]] ===
Grimdoomer discovered a savegame exploit in THPS4, shared it on Discord and was later included with the Rocky5 softmod installer.
[https://drive.google.com/file/d/0B9WVULxHOmNkQVBCMHMtVGhqVVU/view a video demonstrating the game trigger (custom skatepark)]

''10-4-2017 it's just shell code I injected into the game save/ granted this save is slightly more complicated than the others and requires a small "loader" that is just a memcpy basically it's literally as simple as a buffer overflow...I just looked for null terminated strings and fuzzed them then when I got a crash I looked in teh xbe to figure out what was going on. yeah it's literally just a stack overflow'' - grimdoomer

another website talking about his exploit.
[https://www.xbmc4xbox.org.uk/forum/viewtopic.php?t=7310 xbmc4xbox.org.uk]

== Attack ideas ==

{| class="wikitable"
! Purpose || Author || Description || Status
|-
|Xbox DVD Movie Playback Kit Dongle ROM manipulation || Xbox-Linux wiki
|As the dashboard presumably downloads the code from the ROM into the memory of the Xbox, this could be a hardware hack requiring no hardware modifications. The XBE loader for the DVD image is different from the usual XBE loader. However, the XBE is still signed and checked for security.
| XBE loader seems to be secured, although no full analysis has been done.
|-
| Preserving memory across boot || JayFoxRox
| Confirm behaviour described in the coldboot paper (https://jhalderm.com/pub/papers/coldboot-cacm09.pdf). This can be used to transfer code / setups for other exploits across a boot (such as preparing memory for A20 attack).
| Success: We have marked memory and rebooted the Xbox (through SMC warm and cold, and manual reboot using power switch). At room temperature, and the Xbox pre-heated, hundreds of markers can still be found after 10 seconds. Within the first 5 seconds, no loss of data was measured at all (although not many bits have been marked to begin with). We have confirmed the memory persistence not only for the main RAM, but also MCPX APU DSP memory banks. Other memory or register banks were not tested yet.
|-
| Early boot control || JayFoxRox
| Xcodes allow writing PCI config space. This can be used to set PCI BARs to random page-aligned addresses. Some devices like the NV2A or MCPX APU contain large register banks which can be read and written like RAM. So effectively we can probably overlay the flash memory or MCPX ROM with a temporary PCI mapping. To fill the memory, the PCI device can be mapped to a lower region, and be filled through Xcode memory writes.
This can be used to take control over code contained in RAM (FBL / 2BL), flash or possibly even the MCPX ROM during boot. This attack could be used to avoid unmapping the MCPX ROM and is therefore quite powerful. However, it requires knowledge of the Xcodes.
| This has not been tested during real-mode or early boot yet, but is assumed to work. It was tested from protected mode by mapping USB1 over the Flash and MCPX ROM region (main RAM has not been tested yet). Mapping the overlay pages without caching resulted in crashes. However, the PD was not reviewed at the time and might have been broken (through unconventional use of MmMapIoSpace).
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain:
* Map PCI devices over the MCPX ROM region
* Schedule a reset
* Keep reading MCPX ROM memory with CPU to persistent page
* If we are lucky, the CPU would now copies the MCPX ROM to RAM in it's last cycles with a broken LDT (this depends on how LDTs work and if they can recover)
| Failed: I've tried reading MCPX ROM memory for as long as possible using the CPU. I've tried resets using PM26 (assumed PWRBTN), SMC Soft (0x01) and SMC Hard (0x40).
Memory was read based on observing value changes (in PCI regions, signalling reset), and timing alone (X cycles after starting reset).
The MCPX ROM region access always crashed. Shadowing the MCPX ROM with a PCI device does not help: The CPU never observed the PCI devices being remapped / lost.
As MCPX and CPU are both reset by the SMC directly, this is not surprising.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain:
* Map PCI devices over the MCPX ROM region
* Check if NV2A can access the mapped PCI device
* Configure NV2A to continously stream from MCPX ROM region to RAM - Reset system using SMC (idea: this resets the PCI device mappings in the MCPX and should re-enable the MCPX ROM)
* If we are lucky, the NV2A would now stream the MCPX ROM to RAM in it's last cycles with a broken LDT (this depends on how LDTs work and if they can recover)
| Concept only: No interest in experimenting with NV2A DMA.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain: On a warm boot, the x86 might do a bad boot (the following is a theory, someone please measure pins). Theroy: PWRGD is provided, but CPURST is still high from the previous run; CPURST might only go low once NV2A reboots:
* Map device in NV2A to MCPX ROM region (note: mapping MCPX device would not work, because that gets reset with PWRGD)
* Warm reset using SMC
* Code in NV2A device should now jump to lower memory and unmap the MCPX ROM region (by moving itself for example)
* Delay by X cycles [probably in the range from 1ns to idk.. 500ms] to avoid reading the MCPX ROM before MCPX reset
* Code in lower region should copy MCPX ROM region to persisting pages
| Concept only: Someone should measure the pins and possibly look into the memory signals. This is too time consuming for me.
|-
| Unknown || JayFoxRox
| Partial system reset using 0xCF9 I/O register
| Resetting through 0xCF9 lands us on a black screen and the LED flashes as if the DVD tray was being opened. It's currently assumed that 0xCF9 only resets peripherals and NV2A / CPU, but it does not seem to reset the MCPX itself (hence issues booting and PCI activity which causes LED to flash). This has not been tested yet. An idea to confirm this, might be to map a device at 0xFFFFFFF0 which places an x86 jump to a good memory page. If the MCPX really isn't reset, then the CPU would boot from the MMIO / known page.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain. The SMC takes a couple of milliseconds to reset the system. Parts of the peripherals might stay alive for long enough. So chances (extremly unlikely) are, the peripherals could be programmed to do DMA where the DMA is only executed after the reboot.
| Failed: An attempt was made to use the APU GP DSP DMA to continuously store x86 code where 2BL would unpack. The system was then reset using the SMC. It booted normally. It is assumed that the DMA is probably long dead by the time that the 2BL is being unpacked / ran.
|-
| Unknown || JayFoxRox
| Resetting from wrong address. The errata for the CPU states that a warm-reset might occur from the wrong address.
| Concept only: Needs more research
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to access MCPX ROM through peripherals in the southbridge. If the address logic is broken, parts like the OHCI, APU or AC97 might be able to access it still.
|
* AC97: Lots of crashes / hangs. Sometimes crackling noise. Sometimes does not crash. Also can access some non-existing memory regions without any crashes. Data read from invalid addresses seemed to be 300 Hz square wave. While crashing the hardware output will have exponential falloff (measured on PCM line-out).
* APU: Mapping GP DSP Scratch memory from 0x00000000 to 0x7FFFFFFF reveals mirrors of physical RAM. Setting the highest bit (addresses over 0x80000000) will result in a crash of the Xbox.
* OHCI: Untested
* Others: Untested
|-
| Dumping Kernel INIT || JayFoxRox
| INIT is free'd right before passing execution to the first XBE. Depending on what the XBE allocates, the INIT section might still be in memory when a dumper is run.
| Probably doesn't work. Would need the dumper to directly run after cold-boot. Softmods unfortunately reboot the Xbox and during this warm-boot the INIT section is (in at least most cases) lost.
|-
| Dumping Kernel INIT || DaveX || An extension to JayFoxRox dumping idea. Instead of running a dumper-XBE through a softmod, the softmod itself could do the dumping. This means creation of a custom softmod, just for dumping. This depends on the used softmod entry-point (font-exploit (signed target xbe), audio-exploit, ..) to gain execution as early as possible. This strategy might be slightly risky as harddisk contents have to be modified for the temporary softmod.
| WIP as of 2018-09-12
|-
| rowspan="13" | Homebrew entry point || rowspan="13" | Community
| rowspan="13" | Some movie DVDs contain default XBEs signed to run on original Xbox from DVD-ROM. The XBE extracts the actual game XBE (which is signed to run from HDD) onto the cache drives. If we can find a vulnerability in one of them (loaded files), we could possibly take over the entire system and run a softmod from DVD+R. In order to make a bootable DVD+R, you must have a DVD burner that - either natively, or by custom firmware - can set booktype to DVD-ROM. From a small sample size, it appears that the drive must also be capable of setting the layertype on the disc to "read-only", which is a very rarely used security feature apparently only present for Xbox, Xbox 360, and an Audi navigation system. Layertype is a rather unknown thing, and it appears DVD burners were accidentally set with this from factory, but regular burner drives could potentially have the layertype modified using custom firmware (as the Burnermax payload does for dual layer DVDs).
|-
|'''Hulk (Special Edition)'''

UPC 2519224892

[[The Hulk]]

This DVD is unique and contains a partial dashboard (5860 with 4831 libraries) with an xboxdash.xbe signed to run from DVD-ROM. The default.xbe calls this dashboard XBE with parameters to play a video on the disc. By swapping this XBE with the default.xbe, you can boot the dashboard to a blank sphere. By placing dashboard 4920's mainmenu5.xip in the xboxdash folder, you can restore the orb and menu options, but selecting an option will show a blank sphere after the zoom animation. All xips are loaded from DVD and are hash checked. Font/audio files are loaded from HDD and hash checked. Aside from xboxdash.xbe, default.xbe will load video_ts.ifo and an audio file from cdrom, so a vulnerability could be found in those.

Untested
|-
|'''Star Wars: Clone Wars - Volume One'''

UPC 2454317005

[[Republic Commando]]

Untested
|-
|'''Star Wars: Clone Wars - Volume Two'''

UPC 24543214137

[[Battlefront II]]

Untested
|-
|'''Star Wars: Episode III - Revenge of the Sith (Widescreen Edition)'''

UPC 5039036023238

[[Battlefront II]]

Untested
|-
|'''Star Wars Trilogy (Widescreen Edition with Bonus Disc)'''

UPC 24543123415 or 5039036017374

[[Star Wars Battlefront]]

Untested
|-
|'''Star Wars Trilogy DVD (Widescreen theatrical edition)'''

UPC 24543559856

[[Lego Star Wars 2]]

Untested
|-
|'''The Chronicles of Riddick (Widescreen Unrated Director's Cut)'''

UPC 5050582274639

[[Chronicles of Riddick]]

Untested
|-
|'''Doom (Unrated Widescreen Edition)'''

UPC 25192031229

[[Doom 3]]

Untested
|-
|'''King Arthur - The Director's Cut (Widescreen Edition)'''

UPC 786936265262

[[King Arthur]]

Untested
|-
|'''Robots (Widescreen Edition)'''

UPC 24543193845

[[Robots]]

Untested
|-
|'''Van Helsing (Widescreen Edition)'''

UPC 25192326622 or 25192586125

[[Van Helsing]]

Untested
|-
|'''The Godfather'''

UPC not 5014437812834 nor 14633165401 nor 014633165401

SPPV and Atreyu187 claim this exists and contains an XBE capable of chainloading any signed game XBE. No evidence exists of this actually existing on the DVD or game bonus disc, but it is listed here for posterity.

[[The Godfather: The Game]]
|}

== Notes ==

* [https://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf 17 Mistakes Microsoft Made in the Xbox Security System]
* [http://toogam.bespin.org/xboxmod/site/xbehacks.htm A list of some exploit implementations]

Exploits

2024-01-09T02:33:13Z

Lowtolerance: Fleshed out Visor Hack, MIST hack and A20M# hacks with information gleaned from 17 Mistakes.

== MCPX ==

=== LDT (Hypertransport) bus tap ===

See [http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html#ldt bunnie's adventures hacking the Xbox].

=== Visor hack ===

Exploits incorrect rollover of memory address. Microsoft's strategy for halting the system in the event of a "panic" event during the boot process (i.e., the hash for decrypting 2bl is incorrect) was to put the code to hide the MCPX ROM at the very end of the ROM itself, which is mapped to the top of addressable memory, and rely on the CPU to halt when the instruction pointer rolls over from 0xFFFFFFFF to 0x00000000. Incredibly, Microsoft missed that this behavior was specific to AMD's x86-compatible CPUs, which were used during the development process. In fact, the Intel CPU that ended up in retail units will happily continue execution at 0x00000000.

Visor's hack used Xcodes to write a jump into a location in flash memory at the very beginning of the address space and forced the MCPX ROM to panic by rewriting bytes at the end of 2bl. When the MCPX attempts to validate the 2bl, it will fail and attempt to "fall through" the memory space until the system halts, which never actually happens and the CPU will continue to execute the injected code that jumps into flash.

=== MIST hack ===

Exploits error in xcode interpreter security check. MCPX 1.0 contains code intended to prevent an attacker from using Xcodes to turn off the Xcode interpreter, which is normally accomplished by setting a bit in memory used by the PCI bus to set device configuration, directing the mapping of memory to the top of memory from the MCPX's ROM to flash. The interpreter will reject Xcode that attempts to modify data at this address, but neglects to consider the behavior of the PCI controller, which only utilizes the lower 24 bits of a memory address. Consequently, it is still possible to toggle the necessary bit and turn off the MCPX's secret ROM by using a "fake" address -- the desired address with the upper bits modified so that the interpreter's check will not catch that we are hiding the secret ROM.

A similar attack is possible by abusing the Xcode interpreter's ability to outputting the necessary code to hide the secret ROM to the appropriate I/O port, which the interpreter does not attempt to stop.

=== A20M# hack ===

[[File:Haxar-a20m.jpg|thumb|200px|A jumper wire hack to enable A20]]

Uses a legacy x86 feature (beginning with 286 CPUs) that relied on a gate on address line 20 (A20) to determine whether the code execution should roll over to the lower 64kb or continue on into higher memory addresses. This feature still existed in the CPU used in the Xbox. By pulling down the A20 gate, an attacker can effectively modulate an address so that the system will point to a location in memory below the addressed location. For instance, with the A20 gate pulled down, the address 0xFFFFFFFF would be translated to 0xFFEFFFFF, which on the Xbox would continue code instruction at a location in flash.

=== RC4 attack (MCPX 1.0 only) ===

Microsoft uses the last bytes of the decrypted 2BL to check the integrity of the 2BL.
However, RC4 does not have any feedback which means changes in the 2BL will not reflect in the last couple of bytes which are checked.
As such, the 2BL can be freely modified, as long as the last couple of bytes still match what the MCPX ROM expects.

This can be used to take over the 2BL entry point.

When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.

''This attack is described by Michael Steil in his Google talk, [Hacking the Xbox Security System][https://www.youtube.com/watch?v=9NqLljaHc80].''

=== TEA attack (MCPX 1.1 only) ===

TEA, which is only used in MCPX 1.1, can not be used as a hash in Davies-Meyer mode [http://www.tayloredge.com/reference/Mathematics/VRAndem.pdf][https://www.schneier.com/academic/paperfiles/paper-key-schedule.pdf]. And yet, Microsoft used it that way.

The original attack uses the 5 bytes at 0xffffd400 (FBL entry point) which are <code>E9 83 01 00 00</code>.
This is <code>jmp 0xffffd588</code> (which is a jump within the flash region).

When flipping the highest bit of the operand DWORD (at 0xffffd400, mind your endianess) this will become: <code>E9 83 01 80 00</code>.
This is <code>jmp 0x7fd588</code> (which is a jump into the RAM region).
For the attack to be successful, the highest bit in the DWORD at 0xffffd404 also has to be flipped.

The RAM can be controlled using the x-code command to write to RAM.
So the idea is to copy a program from Flash to RAM using x-codes.
Then the FBL / 2BL is modified to jump into said RAM region by flipping a bit of a jump operand (as described above).
The 2 bit flips will not change the hash of FBL / 2BL as TEA is broken.

As such, the FBL verification will succeed, the MCPX ROM will hand control to the FBL which will then jump into the attacker controlled RAM.

When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.

''The TEA algorithm and exploit are also described in more detail in Bunnie's book (Page 109 and Page 142).''

== Dashboard ==

=== Audio hacks ===
=== Font hacks ===

[http://archiv.sega-dc.de/phoenix.maxconsole.net/docs/berternie.inc.htm Analysis of "Bert & Ernie" font-exploit].

==== Easter-egg exploit ====

== Savegames ==
Savedgames can be used as an exploit method, but care must be taken for most games are verifying digital signatures of savedgames {{citation needed}} [http://bunniefoo.com/nostarch/HackingTheXbox_Free.pdf]
=== [[007: Agent Under Fire]] ===

[https://web.archive.org/web/20031003093240/http://xbox-linux.sourceforge.net:80/docs/007analysis.html Analysis of this savegame-exploit].

=== [[Frogger Beyond]] ===
Not much is known why this game was in the list, [https://events.ccc.de/congress/2005/fahrplan/attachments/674-slides_xbox.pdf 22C3, page 85]
The game isnt shown in the final presentation at 22C3 (neither are Mechassault nor SplinterCell).

=== [[MechAssault]] ===
=== [[Tom Clancy's Splinter Cell]] ===
=== [[Tony Hawk's Pro Skater 4]] ===
Grimdoomer discovered a savegame exploit in THPS4, shared it on Discord and was later included with the Rocky5 softmod installer.
[https://drive.google.com/file/d/0B9WVULxHOmNkQVBCMHMtVGhqVVU/view a video demonstrating the game trigger (custom skatepark)]

''10-4-2017 it's just shell code I injected into the game save/ granted this save is slightly more complicated than the others and requires a small "loader" that is just a memcpy basically it's literally as simple as a buffer overflow...I just looked for null terminated strings and fuzzed them then when I got a crash I looked in teh xbe to figure out what was going on. yeah it's literally just a stack overflow'' - grimdoomer

another website talking about his exploit.
[https://www.xbmc4xbox.org.uk/forum/viewtopic.php?t=7310 xbmc4xbox.org.uk]

== Attack ideas ==

{| class="wikitable"
! Purpose || Author || Description || Status
|-
|Xbox DVD Movie Playback Kit Dongle ROM manipulation || Xbox-Linux wiki
|As the dashboard presumably downloads the code from the ROM into the memory of the Xbox, this could be a hardware hack requiring no hardware modifications. The XBE loader for the DVD image is different from the usual XBE loader. However, the XBE is still signed and checked for security.
| XBE loader seems to be secured, although no full analysis has been done.
|-
| Preserving memory across boot || JayFoxRox
| Confirm behaviour described in the coldboot paper (https://jhalderm.com/pub/papers/coldboot-cacm09.pdf). This can be used to transfer code / setups for other exploits across a boot (such as preparing memory for A20 attack).
| Success: We have marked memory and rebooted the Xbox (through SMC warm and cold, and manual reboot using power switch). At room temperature, and the Xbox pre-heated, hundreds of markers can still be found after 10 seconds. Within the first 5 seconds, no loss of data was measured at all (although not many bits have been marked to begin with). We have confirmed the memory persistence not only for the main RAM, but also MCPX APU DSP memory banks. Other memory or register banks were not tested yet.
|-
| Early boot control || JayFoxRox
| Xcodes allow writing PCI config space. This can be used to set PCI BARs to random page-aligned addresses. Some devices like the NV2A or MCPX APU contain large register banks which can be read and written like RAM. So effectively we can probably overlay the flash memory or MCPX ROM with a temporary PCI mapping. To fill the memory, the PCI device can be mapped to a lower region, and be filled through Xcode memory writes.
This can be used to take control over code contained in RAM (FBL / 2BL), flash or possibly even the MCPX ROM during boot. This attack could be used to avoid unmapping the MCPX ROM and is therefore quite powerful. However, it requires knowledge of the Xcodes.
| This has not been tested during real-mode or early boot yet, but is assumed to work. It was tested from protected mode by mapping USB1 over the Flash and MCPX ROM region (main RAM has not been tested yet). Mapping the overlay pages without caching resulted in crashes. However, the PD was not reviewed at the time and might have been broken (through unconventional use of MmMapIoSpace).
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain:
* Map PCI devices over the MCPX ROM region
* Schedule a reset
* Keep reading MCPX ROM memory with CPU to persistent page
* If we are lucky, the CPU would now copies the MCPX ROM to RAM in it's last cycles with a broken LDT (this depends on how LDTs work and if they can recover)
| Failed: I've tried reading MCPX ROM memory for as long as possible using the CPU. I've tried resets using PM26 (assumed PWRBTN), SMC Soft (0x01) and SMC Hard (0x40).
Memory was read based on observing value changes (in PCI regions, signalling reset), and timing alone (X cycles after starting reset).
The MCPX ROM region access always crashed. Shadowing the MCPX ROM with a PCI device does not help: The CPU never observed the PCI devices being remapped / lost.
As MCPX and CPU are both reset by the SMC directly, this is not surprising.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain:
* Map PCI devices over the MCPX ROM region
* Check if NV2A can access the mapped PCI device
* Configure NV2A to continously stream from MCPX ROM region to RAM - Reset system using SMC (idea: this resets the PCI device mappings in the MCPX and should re-enable the MCPX ROM)
* If we are lucky, the NV2A would now stream the MCPX ROM to RAM in it's last cycles with a broken LDT (this depends on how LDTs work and if they can recover)
| Concept only: No interest in experimenting with NV2A DMA.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain: On a warm boot, the x86 might do a bad boot (the following is a theory, someone please measure pins). Theroy: PWRGD is provided, but CPURST is still high from the previous run; CPURST might only go low once NV2A reboots:
* Map device in NV2A to MCPX ROM region (note: mapping MCPX device would not work, because that gets reset with PWRGD)
* Warm reset using SMC
* Code in NV2A device should now jump to lower memory and unmap the MCPX ROM region (by moving itself for example)
* Delay by X cycles [probably in the range from 1ns to idk.. 500ms] to avoid reading the MCPX ROM before MCPX reset
* Code in lower region should copy MCPX ROM region to persisting pages
| Concept only: Someone should measure the pins and possibly look into the memory signals. This is too time consuming for me.
|-
| Unknown || JayFoxRox
| Partial system reset using 0xCF9 I/O register
| Resetting through 0xCF9 lands us on a black screen and the LED flashes as if the DVD tray was being opened. It's currently assumed that 0xCF9 only resets peripherals and NV2A / CPU, but it does not seem to reset the MCPX itself (hence issues booting and PCI activity which causes LED to flash). This has not been tested yet. An idea to confirm this, might be to map a device at 0xFFFFFFF0 which places an x86 jump to a good memory page. If the MCPX really isn't reset, then the CPU would boot from the MMIO / known page.
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to find problems with the SMC reset chain. The SMC takes a couple of milliseconds to reset the system. Parts of the peripherals might stay alive for long enough. So chances (extremly unlikely) are, the peripherals could be programmed to do DMA where the DMA is only executed after the reboot.
| Failed: An attempt was made to use the APU GP DSP DMA to continuously store x86 code where 2BL would unpack. The system was then reset using the SMC. It booted normally. It is assumed that the DMA is probably long dead by the time that the 2BL is being unpacked / ran.
|-
| Unknown || JayFoxRox
| Resetting from wrong address. The errata for the CPU states that a warm-reset might occur from the wrong address.
| Concept only: Needs more research
|-
| Dumping the MCPX ROM || JayFoxRox
| Trying to access MCPX ROM through peripherals in the southbridge. If the address logic is broken, parts like the OHCI, APU or AC97 might be able to access it still.
|
* AC97: Lots of crashes / hangs. Sometimes crackling noise. Sometimes does not crash. Also can access some non-existing memory regions without any crashes. Data read from invalid addresses seemed to be 300 Hz square wave. While crashing the hardware output will have exponential falloff (measured on PCM line-out).
* APU: Mapping GP DSP Scratch memory from 0x00000000 to 0x7FFFFFFF reveals mirrors of physical RAM. Setting the highest bit (addresses over 0x80000000) will result in a crash of the Xbox.
* OHCI: Untested
* Others: Untested
|-
| Dumping Kernel INIT || JayFoxRox
| INIT is free'd right before passing execution to the first XBE. Depending on what the XBE allocates, the INIT section might still be in memory when a dumper is run.
| Probably doesn't work. Would need the dumper to directly run after cold-boot. Softmods unfortunately reboot the Xbox and during this warm-boot the INIT section is (in at least most cases) lost.
|-
| Dumping Kernel INIT || DaveX || An extension to JayFoxRox dumping idea. Instead of running a dumper-XBE through a softmod, the softmod itself could do the dumping. This means creation of a custom softmod, just for dumping. This depends on the used softmod entry-point (font-exploit (signed target xbe), audio-exploit, ..) to gain execution as early as possible. This strategy might be slightly risky as harddisk contents have to be modified for the temporary softmod.
| WIP as of 2018-09-12
|-
| rowspan="13" | Homebrew entry point || rowspan="13" | Community
| rowspan="13" | Some movie DVDs contain default XBEs signed to run on original Xbox from DVD-ROM. The XBE extracts the actual game XBE (which is signed to run from HDD) onto the cache drives. If we can find a vulnerability in one of them (loaded files), we could possibly take over the entire system and run a softmod from DVD+R. In order to make a bootable DVD+R, you must have a DVD burner that - either natively, or by custom firmware - can set booktype to DVD-ROM. From a small sample size, it appears that the drive must also be capable of setting the layertype on the disc to "read-only", which is a very rarely used security feature apparently only present for Xbox, Xbox 360, and an Audi navigation system. Layertype is a rather unknown thing, and it appears DVD burners were accidentally set with this from factory, but regular burner drives could potentially have the layertype modified using custom firmware (as the Burnermax payload does for dual layer DVDs).
|-
|'''Hulk (Special Edition)'''

UPC 2519224892

[[The Hulk]]

This DVD is unique and contains a partial dashboard (5860 with 4831 libraries) with an xboxdash.xbe signed to run from DVD-ROM. The default.xbe calls this dashboard XBE with parameters to play a video on the disc. By swapping this XBE with the default.xbe, you can boot the dashboard to a blank sphere. By placing dashboard 4920's mainmenu5.xip in the xboxdash folder, you can restore the orb and menu options, but selecting an option will show a blank sphere after the zoom animation. All xips are loaded from DVD and are hash checked. Font/audio files are loaded from HDD and hash checked. Aside from xboxdash.xbe, default.xbe will load video_ts.ifo and an audio file from cdrom, so a vulnerability could be found in those.

Untested
|-
|'''Star Wars: Clone Wars - Volume One'''

UPC 2454317005

[[Republic Commando]]

Untested
|-
|'''Star Wars: Clone Wars - Volume Two'''

UPC 24543214137

[[Battlefront II]]

Untested
|-
|'''Star Wars: Episode III - Revenge of the Sith (Widescreen Edition)'''

UPC 5039036023238

[[Battlefront II]]

Untested
|-
|'''Star Wars Trilogy (Widescreen Edition with Bonus Disc)'''

UPC 24543123415 or 5039036017374

[[Star Wars Battlefront]]

Untested
|-
|'''Star Wars Trilogy DVD (Widescreen theatrical edition)'''

UPC 24543559856

[[Lego Star Wars 2]]

Untested
|-
|'''The Chronicles of Riddick (Widescreen Unrated Director's Cut)'''

UPC 5050582274639

[[Chronicles of Riddick]]

Untested
|-
|'''Doom (Unrated Widescreen Edition)'''

UPC 25192031229

[[Doom 3]]

Untested
|-
|'''King Arthur - The Director's Cut (Widescreen Edition)'''

UPC 786936265262

[[King Arthur]]

Untested
|-
|'''Robots (Widescreen Edition)'''

UPC 24543193845

[[Robots]]

Untested
|-
|'''Van Helsing (Widescreen Edition)'''

UPC 25192326622 or 25192586125

[[Van Helsing]]

Untested
|-
|'''The Godfather'''

UPC not 5014437812834 nor 14633165401 nor 014633165401

SPPV and Atreyu187 claim this exists and contains an XBE capable of chainloading any signed game XBE. No evidence exists of this actually existing on the DVD or game bonus disc, but it is listed here for posterity.

[[The Godfather: The Game]]
|}

== Notes ==

* [https://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf 17 Mistakes Microsoft Made in the Xbox Security System]
* [http://toogam.bespin.org/xboxmod/site/xbehacks.htm A list of some exploit implementations]

Boot Process

2024-01-07T00:03:56Z

Lowtolerance: /* References */ -- links now point to appropriate articles through wayback machine

This article describes the boot sequence of the Xbox.
A large portion of it is patended in [https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US6907522.pdf Patent "US 6,907,522 B2"]

== Overview ==

The Xbox has a 256 kiB ROM containing the startup animation and sound, as well as the Xbox kernel, which contains a stripped down version of the Windows 2000 (NT 5.0) microkernel, the HAL, filesystems, as well as HDD and DVD drivers.

When the Xbox is turned on, the software in ROM is decompressed into RAM, and the kernel initializes the hardware. Because there are no audio or video drivers in the kernel, the startup code plays the animation and sound by accessing the registers of the hardware directly. As soon as the Xbox logo is on the display, the kernel unlocks the hard disk and checks whether there is a valid game medium in the DVD drive. If not, the file xboxdash.xbe gets loaded from partition #3 (Typically the [[Dashboard]]). In either case, the Microsoft logo is shown below the Xbox logo and the executable is started. If an error occurs (no/wrong hard disk, wrong signature, ...), the boot loader shows a [[Fatal Error]] screen and halts.

=== Chain of trust ===

The Xbox uses a chain of trust during the boot process:

'''MCPX X2'''

There's no chain of trust.

It behaves similar to the MCPX X3 1.0 boot, just that the MCPX ROM is not available, so the code is loaded from untrusted flash.

There are also different X-Code opcodes and keys.

'''MCPX X3 1.0'''

* MCPX ROM:
** Runs untrusted from flash X-Codes in a limited virtual-machine.
** Contains key + decrypts the 2BL using RC4.
** In success case: Go to 2BL.
** In error case: Hides ROM and intends to triple-fault.
* 2BL:
** The MCPX ROM is hidden.
** The 2BL decryption key is (overwritten with 0x00-Bytes){{FIXME|reason=Does this actually happen?}}.
** Contains keys for kernel decryption and execution; decrypts kernel using RC4 and extracts using LZX.{{FIXME|reason=I believe kernel is also hashed}}
* Kernel:
** The kernel decryption key is overwritten with 0x00-Bytes.
** The 2BL is overwritten with 0xCC-Bytes.
** Once the kernel is initialized, the INIT section is discarded.
** The kernel only runs signed [[XBE]] files from allowed media.

'''MCPX X3 1.1'''

* MCPX ROM:
** Runs untrusted from flash X-Codes in a limited virtual-machine.
** Hashes the unencrypted FBL using TEA encryption.
** In success case: Go to FBL.
** In error case: Hides ROM and intends to triple-fault.
* FBL:
** Verify 2BL image.
** Derive key from key stored in MCPX + Flash, and decrypt 2BL.
** Go to 2BL.

The rest of the boot behaves like MCPX X3 1.0.

'''Assumptions for chain-of-trust'''

* The CPU will start execution in trusted MCPX ROM.
* The MCPX ROM can not be read or modified.
* The decrypted 2BL or kernel can not be read entirely.
* All parts of the software following the MCPX are not-attackable and signed.

See [[Exploits]] for possible options to break the chain of trust.

== MCPX ROM ==

Certain things are still missing, for example, getting the CPU to 32 bit protected mode and enabling caching.{{FIXME}}

=== Xcodes ===

The xcode interpreter is common through both versions of the MCPX ROM. The high level interpretation of the MCPX ROM might look like this:

<pre>
void xcode_interpreter() {

// values are implied as x86 is just starting up
register uint32_t pc = 0; // stored in ESI register
register uint8_t opcode = 0; // stored in AL register
register uint32_t operand_1 = 0; // stored in EBC register
register uint32_t operand_2 = 0; // stored in ECX register
register uint32_t result = 0; // stored in EDI register
register uint32_t scratch = 0; // stored in EBP register

// explicitly set startup point
pc = 0xFF000080;

while (1) {
opcode = get_memory_byte(pc);
operand_1 = get_memory_dword(pc+1);
operand_2 = get_memory_dword(pc+5);

if (opcode == 0x07) {
opcode = operand_1;
operand_1 = operand_2;
operand_2 = result;
}

if (opcode == 0x02) {
result = get_memory_dword(operand_1 & 0x0fffffff);
} else if (opcode == 0x03) {
set_memory_dword(operand_1) = operand_2;
} else if (opcode == 0x06) {
result = (result & operand_1) | operand_2;
} else if (opcode == 0x04) {
if (operand_1 == 0x80000880) {
operand_2 &= 0xfffffffd;
}
outl(operand_1, 0xcf8);
outl(operand_2, 0xcfc);
} else if (opcode == 0x05) {
outl(operand_1, 0xcf8);
result = inl(0xcfc);
} else if (opcode == 0x08) {
if (result != operand_1) {
pc += operand_2;
}
} else if (opcode == 0x09) {
pc += operand_2;
} else if (opcode == 0x10) {
scratch = (scratch & operand_1) | operand_2;
result = scratch;
} else if (opcode == 0x11) {
outb(operand_2, operand_1);
} else if (opcode == 0x12) {
result = inb(operand_1);
} else if (opcode == 0xee) {
break;
}

pc += 9;
}
}
</pre>

=== RC4 Decryption of the 2BL (MCPX 1.0 only) ===

Version 1.0 of the ROM uses RC4 to decrypt the 2BL.
The RC4 algorithm was included as part of MCPX 1.0 and seems to work fine with BIOS versions 3944, 4034, and 4134.

==== Stage 1: Key Scheduling ====

The [https://en.wikipedia.org/wiki/RC4#Key-scheduling_algorithm_.28KSA.29 RC4 Key-Scheduling Algorithm] is used to initialize the RC4 “S” array, first initializing the identity permutation (writing 1, 2, ..., 255 to 0x8F000 to 0x8F0FF), then processed in a way similar to the PRGA to mix in the key.

<pre>
uint8_t *s = (uint8_t *)0x8f000;
uint32_t i;

for (i = 0; i <= 255; i++) {
s[i] = i;
}

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;
}
</pre>

==== Stage 2: PRGA ====

The [https://en.wikipedia.org/wiki/RC4#Pseudo-random_generation_algorithm_.28PRGA.29 RC4 Pseudo-random generation algorithm (PRGA)] is then used to decrypt the 2BL from 0xFFFF9E00, storing the decrypted 2BL at 0x00090000. It is 24KiB in size.

<pre>
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] ];
}
</pre>

==== Stage 3: Signature Verification ====

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. If the signature does match, the code will jump to the 2bl entry point, which is given by the first dword of the decrypted 2bl.

<pre>
mov eax, [0x95fe4]
cmp eax, MAGIC_NUMBER
jne 0xffffff94 ; If signature check failed, jump to error handler
mov eax, [0x90000]
jmp eax ; Jump to 2BL entry point
</pre>

=== TEA Decryption of the FBL (MCPX 1.1 only) ===

{{FIXME}}

== FBL (MCPX 1.1 only) ==

The Flash Boot Loader was added in MCPX 1.1, it connects the MCPX ROM and the 2BL.{{FIXME}}
It is not part of the MCPX ROM, but part of the flash.

== 2BL ==

{{FIXME|reason=Certain parts are still missing.}}

=== MTRR Setup ===

First, the cache is disabled.{{FIXME}}
Then, the MTRR (Memory Type Range Register) will be setup (using <code>wrmsr</code>) in the following way:

{| class="wikitable"
! MTRR (ecx) !! High value (edx) !! Low value (eax) !! Notes
|-
|0x200 || 0x00000000 || 0x00000006 ||
|-
| rowspan = "2" | 0x201 || rowspan = "2" | 0x0000000F || 0xFC000800 || ''(For 64 MiB RAM BIOS)''
|-
|0xF8000800 || (''For 128 MiB RAM BIOS'')
|-
|0x202 || 0x00000000 || 0xFFF80005 ||
|-
|0x203 || 0x0000000F || 0xFFF80800 ||
|-
|0x204 || 0x00000000 || 0x00000000 || rowspan="3" | Clear all unused MTRR
|-
| colspan = "3" | ...
|-
|0x20F || 0x00000000 || 0x00000000
|-
|0x2FF || 0x00000000 || 0x00000800 ||
|}

Once the MTRR have been written, the cache is enabled.{{FIXME}}

=== Register setup ===

Now the 2BL will set up the segment registers{{FIXME|reason=why?!}} and stack:

{| class="wikitable"
! Register !! Value !! Notes
|-
|ds || 0x0010 || rowspan="3" | Data segment{{citation needed}}

|-
|es || 0x0010

|-
|ss || 0x0010

|-
|esp || 0x00400000 ||

|-
|fs || 0x0000 ||

|-
|gs || 0x0000 ||
|}

=== Self-copy ===

Now the 2BL copies itself (24 kiB) from 0x00090000 to memory address 0x00400000.

=== Paging ===

Now a PDE is prepared at address 0x0000F000:

{| class="wikitable"
! Offset in PDE !! Value !! Notes
|-
|0x800 || 0x000000E3 || rowspan="7" | Identity maps the first 256MiB of RAM: 0x80000000 and 0x00000000 will each map to physical page 0 0xE3: Flags: * 0x80: 4 MiB page * 0x40: Marked as previously written (Dirty) * 0x20: Marked as previously accessed * 0x02: Read/Write * 0x01: Present
|-
|0x000 || 0x000000E3
|-
|0x804 || 0x004000E3
|-
|0x004 || 0x004000E3
|-
| colspan="2" | ...
|-
|0x8FC || 0x0FC000E3
|-
|0x0FC || 0x0FC000E3
|-
|0x900 || 0x00000000 || rowspan="5" | Unmapping the rest of the pages
|-
|0x100 || 0x00000000
|-
| colspan="2" | ...
|-
|0xFFC || 0x00000000
|-
|0x7FC || 0x00000000
|-
|0xC00 || 0x0000F063 || Maps the PDE (4 kiB page) to address 0xC0000000 0x63: Flags: * 0x40: Marked as previously written (Dirty) * 0x20: Marked as previously accessed * 0x02: Read/Write * 0x01: Present
|-
|0xFFC || 0xFFC000E3 || Identity maps the upper portion of the Flash (4 MiB page) to address 0xFFC00000 0xE3: Flags: * 0x80: 4 MiB page * 0x40: Marked as previously written (Dirty) * 0x20: Marked as previously accessed * 0x02: Read/Write * 0x01: Present
|-
|0xFD0 || 0xFD0000FB || rowspan="4" | Maps 16 MiB for the GPU control registers 0xFB: Flags: * 0x80: 4 MiB page * 0x40: Marked as previously written (Dirty) * 0x20: Marked as previously accessed * 0x10: Cache disabled * 0x08: Write-Through caching * 0x02: Read/Write * 0x01: Present
|-
|0xFD4 || 0xFD4000FB
|-
|0xFD8 || 0xFD8000FB
|-
|0xFDC || 0xFDC000FB
|}

After setting up the PDE, the PAT is set up using <code>wrmsr</code>: {{FIXME}}

CR4 is touched {{FIXME}}

CR3 is touched {{FIXME}}

Now paging is activated by enabling the PG and WP bits in CR0.
Additionally, the same <code>or</code> instruction is used to enable the NE bit in cr0.

=== 2BL main ===

esp is now also reloaded to point at the relocated address. It will be set to 0x80400000 (absolute value, independent of previous esp value).
The 2BL will now <code>call</code> into the relocated 2BL code somewhere near 0x00400000.

==== Disabling of the MCPX ROM ====

<pre>
out32(0xCF8, 0x80000880);
out8(0xCFC, 0x02);
</pre>

==== SMC handling ====

The [[SMC]] has a watchdog functionality which must be turned off.
This is done by querying the SMC registers 0x1C - 0x1F.
If all of them are 0x00 the 2BL will shutdown the system{{FIXME}}.
If this is not the case, the bootloader calculates the watchdog challenge response and sends it to SMC registers 0x20 and 0x21.

Additionally, the 2BL will set SMC register 0x01 to 0 (which resets the cursor position for reading the SMC revision information).

==== Enable IDE and NIC ====

<pre>
out32(0xCF8, 0x8000088C);
out32(0xCFC, 0x40000000);
</pre>

==== Memory cleanup ====

The 2BL fills memory with 0xCC from 0x80090000 to 0x80095FFF. These are the 24 kiB where the 2BL was stored previously.

==== Setup RAM timing ====

Not described yet, this is complicated{{FIXME}}.
This got a lot more complicated when Microsoft started using different RAM sometime after [[Hardware Revisions#1.6|Hardware Revision 1.6]] was already out.

==== Configure LDT bus ====

DWORD flow control is enabled in the MCPX.

<pre>
out32(0xCF8, 0x80000854);
out32(0xCFC, in32(0xCFC) | 0x88000000);
</pre>

DWORD flow control is also enabled in the NV2A core.

<pre>
out32(0xCF8, 0x80000064);
out32(0xCFC, in32(0xCFC) | 0x88000000);
</pre>

The LDT bus is reset.

<pre>
out32(0xCF8, 0x8000006C);
uint32_t tmp = in32(0xCFC);
out32(0xCFC, tmp & 0xFFFFFFFE);
out32(0xCFC, tmp);
</pre>

The rest is unknown{{FIXME}}.

<pre>
out32(0xCF8, 0x80000080);
out32(0xCFC, 0x00000100);
</pre>

==== Enable USB ASRC ====

The USB controller's "automatic slew rate compensation" feature is enabled for MCPX revisions D01 and later.

<pre>
out32(0xCF8, 0x80000808);
uint8_t mcpx_revision = in8(0xCFC);

if (mcpx_revision >= 0xD1) {
out32(0xCF8, 0x800008C8);
out32(0xCFC, 0x00008F00);
}
</pre>

==== Loading the kernel ====
===== Kernel-copy =====

The Kernel is now copied into RAM.

===== Kernel decryption =====

The 2BL will copy the kernel decryption key (16 bytes) from offset 32 of an array of 3 keys:

{| class="wikitable"
! Offset !! Use
|-
| 0 || EEPROM key
|-
| 16 || Certificate key
|-
| 32 || Kernel key
|}

The Kernel is then decrypted in-place using RC4.

===== Kernel decompression =====

The Kernel is decompressed directly to 0x80010000 where it will reside until a full system shutdown.

==== Running the kernel ====

The xboxkrnl.exe header at 0x8001000 is checked{{FIXME|reason=how?}}.
If it is invalid, {{FIXME}}.
If it is valid, the kernel entry point is looked up from the PE optional header. The hardcoded image base of 0x8001000 is added to the entry point.
The entry-point is now being called. Argumnts are passed on the stack, from right to left.
The first argument is a commandline string loaded from memory address 0x80400000. It is an empty string for retail BIOS{{FIXME|reason=Mention options for debug bioses here}}.
A pointer to the previously mentioned array of 3 keys is passed as the second argument.

== Kernel ==

=== Initialization ===

==== Stage 1 (Cold-boot only) ====

The entry point to the kernel will first parse the arguments.{{FIXME}}
At the end, the kernel will call the initialization routine for what we'll refer to as: Stage 2a.

==== Stage 2 (Cold-boot only) ====

The kernel initialization will only happen once on a cold-boot. It will not happen for reboots.

* ebp is set to 0x00000000
* esp is modified{{FIXME}}
* GDT is prepared{{FIXME}} and loaded{{FIXME}}
* cs and ds are reloaded
* fs is set{{FIXME}}
* TSS is loaded{{FIXME}}
* cr3 is moved to 3 tasks{{FIXME}}
* The CPU microcode is updated

After this comes Stage 3 initialization which will also be repeated on kernel re-initialization.

==== Stage 3 ====

This is code which is duplicated in INIT and .text sections.
* In the INIT section it directly follows the Stage 2 initialization.
* In the .text section it follows the Kernel re-initialization code mentioned below.

This code does the following:

* IDT is prepared{{FIXME}} and loaded{{FIXME}}
* {{FIXME|reason=a lot more happens here.. If you want to RE this: look into the HalReturnToFirmware code [last call is to Stage 2b]; the kernel entry point [last call is to Stage 2a]; or just search for lidt instructions}}

=== Re-initialization ===

On reboots, initialization Stage 1 and 2 are not in memory anymore (as the INIT section has been discarded), and can't be run anymore.
Instead, a seperate function replaces their functionality and then jumps directly to Stage 3 initalization.

This code is the partial kernel reinitialization, which will be ran on reboots using [[Kernel/HalReturnToFirmware]].

* ebp is set to 0x00000000
* esp is modified{{FIXME}}
* Some memory stuff in a seperate function{{FIXME}}
* The .data section from [[Flash]] is loaded and replaces the running .data
* The byte infront of KeSystemTime is set to 0x01, indicating the system comes from a reboot.

After this has completed, [[#Stage 3]] of the kernel initialization will take over.

==== Skipped initialization ====

When rebooting, certain parts are still initialized and assumed to be working:

(This list is currently in no particular order and incomplete)

* Anything already done by Stage 1 and Stage 2
* PCI device setup
* EEPROM decryption{{FIXME}}
* Check for AV-Pack{{FIXME}}
* Video mode setup (boot animation is not played again)
* Some IDE stuff{{FIXME}}
* Some SMC stuff{{FIXME}}
* Memory allocator initialization{{FIXME}}
* Kernel debugger (Super-I/O) initialization{{FIXME}} (This still seems to be in memory?!){{citation needed}}

=== Startup animation ===

== References ==

* [https://web.archive.org/web/20141024145145/http://hackspot.net/XboxBlog/?p=1 Understanding the Xbox boot process]
* [https://web.archive.org/web/20150612173331/https://mborgerson.com/deconstructing-the-xbox-boot-rom Deconstructing the Boot ROM]