# New-area exploration round (post ASD-0x308)

## ASD 0x308 fptr claim — WITHDRAWN (corrected)
Rigorous load-then-call scan of [0xd1f038,0xd2f038): ZERO called function pointers.
0xd25a3c/0xd26c94/0xd26ca8 are DATA counters/limits (installed as 1000/-1, compared
with CMP), not fptrs. ASD 0x308 is a confirmed UNAUTHENTICATED gate-bypass OOB but
DoS/data-corruption only, NOT RCE.

## ASD command surface — EXHAUSTED
All 49 dispatched ASD commands scanned: only 0x300/0x301/0x308 have non-const
copies; only 0x308 is the (re-derived-length) OOB. No second copy OOB.
sub_D0D134(0x102)/sub_D0D26C(0x103): validate ptr for 4B. sub_D15AF8(0x201): host
len capped <=0x920. All bounded.

## SYS_DRV PROG_REG (sub_E1B558) — bounded
Programs a FIXED register whitelist (0x4480/0x44B0/0x44E0) with host value gated by
(value>>28)&7 != 3. Register not host-selectable. Not arbitrary.

## Register syscalls SVC 0x7B/0x7C/0xA0 — 310 sites, bounded
Register addresses are constants (baked in SYS_DRV) or come from the signed
firmware / register-list. No host-controlled unbounded register address found.

## Register-list applier (ring cmd 4214 -> sub_E2005C -> sub_E20570/sub_E20108)
HOST-REACHABLE: cmd 4214 passes a host pointer (a1[2]); the PSP applies a
(register,value) list with PSP privilege and NO signature check in sub_E2005C.
BUT each register is gated by sub_E177FC((reg>>12)&0x3FF), an APERTURE WHITELIST
restricted to the GFX IP register apertures (table off_E17854, per-instance
ranges). So the host can only program GFX-block registers it ALREADY controls via
MMIO -> intended GPU-bringup path, not a privilege escalation. (Caveat: the
allowed-aperture table is runtime-populated; a runtime dump of off_E17854 would
confirm no non-GFX/PSP-protected aperture is whitelisted. Static intent = GFX.)

## Net
The reachable software attack surface (TA copies/indexed-writes/state, ASD 49
cmds, SYS_DRV copies + register programming + register-list, sOS RPC gate) is now
comprehensively audited. The headline confirmed bug remains the ASD 0x308 gate
fail-open (unauthenticated OOB, DoS). No new memory-corruption-to-RCE primitive.
Remaining frontiers (crypto-service internals; boot-chain signature/parse) need
different tooling (PSP RAM read / fault injection), not more host-side static+fuzz.

================================================================================
## Register-list whitelist — deep dive (answers: matches expectation? influenceable?)

WHITELIST TABLE = dword_E26270 (== off_E17854 == off_E13F44), in the SYS_DRV
image's .data. sub_E177FC checks (reg>>12)&0x3FF against per-GFX-instance fields.
  instance 0 allowed apertures: 186(0xBA), 368(0x170), 384(0x180), range 390-393.
  static init bytes: [1,3,4,5,6,7,8,9,11,15,16,18,34,35,36,37,40,41,45,46,49,70,
                      79,80,88,108,128,181,182,186,187,188,189,190,191,255,259,...]
=> a CURATED, restrictive per-instance list of GFX register segments (not "all GFX").

INFLUENCEABLE? NO (verified):
  * Scanned ALL of SYS_DRV for stores through =dword_E26270 -> ZERO writes.
    The table is read-only .data in the signed image; no code (let alone host
    data) ever writes it.
  * sub_E13C48 (reached from ring dispatcher via a1+14) selects WHICH fixed subset
    of these static apertures to apply, based on host mode v7=*a1 -- but the
    aperture VALUES are hardcoded constants / this static table, never host-supplied.
  * Changing the whitelist requires modifying signed SYS_DRV (blocked by
    signature/anti-rollback).

CONCLUSION: ring cmd 4214 register-list apply is confined to a fixed, curated set
of GFX register segments (host already controls these via MMIO); the whitelist is
NOT host-influenceable. Intended GPU-bringup mechanism, not an arbitrary-MMIO bug.
Caveat: values read from the file-based ELF; a runtime dump of 0xe26270 would
reconfirm, but the 0-writes result + sane static contents make static config certain.

================================================================================
## RCE target located: the ASD callback vtable @0xd42890 (DTM-reachable call)

DTM cmd 2 -> ASD 0x100 (sub_D1061C) does:
    v13 = *(fptr)(dword_D115E0 + 6152);   // dword_D115E0 = 0xd42890 -> slot 0xd44098
    if (v13) result = v13(v6);            // CALLS the vtable slot
More vtable calls in sub_D113A0: (0xd42890+6236)/(+6256)/(+6268)/(+6152) all
invoked on DTM/ASD-reachable paths. So the ASD callback vtable @0xd42890 is a
genuine, host-reachable indirect-call table = the ideal RCE target.

WHY IT'S STILL BLOCKED (precise gap):
  * Installed with FIXED per-ASIC handlers (0 direct stores; register-offset
    installer via ASD cmd 0x02 -> sub_D0D2AC). NOT host-controlled -> no
    install-a-callback RCE.
  * No write primitive reaches it. The only OOB write (ASD 0x308) writes forward
    from byte_D1F038 (0xd1f038) and stops at 0xd2f038 (its source read faults at
    the ASD stack top 0xd5b000, a1' max ~0x10000). The vtable at 0xd42890 is
    ~0x13858 (~78 KB) BEYOND that stop. Controlled content only reaches 0xd20438
    (first 5120 B); that region is the pointer-free receiver buffer.

## Net (deepest characterization)
RCE on ASD reduces to: a write primitive that reaches [0xd42890, ~0xd44100] with
a controlled value. None exists on the reachable surface -- the 0x308 OOB (the
only OOB write) falls ~78 KB short, and the vtable install is fixed-handler. This
is the exact ceiling: target identified (DTM->ASD vtable call), gap quantified.
Closing it needs either a longer-reach / different-base write primitive (not
found) or influencing the fixed vtable install (signature/asic-gated).