Record PSP security investigation artifacts and probesHEADmain

1 files changed, 61 insertions, 0 deletions

diff --git a/fw/CANDIDATE-ASD-163-1A2-LAST-CHANNEL-SWEEP.md b/fw/CANDIDATE-ASD-163-1A2-LAST-CHANNEL-SWEEP.md
new file mode 100644
index 0000000..d7ba425
--- /dev/null
+++ b/fw/CANDIDATE-ASD-163-1A2-LAST-CHANNEL-SWEEP.md
@@ -0,0 +1,61 @@
+# ASD `.163` `0x1A2`: group sweep omits last of 32 channel records
+
+**Conditional off-by-one callback omission in signed code, shown with
+synthetic channel records; no live HDCP/security effect.** The signed
+`0x1A2` dispatcher entry reaches `sub_D0AEB0` with selected channel
+`0..31`. For an active selected record at `0xD33510+92*channel`
+with `+8 != 1`, `+64 == 5`, and stored `+60 == channel`, raw
+`0xD0AF04..0xD0AF32` starts at the **first** record, sets remaining
+count to **31**, and advances by 92 bytes each iteration. Its group
+match requires an active record, equal `+20` key, and `+64 == 5`.
+Matching records trigger callback entries at
+`0xD0AF40/0xD0AF4E`. Exactly indices **0..30** are checked;
+index 31 is not. The selected record also has a separate final
+callback path, so this is specifically an omission when record 31
+is a *peer* of a different selected channel, not proof that direct
+`0x1A2(31)` is inert.
+
+`python3 psp_emu/harness/probe_asd163_1a2_last_channel_sweep.py`
+passed through the signed `.163` dispatcher with only synthetic
+active records and **intercepted ASIC/link callback callsites**.
+For selected channel 0, a planted matching record 30 reached the
+first captured sweep callback. Replacing it with an otherwise
+identical matching record 31 left only selected record 0 in that
+capture; 31 never reached it. Both runs reached the selected-channel
+final callback site and returned zero under stubbed callback results.
+Neither the callbacks nor a real protected session were executed.
+
+This is distinguishable from the earlier `0x1A9` sparse enumeration,
+`0x1AA` duplicate handling, and SRM multi-revocation cursor bugs:
+this loop is the `0x1A2` group teardown/status path over a
+**32-slot channel table**, not the SRM bitmap. Signed caller-ID and
+actual ownership are not compared in the immediate handler, but
+global management may be intended. Signed HDCP `.57` supplies a real client path: its command-14
+entry (`hdcp_TA_InvokeCommandEntryPoint` at `0x4013B4`)
+passes the request's first two inline words at `req+0xC` to
+`hdcp2_create_session` (`0x401E28`). The routine stores the
+first word as session `+4` and sends it to ASD `0x1A0` via
+`0x4044EA`. Its later session-teardown paths load that same
+`+4` word into the `0x1A2` wrapper at `0x404464`. The examined
+client does not cap this word at 30 before ASD dispatch. Signed
+ASD `0x100` itself admits index 31 and marks the 92-byte record
+active **before** its ASIC callback. For the measured ASIC-20
+variant, `sub_D08DAC` installs `field08` thunk `0xD050D1` →
+`asd_program_link_by_signal`; that signed descendant can set record
+`+64` to 5, but only under descriptor/signal and sometimes fixed
+fabric-read predicates. Type-1 descriptor callback `field80` instead
+sets `+64=6`. These paths show 31 is not barred at the *first*
+ASD/index check; they do **not** prove real hardware accepts a
+valid class/port combination for index 31 or yields the specific
+paired state. ASD `0x1A0` still requires active `+64=5`, and no
+live channel-31 admission is shown. Whether natural signed HDCP
+clients create an active peer at 31, produce the required `+60/+64`
+state, and depend on the omitted callbacks for security or
+availability is open. **Counterweight:** the separately audited
+`0x1A0` matching-peer loop also iterates indices 0..30 and `0x180`
+limits its selected index to 30, while other setters admit index 31
+(`fw/AUDIT-ASD-163-1A6-PEER-INDEX.md`). Index 31 could be
+reserved or intentionally excluded from *peer-group* operations;
+without its natural role, this is a conditional omission, not a
+proven security bug. No card request was made; do not create or
+tear down channels on hardware for a return code.