# Phase 0.9D independent recovery analysis

Date: 2026-07-18
Status: `UNPROVEN`

## elfldr

| Question | Source-bound answer |
|---|---|
| Write mechanism | none in audited source |
| Executor | original external exploit/rudimentary loader could launch an ELF, but its source is absent |
| Works if elfldr is broken | bootstrap independence is described, not demonstrated: `PARTIAL` |
| Works if Manager is broken | bootstrap path does not name Manager: `PARTIAL` |
| Works after reboot | `UNPROVEN` |
| Works without autoload | manual host send is described: `PARTIAL` |
| Works without defective listener | port 9020 is described as distinct from elfldr port 9021: `PARTIAL` |
| Exact restore target selectable | no live target mapping or write contract |
| Write then verify | absent |
| Old file remains intact | no restore transaction exists |
| Power-loss behavior | `UNPROVEN`; no atomic restoration contract |
| Second route | none source-bound |

Top-level required classification: `PARTIAL`. Detailed restore classifications:
`UNPROVEN` and `ABSENT`; no `INDEPENDENT_RECOVERY_CANDIDATE` is established.

## Payload Manager

| Question | Source-bound answer |
|---|---|
| Write mechanism | full Manager upload/install routes write files, but using a Manager to restore that same Manager is self-dependent and is not authorized |
| Executor | elfldr can launch a Manager ELF sent from a host, according to README/deploy source |
| Works if elfldr is broken | no; described manual Manager route depends on elfldr: `CROSS_DEPENDENT` |
| Works if Manager is broken | a separately supplied candidate could be launched through elfldr, but persistent restoration is absent: `PARTIAL` |
| Works after reboot | original exploit and elfldr repeatability are `UNPROVEN` |
| Works without autoload | manual send is described: `PARTIAL` |
| Works without normal Manager listener | host-to-elfldr launch is structurally separate: `PARTIAL` |
| Exact restore target selectable | no current live mapping |
| Write then verify | absent |
| Old file remains intact | upload/install paths are not an audited self-recovery transaction |
| Power-loss behavior | existing writes/renames are not proven safe for the current live Manager object |
| Second route | absent |

Top-level required classification: `PARTIAL`. Detailed classifications:
`CROSS_DEPENDENT`, `SELF_DEPENDENT`, and `POWER_LOSS_UNSAFE` for the available
shapes. None is recovery proof.

## Failure matrix

| Failed component | Still source-plausible | Not proven / unavailable |
|---|---|---|
| elfldr | original port-9020 exploit bootstrap, if the absent external chain remains usable | current exploit availability, persistent rewrite, exact target, verification, power-loss recovery |
| Payload Manager | elfldr remains capable of accepting and launching a separately supplied ELF in source | Manager live path, durable replacement, independent verification, recovery when elfldr also fails |

The current byte-exact Payload Manager backup remains
`HARD_BLOCKER_FOR_INSTALLATION`. Lack of independent recovery remains
`HARD_BLOCKER_FOR_EVERY_DEVICE_WRITE`.

## Side-by-side feasibility

elfldr `socksrv.c:477-507` terminates an already running `elfldr.elf` service
before creating another one. Payload Manager `main.c:81-103` terminates another
`pldmgr.elf` instance during startup. Both therefore have process/listener
overlap and global-state risks.

The controlled Manager source uses a separate profile/port but is not installed
or runtime-proven. Any candidate would require transfer and execution, a
source-bound non-live path, collision review, a timeout/cleanup contract, and
independent recovery. None exists here.

Classification: `BLOCKED` / `RECOVERY_UNPROVEN`. This is not staging,
installation, or execution approval.