A payload URL that works in your desktop browser can still fail when the console fetches it. Before changing payloads, work out what you actually sent: ELF bytes, a console-file reference, or a remote URL. Those are different operations, even when they use the same loader port.
Pick the input path
For these examples, elfldr must already be running and the payload must be compatible with your setup. The elfldr v0.27 README uses an exploit-provided loader on port 9020 to deploy elfldr, then port 9021 for subsequent payloads. Check which listener your host actually provides.
| Input sent to elfldr | Where the payload comes from | What must already exist |
|---|---|---|
| Raw ELF bytes | The sending computer | A local payload file |
Text file:/data/payload.elf |
The console's filesystem | That file on the PS5, readable by the loader |
Text https://…/payload.elf |
A request made by the console | A reachable URL returning the intended payload |
A file: reference does not upload your PC's file. Likewise, your desktop browser reaching a URL does not establish that the console can fetch the same bytes.
Here are the first two forms, following upstream's netcat syntax. Replace the documentation IP with your console's LAN IP; the first command reads a file on your computer, while the second names a file already on the console:
PS5_HOST=192.0.2.10
nc -q0 "$PS5_HOST" 9021 < ./payload.elf
printf '%s\n' 'file:/data/payload.elf' | nc -q0 "$PS5_HOST" 9021These are alternatives, not two required steps. The upstream examples use netcat's -q0 option; netcat variants differ, so check your implementation's EOF/quit option if it rejects that flag.
A URL inside a URL needs its own encoding
The HTTP interface accepts a payload URL in the outer request's uri parameter. Suppose the intended payload URL is:
https://example.invalid/payload.elf?a=1&b=2This is an illustrative address, not a download. If you paste it directly after ?uri=, its raw & becomes a separator in the loader's outer query. In v0.27's URI parser, uri_get_param extracts the value up to that separator and then percent-decodes it.
Encode the entire inner URL as one parameter value. The corresponding outer request target is:
/?uri=https%3A%2F%2Fexample.invalid%2Fpayload.elf%3Fa%3D1%26b%3D2After the outer decoding step, the loader receives the intended inner URL, including &b=2. If that inner URL already contains percent escapes, encode those percent signs for the outer layer too. Quoting a shell argument protects it from the shell; it does not encode an HTTP query value.
Read the response, not just the status
In v0.27's socket handler, the GET parser writes HTTP/1.1 200 OK before on_connection calls uri_get_content. Payload spawning happens later.
So that client-facing 200 is not a download receipt or an execution result. The handler can subsequently emit Error reading HTTP payload or Error spawning payload; retain the response body and any loader/payload logs, not only the status line. This ordering describes the tagged source, not proof that every exploit host's bundled ELF matches it.
For a useful failure report:
- Record the loader build, console firmware and payload version.
- Say whether you uploaded bytes or sent a reference. For a URL, preserve the outer encoding and intended inner URL, with credentials or signed tokens redacted.
- Separate acquisition/read errors from spawn errors, then describe the payload's expected observable effect.
If raw upload works but URL loading fails, that gives you an acquisition path to investigate before blaming the ELF itself.
When comparing raw upload with URL loading, what console-side evidence has helped you distinguish a failed download from a payload that started and then exited?