Difference between revisions of "Exploits"

From xboxdevwiki
Jump to: navigation, search
m (→‎Savegames: Added the Frogger exploit (as seen in presentations) and recent addition THPS4 (grimdoomers work))
 
(32 intermediate revisions by 8 users not shown)
Line 7: Line 7:
 
=== Visor hack ===
 
=== Visor hack ===
  
−
Exploits incorrect rollover of memory address.
+
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 ===
 
=== MIST hack ===
  
−
Exploits error in xcode interpreter security check.
+
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.
−
There are at least 2 variations of this hack.
+
 
 +
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 ===
 
=== A20M# hack ===
  
−
Uses a legacy x86 feature.
+
[[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) ===
 
=== RC4 attack (MCPX 1.0 only) ===
Line 28: Line 33:
 
When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.
 
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.''
+
''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 attack (MCPX 1.1 only) ===
Line 39: Line 45:
 
When flipping the highest bit of the operand DWORD (at 0xffffd400, mind your endianess) this will become: <code>E9 83 01 80 00</code>.
 
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).
 
This is <code>jmp 0x7fd588</code> (which is a jump into the RAM region).
−
For the attack to be succssful, the highest bit in the DWORD at 0xffffd404 also has to be flipped.
+
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.
 
The RAM can be controlled using the x-code command to write to RAM.
Line 50: Line 56:
 
When the attack happens, the MCPX ROM is still visible, making this a very powerful attack.
 
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 Bunnnies book (Page 109 and Page 142).''
+
''The TEA algorithm and exploit are also described in more detail in Bunnie's book (Page 109 and Page 142).''
  
 
== Dashboard ==
 
== Dashboard ==
Line 56: Line 62:
 
=== Audio hacks ===
 
=== Audio hacks ===
 
=== Font hacks ===
 
=== Font hacks ===
 +
 +
[http://archiv.sega-dc.de/phoenix.maxconsole.net/docs/berternie.inc.htm Analysis of "Bert & Ernie" font-exploit].
  
 
==== Easter-egg exploit ====
 
==== Easter-egg exploit ====
  
 
== Savegames ==
 
== 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].
  
−
=== [[007: Agent Under Fire]] ===
 
 
=== [[Frogger Beyond]] ===
 
=== [[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]] ===
 
=== [[MechAssault]] ===
 +
 +
Exploit runs a modified version of Xbox Live Update to execute a paylaod.
 +
 
=== [[Tom Clancy's Splinter Cell]] ===
 
=== [[Tom Clancy's Splinter Cell]] ===
 
=== [[Tony Hawk's Pro Skater 4]] ===
 
=== [[Tony Hawk's Pro Skater 4]] ===
−
[https://www.xbmc4xbox.org.uk/forum/viewtopic.php?t=7310]
+
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 ==
 
== Notes ==

Latest revision as of 23:40, 9 January 2024

MCPX

LDT (Hypertransport) bus tap

See 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

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.


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 [1][2]. And yet, Microsoft used it that way.

The original attack uses the 5 bytes at 0xffffd400 (FBL entry point) which are E9 83 01 00 00. This is jmp 0xffffd588 (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: E9 83 01 80 00. This is jmp 0x7fd588 (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

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] [3]

007: Agent Under Fire

Analysis of this savegame-exploit.

Frogger Beyond

Not much is known why this game was in the list, 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.

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. 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. xbmc4xbox.org.uk

Attack ideas

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
Homebrew entry point Community 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

Retrieved from "https://xboxdevwiki.net/index.php?title=Exploits&oldid=7351"