Join Us and become a Member for a Verified Badge to access private areas with the latest PS4 PKGs.
PS5 Jailbreaking       Thread starter PSXHAX       Start date May 27, 2021 at 4:37 PM       20      
Not open for further replies.
Recently a SMAP (Supervisor Mode Access Prevention) Bypass FreeBSD 12 Vulnerability reported by m00nbsd via Twitter was disclosed on the bug bounty site in a flurry of PlayStation Hacktivity, which according to m00nbsd may also affect the PlayStation 5 although he reports being unable to confirm the SMAP bypass on a PS5 console. :geek:

For those following the PS5 Jailbreak updates and PS5 NFOs in the PS5Scene, this comes proceeding the Talos WebSocket Vulnerability that may be present in the PS5 WebKit... also unconfirmed in part due to the limited console supply as a result of PlayStation 5 Scalpers.

The potential PS5 SMAP Bypass references CVE-2021-29628, which is described as follows:

In FreeBSD 13.0-STABLE before n245764-876ffe28796c, 12.2-STABLE before r369857, 13.0-RELEASE before p1, and 12.2-RELEASE before p7, a system call triggering a fault could cause SMAP protections to be disabled for the duration of the system call. This weakness could be combined with other kernel bugs to craft an exploit.

Finally, below is the SMAP Bypass report summary for those interested to quote:

SMAP is a security feature on x86 CPUs, that forbids ring0 from reading/writing to ring3 pages, making it harder to exploit entire classes of vulnerabilities.

There is a vulnerability in FreeBSD 12 that allows SMAP to be bypassed by userland. There is a very high probability that it affects the PS5 but I was unable to access a PS5 firmware to confirm it.

This vuln downgrades the security properties of the OS, and is a building block for exploitation chains.


With SMAP enabled, when %RFLAGS.AC is cleared the kernel will page-fault if it tries to access a page marked as "user page". When %RFLAGS.AC is set the kernel can access the user pages as if SMAP was not enabled.

In the FreeBSD kernel, a few functions exist that temporarily set %RFLAGS.AC in order to access user pages: the copyin() and copyout() functions.

These functions are used in all syscalls and are the only ways the kernel can copy data from/to userland.

These functions handle faults gracefully, that is, if userland passes an unmapped address and the kernel tries to copy data from it, the functions will simply return an error without kernel panic.

There is a bug in the fault handling of these functions. Typically copyin() is implemented as follows:
.macro    COPYIN smap erms     /* ... */    movq    $copy_fault,PCB_ONFAULT(%r11)    /* ... */    stac // set %RFLAGS.AC, to allow access to user pages    do_the_copyin    clac // clear %RFLAGS.AC, to forbid access to user pages    /* ... */ copy_fault:    movq    $0,PCB_ONFAULT(%r11)    movl    $EFAULT,%eax    POP_FRAME_POINTER    ret
void trap(struct trapframe *frame) {    /* ... */            if (curpcb->pcb_onfault != NULL) {                frame->tf_rip = (long)curpcb->pcb_onfault;                return;            }    /* ... */ }
The fault handler copy_fault is registered in pcb_onfault at the beginning, then %RFLAGS.AC is set, the copy is made, and %RFLAGS.AC is cleared back.

If the copy faults for whatever reason, an exception is raised, the trap() handler sees that pcb_onfault has a pointer registered, and simply IRETs back to the pointer that was registered.

The problem is, the fault handler copy_fault does not clear %RFLAGS.AC, meaning that it remains set after copyin()/copyout() returns. The rest of the syscall will therefore execute with SMAP effectively disabled, until the kernel returns to userland where the SMAP state gets reset back to normal.

This SMAP disablement survives context switches, so a user that disables SMAP during one of his syscalls can also disable SMAP in other user/kernel threads if a rescheduling happens after/during the syscall (taking a mutex for example).


Add a clac instruction in copy_fault to clear %RFLAGS.AC:
copy_fault: +    clac     movq    $0,PCB_ONFAULT(%r11)     movl    $EFAULT,%eax     POP_FRAME_POINTER     ret

Userland can open lage windows where the kernel executes with SMAP disabled.

Lack of SMAP makes exploitation of common vulnerabilities easy/trivial.
There is another vulnerability in zen 2 architecture that you can trigger it COMPLETELY FROM SOFTWARE. We have tested it and it's confirmed that affects ps5 apu as well. There is also the PoC. Impact is: Leaks hypervisor and kernel memory.
some news: smap bug is officially patched on 2.50 ps5, however it should exist on 2.30 and below. unfortunately for me this means that the bug i found cannot be successfully exploited on 2.50, but it can be exploited on 2.30 and below
  • / AMD-SP-Loader GIT - Binary Ninja (Binja) loader for AMD Secure Processor (SP) / Platform Security Processor (PSP) firmware binaries. It will try to load AGESA Bootloader (ABL) and Bootloader blobs and will setup the correct load addresses.
Put out a blog post on some reversing I've been doing on the side of the AMD Platform Security Processor / PSP. Part 1 is an overview of the design and memory-mapped I/O (MMIO), part 2 will be on the Crypto Co-Processor MMIO.
Published part 2 of the AMD PSP reversing stuff. This one focuses on the Crypto Co-Processor (CCP) and looking at the system for loading firmware and decrypting it.
Scratch that "locked/unreadable key slots" idea ;)
zen 1 and zen 2 bootroms. PS5 APU is a custom ZEN 2 ryzen chip. this is extremely important to reverse engineer and find ways to dump the PS5 bootrom
Leak News AMD PSP Bootroms and VMProtect Source
SpecterDev thoughts on the leaked AMD Secure Processor bootroms (for people who don't know what this is about: AMD Zen 2 bootrom has been leaked, the PS5 CPU is also based on Zen 2, reverse engineering the secure processor may lead to a full PS5 jailbreak)
SMAP Bypass FreeBSD 12 Vulnerability May Affect PS5 via M00nbsd.jpg


I wonder when PS5 manufacturing and distribution will reach a point where stores carry full stock of the console and people can actually buy them without being sold out... apparently right now that's an advantage Sony has over hackers. :unsure: Maybe by 2022?!
Maybe Sony deliberately manufacturing this way. Ultimately everyone will still want one but if bugs are found, hardware/software is changed before distributed.

Just a thought
@PSXHAX Sony has said themselves that it will "last until at least 2022". My honest to goodness bet would be late-2022 when we start to see a flow that allows those that want one to get one easily. Be it online or in a store, late-2022 is probably when they will be widely available.

Which is crazy but we know why and it wasn't just the pandemic. Chip manufacturing has been below demand for a while and we just asked the same few foundries, supply chains and resource chains to work at 100% all the time. All it took was an extra little push for it to fall apart.

Other chips actually need subsidies to get going again. It's crazy. Some chips are heavily in stock and can be produced right now but the slight uptick in materials cost now make them a financial loss to even produce and sell. These are many of the small ICs that make up most of modern electronics. PMICs, some mosfets, security chips, etc. It's an entire pipeline that's been burst in 2020 and it likely won't really get moving again until 2022.

2023 isn't out of the question. Imagine a new console launch in 2020 that cannot get units to it's customers until 3 years later. That's not a launch but a beta program, lmao.
Not open for further replies.