# 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.**