Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 PKGs.
PS4 Jailbreaking       Thread starter g991       Start date Feb 9, 2018 at 6:21 PM       183      
Status
Not open for further replies.
Process Memory View is a cool little memory tool! Do not press backspace in the Hex View, it will delete a byte so when you poke it messes it all up.. idrc to fix it. If anyone wants it, I can make a much much better tool later.

Edit the ip file and change it to your PlayStation's ip address, make sure you have jkpatch loaded first. If your console goes into rest mode, then doing anything with RPC may crash it.

Download: memview-r4.zip (45.57 KB)

Look at the release page for payload.bin and kpayload.bin!

Use the send.sh bash script to easily send it to the console!

To be honest, this is not about the Memory View tool... This is about jkpatch! A little project I have been working on. I want the community to help me develop this, so please send some pull requests or open an issue!

The RPC networking is light speed! On LAN there is basically no latency.

Please help commit to my project!

https://github.com/xemio/jkpatch

And from the README.md: Jailbreak Kernel Patches

Spoiler

:arrow: Update: Here is a new version with a reboot function, peek/poke unlimited length, and save view bytes to file. Also the hex view will now prevent you from inserting/deleting bytes. Oh also the memory map view looks 100x better, and you can see all the mappings now.

JKPatch PS4 4.05 Jailbreak Kernel Patches, Process Memory View Tool.png


I have also build the latest version of librpc and jkpatch for you all:
https://github.com/xemio/jkpatch/releases/tag/1

golden <3

JKPatch PS4 4.05 Jailbreak Kernel Patches, Process Memory View Tool.jpg
 

Comments

Thank you for this great tool. let's try it
has anyone try it old >4.O5 firmware ?
Wonderful again @g991
 
whoops... tried to peek 0x1000000 length, and the ps4 shutted down
You should try to see the serial output, I would be interested to see what faulted.
The code is pretty well maintained with error checking and what not... but obviously you can't read that much memory because no virtual mapping has 0x1000000 bytes in one allocation.
 
The reason i tried a million for length was because, when the ps4 aio was posted, i used the peek and poke function that came with it. I was able to peek a length of 0x6700000 for the eboot.bin playing Final Fantasy XV. And, when i was playing Gravity Rush 1, i was able to peek 0x2300000. And, now, i was playing Gravity Rush 2, so i tried with a length of 0x1000000.

When the length was to much in the ps4 aio, the game freeze, and i just have to close it using the quick menu of the ps4. Never had a shutdown before :O
 
You should try to see the serial output, I would be interested to see what faulted.
The code is pretty well maintained with error checking and what not... but obviously you can't read that much memory because no virtual mapping has 0x1000000 bytes in one allocation.

From what I have found out you need to do it with multiple package dumps of the maximum size.
Also im a bit confused atm... when i peek memory in the ps4 aio tool it gives me totally diffrent offsets than with yours.

I was just sitting here trying to peek my name in bo3 and got an error all the time.
I then used your tool and saw that eboot.bin starts at 0x3D318000 in your tool and at 0x400000 in modded warfares tool. Is that just calculation or is something messed up with either one of the tools ?
 
The reason i tried a million for length was because, when the ps4 aio was posted, i used the peek and poke function that came with it. I was able to peek a length of 0x6700000 for the eboot.bin playing Final Fantasy XV. And, when i was playing Gravity Rush 1, i was able to peek 0x2300000. And, now, i was playing Gravity Rush 2, so i tried with a length of 0x1000000.

When the length was to much in the ps4 aio, the game freeze, and i just have to close it using the quick menu of the ps4. Never had a shutdown before :O
The RPC server runs in kernel mode and functions different from other RPCs. It is better this way but presents a harder implementation and consequently more bugs.

From what I have found out you need to do it with multiple package dumps of the maximum size.
Also im a bit confused atm... when i peek memory in the ps4 aio tool it gives me totally diffrent offsets than with yours.

I was just sitting here trying to peek my name in bo3 and got an error all the time.
I then used your tool and saw that eboot.bin starts at 0x3D318000 in your tool and at 0x400000 in modded warfares tool. Is that just calculation or is something messed up with either one of the tools ?
jkpatch does not disable process ASLR, this is most likely the reason why the addresses differ. Process memory writing is a little messed up in memview. If you find a bug, and can be more specific, please open an issue on github.com
 
I wouldnt call it a bug it just confuses me. I also compared it with offsets that were posted in the 1.76 days for ghosts and they all use 0x400000 for their process entry point.

But as you said, you are using a different method, you are not even really attaching to a process.

I might just do some calculation in my tool to keep the entry point at 0x400000.
 
Or submit a pull request with the ASLR disable patch on github! Ill add it to jkpatch, just do it where I do all the kernel patches in the loader payload.
 
You should try to see the serial output, I would be interested to see what faulted.
that's the error: https://pastebin.com/VAF7AWNL
Code:
System.Net.Sockets.SocketException (0x80004005):  A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
   in System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   in librpc.PS4RPC.ReceiveRPCStatus()
   in librpc.PS4RPC.CheckRPCStatus()
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in librpc.PS4RPC.ReadMemory(Int32 pid, UInt64 address, Int32 length)
   in memview.MemoryView.RefreshMemoryView()
   in memview.MemoryView.PeekButton_Click(Object sender, EventArgs e)
   in System.Windows.Forms.Control.OnClick(EventArgs e)
   in System.Windows.Forms.Button.OnClick(EventArgs e)
   in System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   in System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   in System.Windows.Forms.Control.WndProc(Message& m)
   in System.Windows.Forms.ButtonBase.WndProc(Message& m)
   in System.Windows.Forms.Button.WndProc(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   in System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
your program tries to communicate with PS4, but, as the length of search is big (I tried 0x02000000 cause 0x01000000 works in Bloodborne), the PS4 ("host" in this case) crashes, so your program can't receive a response
 
I added a better patch to the git, and updated current build. It should not crash your PS4 now, it should just throw an error.

I feel as though the problem with poking data has to do with the memory view tool itself.
 
tested this last kpayload.elf and still crashes
I've also tried, with both old and new .elf, to search for a length of 0x00500000 and the PS4 crashes.

Only the first time that I tried with length 0x01000000, it did not crashed; then always crashed (with lengths: 0x02000000, 0x01000000, 0x00800000, 0x00500000)
 
Status
Not open for further replies.
Back
Top