Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 PKGs.
Status
Not open for further replies.
We've seen PS3 Browser ROP Exploitation, a PS4 ROP Tool, a PS4 ROP / SPRX / ELF File Archive, PS4 ROP Gadgets, a PS4 ROP Kernel Dumper and following his Blu-Play DOOM I Port PlayStation 4 scene developer sleirsgoevy made available a PS4 ROP 8CC Return-Oriented Programming Port for use with Fire30's PS4 6.XX Webkit Exploit on PS4 OFW 6.51 including OpenOrbis PS4 Toolchain support! :fire: 😍

Download: ps4-rop-8cc-master.zip / GIT

From the README.md, to quote: PS4-ROP-8cc

This is a port of shinh's ELVM branch of 8cc to the PS4 return-oriented programming. It runs C code on OFW 6.51 via Fire30's WebKit exploit.

Building

Simply run make and follow the instructions to setup the toolchain.

Running

A reference script, scripts/run.py, is provided.
Code:
python3 scripts/run.py file1.c [file2.c]...
Look at its source code if you want more precise control over what's happening.

ABI

ELVM/x64 register mapping:
Code:
ELVM    x64     notes
A       rax
B       rcx
C       r10
D       --      the compiler never uses the D register
SP      rdi     rsp is used for the ropchain, so the stack has to be emulated
BP      r8
The compiler has been modified so that memory addressing and type sizes are the same as in native code. This allows native headers (e.g. from OpenOrbis ***) to be included directly.

The calling convention is essentially CDECL, with call being implemented as push next ; jmp func ; next:. That is, SP (rdi) points to the return address on function entry. The result is returned in B (rcx).

The compiler detects whether a given function call is a rop-to-rop or rop-to-native call, and converts the calling convention if necessary. For native-to-rop calls the conversion has to be performed explicitly:
Code:
#include <librop/extcall.h>

void native_func(..., void(*)(...), void* opaque, ...);
void my_very_func(void* opaque, ...); // only this format is supported

...

extcall_t ec;
char stack[8192]; // emulated stack to be used by my_very_func
create_extcall(ec, my_very_func, stack, opaque);
native_func(..., extcall_gadget, ec, ...);
To call a native function pointer, you must call rop_call_funcptr or implement the same functionality yourself:
Code:
rop_call_funcptr(ptr_to_printf, "Hello, %s!\n", "world");
Note: there is a ready-to-use wrapper for pthread_create in librop/pthread_create.h that will perform the conversion for you.

Speed

This is no speed demon. 8cc compiles the C code to a stack machine, and is is then run on a software-emulated stack. The use of ROP further slows things down by essentially disabling CPU branch prediction. The end result is that an empty for loop does about 1e6 iterations per second.

Known bugs
  • Code using global or static variables won't compile. Use mmap if you are not happy with 64KB of stack.
  • The constant-parsing code stores constants as int internally. This means that 64-bit constants won't work.
  • 64-bit integer comparison is always signed.
  • Arithmetic shift right is not supported (yet).
  • The generated ROP is reentrant but not thread-safe. That is, one ROP function can only be called on a single thread. This does not apply to rop-to-native calls.
Cheers to @liylith and @mcmrc1 via Twitter for the heads-up on this PlayStation 4 ROP news. 🍻
PS4 ROP 8CC Return-Oriented Programming Port by Sleirsgoevy for 6.51 WebKit Exploit.jpg
 

Comments

Looks like they are digging higher fws... 6.20 is mountable aka jailbreakable... 6.50-7.02 idk... progress being made 👊🏽
 
Status
Not open for further replies.
Back
Top