Reading PS5 exploit results: from chain completion to a working payload

The most useful PS5 success report tells you which capability worked, not just that the page reached its final line. Separating chain completion, loader connectivity and payload behavior makes a failed run much easier to narrow down.

Relapse provides a concrete example: its completion message, native-thread status and optional-payload upload are separate observations. Treating them as interchangeable throws away useful diagnostic information.

What the completion screen actually checks

In Relapse's main.js, result.payloads selects the message elfldr is listening on port 9021. That branch does not itself connect to the loader. It registers an R2 handler which later calls loadOptionalPayloads; printing the message is not the same event as sending those payloads.

There is another distinction in the native-stage wrapper, kexp.js. After its prerequisite checks and payload preparation, runKexp rejects a nonzero pthread_join status, logs shellcodeResult, then returns true. The native thread's returned value is logged, not used as a success predicate.

That is a statement about these JavaScript checks, not evidence that the native stage failed. The native return-value contract and actual console behavior are not established by this source reading.

Three milestones worth keeping separate

1. The chain reached its completion path. Preserve the exact message and any earlier error. This identifies the path reported by the host; it is not an independent loader test.
2. The loader accepted a connection and a transfer. Those are additional observations. In the same kexp.js, connectToElfldr checks connection status, while sendElf checks socket writes. A completed upload still does not demonstrate that the ELF executed successfully.
3. The payload produced its expected effect. A small, known payload with an unambiguous observable result is stronger execution evidence than an open port or a “sent” line. Describe the effect, not just the absence of an error.

These are troubleshooting boundaries, not a universal recipe for every exploit host. A loader can be reachable while a particular ELF is incompatible; a transfer can finish without the requested feature becoming usable. Conversely, an unavailable loader alone does not identify which earlier stage went wrong.

Make the report useful to the next person

Include the firmware and console model, the exact host revision/build, the last completed milestone, the payload version, and the result you actually observed. Keep “loader connected”, “ELF sent” and “payload feature worked” as separate statements. That gives someone a boundary to investigate instead of one oversized “jailbreak failed”.

For a minimal loader demonstration, which benign ELF behavior would you choose to prove execution, and would one successful run be enough or should repeat loading be part of the claim?