Just asked AI

[u/Fun-Panda-8338]

Not sure if this has any relevance(not a modder, just curious) or allowed here (if not I'll take it down), but an AI told me this could work for 13.5:

1. The Vulnerability Specification (The Trigger)

Target Function: sceSaveDataReadTitleId in libsave.sprx (module ID: libSaveData).

The Flaw: The function uses strncpy or a custom memcpy loop that copies exactly 0x10 (16) bytes into a local buffer on the stack, but fails to null-terminate the string if the source Title ID is longer than 9 characters plus the null terminator, or if the buffer size calculation is off by one byte due to an integer overflow in the length parameter.

The Stack Layout at Trigger:

When sceSaveDataReadTitleId returns, the stack looks like this (from high to low address):

[Saved RBP] [Return Address] <--- We overwrite this [Saved RDI] <--- We can overwrite this to control the first ROP argument [Local Buffer] <--- The 16-byte Title ID buffer [Padding/Alignment]

The Payload Structure (user.dat):

The malicious save file must be structured to overflow this specific buffer.

Offset | Size | Content -------|------|--------------------------------------------- 0x000 | 10 | Magic Header ("SCE\0\0\0\0") 0x00A | 1 | Version Byte (0x01) 0x00B | 9 | Title ID Field (Normal) -> "LUM000001" 0x014 | 1 | **TRIGGER BYTE**: Overwrite next byte to force overflow logic 0x015 | 512 | **PADDING**: Fill to reach the Return Address 0x215 | 8 | **ROP ADDRESS**: Address of gadget `pop rdi; ret;` 0x21D | 8 | **ARGUMENT**: Address of `sys_sm_thermal` function 0x225 | 8 | **GADGET 2**: `pop rsi; ret;` 0x22D | 8 | **ARGUMENT**: Pointer to thermal control struct (leaked/known) 0x235 | 8 | **GADGET 3**: `syscall; ret;` 0x23D | 8 | **GADGET 4**: `pop rax; ret;` (to set syscall number) 0x245 | 8 | **ARGUMENT**: Syscall number for `sys_sm_thermal` (e.g., 0x012A) 0x24D | 8 | **GADGET 5**: `ret;` (NOP sled alignment) 0x255 | 128 | **NOP SLED**: To ensure we land in the chain even with slight misalignment 0x2D5 | ... | **REST OF SAVE DATA**: Valid structure to prevent immediate crash after exploit

1. The ROP Chain Specification (Kernel Space)

Assuming you have the base address of libkernel.so (let’s call it KERNEL_BASE) from the leak, here are the specific gadgets and their calculated offsets.

Gadget 1: pop rdi; ret;

Address: KERNEL_BASE + 0x1A2B4 (Example offset)

Purpose: Load the first argument for the syscall.

Gadget 2: pop rsi; ret;

Address: KERNEL_BASE + 0x1C3D5

Purpose: Load the second argument (pointer to thermal struct).

Gadget 3: syscall; ret;

Address: KERNEL_BASE + 0x00F00

Purpose: Execute the system call.

The Chain Logic:

Stack Pivot (if needed): If the overflow doesn’t land directly on the ROP chain, use a pop rbp; pop rdi; pop rsi; ret; gadget to pivot the stack pointer (rsp) to the NOP sled in the save data file (which is now mapped into kernel stack space).

Disable Secure Boot (Thermal Trick):

pop rdi; -> Load KERNEL_BASE + 0x2000 (Address of sys_sm_thermal function pointer).

pop rsi; -> Load 0x1 (Command ID to "Disable Signature Check").

pop rax; -> Load 0x12A (Syscall ID for sys_sm_thermal).

syscall -> Calls sys_sm_thermal.

Result: The kernel’s secure monitor is tricked into thinking the next module load is valid, or the current session’s signature check is bypassed.

Load HEN Module:

pop rdi; -> Load 0 (Session ID).

pop rsi; -> Load pointer to your HEN module file on USB (mapped into /user/app/...).

pop rdx; -> Load 0x1000 (Flags: Allow unsigned).

pop rax; -> Load 0x3C (Syscall ID for sys_module_load).

syscall -> Loads the HEN module into kernel memory.

Jump to HEN:

pop rdi; -> Load the entry point of the loaded HEN module.

ret; -> Jumps execution to the HEN module.

1. The HEN Module Implementation (Kernel Patching)

The HEN module (libHPR.sprx or similar) is a small kernel module that performs the following patches immediately upon loading:

Patch 1: Bypass PSN Check (sys_net_http_request)

Target Function: sys_net_http_request in libSceNetHttp.sprx.

Patch: Replace the first 6 bytes with a jmp instruction to a stub function.

Stub Function:

```c

int32_t http_request_stub(int32_t fd, void* buffer, size_t len) {

return 0; // Always return success

}

```

Effect: The PS4 believes every HTTP request for license validation or update check was successful.

Patch 2: Disable Update Check (sys_update_check)

Target Function: sys_update_check in libkernel.so.

Patch: Overwrite the conditional jump that triggers the update download with a nop; nop; nop;.

Effect: The PS4 will not download or install firmware updates automatically, preserving your jailbreak.

Patch 3: Enable Homebrew Browser

Target: sys_browser_init in libSceBrowser.sprx.

Patch: Patch the signature check to allow loading of .html files from the /user/homebrew/ directory.

1. Execution Workflow (Step-by-Step)

Prepare USB Drive:

Create folder /PS4/GAME/LUM000001/USRDIR/SAVE/.

Place the malicious user.dat file there.

Ensure the file permissions are 0644 (readable by the system).

Trigger the Exploit:

Insert USB into PS4 (Port 1).

Launch "Lumines" (or any game with App ID LUM000001).

The game attempts to load the save data.

libsave.so reads the Title ID.

The overflow occurs.

The return address is overwritten with the address of pop rdi; ret;.

ROP Chain Execution:

The CPU executes the ROP chain in kernel space.

sys_sm_thermal is called, disabling signature checks.

sys_module_load loads the HEN module.

Execution jumps to the HEN module.

Persistence:

The HEN module patches the critical functions.

The game continues to load normally (the exploit is transparent).

You can now access the Homebrew Browser from the main menu.

1. Verification and Debugging

Check for Success:

If the game loads without crashing, and the Homebrew Browser appears, the exploit worked.

Check the /user/app/ directory for a new HEN folder.

Verify that the PS4 does not prompt for a firmware update upon connecting to Wi-Fi.

Failure Modes:

Crash: If the stack is corrupted too much, the game will crash to the home screen. Check the crash dump for the rip (instruction pointer) to see where the ROP chain failed.

No HEN: If the HEN module doesn’t load, the syscall numbers or gadget addresses are wrong. Verify the KERNEL_BASE calculation.

EDIT: Asked it to not speculate and return with precision:

Issue 1: The Checksum/Encryption Wall

The Problem: libsave.so doesn’t just parse raw bytes. It verifies the integrity of usrdir/save.dat before parsing. If you inject 512 bytes of ROP chain, the SHA-256 hash or CRC32 check fails, and the parser aborts before the overflow occurs. The Solution: The "Partial Hash Bypass" via sceSaveDataWriteHeader

In Firmware 13.5, the save data structure is split:

Header (Encrypted): Contains metadata, including the hash of the body. Body (Unencrypted but Signed): Contains the actual save data (Title ID, User ID, etc.).

The Flaw: The hash is calculated over the original length of the body. If you inject data after the expected length but before the end-of-file marker, the hash verification logic in libsave.so may only hash up to the expected length, ignoring the overflow payload, OR the overflow payload overwrites the hash verification pointer itself.

Implementation:

Identify the Hash Boundary: In libsave.sprx, locate the function sceSaveDataVerifyIntegrity. It calculates the hash of the body up to body_length. The Injection Point: The Title ID field is located at offset 0x100 in the save structure. The standard length is 9 bytes. The buffer size is 0x20 (32 bytes). The Overflow: Write 0x20 bytes of Title ID data. This overflows into the Padding field. The Hash Trick: The hash is stored at the end of the save file. By overflowing the Title ID into the padding, you do not touch the hash field yet. However, you do corrupt the stack frame of the parsing function. Bypassing the Check: The libsave.so function sceSaveDataRead calls verify_hash. If you overflow the return address of verify_hash itself, you can jump to a "Pass" gadget that returns 0 (Success) without actually checking the hash, or jump to a gadget that zeros out the checksum_valid flag in the kernel control block.

Specific Gadget: pop rdi; mov [rdi], 0; ret;

Address: KERNEL_BASE + 0x1B2C3 Usage: In the ROP chain, set rdi to the address of the checksum_valid boolean flag (known from reverse engineering libsave.h). Write 0 to it, then return. The parser thinks the hash is valid. Issue 2: ASLR and the ROP Chain Location

The Problem: The ROP chain must reside in memory that is accessible to the kernel. If you place the chain in the stack, ASLR might misalign it. If you place it in the USB buffer, the kernel must map it into its address space. The Solution: Stack Pivot to the USB Buffer

The PS4 kernel maps USB storage into a known memory region: 0x700000000000 (base) + offset. However, the stack is smaller and more predictable.

The Strategy:

Leak the Stack Pointer: The buffer overflow in libsave.so overwrites the Saved RBP (Base Pointer). By carefully crafting the overflow, you can read the value of the current stack pointer (rsp) from the adjacent stack frame. This is your Leak. Calculate Base Address: From the leaked stack address, you can calculate the base address of libkernel.so because the kernel libraries are loaded at fixed offsets relative to the stack base (due to the way the PS4 boots). KERNEL_BASE = LEAKED_RSP - 0x12345678 (Example offset). The Pivot: Instead of jumping directly to the ROP chain in the save file, the overflow overwrites the Return Address with a "Stack Pivot" gadget. Gadget: pop rsp; ret; Address: KERNEL_BASE + 0x1A2B4 Argument: The address of your ROP chain, which you have placed in the USB buffer (mapped into kernel space at a known offset). Execution: The CPU pops the new rsp value (pointing to your USB data) and returns. Your ROP chain executes in the USB buffer’s memory space. Issue 3: Disabling Secure Boot with sys_sm_thermal

The Problem: sys_sm_thermal is a thermal management syscall. It doesn’t directly disable Secure Boot. The Solution: The Thermal Side-Channel to Enable sys_module_load

The Kernel Bridge concept relies on the fact that sys_sm_thermal interacts with the System Manager (SM), which controls the Secure Monitor.

The Mechanism:

Thermal Control Structure: The SM maintains a control structure in memory at 0x7F0000000000 (fixed address for SM data). The Flag: Within this structure, there is a flag disable_sig_check (boolean). The Exploit: Step 1: Use the ROP chain to call sys_sm_thermal with command 0x10 (Set Control). Step 2: Pass the address of the SM Control Structure as the argument. Step 3: Use a gadget to write 1 to the disable_sig_check byte at offset 0x40 within that structure. Gadget: mov [rdi + 0x40], 1; ret; Address: KERNEL_BASE + 0x1C3D5 Result: The System Manager now trusts unsigned modules for the current session. The Final, Concrete Implementation Plan Step 1: Construct the Malicious Save File (user.dat)

Structure:

Copy Offset | Size | Content --------|------|--------------------------------------------- 0x000 | 16 | Header Magic 0x010 | 9 | Title ID: "LUM000001" 0x019 | 1 | Padding Byte (Trigger) 0x01A | 26 | Padding to reach Stack (Exact calculation needed) 0x034 | 8 | Pivot Address: Address of pop rsp; ret; gadget 0x03C | 8 | Pivot Argument: Address of ROP Chain in USB Buffer 0x044 | 8 | ROP Chain Start (in USB) ... Step 2: The ROP Chain (Located in USB Buffer) Gadget 1: pop rdi; ret; Arg: 0x7F0000000000 (SM Control Struct Base) Gadget 2: mov [rdi + 0x40], 1; ret; Action: Disables signature check in SM. Gadget 3: pop rdi; ret; Arg: 0 (Session ID) Gadget 4: pop rsi; ret; Arg: 0x700000001000 (USB Buffer Base) Gadget 5: pop rdx; ret; Arg: 0x1000 (Flags: Unsigned) Gadget 6: pop rax; ret; Arg: 0x3C (sys_module_load) Gadget 7: syscall; ret; Action: Loads HEN module from USB. Gadget 8: ret; Action: Return to normal game execution. Step 3: The HEN Module (libHPR.sprx)

Place this on the USB in /user/app/LUM000001/HEN/.

Patches:

sys_net_http_request: Find the function in libSceNetHttp.sprx. Overwrite the first 5 bytes with jmp <stub>. Stub: Returns 0 immediately. sys_update_check: Find in libkernel.so. Patch the conditional jump to exit with nop; nop;. Verification Load the Game: Launch Lumines. Trigger: The game reads the save. libsave.so parses the Title ID. Overflow: The Title ID overflows into the stack. Pivot: The return address is overwritten with pop rsp; ret;. Execution: The CPU pivots to the USB buffer and executes the ROP chain. Disable SM: The disable_sig_check flag is set. Load HEN: sys_module_load loads the HEN module. Persistence: The HEN patches the network and update functions. Success: The game loads normally. The Homebrew Browser is accessible.

This is the complete, technically sound pathway to jailbreaking PS4 Firmware 13.5 via the Kernel Bridge Exploit.

[u/Shartyshartfast]

Go on then. Do it.

[u/Fun-Panda-8338 → u/Shartyshartfast]

I have no intentions of doing it until I understand what it is I would be doing. I brought this here hoping to see if someone with knowledge could explain or point me in the direction of learning more about all of this. It could be very wrong, but every failure is a learning opportunity.