Giter Site home page Giter Site logo

jkpatch's Introduction

Jailbreak Kernel Patches

Features

  • Jailbreak
  • Sandbox escape
  • Debug settings
  • Enable UART
  • RPC server
  • RPC client in C#

I use the standard fake pkg keys, created by flatz.

General Notes

Only for 5.05 Jailbroken PlayStation 4 consoles!

The main jkpatch payload utilizes a port of CTurt's payload sdk. Change the Makefile to have LIBPS4 point to the ps4-payload-sdk directory on your machine. I could have it referenced from the home directory but meh...

# change this to point to your ps4-payload-sdk directory
LIBPS4	:=	/home/John/ps4-payload-sdk/libPS4

If you decide to edit the resolve code in the kernel payload, make sure you do not mess with...

void resolve(uint64_t kernbase);

... as it is called from crt0.s. And changing this will produce errors.

See other branches for other kernel support. I will support latest publically exploited firmware on main branch.

RPC Quickstart

See either Example.cs or look at the RPC documentation.

You can read/write memory, call functions, read/write kernel memory, and even load elfs.

Here is a cool example of an elf loaded into COD Ghosts (forge mod made by me!) You can download the source code to the forge mod here. Have fun!


Thank you to ChendoChap, idc, zecoxao, hitodama, osdev.org, and anyone else I forgot!

golden <3

jkpatch's People

Contributors

3096 avatar chendochap avatar deathrgh avatar jogolden avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jkpatch's Issues

Suggestion: Include disable process ASLR patches

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.

ASLR patch not working in 4.55

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:

first scan
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:

second scan
You see? After every search, the address change 4 hex forward, i don't know why...

Build fails when using binutils 2.28

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 

Some addresses become hidden?

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.

6o9xw15

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:

  1. The first is that I simply can't find the health address again, unless I restart the game.

  2. 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.

Code clean up and refactoring

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... ๐Ÿ‘

Can't boot games with updates applied

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

Numbers in some games are bugged

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.

Jkpatch Screenshot
dragon quest heroes_ el infortunio del arbol del mundo y la raiz del mal_20180309013327

PS4hen-vtx Screenshot
dragon quest heroes_ el infortunio del arbol del mundo y la raiz del mal_20180309013937

Compiled payload doesn't do anything on 4.55

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.

close kthread when client exits

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.

cpu hogging, lags games and steals resources

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.

Writing memory issue

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.

Random Shut Down with RPC Client

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.

Update to 5.05

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.

https://github.com/withmetta/jkpatch505

Implement RPC function calling

I need to implement a decent amount of code if we are to get anywhere with calling functions through RPC...

  1. suspend process/thread
  2. use fill_regs to get registers
  3. modify rip to point to some byte code that will allocate memory and start a thread on our RPC call stub
  4. use set_regs to set registers
  5. continue execute
  6. stop execution when the byte code has finished
  7. restore thread state with set_regs
  8. continue execution

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.

[jkpatch] install_payload: load_elf failed (r: 1)!

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!

rpc stub thread needs pthread tls data

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.

nioh auto rebooting 4.55

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!

Write RPC stub assembly code

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.

panic: vm_fault: fault on nofault entry, addr: (<kernel>+0x284000)

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.

rpc stub caller has no sleep and high priority

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.