PS5 Ban-Risk Report: Offline Jailbreak + Full USB Firmware Reinstall

ps5analysis

Date: October 3, 2026

Scope: Relapse exploit (PS5 FW 7.00–13.60), official firmware PUP, decrypted firmware analysis (5.50 / 6.02 / 10.60)

Scenario: jailbreak applied with no internet access → console fully reinstalled from USB with official firmware → console later used online / signed into PSN.

TL;DR

If the jailbreak was applied with no internet path at all (exploit hosted locally and the router's internet physically cut, not just a custom DNS), and the console was later fully reinstalled from USB with official firmware, there is no technical path for a ban from this scenario:

No jailbreak-related data ever reached Sony's servers (the console was offline).
A full reinstall erases all local software traces.
The only surviving hardware-level record (the EMC error log) cannot be read remotely by Sony; it requires a physical UART connection used by repair tools.

In this specific scenario, a ban is effectively impossible.

The common setup (custom DNS, internet still connected) is not an offline setup; see Step 0.5.

1. The Scenario

Console is fully offline (no Wi-Fi, no Ethernet).
The Relapse jailbreak is applied and used.
Console is fully reinstalled with official firmware from USB (Safe Mode → Reset PS5 → Reinstall System Software).
Console later goes online / signs into PSN normally.

Questions: can this lead to a ban? Does something like the EMC log get sent to PSN servers? What goes in and out?

2. What was done and how (step by step)

Step 0: How the Relapse jailbreak is applied (procedure research)

Community instructions (project README + scene guides) describe this procedure:

Console on firmware 7.00–13.60; disable automatic system updates.
Network settings → Set Up Internet Connection → Advanced Settings → DNS Settings → Manual → Primary DNS 45.56.67.85 (the project's recommended scene DNS).
Open Settings → Guide & Tips → User's Guide (the stock browser entry point).
Load the exploit page: https://ntfargo.github.io/Relapse-Exploit/, or a locally hosted copy (python serve.py → http://<PC-IP>:8000/).
WebKit stage runs (reloads are normal); kernel stage follows.
On success, an ELF loader listens on TCP/9021; payloads (kstuff, shadowmountplus, etaHEN) are sent from a PC over the LAN.

The console must be connected to the network for this setup. Setting a custom DNS is not the same as being offline; see the analysis below.

Step 0.5: Live test of the recommended DNS (tested 2026-10-03)

We queried the scene DNS (45.56.67.85) directly and compared every answer with a control resolver (1.1.1.1):

manuals.playstation.net → 45.56.67.85 (the scene server itself) vs 184.29.240.92 (control): redirected
duk01 / fsa01 / dus01.ps5.update.playstation.net → 0.0.0.0 vs real Sony IPs: blackholed
update.playstation.net → 0.0.0.0: blackholed
gs2.ww.prod.dl.playstation.net → 0.0.0.0 vs 34.104.36.172: blackholed
agst.e1.dl.playstation.net, agst.prod.dl.playstation.net (found in the firmware) → 0.0.0.0 vs 184.25.81.205 / 184.25.93.215: blackholed
apsnobj.non-prod.dl.playstation.net, apsnobj.stage.dl.playstation.net (found in the firmware) → 0.0.0.0 vs 184.25.90.135: blackholed
web.np.playstation.com, nsx.sec.np.dl.playstation.net → 0.0.0.0 vs real Sony IPs: blackholed
telemetry-console.api.playstation.com → 0.0.0.0 vs 92.122.17.216: blackholed
telemetry-web.api.playstation.com, analytics.playstation.net → 0.0.0.0 vs real Sony IPs: blackholed
zz-nonexistent-….playstation.net and ….playstation.com → 0.0.0.0 vs NXDOMAIN: wildcard match, the entire zones are blackholed
example.com, github.com, tiny.cc → normal vs normal: pass-through
ca.account.sony.com, auth.api.sonyentertainmentnetwork.com → 23.220.161.214 / 23.204.172.91 vs real IPs: not blocked

Additional checks:

IPv6 (AAAA) queries for blocked names return ::; no IPv6 leak.
The blackholed telemetry host is live: connecting to its real IP presents a Sony certificate (CN=telemetry-console.api.playstation.com, issued by SCEI DNAS Root 05) and Akamai answers 403. The only thing stopping the console is the DNS answer.
The scene server serves the User's Guide from its own nginx with a self-signed certificate for manuals.playstation.net (valid until 2036). It acts as a man-in-the-middle for that domain.

What this means:

The scene DNS is stronger than commonly described: it wildcard-blackholes the entire playstation.net and playstation.com zones; update, CDN, PSN, and telemetry names (including the endpoints found in the firmware analysis) all become unreachable.
But it is still not isolation:
- *.sony.com / *.sonyentertainmentnetwork.com (account/login infrastructure) are not blocked and resolve normally.
- It only controls DNS: hardcoded IPs or non-DNS traffic bypass it; the rules are third-party-controlled, unauditable, and can change at any time.
- The operator is in a MITM position for the User's Guide and sees every lookup the console makes.
- Everything non-Sony still works, so the console remains fully online.

Conclusion: the scene DNS blocks Sony's playstation.net/playstation.com name resolution, but it is not a firewall and not a guarantee. For an offline jailbreak, host the exploit locally and physically remove the internet path.

Step 0.6: The correct way to run the jailbreak with no internet path

On a PC on the same LAN: python serve.py (serves the exploit on port 8000 and prints http://<PC-IP>:8000/).
Remove the router's internet path: unplug the WAN/uplink, or use a dedicated router/AP with no internet connection.
Set the console's DNS to the router (or leave automatic). This is not required: type the local IP URL into the User's Guide.
Verify isolation: external pages fail to load, the local exploit URL works.
Run the exploit and send payloads over the LAN.

This guarantees nothing can reach Sony during the jailbreak session; that is the exact condition the "ban is impossible" conclusion depends on.

Step 1: Static analysis of the jailbreak itself

Cloned the public Relapse-Exploit repository and reviewed the entire exploit chain and its payloads.
Findings: browser-stage exploit → kernel use-after-free (aio_multi_wait) → kernel read/write → privilege escalation (uid 0, syscore-level auth) → QA / target_id / utoken flags patched in RAM only.
The payload loader listens on TCP/9021 and executes payloads in memory.
No persistent kernel patches. Only user-partition files are written (homebrew libs, temp payloads). Everything else is memory-only and disappears on reboot.

Step 2: Official PUP outer structure analysis

Downloaded the current official recovery PUP from Sony's CDN.
Parsed the outer container: it is a plaintext SLB2 wrapper with two entries (PS5UPDATE1.PUP, PS5UPDATE2.PUP); everything beyond the header is encrypted.

Step 3: EMC / hardware log research

EMC = the console's southbridge / embedded controller. Its error log ("errlog") lives in the NOR/NVS flash (32 entries; OS crash codes, watchdog, thermal, VRM events).
The errlog is read/cleared only over UART (Console Service Tool / ps5-uart tools).
It survives firmware reinstalls and is not remotely accessible by PSN.
The same NVS area also holds QA flag token, IDU mode, regmgr upcause/seqno, factory/current FW fields (mapped from public psdevwiki documentation).

Step 4: Decrypted firmware acquisition and extraction

Downloaded three decrypted firmware archives from the public community archive DKS (darksoftware.xyz):
- 5.50 Recovery: 550RT.zip, MD5 a7d1a015b12c4e0e085ef89274da1741, verified
- 6.02 Recovery: 602_PS5UPDATE1.PUP.zip, MD5 257298ed6379c4b464e8bfd3428905e1, verified
- 10.60 Update: 1060.rar, MD5 959d1addacc665bd4592c40093482719, verified
Unpacked with the open-source tool ps5-pup-unpacker.
The system partition images inside (ssd0.system_b, ssd0.system_ex_b, ssd0.preinst) are plain exFAT filesystems (fully decrypted), not encrypted blobs.
Mounted them read-only on macOS and inspected the real filesystem contents.

Step 5: Logging / telemetry analysis on the filesystem

Found the complete OS logging stack in retail firmware:

SystemLogger (v1):
- system_log.db: event log rows contain event_id, session_id, psn_account_id_01..04, delivery_time, up to 99 parameters.
- sl_performance.db: delivery statistics including http_communication_time_histogram, retries_to_send_histogram, success/failure counters.
SystemLogger2 (v2):
- sl2_log*.db: fields tried_to_server_notify_date, server_notify_interval_time, server_notify_retry_count, user_id0..3.
- Config table with insert_limit, retry_limit, periodic_event_interval.
Delivery libraries present in retail: libSceSystemLogger2Delivery.sprx, libSceSystemLogger2NativeQueueClient.sprx.
Redis-based telemetry: app NPXS40028 ("RedisServer") loads libSceTelemetryRedisModule.sprx; it is bound to localhost only (127.0.0.1:1003), an internal store, not an internet service. VSH also ships ReactNative.Modules.Vsh.Telemetry.Nq.dll.sprx. Version 10.60 adds NetworkProfilerDaemon and a shared pub/sub client.

The configs that define which events are sent (sl-config*.xml.env, sl-privacy-def*.json.env) are encrypted, and live databases are not present in these read-only images. So the capability is proven; the exact payloads and schedules cannot be read statically.

Step 6: Plaintext network endpoint scan (all three versions)

Scanned every plaintext file in all mounted images for URLs and domains. Found only:

agst.prod.dl.playstation.net, apsnobj.*.dl.playstation.net: Sony content CDN domains (in title_separation_ro/FQDN_list.json).
rcl.ueiquickset.com: a third-party TV remote setup service (UEI QuickSet; default mode is local).
Open-source/license links and internal Sony GitHub references.
No telemetry/log endpoint in plaintext.
No EMC / errlog references anywhere in the filesystem (apparent matches inside certificate dumps were base64 coincidences).
EMC/chip firmware blobs (emc_salina_c/d.bls, titania.bls, eap_kbl.bin) are encrypted SLB2 containers; they are updated by flashing, not readable.

3. Findings summary

EMC error log (hardware). Sent to Sony servers? No mechanism. Survives reinstall? Yes. Remotely readable? No — UART only.

OS event logs (SystemLogger2). Sent to Sony servers? Designed for server delivery (config-dependent). Survives reinstall? Local queues wiped by reinstall. Remotely readable? N/A.

Jailbreak artifacts. Sent to Sony servers? Never (offline JB). Survives reinstall? No. Remotely readable? N/A.

Console identity (serial/ID). Sent to Sony servers? Used by PSN normally. Survives reinstall? Yes. Remotely readable? Yes (but not flagged unless previously banned).

4. Why a ban is effectively impossible in this scenario

Offline JB (enforced: local host + internet path removed) → no request was ever made to Sony's servers during the jailbreak session; no server-side record exists.
A full USB reinstall rewrites the system, system_ex and preinst partitions from the official images (verified: the recovery PUP contains these exact exFAT images), so all local traces are gone.
The EMC log cannot be transmitted: no component in the firmware references or packages it, and it is a hardware-level record readable only via physical UART.
After reinstall, the console behaves like a normal console: its online requests are ordinary (update checks, PSN session, store/content, privacy-dependent telemetry).
The only ways this scenario could still be risky: the console identity had already been flagged before (not part of this scenario), or the console was not offline (e.g., Wi-Fi left on in the background).
Caveat: DNS is not isolation. If the jailbreak was done with the public DNS (45.56.67.85) and the internet still connected, the console remained online. Our live test shows that DNS blackholes all playstation.net/playstation.com names (updates, CDN, PSN, telemetry), but *.sony.com account endpoints still resolve, the block is DNS-only (no firewall), and the DNS operator is an unauditable third party. Under that setup the "nothing reached Sony" guarantee does not fully hold.

5. Limitations

Sony publishes no ban statistics; this is a technical assessment, not a guarantee.
Exact telemetry event lists and endpoints are encrypted in firmware; a live network capture (DNS log or Wireshark SNI) is required for full endpoint enumeration.
"Impossible" refers to this specific scenario (offline JB + full official reinstall). It does not cover going online with the jailbreak active, cheats/piracy, or a previously flagged console.
"Offline" must be enforced (local hosting + internet path removed). A custom DNS alone does not isolate the console.

6. Optional: verify on your own console

Use a DNS logger (Pi-hole / AdGuard / router) or a hotspot + Wireshark capture.
In Wireshark, filter tls.handshake.extensions_server_name to list every domain the console contacts. TLS hides payloads, but the SNI field shows destinations.

Sources

Relapse-Exploit source repository (public)
Relapse-Exploit usage instructions (recommended DNS, local serve.py, User's Guide entry point)
Community jailbreak guides (Se7enSins, OneJailbreak, SuperPSX): procedure details
psdevwiki: PUP structure, EMC/NVS layout
Console Service Tool / ps5-uart documentation
DKS decrypted firmware archive (5.50, 6.02, 10.60): MD5s verified
ps5-pup-unpacker; macOS exFAT read-only mount; SQLite schema analysis

This report was produced with the assistance of an AI (large language model). All firmware files were obtained from public community archives; no proprietary keys or console hardware were used. Provided for educational and research purposes.