LEAD: use the anti-rollback gap to make the confirmed count-underflow reachable

Status: CLOSED NEGATIVE on its central hypothesis. The rollback does not make the count-underflow reachable. Retained because the reasoning and artifacts are reusable, and because the rollback finding itself stands independently.

Why this lead exists

Two separate results now sit next to each other:

1. A confirmed corruption defect that is not reachable. sub_E04B68 (and clone sub_E04DFC) read a count from buf+0x88 unvalidated, use it unclamped for memcpy(glob+0x6c0, buf+8, count), then compute 0x400 - count unsigned for a second copy. Verified 14/14 mechanically and reproduced in emulation through the real dispatcher. Not host-reachable in 49.0.54: planting the count needs 0x8c bytes into the 0x33 descriptor helper (sub_E1EA54 -> sub_E18EAC, sole writer of channel+0x70), and no corpus TA delivers that much - OC 0x30 is a firmware global, AUC/OPM/FP give 0x10, GCP is auth-gated, MERIT gated. (fw/CANDIDATE-SYSDRV-E04B68-COUNT-UNDERFLOW.md)

2. No anti-rollback. An older AMD-signed SYS_DRV boots and services requests on a part shipping 49.0.54 - 49.0.37 and 49.0.47 both verified from a cold power cycle. (fw/FINDING-PSP-SYSDRV-NO-ANTIROLLBACK.md)

The defect's unreachability is a property of one specific build's gates, and rollback lets the attacker choose the build. So the question is precise:

In 49.0.37 or 49.0.47, does any path deliver >= 0x8c caller-controlled bytes into the payload helper that writes the slot staging buffer - is the front half open in an older build?

If yes, rollback plus the existing defect is an exercisable memory-corruption primitive: choose the old build, open the front half, plant the count, trigger the unclamped copy.

Closed: the required payload does not shrink in an older build

First, a correction to this lead's own logic. The 0x8c requirement is TA-side - how many caller-controlled bytes a TA pushes into the payload helper - and TA choice is already free, since 63 corpus TA builds load on this part and the front-half survey covered all of them. So rolling back SYS_DRV only helps if the older build needs a smaller payload, i.e. reads the count at a lower offset.

It does not. Scanning both older images for every LDR.W rD,[rN,#imm12], grouped by immediate:

Those sites cluster at file offsets 0x49e8, 0x4a10 and 0x4c7a-0x4cd8 (v37; v47 identical shifted +0xc). At the established load base 0xE00100, the two defective functions in the current build sit at file offsets 0x4A68 (sub_E04B68) and 0x4CFC (sub_E04DFC) - the same two clusters. The count is read at +0x88 in the older builds too, so the payload needed is still 0x8c and the front-half blocker is unchanged.

Caveat on strength: the offset-to-function mapping is inferential (base arithmetic plus cluster position), not a confirmed symbolisation of the older images. The conclusion therefore rests on the weaker, safer claim that +0x88 count reads are still present in the same region of both older builds, so there is no evidence the requirement shrank - and a lead needs positive evidence to stay open.

What would still be needed (if resumed)

• Load data/rollback/sysdrv_v37.bin and sysdrv_v47.bin, taking the load base from the segment table, never from a printed address (the 0x100 trap; current build is 0xE00100).
• Re-run the validated detectors (fw/ta_copylen_slice.py, fw/ta_bufferfield_audit.py, fw/ta_bufferfield_xfn.py) and confirm each rediscovers a known defect in that image before trusting any negative from it.
• Locate the older equivalents of sub_E087E4 (request entry), sub_E1DC30 (53-opcode family), sub_E1EA54/sub_E18EAC (the 0x33 payload helper) and compare the length gate.
• Also check whether sub_E04B68's count read is already clamped in an older build, which would invert the picture.

Both images are plaintext - entropy 6.74 / 6.77 over the body versus ~8.0 for encrypted - so they are directly analyzable.

Honest caveats

• The defect shape was found in all 31 SYS_DRV builds, so the back half is presumably open in the older ones - but that must be confirmed per image, not assumed.
• A v37/v47 string diff shows no added error messages, so there is no cheap signal that a bounds fix landed in that window; this needs real code comparison.
• Rollback changes which SYS_DRV runs. The front-half blocker is partly about what TAs send, and TAs load separately - so the thing to look for is an older SYS_DRV with a laxer gate, not an older TA.

Artifacts

data/rollback/sysdrv_v37.bin (0x310025, 157,584 B, sha 8ff372e135a0342b8d3b...) and data/rollback/sysdrv_v47.bin (0x31002f, 157,584 B, sha 1ec6756ce3e37cea207b...), both hashed into data/MANIFEST.sha256, extracted from public linux-firmware psp_13_0_0_sos.bin by hw/rollback_inspect.py.