Explore both untested sink items; both close negatively

Item 2, the sender question. Decoded ASD's 0x300..0x309 arm, resolved each
handler's worker function, and tested forward reachability to sub_D12D4C with the
dispatcher excluded as a bridge -- including it makes every handler "reach"
everything, which is how a first attempt produced a vacuous all-REACHES result.
Only cmd 0x301 (worker 0xd132a8) reaches the rxid parser. Scanning every image for
a dest-2 sender of it: hdcp sends 0x302/0x303/0x307 but not 0x300/0x301, and dtm,
ras, asd and sos send none in that range. So no firmware we hold sends ASD command
0x301, and the one parser whose length comes from sink-supplied content cannot be
driven from the host at all -- the same wall ASD 0x100 sat behind, but with no
DTM-style sender to find this time.

Item 1, structured data. Compared sink strategies against a 209-block baseline:
constant 0x06 gives 1027 reads and 10 new ASD blocks; per-read varying data gives
22 reads and 1 new block; address-derived data gives 27 reads and none. Constant
fill reaches the most new code, and the read counts explain why -- varying replies
make the firmware bail after ~25 reads instead of looping 1000+ times, so it never
enters the retry paths. The intuition that valid-looking data explores deeper is
wrong here: the sink-only surface is polling loops entered by data that keeps a
status bit stuck, which a constant provides and a varying value does not.

Net: both items close negatively. The length-bearing parser has no sender, and
structured data reaches less code than byte fill, so there is no hidden depth
behind the experiments already run. That exhausts the display-sink angle at this
rig's reach; the harness remains the only way to execute ASD's display paths, but
the surface is polling and control flow.

1 files changed, 56 insertions, 0 deletions

diff --git a/psp_out/ANGLE-DISPLAY-SINK-INPUT-SURFACE.md b/psp_out/ANGLE-DISPLAY-SINK-INPUT-SURFACE.md
index 3cfab7b..3275bdd 100644
--- a/psp_out/ANGLE-DISPLAY-SINK-INPUT-SURFACE.md
+++ b/psp_out/ANGLE-DISPLAY-SINK-INPUT-SURFACE.md
@@ -1821,3 +1821,59 @@ behind the same wall as ASD command `0x100` was (a sender outside the host path)
 A malicious monitor is a real, demonstrated input channel into PSP firmware that
 steers execution. No path from it to memory corruption has been found, and the
 most promising target is not reachable from the host side.
+
+## Both untested items, explored
+
+### Item 2: only ASD cmd 0x301 reaches the parser, and nothing sends it
+
+Decoded ASD's `0x300..0x309` arm and resolved each handler's **worker** function,
+then tested forward reachability to `sub_D12D4C` **with the dispatcher excluded as
+a bridge** (including it makes every handler "reach" everything, which is how a
+first attempt produced a vacuous all-REACHES result):
+
+    cmd 0x300 -> worker 0xd13248  no
+    cmd 0x301 -> worker 0xd132a8  REACHES the rxid parser
+    cmd 0x302 -> worker 0xd13158  no
+    cmd 0x303 -> worker 0xd131dc  no
+    cmd 0x304..0x309             no
+
+So the sink-derived-length parser is reachable through **exactly one** command,
+`0x301`. And scanning every image for a dest-2 sender of it:
+
+    hdcp  sends 0x302, 0x303, 0x307   (NOT 0x300/0x301)
+    dtm   none in 0x300..0x308
+    ras   none        asd none        sos none
+
+**No firmware we hold sends ASD command 0x301.** The one parser whose length comes
+from sink-supplied content therefore has no sender in any of the five images, so it
+cannot be driven from the host at all — the same wall ASD `0x100` sat behind, but
+this time with no DTM-style sender to find.
+
+### Item 1: structured sink data opens LESS surface, not more
+
+Compared sink strategies over the same chain (baseline = no sink, 209 ASD blocks):
+
+    const 0x06   reads=1027  ASD=219  new blocks vs baseline: 10
+    seq (varies)  reads=22    ASD=206  new blocks vs baseline: 1
+    addr-derived  reads=27    ASD=209  new blocks vs baseline: 0
+
+Constant fill reaches the most new code; per-read varying data reaches almost
+none, and address-derived data reaches nothing new. The reason is visible in the
+read counts: with varying replies the firmware bails after ~22-27 reads instead of
+looping 1000+ times, so it never enters the retry paths. The intuition that
+"valid-looking data explores deeper" is **wrong here** — the polling loops that
+constitute the sink-only surface are entered by data that keeps a status bit
+*stuck*, which a constant provides and a varying value does not.
+
+### Net
+
+Both untested items are now closed and both close negatively:
+
+* the sink-derived-length parser has **no sender** in any firmware we hold;
+* structured sink data reaches **less** code than constant fill, so there is no
+  hidden depth behind the byte-fill experiments already run.
+
+That exhausts the display-sink angle at this rig's reach. The capability
+(`harness/display_sink_e2e.py`) remains valuable as the only way to execute ASD's
+display paths at all, but the surface it opens is polling and control flow, with
+the one length-bearing parser unreachable.