STLcardsWS
Administrator
Recently, we told you about the leak of BadIRET kernel exploit,, since that time we have been some new information and details surface as ps4 hacker CTurt has published additional information as it appears a new entry ("Restoration of kernel state") was made in CTurt/qwertyoruiop -- Analysis of sys_dynlib_prepare_dlclose PS4 kernel heap overflow since our initial report. . As Cturt details a better exploit then the BadIRET approach, that information can be seen below, along with a "brief overview of Booting Linux on the PS4" and bit also on what is required . Now this information [break]ss[/break] is not user-friendly and not intended for the average user., this information is most useful to developers. Checkout all the details from recent CTurt releases and information provided below and remember these exploits rely on the webkit exploits found within firmware version 1.76, later firmware do not work as Sony has patched these exploits.
Useful PS4 Tools & Releases by CTurt & Others (Thanks to Wololo.net for list)
CTurt said:
Booting Linux
I wanted to give a brief overview of how to setup and boot Linux on your PS4, thanks to the hard work of the fail0verflow team. To create your own Linux distro, you'll need to compile fail0verflow's fork of the Linux kernel, and then create your own initramfs. The easiest way to get these files into RAM is to copy them to a USB flash drive formatted as FAT32, which can then be read from once you've broken out of sandbox as explained earlier (/mnt/usb0/). You could also download them over the network if you prefer. You'll also need to compile the ps4-kexec system call implementation as a relocatable binary and include it in your kernel exploit.
For your kernel payload you should copy the system call somewhere into kernel address space (like DT_HASH_SEGMENT), and run kexec_init to install it (which is guaranteed to be at offset 0 from the binary):
There are still a few issues which need to be addressed, such as only 1080p display being supported, but it's still a fun thing to play with, and the fail0verflow team continues to make steady progress on the project all the time.void *DT_HASH_SEGMENT = (void *)0xffffffff82200160; memcpy(DT_HASH_SEGMENT, kexec, kexecSize);
void (*kexec_init)(void *, void *) = DT_HASH_SEGMENT;
kexec_init(NULL, NULL); Once you return to userland, you can load the kernel and initramfs from USB, pass them to kexec, and finally reboot!
FILE *fkernel = fopen("/mnt/usb0/bzImage", "r");
...
FILE *finitramfs = fopen("/mnt/usb0/initramfs.cpio.gz", "r");
...
char *cmdLine = "panic=0 clocksource=tsc radeon.dpm=0 console=tty0 console=ttyS0,115200n8 "
"console=uart8250,mmio32,0xd0340000 video=HDMI-A-1:1920x1080-24@60 "
"consoleblank=0 net.ifnames=0 drm.debug=0";
syscall(153, kernel, kernelSize, initramfs, initramfsSize, cmdLine);
free(kernel);
free(initramfs);
// Reboot
int evf = syscall(540, "SceSysCoreReboot");
syscall(546, evf, 0x4000, 0);
syscall(541, evf);
syscall(37, 1, 30);
Useful PS4 Tools & Releases by CTurt & Others (Thanks to Wololo.net for list)
Restoration of kernel state
The BadIRET exploit had a very convoluted execution flow, and required many additional stages after initially gaining kernel code execution before being suitible for general payload development.
For example, with BadIRET we first gained kernel code execution under a very critical double fault context, which we then used to hijack an additional function pointer.
We then had to directly handle return back to userland by restoring the swapgs imbalance to ensure we had userland GS base, before then crafting a valid stack frame to return to with the iret instruction. We could then trigger the second payload from userland to gain kernel code execution under a normal context.
Furthermore, the exploit relied on corrupting the IDT which we had to reinitialise before returning from the critical payload. The dlclose exploit doesn't require any of this, which makes it much easier and more direct to work with than BadIRET. After calling close we immediately gain kernel code execution under a normal context. Secondly, since this exploit doesn't corrupt any global structures; if we perform it in a separate thread, any corruption will be discarded once the thread finishes and so we don't need to clean up anything manually.
The general template for this exploit is as follows:
]void payload(struct knote *kn) {
struct thread *td;
struct ucred *cred;
asm volatile("mov %0, %%gs:0" : "=r"(td));
kprintf(" [+] Entered kernel payload!\n");
// Privilege escalation
...
// Jailbreak
...
// Sandbox escape
...
// Enable UART output
...
// Disable write protection
...
// Patch kernel functions
...
// Restore write protection
...
// Install kexec system call
...
// etc...
}
void *exploitThread(void *arg) {
// Map the buffer, spray the heap, etc
...
// Create hole for the system call's allocation
m = kernelAllocation(bufferSize);
m2 = kernelAllocation(bufferSize);
kernelFree(m);
// Perform the overflow
syscall(597, 1, mapping, &count);
// Execute the payload
kernelFree(m2);
return NULL;
}
int _main(void) {
int sock;
ScePthread thread;
// Resolve functions, connect to socket, etc
...
printf("[+] Starting...\n");
printf("[+] UID = %d\n", getuid());
// Create exploit thread
if(scePthreadCreate(&thread, NULL, exploitThread, NULL, "exploitThread") != 0) {
printf("[-] scePthreadCreate\n");
sceNetSocketClose(sock);
return 1;
}
// Wait for thread to exit
scePthreadJoin(thread, NULL);
// At this point we should have root and jailbreak
if(getuid() != 0) {
printf("[-] Kernel patch failed!\n");
sceNetSocketClose(sock);
return 1;
}
printf("[+] Kernel patch success!\n");
// Dump files, patch memory from other processes, boot Linux, etc
...
sceNetSocketClose(sock);
return 0;
}
Source(s): cturt.github.io (1) / cturt.github.io (2)
Other Useful Links: wololo.net / PlayStationHAX.it / extreme-modding.de
Other Useful Links: wololo.net / PlayStationHAX.it / extreme-modding.de
