PSJailbreak Exploit Payload Reverse Engineering: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
CelesteBlue (talk | contribs) m (Reverted edits by 5.173.244.156 (talk) to last revision by CelesteBlue) Tag: Rollback |
||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
== | = 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 %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 | |||
</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'. | |||
---- | ---- | ||
# | === The Payload === | ||
#exploit_main copies a resident part of the payload to another location, creates | |||
# | 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 = | |||
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: | |||
<pre># --------------------------------------------------------------------------- | <pre> | ||
# --------------------------------------------------------------------------- | |||
struct_patch_table struc # (sizeof=0x8) | struct_patch_table struc # (sizeof=0x8) | ||
addr_offset: .long ? # offset | addr_offset: .long ? # 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> | |||
{{ | {{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:
- 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.
- 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.
- 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.
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
| |||||||||||||||||||||
