Files
chimera-gfx-Public/docs/runtime/phase-0.9d-bootstrap-recovery-chain.md
Chimera GFX release export a6037502d7
phase0-ci / build-and-audit (push) Successful in 2m14s
Publish Chimera GFX source
2026-09-03 03:27:14 +02:00

6.7 KiB

Phase 0.9D bootstrap and recovery chain

Date: 2026-07-18 Status: DESIGN_ONLY

This is an offline source audit. It does not establish current device state, firmware behavior, persistence, a live path, or recovery success. No PS5 was contacted.

Source-bound chain

flowchart LR
    A["External jailbreak / exploit host<br/>source absent from audited trees"]
    B["Rudimentary exploit ELF loader<br/>port 9020 per elfldr README"]
    C["elfldr bootstrap<br/>bdj.elf -> SceRedisServer"]
    D["elfldr socket service<br/>elfldr.elf, port 9021"]
    E["Payload Manager ELF<br/>manual or external autoloader"]
    F["Payload Manager HTTP service"]

    A --> B --> C --> D --> E --> F

The public and hardened elfldr README.md:3-19 describe host-to-console delivery to a rudimentary exploit loader on port 9020. The exploit and its host implementation are not present in any audited tree, so its repeatability and recovery behavior are unproven. Hardened elfldr main.c:28-89 enters through bdj.elf, temporarily attaches to SceRedisServer, and bootstrap.c:38-81 starts the socket server. socksrv.c:477-507 names that service elfldr.elf, removes an already running process with that name, and listens on port 9021.

The Payload Manager README describes either manual loading or placement by an external autoloader. Its deploy.sh only sends an ELF to elfldr; it does not install, read back, or recover a device file. The external autoloader, jailbreak host, browser exploit, and any USB recovery implementation are absent from the audited sources.

Dependency and recovery graph

Component Commit Persistence Start mechanism Boot critical Failure impact Recovery executor Self-dependent Depends on elfldr Depends on Manager After reboot Evidence / classification
Jailbreak/exploit host not present UNPROVEN user/browser/host, details absent UNPROVEN bootstrap unavailable if absent itself/external unknown no no UNPROVEN README description only; UNPROVEN
Rudimentary port-9020 loader not present session behavior UNPROVEN exploit chain UNPROVEN elfldr cannot be bootstrapped through the described route external exploit chain unknown no no UNPROVEN README description only; UNPROVEN
Hardened elfldr bootstrap 197623058f509eddde18868dafcb92fdcac66464 source shows process injection, not filesystem installation sent to port 9020 no source proof no port-9021 service port-9020 chain, if still available no no no UNPROVEN source plus missing upstream executor; PARTIAL
elfldr socket service same process-local in source bootstrap creates elfldr.elf no source proof no normal Payload Manager launch transport bootstrap no no no UNPROVEN source; PARTIAL
Public/full Payload Manager public base cfbc70f30f419b09bf2b52283f7409e2d3117ee1 external autoloader or manual, exact current deployment unknown elfldr or external autoloader UNPROVEN management UI/listener unavailable elfldr/manual route no yes no UNPROVEN README/source; PARTIAL
Controlled minimal Manager source e23d94ff91233aa770e2342800c1467875bdef44 explicitly not installed by the Phase-0.7 record would require a separately authorized transfer and launch no no impact on current device because installation is unproven none in this phase no yes no not installed source/offline record; UNPROVEN as device runtime

Bootstrap questions

  1. Original exploit start: only described as a BD-J or WebKit-style host route to a rudimentary loader; implementation and current operator sequence are absent. UNPROVEN.
  2. Direct browser/exploit delivery: the elfldr README proves only that an elfldr ELF is sent host-to-console. Exact browser assets are absent.
  3. elfldr storage: source proves a process service, not a persistent filesystem installation. Current storage is UNPROVEN.
  4. Payload Manager storage: README permits manual or external-autoloader use; actual current storage is UNPROVEN.
  5. Automatic start: controlled by an external autoloader and/or Manager configuration not present as current device evidence.
  6. Manual-only files: any ELF sent to elfldr can be manually launched in principle; current availability is not proven.
  7. Gone after reboot: process state and volatile flags are source-local, but device restart behavior of the complete chain is UNPROVEN.
  8. Persistent after reboot: no current artifact or configuration is proven persistent.
  9. Exploit after broken elfldr: conceptually independent in the README, but source and current operability of the original exploit are absent: PARTIAL.
  10. Exploit after broken Manager: same PARTIAL result.
  11. Independent recovery payload: the README permits sending another ELF through port 9020, but neither the executor nor a recovery payload is audited: PARTIAL, not recovery proof.
  12. Write-back through original chain: no source-bound file-write contract is present: UNPROVEN.
  13. Ignore a wrong non-autoload file: plausible, but live path and configuration are unobserved: UNPROVEN.
  14. Boot-loop potential: depends on unknown persistent autoload state: UNPROVEN.
  15. Automatic-start configuration: external autoloader configuration is absent. Manager uses /data/pldmgr/autoload.txt and /data/pldmgr/pldmgr_config.txt, but this does not prove the current bootstrap configuration.
  16. Keep automatic start disabled: design policy requires it; actual current state has no non-mutating source-bound attestation.
  17. Recovery after reboot: external exploit restart is only described: PARTIAL.
  18. Recovery after crash/hang: elfldr source restarts its accept loop and uses a controlled watchdog, but recovery of a broken persistent file is absent.
  19. USB/browser/host independent path: upload and launch paths exist; no audited PS5-to-host readback or independent restore path exists.
  20. Unproven answers: current persistence, live paths, installed versions, autoload state, exploit repeatability, boot-loop behavior, write-back, power-loss recovery, and post-reboot recovery all remain hardware facts.

Recovery classification

  • elfldr: PARTIAL. The described port-9020 bootstrap does not depend on the port-9021 elfldr service, but its implementation and current operability are missing.
  • Payload Manager: PARTIAL with a CROSS_DEPENDENT restore shape. Manual launch through elfldr is described, but durable restoration and verification are absent.
  • Byte-exact file recovery for either component: UNPROVEN.