AXP-Resurection/docs/009-fortify-v4-capture-results-review-20260927.md

<!-- Status: historical — Magisk 009 ship resume: docs/009-handoff-20261008.md -->

> **Status: historical.** Do not use as execution order. Resume: [`009-handoff-20261008.md`](009-handoff-20261008.md).

# v4 capture results review — 2026-09-27

## Result

The capture channel still has no validated panic-survival result. Do not infer
that AES selectively overwrites offset 0 while sparing offset 2048, and do not
choose a high offset as a safe region without establishing its ownership and
observed persistence. No FORTIFY-specific failure has been captured yet.

Reviewed Cursor's recorded experiment summaries, v4 generated source, the kernel
ramoops implementation, sunfish DT and init.ramoops.sh. Read the current LAB alt
region while LAB was running combo4 #16; no device writes, flashes or reboots.

Current 4 MiB capture SHA-256:
`24bbccbf4ed1271bc0950167f4a7921e2a79c534ad735d506ebb504a0353f310`.
It contains `AXPDIAG0,M,20260927T084531Z,panic_reg` at 2048, and no AXPDIAG
marker at the eight expected failure offsets 0,128,256,384,512,640,768,896.

## Unsupported steps in the current explanation

1. Random-looking bytes are not proof that the current test caused encryption.
   Without a before/after snapshot from the same attempt, they can be old data,
   overwritten data or ciphertext. The stored old captures are from different
   experiments and cannot establish this particular transition.
2. The milestone is written again on every v4 boot, with a build-time identifier
   shared by every boot of that image. Cursor reports that the first SysRq-c
   returned with kernel_panic, followed by further live v4 tests. A regenerated
   milestone is therefore an alternative to survival across panic. Final
   recovery to combo4 does not resolve its age across the preceding boots.
3. The v4 latch is in ordinary kernel RAM. SysRq-x sets it. Clearing the alt
   region with dd does not clear the latch in the running kernel. A subsequent
   SysRq-c in that same boot will skip recording, even if the region looks
   empty. Cursor's summary says a clean retry occurred but does not establish
   the full clear/reboot/no-X sequence; this remains a confounder, not a proven
   mistake in the executed sequence.
4. Current fs/pstore/ram.c exposes ramoops_decrypt_alt: it reads cxt->size,
   decrypts with crypto_aead_decrypt, and copies the whole buffer back only on
   success. This is not a panic-time encrypt routine. The inspected sunfish
   init script invokes ramoops -D and then ramoops -g -l -c. No kernel panic
   encrypt implementation was identified by these searches. Firmware ownership
   remains possible, but unproven. Disabling kernel decryption would not by
   itself demonstrate that an external encryption path was disabled.
5. The DT declares a 4 MiB alt ramoops reservation, not a separately reserved
   diagnostic high-offset region. No offset within it is currently shown safe.

## Next useful test: preserve attribution before another rebuild

Use the existing no-FORTIFY control to establish a documented timeline. Keep
SysRq-x and SysRq-c experiments in separate boots, and archive full dumps,
kernel identity, and boot reason at each available observation point.

- Archive and clear the diagnostic region BEFORE booting the control; then
  verify the region contains no complete old failure record. Do not clear only
  the persistent bytes after X and assume the in-memory latch has reset.
- Run a fresh boot with no X. Archive the pre-C contents; execute only C.
  Recover directly to combo4 when possible, recording any intermediate v4
  boot or forced hardware reset. A forced reset is a separate experimental
  condition from the automatic panic reboot.
- Compare the full before/after bytes, including mirrors and milestone area.
  Do not use the same-build milestone alone as evidence of survival.
- Independently test X persistence through the SAME recovery sequence. This
  distinguishes a writer that works in a live kernel from storage that survives
  the recovery path. It does not replace the fresh-C test.

If fresh C still leaves no attributable record, a control-only diagnostic can
read back/validate the exact committed C record immediately before panic and
report or expose that result while observable. This separates failure to write
from later loss. It must remain a diagnostic experiment, not a swallowed panic
or a production hardening change.

Only after identifying which transition loses a verified record should the
next patch change its storage or intercept an identified writer. A separately
reserved region needs a board/firmware-compatible design; an arbitrary high
offset is not a substitute for that evidence.

## Remaining source limitation

v4 composes up to 128 bytes but caps persistence at 120; long tokens can lose
the terminating newline required by adoption. This does not explain the short
sysrq-c/sysrq-x records, but must be fixed for general panic messages.

The original FORTIFY cause remains open. Diagnostics v2/v3 had concrete
implementation defects; v4 fixes those major defects and boots, but its test
results still do not establish a working early-panic channel.

## Follow-up LAB (same evening, documented)

Clean C-only:
`.local-artifacts/009-v4-clean-c-20260927T190738Z/` — clear → v4 boot (no X)
→ C → **intermediate auto v4 reboot** (`kernel_panic`) → combo4. No
`AXPDIAG1` at T3 or T4. Fail zone 0:1024 went from all-zero (T2) to opaque
non-`AXPDIAG1` bytes (T3=T4). Latch/X confounder ruled out for this run.

X persistence (no panic):
`.local-artifacts/009-v4-x-persist-20260927T191143Z/` — `AXPDIAG1,X,...`
survives combo4 recover; fail[0:128] identical before/after.

Next: distinguish “C never committed” vs “lost across panic” with a
control-only pre-panic readback of the committed C record (see above).