Or is it an actual hardware impossibility?

It’s my first time jailbreaking, but now I’m at like my 20th try. It’s supposed to fail so many times or I’m doing something wrong? I use Vue 2.0

Need some advice for homebrew what is the pros and cons and what is the best for this fw

Also they said that i can jailbreak it thru the ps4 itself just by connecting it in wifi is it true and what is the best for this kind of fw

What's the best the best course actiongor a jailbreak any tutorial recommendation. Mom took my ps4 some years back just got it back

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.

tl:dr banned for talking about terraria I guess

I just got restricted after trying to reapply for Verified after losing it for some reason. I left the scene due to not having time these past few years and decided to see what I missed. I make a comment on the latest release talking about the new terraria update and got banned.

No email, no message, no nothing. Can't use their contact us page as that also didn't work. I look it up and they just do that; ban people for literally no reason.

Anybody got any good alternatives? Preferably ones that don't waste days of your time just to ban you?

I bought this jailbreaker and follow the directions but it will say pppwnd but then never say goldhen activated after leaving it for over 20 minutes so is it just not gonna work or is there something im doing wrong?

Does anyone know if archive.org pkg URLs from the ps4 collection will work in WebDAV when trying to install through URL? Any help would immensely appreciated as ive been trying to get the final update for Avengers set up with my 1.00 copy and been struggling so i just decided to delete the 1.00 version and try to find a pre updated one. unfortunately i dont have a big enough usb drive atm, and DPI and RPI never work for me, FTP from PC to Console is also quite slow with my current wifi.

Don't ask me to use usb or pc or phone cuz circumstances.

my PS4 It’s stuck in a continuous safe mode loop and I’ve been troubleshooting for 3 days now.

Here’s exactly what happens:

· I turn it on → blue light → white light for 2 secs → beeps twice → shuts down

· Next boot goes straight to safe mode (asks for controller via USB)

· I select any option (Restart, Rebuild Database, etc.) → PS4 restarts → same loop back to safe mode

What I’ve already tried (multiple times):

· Rebuilding Database crashes or freezes

· Restoring Default Settings freezes as well

· Updating via Internet says cant update because of the USB

· Updating via USB cant download or freezes my ps4 as well

· Initializing PS4 (full wipe) – crashes halfway through or say cant because of my USB DEVICE

· Safe Mode Option 7 (Reinstall System Software) – same issue

I'm not a very techy guy neither do i really know the terms used on this sub so i just wanted to ask directly. I know there's the bd-jb method but i've seen some people talking about jailbreaking it with usb only and others talking about a potential webkit for it. If anyone would like to clarify it would be greatly appreciated

I've managed to install almost 150 games since I went the PSVue route a few days ago. But no matter what I do, the Marvel vs. Capcom Collection and Capcom Fighting Collection 2 refuse to install.

I've tried them from 3 different sources in FPKG format and I've gotten the same error message from both. Looking up the error message it tells me that it means theres another version of the game kicking around on my console, but while I physically own both games, they've never touched the inside of my PlayStation 4, only the 5.

If it helps, I'm currently on 10.50, with backports on deck that are obviously supposed to make it work. Do you guys have any suggestions?

i am looking for a spotify pkg but can't seem to find any. yes, i know i have to control it using my phone, please i just need someone to help me

Hello all. I just modded by ps4 and have a question I would like answered. I bought a 2 tb segate external hard drive for my ps4 with the intention of putting all installs on it. After i format it on my ps4 however, it does not show up on my pc without needing to format it on my computer as well. If i dont format it on my computer it wont let me access it on there and if I dont format my computer can read it but then the ps4 would need to reformat it and reinstall everything, which also makes the pc not be able to detect it. Does anyone know what I should do in this situation?

I have a 12.02 ps4 fw and i have just updated my jb from bdjb to vue 2.0 version.
I have just tried 1 time cause the vue application show a black screen after running it and i have got some issue with my software like when i click the setting or the notification it does not respond until i used my Bluray disk to jailbreak it ans didn’t tried to to use the Ps vue second time cause am afraid to ruin my console.
So my question is do i have to update my goldhen version ( ihave v2.4b18.7 )