Record PSP security investigation artifacts and probesHEADmain

1 files changed, 54 insertions, 0 deletions

diff --git a/fw/AUDIT-ASD-163-207-ASIC20-CALLBACK-OUTPUT.md b/fw/AUDIT-ASD-163-207-ASIC20-CALLBACK-OUTPUT.md
new file mode 100644
index 0000000..8d7a9ab
--- /dev/null
+++ b/fw/AUDIT-ASD-163-207-ASIC20-CALLBACK-OUTPUT.md
@@ -0,0 +1,54 @@
+# ASD `.163` service-2 `0x207`: ASIC-20 callback stores one validated dword
+
+**Scoped signed callback audit and synthetic control, not a live
+private-pointer disclosure.** Immediate `asd_svc_op_207`
+(`0xD0DF9C`) validates exactly **four output bytes** at `msg[1]`,
+then calls callback slot `0xD397B0+0x3C` if nonnull. Signed startup
+`sub_D0E75C → sub_D0E10C` installs thunk `0xD0C351` at that slot
+for ASIC variant **20** (the variant measured on the card in
+separate read-only work). Its signed descendant
+`asd_get_pair_D49838` (`0xD0C440`) loads a pointer from ASD-private
+`0xD39848`, loads **one** dword from that pointer, and stores it at
+caller output offset **zero only**. The misleading `get_pair` name
+must not be used to infer an eight-byte output. The callback return
+is ignored by the leaf after the nonnull precheck.
+
+`psp_emu/harness/probe_asd163_207_asic20_output.py` passed on
+signed `.163` dispatch with a **planted synthetic** ASIC-20 slot and
+source pointer. A GCP-owned validated output received exactly four
+public marker bytes; its next 12 sentinel bytes were unchanged.
+An ASD-private output pointer was rejected with status 2 before
+callback invocation. Both config words were restored **only in
+emulator memory**. No natural ASD-private pointer content or
+hardware read was sampled.
+
+**Additional signed startup trace (no card read):** the original
+ELF has no IDA-mapped BSS beyond `0xD29100`, so a direct IDA xref
+to `0xD39848` is unavailable. Following code/data literals instead
+resolved `off_D0C47C = 0xD39848` and
+`dword_D0C438 = 0x030109EC`. The ASIC-20 branch of `sub_D0E10C`
+installs Thumb pointer `0xD0C355` (`sub_D0C354`) in the callback
+at `0xD397B0+0x24`. **Correction to the earlier scoped scan:**
+`sub_D0E75C` directly calls that callback as
+`v6 = *((... )v5+9); v6()` after successful variant setup;
+that indirect invocation was overlooked. `sub_D0C354 →
+asd_set_pair_D49838` sets private `0xD39848` to the **fixed**
+CPU-address value `0x030109EC` and the adjacent word to
+`0x03010AE8`. ASIC-20 `0x207` then dereferences the first fixed
+address and writes one dword into a validated caller buffer.
+The two pointers are not taken from the `0x207` request.
+Older local emulator notes already identified `0x030109EC` as
+**C2PMSG_59** (`psp_emu/pspemu/memmap.py`,
+`psp_out/FUZZING-EMULATED.md`); this startup trace resolves *how*
+that fixed source is installed in signed `.163`, not a newly
+identified arbitrary target. The register's live content and
+security meaning are not established by the emulator's label.
+
+This establishes a signed natural *writer path*, **conditional on
+startup succeeding through that callback**. It does not establish
+the live pointer value, the Navi31 meaning or permissions of those
+CPU-window addresses, a card `0x207` return, or confidentiality
+impact. Other variants and dynamic reinitialization remain open.
+The isolated synthetic source pointer is not proof of GCP control
+of an ASD-private read target. GCP's separate `0x404` read remains
+the established disclosure route. No card `0x207` request was made.