1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
# ASD `.163` `0x1AA`: global ID update can retire another channel's allocation
**Status:** conditional authority/error-order candidate. Signed code and
connected synthetic allocation/sweep evidence; no live second client,
accepted signed SRM, natural `0x1AA` producer, ASIC effect, or hardware
restoration oracle. **Do not** invoke this stateful opcode on the card
merely to see a return value.
The service-2 dispatcher routes `0x1AA` to `sub_D0B550(input160,count)`.
Its checked caller pointer and `global_count+count<=32` gate do **not**
include a channel/TA owner. On status success it invokes
`sub_D08404`, which scans all IDs in the ASD-global `+3284` list against
all occupied entries of the HDCP2/`0x1A7` global allocation table. For a
matching ID whose selected channel `+88` state is nonzero, the signed
sweep can zero that state, call the stateful `sub_D0AEB0(channel)` link
teardown, and clear the global bitmap/count. It does not compare an
originating TA identity to the stored channel annotation. `sub_D08404`
also **does not check `sub_D0AEB0`'s return** before clearing the
allocation bit/count: a failed link/ASIC teardown can leave bookkeeping
claiming the entry is gone. That is an emulator-supported signed-code
error-order discrepancy, not a measured hardware desynchronization.
`python3 psp_emu/harness/probe_asd163_1aa_alloc_cleanup.py` passes with
signed dispatcher `0x1A7` allocating synthetic channel 6 / ID `FGHIJ`
under a synthetic caller scalar 2; signed `0x1AA` updates use scalar 7.
When the input includes `FGHIJ`, the signed `sub_D08404` loop visits
`sub_D0AEB0` and clears bitmap/count `1/1 → 0/0` despite the **only
intercepted helper** returning modeled failure 9. A duplicate-first
`ABCDE,FGHIJ` input triggers the separate `0x1AA` dedup bug: `FGHIJ` is
dropped, so the sweep does not visit teardown and bitmap/count remain
`1/1`. The caller scalars are synthetic register inputs, **not verified
sOS caller identities**; the channel, ID and state word are synthetic.
The distinction establishes signed handler ordering and selected global
bookkeeping, not a real cross-process fault or authentication bypass.
`0x1AA` is the only direct signed-image caller of `sub_D0B550` found in
IDA; a scoped signed-ELF scan found no direct external opcode immediate
or aligned executable literal. Computed/indirect callers and other
images remain open. GCP's service-2 reach was demonstrated with other
opcodes, not a hardware `0x1AA` invocation. The integrity/security
meaning of an allocation bit after a failed real callback, actual ASIC
register effects and an exact restoration oracle must be established
before assigning practical impact. The duplicate-drop/ID-admission
defects are documented separately in
`fw/CANDIDATE-ASD-163-1AA-DUPLICATE-DROPS-TAIL.md`.
|
