jogolden / jkpatch Goto Github PK
View Code? Open in Web Editor NEWPlayStation 4 Jailbreak Kernel Patches
PlayStation 4 Jailbreak Kernel Patches
I just tried to get the new version running and successfully compiled the payload:
gcc -c -o build/resolve.o source/resolve.c -I/ps4/ps4-payload-sdk/libPS4/include -I. -Iinclude -O2 -std=c11 -fno-builtin -nostartfiles -nostdlib -Wall -masm=intel -march=btver2 -mtune=btver2 -m64 -mabi=sysv -mcmodel=large -DTEXT_ADDRESS=0x926200000 -DDATA_ADDRESS=0x926300000 gcc -c -o build/utilities.o source/utilities.c -I/ps4/ps4-payload-sdk/libPS4/include -I. -Iinclude -O2 -std=c11 -fno-builtin -nostartfiles -nostdlib -Wall -masm=intel -march=btver2 -mtune=btver2 -m64 -mabi=sysv -mcmodel=large -DTEXT_ADDRESS=0x926200000 -DDATA_ADDRESS=0x926300000 gcc -c -o build/install.o source/install.c -I/ps4/ps4-payload-sdk/libPS4/include -I. -Iinclude -O2 -std=c11 -fno-builtin -nostartfiles -nostdlib -Wall -masm=intel -march=btver2 -mtune=btver2 -m64 -mabi=sysv -mcmodel=large -DTEXT_ADDRESS=0x926200000 -DDATA_ADDRESS=0x926300000 gcc -c -o build/elf.o source/elf.c -I/ps4/ps4-payload-sdk/libPS4/include -I. -Iinclude -O2 -std=c11 -fno-builtin -nostartfiles -nostdlib -Wall -masm=intel -march=btver2 -mtune=btver2 -m64 -mabi=sysv -mcmodel=large -DTEXT_ADDRESS=0x926200000 -DDATA_ADDRESS=0x926300000 gcc -c -o build/main.o source/main.c -I/ps4/ps4-payload-sdk/libPS4/include -I. -Iinclude -O2 -std=c11 -fno-builtin -nostartfiles -nostdlib -Wall -masm=intel -march=btver2 -mtune=btver2 -m64 -mabi=sysv -mcmodel=large -DTEXT_ADDRESS=0x926200000 -DDATA_ADDRESS=0x926300000 gcc /ps4/ps4-payload-sdk/libPS4/crt0.s build/*.o -o temp.t -I/ps4/ps4-payload-sdk/libPS4/include -I. -Iinclude -O2 -std=c11 -fno-builtin -nostartfiles -nostdlib -Wall -masm=intel -march=btver2 -mtune=btver2 -m64 -mabi=sysv -mcmodel=large -DTEXT_ADDRESS=0x926200000 -DDATA_ADDRESS=0x926300000 -L/ps4/ps4-payload-sdk/libPS4 -L. -Llib -Xlinker -T /ps4/ps4-payload-sdk/libPS4/linker.x -Wl,--build-id=none -Ttext=0x926200000 -Tdata=0x926300000 -lPS4 objcopy -O binary temp.t payload.bin rm -f temp.t
Using ps4-exploit-host I now then wanted to send the payload which allegedly worked:
Choose a payload to send:
Sending payload.bin...
Connected to PS4
Payload Sent!
But nothing seems to have changed on my Console. No debug settings visible and the RPC Client is unable to connect too.
I have a CUH-2016B console.
I need to implement a decent amount of code if we are to get anywhere with calling functions through RPC...
fill_regs
to get registersset_regs
to set registersset_regs
We should cache the location of the RPC call stub, so we can refer to it when making subsequent RPC function calls. This will point to a location that has a predefined structure that includes parameters/return values for call.
I know this is hacky? I may later on just refactor the whole way I go about implementing this calling protocol but meh...
But mapping a processes virtual address space in the kernel then calling it, then undoing everything would be a bad alternative, plus creating a usermode thread for each and every function call would be resource intensive. The way I have in mind (of creating a calling stub that monitors for incoming data and then calls said function) is actually not bad.
If you want to get started, look at regs.txt for structures and offsets on 4.05.
The payload seems to crash when your refreshing processes too often. Not in a short ammount of time just in general. When I reload my tool it sometime just shuts down my console when I first grab the process list.
Also shuts down sometimes when peeking memory, even if its just 0x100 in lenght.
I need to write the RPC assembly code for calling functions. This stub will be injected into a process that we would like to call functions within.
Exactly what the title says...
Standard libraries and rtld need fs:0x10 to be set as the current thread, or else a seg fault occurs...
example (this will fault)
mov rax, qword fs:0x10
But it is not so easy setting this pthread data, I feel like I need to hijack a thread instead of creating a new one. I will work on this later, may take some time as I have already tried a few hacks.
Hi,
the build of kpayload fails at linking time when using binutils 2.28:
COLLECT_GCC_OPTIONS='-o' 'kpayload.elf' '-I' '.' '-I' 'include' '-O3' '-std=gnu11' '-fno-builtin' '-fno-exceptions' '-fno-asynchronous-unwind-tables' '-nostartfiles' '-nostdlib' '-Wall' '-masm=intel' '-march=btver2' '-mtune=btver2' '-m64' '-mabi=sysv' '-mcmodel=small' '-fPIE' '-L.' '-Llib' '-v' '-pie'
/usr/lib/gcc/x86_64-linux-gnu/6/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/6/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper -plugin-opt=-fresolution=/tmp/ccmLefJU.res --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -o kpayload.elf -L. -Llib -L/usr/lib/gcc/x86_64-linux-gnu/6 -L/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/6/../../.. /tmp/ccf0OoIO.o build/fpkg.o build/fself.o build/main.o build/net.o build/proc.o build/resolve.o build/rpc.o build/uart.o build/utilities.o -T ./kpayload.x --build-id=none
/usr/bin/ld: kpayload.elf: error: PHDR segment not covered by LOAD segment
/usr/bin/ld: final link failed: Invalid operation
collect2: error: ld returned 1 exit status
Makefile:22: recipe for target 'kpayload.elf' failed
My guess is the SIZEOF_HEADERS directive in the kpayload.x SECTIONS is ignored by ld but I'm lost on how to proceed as I don't know enough about ELF sections/segments.
I've verified that that it builds OK using binutils 2.25.
Searching online I think I've found the commit that introduced the new behaviour (https://lists.gnu.org/archive/html/bug-binutils/2016-11/msg00257.html) but don't know if it's a regression or the binary produced with binutils 2.25 is broken. This is its readelf output:
Elf file type is EXEC (Executable file)
Entry point 0x120
There are 4 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000200040 0x0000000000000000 0x0000e0 0x0000e0 R 0x8
LOAD 0x000120 0x0000000000000120 0x0000000000000120 0x004ee5 0x004ee5 R E 0x200000
LOAD 0x005008 0x0000000000005008 0x0000000000005008 0x000020 0x000020 RW 0x200000
LOAD 0x005040 0x0000000000005040 0x0000000000005040 0x000000 0x0006e0 RW 0x200000
Section to Segment mapping:
Segment Sections...
00
01 .text .rodata
02 .data
03 .bss
So, i was having problems finding addresses in new games i was playing in 4.55. Sometime i found a value i wanted, but, the next time i wanted to found the same value, i couldn't, and needed several tries before find it again. So, i went to a previously played game, that i have no problem to find values in 4.05. I'm talking about Final Fantasy XV.
In the game i have 545.865.657 of money... and yes, i give me that money in 4.05 using jkpatch with ps4cheater. That's a number very big, so one search is everything i need to found it again. So, i tried now, in 4.55, and this is what i get:
This is the first scan i made. You can see i found the value right away. But when i refreshed the address, the value changed to 2147483648. So, i scanned again, and again, and again... and this are my results:
You see? After every search, the address change 4 hex forward, i don't know why...
Could you include said patches? You can find them in the PS4HEN source code.
That way new processes will start without ASLR, so for example games will always have the same base address in memory.
Thanks in advance.
If anyone wants to help with this, see example.cs
and help me write some documentation for the RPC client.
Sometimes when doing fast write operations in a row, a panic occurs.
When ever there is a write to memory, we should invalidate the TLB/cache for that virtual memory address.
But I need more help figuring this out, the address spit out by vm_fault_hold
is inside the function self_load_shared_object
which does not make much sense to me.
Another reason why a fault may occur could be due to my hacky socket networking... I may be completely wrong about the TLB/cache miss. File descriptors and sockets/vnodes are not really suppose to be associated with the kernel proc0.
I need to clean up the payload and kpayload code. Standardize the style of code and fix variable names.
If anyone wants to help! Feel free, just keep in mind the style I am looking for can be found in rpc.c
(for the most part). But any competent c coder knows what I mean... ๐
I need to change the logic of the rpc_handler
so that it will properly exit when a client disconnects.
I can either set the socket to be non blocking and deal with asynchronous IO and check for EPIPE etc (which I will probably end up doing)
As of now, I set the socket recv timeout to be very small. But I can not detect if a client has disconnected... maybe check the errno.
I didn't know how to message you so this was the closest I could do. I tried forking and updating the repo for 5.05. I got really close with the payload portion. I haven't started on the kpayload. I couldn't find anyone who had patched ASLR or vm_map_protect yet. I put where I got the updated memory addresses in header comments at the top of the relevant files and commented my changes. Please let me know if I made mistakes.
there is a bug, when the payload injecting, and wanna go to the main menu in game, my ps4 just rebooting for some reason, idk know why, hope fix it soon, thanks!
Hi there,
First, I'd like to say thanks for this great tool!
However, I can't seem to get this to build properly. I don't get any errors in output when compiling. But when I fire over the payload, followed by the elf, I get the following. (I can use your elf from the release page, with my payload.bin and it works fine) - Just curious if you've seen it before. I'm currently checking LLVM etc. Thanks!
jkpatch installer loaded
[jkpatch] kernbase 0xFFFFFFFF8B788000
[jkpatch] loading payload...
[jkpatch] install_payload: load_elf failed (r: 1)!
[jkpatch] install_payload failed!
This is just a question, so you can label it as that. Because i don't know if this is a problem with jkpatch or something else. In fact, i posted this same issue in the ps4cheater git just in case.
This is a problem i only have with Horizon Zero Dawn. I don't know if it happens in other games. And i only tested this with ps4cheater. I can't tested it with the ps4 trainer utility of zerofox, because he hasn't added yet a search option for unknown initial value u.u
Let me explain (and maybe you can try yourself if you have the game)
I was trying to find health in horizon zero dawn. I tried float, 2 bytes, 4 bytes, but nothing.
Then i did a 4 byte search, using unknown initial value, and then, did several next scan using only changed and unchanged value. At the end, i had 8 addresses. No matter how much i changed my health in game, those 8 addresses were always there. So, those addresses have something to do with health? That is what i thougth. I tried marking the first one, fall from a high altitud... but my hp went down. I tried the second one, the third one, and so on, but my hp always went down. And then, i tried marking all of them at the same time. And it work!! My hp didn't went down anymore. I did more testing and, at the end, only two of the 8 addresses are needed to be locked to freeze health.
So, here is the problem, or several problems. Or maybe, this is only one big problem.
The health is frozen and everything works fine until i teleport to another campfire. If i teleport, the stored codes stop working and my health stops being frozen. In this case 3 things can happen.
The first is that if I close ps4cheater, open it again and load the saved codes, my health freezes up again and everything continues to function normally.
The second is that the codes stop working even if I restart ps4cheater. And even if I look for the codes again and find them, the addresses has not changed and they still don't work when locked.
And the third is that, even if I search for the addresses using the same method mentioned above, I can't find them again, no matter how much I search. It's like they've been hiding. And when this happens, two more things can happen:
The first is that I simply can't find the health address again, unless I restart the game.
And the second is that it becomes possible to find health by searching with float and exact value options.
So, i don't know why this happens. ASLR is locked by jkpatch, so why the addresses suddenly can't be found? And why sometimes i can find the health as a float value and other times i can't?
Can be a problem with aslr? Or maybe the game has some internal system of randomization aside from the aslr of the ps4? Or it has something to do with the search method?
If the health sometimes is hidden in horizon zero dawn, is possible that there are addresses in other games hidden as well?. Like when i tried to find the experience points in Star Ocean 5. No matter what type of search i did, i wasn't able to find it. But when i searched the exp needed to level up (instead of the accumulated exp until now), i find that right away.
jkpatch 5.05 not work, when send payloads ps4 power down
I need to fix the stub caller code to have a sleep inside of it. Right now it will lag the system because the thread steals all the resources. I need to schedule it properly and make sure it sleeps a proper amount of time.
I activated debug settings using jkpatch, loaded Dragon Quest Heroes (CUSA02769), played the tutorial, then went to a shop and all the money related numbers were bugged!! Just for you to know, i didn't do any editing... i didn't even do any search or anything. So, i saved the game, shut down the console, turned on again, send hen from vtx, loaded the game, and didn't have any problem with the values on screen. I tried shutting down and turning on the console again, sending jkpatch payload, but the number were bugged again.
Here some screenshot of the game loaded with jkpatch and loaded with ps4hen from vtx.
I have a major bug in the RPC server, when it takes up all the resource. I need time to work on figuring out how to properly set the thread affinity, sleeping/yielding to other threads, then still having the RPC be fast.
Booting games with updates applied while running jkpatch causes a console reboot and check of the file system. Base versions of COD BO3 & IW boot fine but booting COD MWR & AW with updates applied results in the issue described above. All games are fakepkg versions and work fine when using only ps4-hen-vtx and worked previously with 4.05 release of jkpatch. Here's a uart log while booting the MWR game if that helps https://pastebin.com/LZT5CpiK
In the latest version the writing memory seems to be broken. I replaced the wrtie memory code in the client with the old and previously working one and still same result. So imo it has something to do with the payload. As an example: I send the write command with byte 0x44 and it actually writes 0x01.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.