Porting tool crashes on 4.02

[burninrubber0]

Running the ps5-kstuff porting tool on a 4.02 PS5 results in it crashing when probing the mini_syscore_header offset. The same behavior was also reported by zecoxao on a testkit.

[sleirsgoevy]

Please provide the full error as printed by the tool.

[burninrubber0]

As far as I can tell, there is no error being output. The PS5 simply panics as this point. The full output of a fresh run is provided below regardless, up to the point of disconnection.

burninrubber0@WHITEBEASTV2:/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool$ python3 main.py symbols.json 192.168.1.187 9020 kernel-data.bin
1 offsets currently known
62 offsets to be found
Probing offset `idt`
rm -f payload.elf payload.bin r0run.o prosper0gdb.o
yasm -f elf64 -g dwarf2 r0run.asm -o r0run.o
gcc -O0 -g -isystem ../freebsd-headers -nostdinc -nostdlib -fno-stack-protector -r -Wl,--unique='*' -ffunction-sections -fdata-sections -DMEMRW_FALLBACK -DNO_BUILTIN_OFFSETS r0gdb.c r0run.o offsets.c -o prosper0gdb.o -fPIE -ffreestanding -fno-unwind-tables -fno-asynchronous-unwind-tables
/usr/bin/ld: warning: r0run.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
gcc -O0 -g -isystem ../freebsd-headers -nostdinc -nostdlib -fno-stack-protector -static ../lib/lib-elf.a -DMEMRW_FALLBACK -DNO_BUILTIN_OFFSETS main.c prosper0gdb.o dbg.c -o payload.elf -fPIE -ffreestanding -Wl,-no-pie -Wl,-zmax-page-size=16384 -Wl,-zcommon-page-size=16384
/usr/bin/ld: warning: ../lib/lib-elf.a: requires executable stack (because the .note.GNU-stack section is executable)
objcopy payload.elf --only-section .text --only-section .data --only-section .bss --only-section .rodata -O binary payload.bin
python3 ../lib/frankenelf.py payload.bin
Connecting to PS5... done
Connecting GDB... warning: remote target does not support file transfer, attempting to access files from local filesystem.
done
dumping kdata... 140509184
offset found! idt = 0x64cdc80
Probing offset `gdt_array`
offset found! gdt_array = 0x64cee30
Probing offset `tss_array`
offset found! tss_array = 0x64d0830
Probing offset `pcpu_array`
offset found! pcpu_array = 0x64d2280
Probing offset `sysentvec`
offset found! sysentvec = 0xd11bb8
Probing offset `sysentvec_ps4`
offset found! sysentvec_ps4 = 0xd11d30
Probing offset `sysents`
offset found! sysents = 0x1709c0
Probing offset `sysents_ps4`
offset found! sysents_ps4 = 0x168410
Probing offset `mini_syscore_header`

##################################################################################
# Cannot ping PS5. It has probably panicked or hung. Restart the PS5 to proceed. #
##################################################################################

PS5 disconnected, retrying mini_syscore_header...
Connecting to PS5...

[sleirsgoevy]

Remove line 191, then try again.

[burninrubber0]

It now produces the following after disconnecting:

Traceback (most recent call last):
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/main.py", line 1325, in <module>
    try: value = i()
                 ^^^
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/main.py", line 195, in mini_syscore_header
    remote_fd = gdb.ieval('(int)open("/mini-syscore.elf", 0)')
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/gdb_rpc.py", line 187, in ieval
    ans = self.eval(expr, timeout, 'int')
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/gdb_rpc.py", line 185, in eval
    return self._read_eval(timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/gdb_rpc.py", line 164, in _read_eval
    ln = self._read_until(b'\n', tl)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/gdb_rpc.py", line 159, in _read_until
    raise DisconnectedException("read failed")
gdb_rpc.DisconnectedException: read failed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/main.py", line 1327, in <module>
    raise Exception("failed to derive `%s`, see above why"%i.__name__)
Exception: failed to derive `mini_syscore_header`, see above why

[sleirsgoevy]

Does it panic at that point?

[burninrubber0]

Yes, it always panics there with the same error.

[sleirsgoevy]

Add the following line to the beginning of the function:

    gdb.execute('set logging file /tmp/log.txt\nset logging enable on\nset debug remote on')

And send the contents of the log file.

[burninrubber0]

That gives the following error. Doesn't execute anything on the PS5, no log file.

Traceback (most recent call last):
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/main.py", line 1326, in <module>
    try: value = i()
                 ^^^
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/main.py", line 193, in mini_syscore_header
    gdb.execute('set logging file /tmp/log.txt\nset logging enable on\nset debug remote on')
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/gdb_rpc.py", line 178, in execute
    assert self.popen != None
           ^^^^^^^^^^^^^^^^^^
AssertionError

[sleirsgoevy]

OK, my bad. You need to put it right after the "use_r0gdb" line.

[burninrubber0]

Nothing was written to the log file for some reason (o bytes) but there was more output from the command. Hopefully it's what you were looking for, see attached. output.txt

[sleirsgoevy]

Can you send here your prosper0gdb/payload.elf? Do NOT rebuild it, send the file as it remains from running the tool.

[burninrubber0]

Sure, here you go. payload.elf.zip

[sleirsgoevy]

OK, so it seems that the PS5 is actually panicking when trying to read the file /mini-syscore.elf. Does FTP work for you with that file?

[burninrubber0]

Interesting. I hadn't tried before, but it seems that even when support for 4.02 is claimed (e.g. for FTPS5) it always panics. I've tried a few payloads now with the same result. So in short, I don't know whether FTP will work with the file, because FTP itself doesn't work. (And nothing else does either - maybe untested on 4.02?)

[sleirsgoevy]

payload.bin.zip

OK, so I built a simple payload that just opens mini-syscore.elf, and does nothing else. Does it work for you?

[burninrubber0]

Nope, just panics.

[sleirsgoevy]

Cursed.

[burninrubber0]

IDK if you're on it already, but it'd worth getting zecoxao to test this stuff as well. At least it'd rule out my specific console as the problem, or a skill issue lol. But given he had the same issues with the porting tool, yeah, not looking good.

Also, is there any chance this is an issue with the jailbreak itself rather than the tools/payloads?

[sleirsgoevy]

There is always such a chance, but I don't know any good way to rule that out. You can try comparing the offsets you've already got to those in the WebKit exploit, maybe you'll find some difference there.

[sleirsgoevy]

main.py.zip

Try running this file, it should dump your /dev/md0 to a file and terminate. Then send this file to me.

[burninrubber0]

Didn't work unfortunately. I see it's meant to output md0.img but it seems it doesn't get that far. output2.txt

[sleirsgoevy]

Sorry, it should've been gdb_rpc.DisconnectedException, not gdb.DisconnectedException. Me sending untested code again.

[burninrubber0]

Still no dump output I'm afraid. output3.txt

[sleirsgoevy]

You've interrupted an attempt to connect to the console. Just wait until it reboots and load the exploit host again.

[burninrubber0]

Ah so I need to reboot? Got it, will give it a go.

[burninrubber0]

It tried after a reboot as you said, but doesn't seem to have completed. Panicked shortly after it said it was dumping, no md0.img to be seen. Doesn't do anything after a second reboot. output4.txt

[sleirsgoevy]

Not good. Either this is an issue with the exploit, or this firmware is just cursed. I kinda hope it's the first.

[sleirsgoevy]

main.py.zip

Run this, and send me the output.

[burninrubber0]

More untested code I believe? :smile:

Traceback (most recent call last):
  File "/mnt/d/Repos/sleirsgoevy/ps4jb-payloads/ps5-kstuff/porting_tool/main.py", line 115, in <module>
    @derivations
     ^^^^^^^^^^^
TypeError: 'list' object is not callable

[sleirsgoevy]

Yes, f*cking autocomplete completed the wrong symbol. Should've been derive_symbol, of course.

[burninrubber0]

Alright, here's the output. output5.txt

[sleirsgoevy]

Added code to the porting tool to find the rootvnode offset. It will now print a warning with the correct offset if opening files keeps failing.

[burninrubber0]

rootvnode offset is 0x66E74C0 just like 4.00 and 4.03. I guess someone made a typo originally, stupid that it cost this much time.

I've spent the last few hours getting the offsets. The attached file has everything up to the "launch a PS4 fake package" message. Unfortunately that's as far as I've been able to get because the debug settings don't appear, so I can't install a package. symbols.json

[burninrubber0]

All offsets found. Closing as the issue is resolved. Thanks a bunch! symbols.json