8.4 KiB
Phase 0.9A offline anti-brick threat model
Status: DESIGN_ONLY. Historical operational status: READ_ONLY_PREFLIGHT_BLOCKED.
This is an offline design review. It does not describe a proven PS5 filesystem, installation method, recovery method, path, syscall or switch primitive. No PS5 was contacted; no file was transferred, installed or executed; no target artifact was created. Host simulation is not hardware evidence.
Evidence boundary
The review uses only existing repository evidence:
- immutable Phase-0.8 record and Phase-0.8R remediation contract;
- the permanent artifact denylist;
- Phase-0.7 offline identities for the hardened elfldr and controlled Payload Manager candidates;
- stock elfldr and Payload Manager sizes and hashes as
reference_only; - the offline rollback and installation review documents;
- clean local source identities for hardened elfldr, controlled Payload Manager and the unchanged lifecycle-probe source.
Current on-device paths, mounts, object IDs, hashes, firmware behavior, processes, services, listeners, autoload state, backups and recovery paths remain unobserved. The byte-exact on-device Payload Manager backup remains a hard STOP gate.
Severity means:
CATASTROPHIC: can remove the only working launch/recovery path, destroy both live and rollback identities, run unverified code automatically, or make recovery depend on a failed component;HIGH: can select or persist wrong/partial bytes, invalidate the evidence binding, or prevent controlled recovery;MEDIUM: disrupts control or observation but does not alone prove loss of both live and recovery objects;LOW: occurs before live mutation and should leave the old object intact, but still needs platform evidence.
Control profiles
A — wrong target
Possible damage is replacement of an unrelated or critical object. Before any
future mutation, one no-follow stable object must bind literal path, mount ID,
object ID, type, size and SHA-256, and the identity must be repeated
immediately before mutation. AB-001, AB-003, AB-004 and AB-007 prevent the
write. Recovery would require a separate verified backup and independent
executor; neither is proven. Namespace and object-identity semantics remain
UNPROVEN, so Phase 0.9A blocks.
| ID | Scenario | Severity |
|---|---|---|
| TM-A-01 | wrong path | CATASTROPHIC |
| TM-A-02 | wrong mountpoint | CATASTROPHIC |
| TM-A-03 | symlink, junction or other redirect | CATASTROPHIC |
| TM-A-04 | path resolves to another object after preflight | CATASTROPHIC |
| TM-A-05 | case or path normalization changes identity | HIGH |
| TM-A-06 | target is replaced between check and write | CATASTROPHIC |
B — wrong pre-image
Possible damage is treating modified or firmware-incompatible bytes as stock.
The future evidence must bind firmware, manifest, stable object, size and
digest in one current observation. AB-001 through AB-004 reject every partial
match. Detection must happen before mutation; rollback is not a substitute.
Current device identities and firmware runtime behavior remain UNPROVEN.
| ID | Scenario | Severity |
|---|---|---|
| TM-B-01 | live hash differs from stock reference | HIGH |
| TM-B-02 | live size differs | HIGH |
| TM-B-03 | object ID changes | CATASTROPHIC |
| TM-B-04 | firmware differs | HIGH |
| TM-B-05 | manifest belongs to another build | HIGH |
| TM-B-06 | modified installation is treated as stock | CATASTROPHIC |
C — backup failure
Possible damage is loss of all trusted rollback bytes. A backup must be
created before staging, on a separate identity, then closed, reopened,
re-identified and rehashed. Capacity, mapping and an independent recovery
executor must be proven. AB-005, AB-006, AB-016 and AB-017 block mutation
until this holds. The Payload Manager backup is currently a
CATASTROPHIC hard blocker.
| ID | Scenario | Severity |
|---|---|---|
| TM-C-01 | backup missing | CATASTROPHIC |
| TM-C-02 | backup is the same object as live | CATASTROPHIC |
| TM-C-03 | backup is on the same vulnerable path | CATASTROPHIC |
| TM-C-04 | backup is partial | CATASTROPHIC |
| TM-C-05 | backup hash differs | CATASTROPHIC |
| TM-C-06 | backup cannot be reopened | HIGH |
| TM-C-07 | backup-to-target mapping is ambiguous | CATASTROPHIC |
| TM-C-08 | recovery tool depends on the replaced component | CATASTROPHIC |
| TM-C-09 | storage or metadata capacity is insufficient | HIGH |
| TM-C-10 | backup is created only after live mutation | CATASTROPHIC |
D — write and power loss
Possible damage is a missing, partial or ambiguous live identity. A safe design needs isolated staging, durable files and directory metadata, and one old-or-new atomic switch. AB-007 through AB-013 reject in-place overwrite and unproven switch semantics. No such PS5 primitive is proven.
| ID | Scenario | Severity |
|---|---|---|
| TM-D-01 | power loss before staging | LOW |
| TM-D-02 | power loss during staging | HIGH |
| TM-D-03 | power loss after staging before verification | HIGH |
| TM-D-04 | power loss during live switch | CATASTROPHIC |
| TM-D-05 | power loss immediately after live switch | CATASTROPHIC |
| TM-D-06 | power loss before directory metadata is durable | CATASTROPHIC |
| TM-D-07 | partial write | CATASTROPHIC |
| TM-D-08 | short write | HIGH |
| TM-D-09 | write error | HIGH |
| TM-D-10 | flush or fsync error | CATASTROPHIC |
| TM-D-11 | file bytes correct but directory not durable | CATASTROPHIC |
| TM-D-12 | new file has wrong ownership, mode or metadata | HIGH |
E — process and lifecycle
Possible damage is automatic launch of unverified bytes, stale mappings or a crash loop. A future observation must establish all relevant owners, instances, mappings, listeners, supervisors and authoritative autoload/retry state. AB-010, AB-013, AB-014 and AB-020 require quiescence and a later one-shot approval. Unknown topology blocks before switch.
| ID | Scenario | Severity |
|---|---|---|
| TM-E-01 | target executable is active | HIGH |
| TM-E-02 | multiple instances exist | HIGH |
| TM-E-03 | service restarts itself | CATASTROPHIC |
| TM-E-04 | listener conflict | MEDIUM |
| TM-E-05 | process holds old file or mappings | HIGH |
| TM-E-06 | watchdog or supervisor automatically restarts | CATASTROPHIC |
| TM-E-07 | autoload starts the candidate before verification | CATASTROPHIC |
| TM-E-08 | automatic retry creates a crash loop | CATASTROPHIC |
F — rollback failure
Possible damage is restoring wrong bytes to a wrong path, automatic execution
or loss of the recovery executor. Rollback must bind the preverified backup,
exact target mapping and independent executor. AB-006 and AB-015 through
AB-017 require a separate approval and post-rollback identity proof. A failed
rollback verification is CATASTROPHIC/BLOCKED, never a retry.
| ID | Scenario | Severity |
|---|---|---|
| TM-F-01 | wrong backup selected | CATASTROPHIC |
| TM-F-02 | wrong rollback target path | CATASTROPHIC |
| TM-F-03 | rollback interrupted | CATASTROPHIC |
| TM-F-04 | restored hash is wrong | CATASTROPHIC |
| TM-F-05 | rollback automatically starts a service | CATASTROPHIC |
| TM-F-06 | rollback works only if Payload Manager works | CATASTROPHIC |
| TM-F-07 | rollback works only if elfldr works | CATASTROPHIC |
G — operator error
Possible damage is a role swap, reused authority or combined loss of both runtime components. Component manifests and approvals must be bound to one device, firmware, action, hash, size and expiration. AB-018 through AB-020 prohibit a combined transaction, exclude the lifecycle probe and stop phase carryover. Component order is not guessed.
| ID | Scenario | Severity |
|---|---|---|
| TM-G-01 | hardened elfldr and Payload Manager are swapped | CATASTROPHIC |
| TM-G-02 | lifecycle probe is treated as installation candidate | CATASTROPHIC |
| TM-G-03 | wrong firmware or build is selected | HIGH |
| TM-G-04 | two installation phases are combined | CATASTROPHIC |
| TM-G-05 | approval for one component is reused for another | HIGH |
| TM-G-06 | stale manifest is used | HIGH |
| TM-G-07 | general READY overrides a specific blocker | CATASTROPHIC |
The item-specific reasons and machine bindings are in
manifests/runtime/phase-0.9-anti-brick-design.json.
Decision
Every threat is detectable only under evidence contracts that are not yet satisfied on the PS5. The design is fail-closed and suitable for host review, but not for installation engineering on a device.
BLOCKER: NO PROVEN POWER-LOSS-SAFE SWITCH.