[ps5-kstuff] Firmware offsets meta-issue

[SevenDice]

I ran your porting_tool and found offsets. I hope this will be useful for porting the exploit to firmware 3.20
symbols.json

[sleirsgoevy]

Send a pull request to Echo Stretch's fork of this repository. They're collecting a database of offsets.

[oden1sy]

I found all of the offsets for 3.00 firmware as well...not sure where to put them :)

Correction on the upload :)

symbols.json

[sleirsgoevy]

Good news that now everybody updated to 4.03 yet.

[oden1sy]

I hope this helps the process for 3.00. :)

[Cerebral-Context]

Good work everyone!

[KsAmJ]

I ran your porting_tool and found offsets. I hope this will be useful for porting the exploit to firmware 3.20 symbols.json

Do anyone need to rerun the tool or that's all of them?

[sleirsgoevy]

3.20 offsets are already in the source, sorry. The last offset should've been "crypt_message_resolve".

[sleirsgoevy]

Firmware 3.00 added. Now theoretically supported (but not yet tested): 3.00, 3.20, 3.21, 4.03, 4.50, 4.51. Other firmwares are welcome!

[Goon3r]

How long should dumping kdata... take when exeuting the porting tool? Feel like it hangs every time i try run the tool. PS5 3.20.

EDIT: Definitely hanging without error. Any ideas on how to fix or ways to increase verbosity to help debug this @sleirsgoevy?

[sleirsgoevy]

3.20 is already probed, no need to do that. But if you want to do it anyway, make sure you are not using WSL2, and if you're using Linux in a VM set your network to bridged.

[Goon3r]

3.20 is already probed, no need to do that. But if you want to do it anyway, make sure you are not using WSL2, and if you're using Linux in a VM set your network to bridged.

Cheers for getting back to me.

I'm currently developing a Docker image to simplify execution of the tool, 3.20 is the only system i have access to test against atm, but hopefully it will make it easier for people to grab offsets for other versions. You can view it here: https://github.com/Goon3r/ps5-kstuff-porting-tool-docker

It seems im able to successfully connect to the PS5, it just hangs on dumping of kernel data. Docker by default uses a bridge network ofcourse.

Output log

1 offsets currently known
63 offsets to be found
Probing offset `rootvnode`
rm -f payload.elf payload.bin r0run.o prosper0gdb.o
cd ../lib; make
make[1]: Entering directory '/kstuff/tool/lib'
yasm -f elf64 crt.asm
yasm -f elf64 rfork.asm
gcc -c -isystem ../freebsd-headers -nostdinc -fno-stack-protector dl.c -o dl.o -fPIE -ffreestanding
python3 syscalls.py > syscalls.asm
yasm -f elf64 syscalls.asm
ld -r crt.o rfork.o dl.o syscalls.o -o lib.a
python3 syscalls-ps5.py > syscalls-ps5.asm
yasm -f elf64 syscalls-ps5.asm
ld -r crt.o dl.o syscalls-ps5.o -o lib-ps5.a
yasm -f elf64 crt-elf.asm
gcc -c -isystem ../freebsd-headers -nostdinc -fno-stack-protector -O3 crt-elf-c.c -o crt-elf-c.o -fPIE -ffreestanding
ld -r crt-elf.o crt-elf-c.o dl.o syscalls.o -o lib-elf.a
make[1]: Leaving directory '/kstuff/tool/lib'
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
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
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...

[sleirsgoevy]

For Docker, you'll want to specify the --net=host parameter to disable the network namespace for the container. The tool listens on a random port by default, and AFAIK Docker's default network configuration can only forward fixed ports.

[Goon3r]

Cheers for the reponse, still hangs when running the container with --net=host

docker run \
    -it \
    --rm \
    --mount type=bind,source="${resultDir}",target=/kstuff/results \
    --net=host \
    ps5-kstuff-porting-tool:latest "$@"

Did try run the gdp command manually that i think the process is hanging at, unsure if this is of any use?

root@docker-desktop:/kstuff/tool/ps5-kstuff/porting_tool# gdb ../../prosper0gdb/payload.elf -ex "target remote 192.168.0.167:1234" -ex "py  import sys sys.stdin = sys.__stdin__ sys.stdout = sys.__stdout__ print('ef3e7a1becb877a1ec2075ac641b36c3')  while True:     try: prompt = input()     except (EOFError, KeyboardInterrupt):         gdb.execute('quit')         break     try: ans = eval(prompt)     except gdb.error as e: ans = str(e)     print(repr([[[ans]]]))  end"
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../../prosper0gdb/payload.elf...
Remote debugging using 192.168.0.167:1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
  File "<string>", line 1
    import sys sys.stdin = sys.__stdin__ sys.stdout = sys.__stdout__ print('ef3e7a1becb877a1ec2075ac641b36c3')  while True:     try: prompt = input()     except (EOFError, KeyboardInterrupt):         gdb.execute('quit')         break     try: ans = eval(prompt)     except gdb.error as e: ans = str(e)     print(repr([[[ans]]]))  end
               ^^^
SyntaxError: invalid syntax
Error while executing Python code.
(gdb)

[sleirsgoevy]

First, you messed up the newlines in Python code, this won't work for obvious reasons. (You can actually enter newlines inside quoted shell arguments.) Second, this won't work because this barely sets up an RPC interface for the main script to use, and if you're using GDB manually you'll be better typing in GDB commands without the custom RPC.

EDIT: also try capturing a Wireshark trace of the communication, maybe that will shed some light.