A Blu-ray Disc Java route to Relapse
BD-JB-Relapse 2.0.0 is a work-in-progress port of the Relapse PS5 kernel exploit to the Blu-ray Disc Java environment. It runs inside the Disc Player’s BD-J virtual machine and uses BD-JB5 to escape the Java sandbox, avoiding the need for a WebKit-based entry point.
Once launched, the project is intended to leak the kernel base, obtain kernel read/write access, escalate to uid 0 outside the sandbox and start an ELF payload loader. The project reports support for PS5 firmware versions up to and including 13.42, with offset tables covering firmware versions from 7.00 through 13.60. Development and testing were carried out on a 13.42 development kit, so the stated support range should not be read as a guarantee of identical results on every retail system.
What is included in version 2.0.0
The 2.0.0 release provides two assets: BD-JB-Relapse-2.0.0.iso and Relapse.jar. The ISO bundles the Java payload into a BD-JB5-based bootable disc image, while the JAR is the payload by itself for the project’s RemoteJarLoader flow. The release notes themselves contain only links to the full changelogs and do not describe individual changes between versions 1.0.0 and 2.0.0.
The ISO is intended to be written to BD-RE, or otherwise served through a method normally used for BD-J discs, and then opened in the console’s Disc Player. Its bundled loader automatically runs the payload from the disc, so this packaged route does not require a network push of the JAR. The standalone JAR is intended for loading through BD-JB5’s RemoteJarLoader, which uses port 9025.
After the exploit chain has completed, the embedded elfldr component serves ELF payloads on port 9021. Progress is reported through BD-JB5’s UDP logging service on port 18194. These network services belong to the PS5-side software and BD-JB5 tooling; they are not requirements for an unrelated host emulator or a general-purpose Java runtime.
Kernel access and payload loading
The port adapts the original Relapse exploit’s aio_multi_wait mode-0 waiter use-after-free to the restrictions of the BD-J environment. The project uses the resulting primitive to corrupt a sysctl object, establish a slow kernel read/write path and then move to a faster pipe-based path. Following privilege escalation, the chain hands control to kexp from ufm42, which applies kernel patches and bootstraps the payload loader, and elfldr from ps5-payload-dev, which moves into a system service and listens for ELF payloads.
This design makes BD-J more than a simple launcher. The Java application must work around restrictions that would not apply to the original browser-based exploit. The README says that libkernel text pages are execute-only, preventing ordinary code scanning and ROP gadget discovery. Instead, the port reaches system calls through exported libkernel wrappers where possible.
One important exception is the mode required by the vulnerability itself. The standard sceKernelAioWaitRequests wrapper rejects mode 0, even though mode 0 is necessary to trigger the waiter bug. The port therefore locates raw syscall stubs inside libkernel_sys at runtime using a dlsym-resolved anchor and fixed offsets, then calls them with the required mode.
Teardown work addresses a previous close panic
The most concrete technical fix documented in the project background concerns cleanup after the payload server starts. Earlier teardown could leave a crossed pipe pointing to the other pipe’s kernel object. When the process exited, pipe_free_kmem could then treat that object as the pipe’s buffer, causing a console panic or reboot.
The current cleanup path saves each pipe’s original buffer and size, restores those values to the correct pipe, clears the count, input and output fields, and verifies the results through the slower read/write window before the process exits. This gives the kernel a valid allocation to release instead of the crossed object.
The project attributes the close-panic teardown fix to 0xXOR. The README says the method was measured on firmware 12.60 but had not yet been validated on the port’s 13.42 target. If closing the application still causes a panic on that target, the documented fallback is to reboot and run the process again.
Known limitations remain
The three hijacked sysctl OIDs remain modified until the next reboot. In particular, kern.smp.cpus may return a kernel address rather than the CPU count, although the project says that nothing in the post-jailbreak chain has been observed to depend on the normal value.
The cleanup process cannot repair the pipes and restore the hijacked OIDs in the same pass. The fast primitive overwrites the pipe field needed for repair, while restoring the OIDs would destroy the slower window used to fix the pipes. The implementation prioritizes pipe restoration because leftover pipe state is what can trigger the close-time panic.
BD-JB-Relapse is explicitly marked as functional but still in progress. The README’s firmware table extends through 13.60, while the stated supported range ends at 13.42 and the available validation information specifically references a 13.42 development kit. Users should therefore treat firmware coverage and the close-time behavior as project-reported compatibility rather than a universal guarantee.
Build information for developers
The project builds a single Java payload, Relapse.jar, and its automated release workflow assembles the corresponding BD-JB5 disc image. Building from source requires the project’s documented JDK 8 and BD-J SDK setup; those details apply to developers compiling the project, not to users running the supplied release assets.
Tagged builds are configured to package the JAR into a BD-JB5 disc image and attach both the standalone payload and ISO to the matching release. The distributed 2.0.0 assets therefore cover both documented usage styles: a disc image with automatic payload loading and a separate JAR for the classic remote-loading route.
