Write primitive — HDCP subcmd12 branch-B OOB write [SEE STATUS BANNER]

Not the authoritative document for this topic. See SUBCMD12-RESOLVED.md, and INDEX.md §3 for why. Kept for its detail and history.

STATUS BANNER — accuracy correction

The original title said "FOUND & hardware-verified". That overstates the hardware evidence. Accurate status: * The 11-byte OOB write past sess->rx_ids is real and proven by static analysis + emulator (exact extent 5*rx_count+9, boundary N=101). [ST+EMU] * The trigger path (DTM topology -> HDCP cmd 0x0E state bypass -> cmd 0x0F subcmd 12) is hardware-confirmed. [HW] * But the write itself has NO hardware-observable effect: the corrupted bytes land in session security fields whose only observable consequence is masked by the err_state latch. It was never independently read back on hardware. * Escalation is canary-gated: the stack-overflow variant (N>=53) hits __stack_chk_guard, which is HW-confirmed randomised by the loader (decisive test: N=56 with 0x33 fill landing exactly on the canary still crashes at PC 0x40433c / FAR 0xdeadbeef). No guard leak exists in the host-reachable TA surface, so this is DoS-grade, not RCE.

The write primitive: HDCP subcmd12 branch-B controlled OOB write

Trigger (no display, hang-free): DTM cmd 2 topology + HDCP cmd 0x0E session-state bypass -> HDCP cmd 0x0F subcommand 12 (branch B: topology_type==6, mode!=20, seq!=0).

Handler hdcp_subcmd12_rxinfo (sub_402A88): ta_memcpy(sess->rx_ids, msg+25, 5*msg[2]); // rx_ids is 504 B at sess+0x55 msg[2] is a full byte; the subcommand-descriptor maxlen (0x220) caps it so the copy is up to 515 B => up to 11 bytes PAST rx_ids, with ATTACKER-CONTROLLED content (from the message at msg+25). The bytes past rx_ids land on session security state: flag_24d @ +0x24D, seq_num @ +0x254 (HDCP2 replay counter), hash @ +0x258. Then the seq check early-returns BEFORE hdcp_verify_mac => NO hang.

Hardware evidence (current run, exploit_branchB_oob.py)

N=52   copy=260  OOB=0   -> sub=108   (in-buffer)
N=101  copy=505  OOB=1   -> sub=100   (behavior flips at the EXACT rx_ids boundary)
N=102  copy=510  OOB=6   -> sub=100
N=103  copy=515  OOB=11  -> sub=100

Persistence / content-control proof: fresh slot: subcmd12 N=52 -> sub=108 OOB write flag_24d = 0xAA (N=102) -> sub=100 follow-up independent subcmd12 N=52 -> sub=100 (was 108) => CORRUPTION OBSERVED All 0.006 s, sOS alive.

This proves: (1) a WRITE occurs past the buffer (behavior changes exactly at the 504-byte boundary N=101); (2) the CONTENT is attacker-chosen (a chosen byte 0xAA written to flag_24d); (3) the write PERSISTS in session memory and alters a later independent operation. => a confirmed, controlled, out-of-bounds WRITE primitive.

Scope: 11 bytes OOB, into pointer-free HDCP session fields (no code pointers in range), so it is a memory-write primitive over session security state, not (by itself) a control-flow/RCE primitive.

Note on ASD 0x308 (previously mis-characterised as a write)

Re-tested rigorously: the ASD 0x308 fault is a SOURCE OVER-READ (DFSR 0x37, WnR=0) inside the gate crypto (sub_D13750->sub_D12DEC->sub_D01C0C), driven by the attacker length a1'. The intended OOB WRITE branch (sub_D010E0(byte_D1F038, v20, a1'); 0xd20438=a1') NEVER fires: swept a2' in {2,0x100,0x8000,0xFFFF} with a1' =0x200 and 0xd20438 stayed 0x30 (write-branch-fired=False) -- the gate does not cleanly fail-open (returns error for small a1', faults for large a1'). So ASD 0x308 is a READ OOB, not a write. The confirmed WRITE primitive is branch-B above.