psp_emu — Unicorn-based emulator for AMD PSP trusted applications

Emulates the PSP TAs (HDCP, ASD, DTM, SYS_DRV) and the RPC edges between them, so handler behaviour can be measured directly instead of inferred from a hardware crash oracle that costs a PCIe retrain per data point.

Setup

python3 -m venv psp_emu/.venv
psp_emu/.venv/bin/pip install -r psp_emu/requirements.txt
psp_emu/.venv/bin/python psp_emu/tests/test_smoke.py        # must be all PASS
psp_emu/.venv/bin/python psp_emu/harness/hdcp_subcmd12.py

Images are read from ../psp_out/ (elf/*.elf, falling back to *_full.bin).

Runtimes and the knobs that control them

gcp_fe08_fullsys.py supplies the Navi 31 ASIC ID (0x31) at the sOS boot-input byte 0x80D0, which the earlier boot stage would set on hardware. Without it ASD rejects startup with status 7. Ring.submit() returns a dispatch-probe hit count, not a firmware status; loaders must read Ring.response() and check service-table registration before interpreting later RPC results.

The current FE08 probe stops at ASD's device-key unwrap (rpc_201 returns 1, FE08 returns 0x263), before its zero ciphertext is processed. That is a separate device-key unwrap failure; its cause remains unproven.

These used to take minutes each, almost entirely spent running a system that had already finished the work being measured. See "Harness runtime" in FIDELITY-NOTES.md for the measurements and the one real fidelity tradeoff.

fuzz_ta_invoke.py deliberately exits non-zero. Its controls pass, but its randomised invokes cover no blocks beyond the benign control, so its "0 faults" is not evidence of absence. It now refuses to report that, the same way it already refused when its positive control failed.

The reason is now understood: hdcp_invoke_entry ignores the GP commandID in R1 entirely and requires paramTypes & 0xF == 7 plus a memref with size > 0x2817, taking its command selector from the first DWORD of the shared buffer. The host path supplies paramTypes = 0x100, so the first check fails and every invoke returns error 6 after 22 blocks. Satisfying the ABI at the entry point unlocks 73 new blocks across commands 1..0x13.

The only code that can produce the required memref parameter (tee_unmarshal_params) was then measured to execute zero instructions across boot, a mailbox sweep, every ring command id 0x00..0x0F and a TA load — with tee_cmd_dispatch firing in the same run as a positive control. So in this configuration the HDCP command surface is not host-reachable, and this harness is correctly blocked rather than broken: removing the gate would just restore the old vacuous "0 faults". Full decode, jump table, per-command measurements and the scope limits of that claim are in psp_out/FINDING-HOST-MAILBOX-AND-RING-IN-EMULATOR.md.

Escape hatches, for when you suspect the fast path is hiding something:

The one thing to know before trusting a number: TIMER_PERIOD sets how many basic blocks make up one emulated millisecond (now 200, was 2000). Lowering it makes firmware delay loops finish in less host time, but it also makes the emulated CPU slower relative to guest time, so firmware timeouts become more likely to fire. Results were identical at 2000/500/200/100 here, but if a finding ever depends on timing, pin TIMER_PERIOD=2000 and say so in the write-up.

Layout

pspemu/
  consts.py     firmware addresses, SVC numbers, RPC ABI, session offsets
  memmap.py     per-component memory layouts (HDCP/DTM/ASD/SYS_DRV)
  loader.py     ELF / raw image loading
  isa.py        ARM vs Thumb detection (call-site voting)
  component.py  Component: Unicorn instance + AAPCS run_function() + faults
  svc.py        SVC decode/dispatch
  services.py   emulated crypto service + ASD RPC (configurable, incl. bugs)
  bus.py        inter-component routing (HDCP -> ASD across address spaces)
  trace.py      WriteTracer, ContentDiff, Watchpoint, CallTracer
harness/
  hdcp_subcmd12.py   rx_ids + v58 stack overflow measurement

Each TA gets its own Unicorn instance — HDCP and DTM are both based at 0x400100 on real hardware and cannot share an address space.

Three caveats that will bite you

1. IDA's T segment register is wrong on these images. HDCP ta_memcpy @0x401058 is marked T=1 (Thumb) but the bytes e3520003 9a000017 e210c003 0a000008 are an ARM memcpy prologue (CMP R2,#3 / BLS / ANDS R12,R0,#3 / BEQ); IDA's own listing there degenerates into DCD. The TAs are mixed ARM/Thumb: handlers are Thumb, several libc leaf routines are ARM, reached by BLX (state-toggling) rather than BL. isa.build_mode_map() votes over every call site instead: ta_memcpy gets 62 ARM votes / 0 Thumb, ta_memclr 91 Thumb / 0 ARM.

2. UC_HOOK_MEM_WRITE corrupts Thumb ITSTATE. Conditional stores that should be skipped execute while a write hook is installed. Measured on ta_memclr(0x4ff980, 0x20):

The optimised memcpy/memset routines are full of IT blocks, so hook-derived extents are not trustworthy. Use trace.ContentDiff (sentinel-fill, run hook-free, diff) for any load-bearing measurement. WriteTracer is still useful for attribution//exploration, not for numbers.

3. The image blobs end with a 256-byte RSA signature that overlaps BSS. *_code.bin is [verified body ($PS1.size)][0x100 signature], and the TA header field +0x1C is the BSS base -- which lands exactly on that tail (ASD BSS 0xD33000 vs image end 0xD33100; HDCP 0x407000 vs 0x407100). Loading verbatim maps high-entropy signature bytes where zeroed BSS belongs, and they masquerade as initialised data -- one of them passed a CBZ null guard in ASD sub_D02794 and became a BLX target. Component._zero_signature_tail() zeroes it after load.

4. ta_memcpy jumps out of its own function bounds (0x401058 → 0x401702), so filtering writes by "PC within [func, func+size)" silently misses most of the copy.

Validated against hardware

• __stack_chk_guard lives at 0x404334. The image holds 0x33333333, but that is only a build-time placeholder: on hardware the runtime guard differs (at N=56 the copy fills the canary with 0x33333333; the emulator returns cleanly, the device faults). Treat the emulated guard as a stand-in, and do not assume a 0x33 payload preserves the canary on real hardware.
• A smashed canary reproduces the exact hardware crash-oracle signature: pc=0x40433c reading 0xdeadbeef (__stack_chk_fail's deliberate trap).
• Fault attribution works: LR=0x40410f identifies hdcp_verify_mac's canary check rather than subcmd12's.

Result: subcmd12 stack overflow (harness/hdcp_subcmd12.py)

Frame: PUSH {R4-R11,LR}; SUB SP,#0x214, v58 at SP+0x100 → canary at v58+272, saved LR at v58+308.

RETRACTED: the "return-address control" result below no longer holds, and the reason is that the emulator got more faithful.

The table originally read:

   N    5N   v58 reach      canary     savedLR  PC-ctl   out     <-- SUPERSEDED
  62   310        +319 0x33333333  0x3e003333    True  FETCH at 0x3e003332
  70   350        +359 0x33333333  0x33333333    True  FETCH at 0x33333332
 103   515        +524 0x33333333  0x33333333    True  FETCH at 0x33333332

and concluded that a 0x33 payload preserves the canary (payload == guard), so for N >= 62 the saved LR is overwritten and the CPU fetches from 0x33333332. That depended entirely on __stack_chk_guard holding the image's build-time placeholder 0x33333333.

It no longer does. The per-load stack canary is now modelled (SVC 0xA2 TRNG + loader write, see FIDELITY-NOTES), so the guard is a real value — measured 0x31cca5e4, stable across loads because the TRNG model is deterministic. A 0x33 payload therefore smashes the canary instead of preserving it, and __stack_chk_fail traps before the corrupted LR is ever used. Current measured output:

   N    5N   v58 reach      canary     savedLR  PC-ctl   out  fault
  40   200        +312 0x31cca5e4  0x00ff0001   False   106
  52   260        +312 0x31cca5e4  0x00ff0001   False   106
  54   270        +312 0x00000000  0x00ff0001   False  None  READ_UNMAPPED at 0xdeadbeef
  56   280        +312 0x33333333  0x00ff0001   False  None  READ_UNMAPPED at 0xdeadbeef
  62   310        +319 0x33333333  0x3e003333   False  None  READ_UNMAPPED at 0xdeadbeef
  70   350        +359 0x33333333  0x33333333   False  None  READ_UNMAPPED at 0xdeadbeef
 103   515        +524 0x33333333  0x33333333   False  None  READ_UNMAPPED at 0xdeadbeef

What survives, and what does not:

• The overflow is real and the reach numbers are unchanged. v58 reach, canary at v58+272 and saved LR at v58+308 all still measure exactly as before; at N >= 62 the saved LR still takes attacker bytes (0x3e003333). The ARM memcpy stores whole words, so the canary is corrupted at N=54 (270 bytes), slightly below the naive 272.
• PC control does not survive. The canary check now fires first, every time, producing pc=0x40433c reading 0xdeadbeef — the exact hardware crash-oracle signature. PC-ctl is False at every N.

This is the emulator converging on hardware, not regressing: the caveat two sections above already said "do not assume a 0x33 payload preserves the canary on real hardware", and the hardware oracle always faulted where the emulator returned cleanly. Those now agree. The earlier unconditional PC-control claim was an artefact of the placeholder guard and should not be cited.

The conditional form of the claim is still exactly true, and was re-verified by forcing the guard back to the placeholder and changing nothing else:

guard = real per-load value (0x31cca5e4)      guard forced to 0x33333333
  N=62  savedLR=0x3e003333  PC-ctl=False        N=62  PC-ctl=True  FETCH at 0x3e003332
  N=70  savedLR=0x33333333  PC-ctl=False        N=70  PC-ctl=True  FETCH at 0x33333332
  N=103 savedLR=0x33333333  PC-ctl=False        N=103 PC-ctl=True  FETCH at 0x33333332

So the guard value is the sole blocker, which is what psp_out/SUBCMD12-RESOLVED.md and psp_out/FINDINGS-SUMMARY.md already say ("with a matching guard, N>=63 yields full PC control", "blocked solely by the runtime stack guard value"). Those two documents were written conditionally and remain accurate as-is; only this README overstated it.

The hardware divergence is now explained (harness/hdcp_cmd0f.py). hdcp_cmd0F_handler has a latch at 0x402234: ldr r1,[r2,#0x18] (sess->err_state) / cmp r1,#7 / return with all response sub-status fields left at 100. subcmd12 sets err_state=7 on every failure path (109/107/108/106), so the first failing subcommand bricks the session for cmd 0x0F:

A) fresh session, N=40      -> subs=[106,..] err_state=7 rx_count=40  (ran)
B) same session, N=90       -> subs=[100,..] err_state=7 rx_count=40  (NOT called)
C) err_state=7 preset       -> subs=[100,..]              rx_count=0
D) FRESH slot, N=90 one-shot-> rx_count=90, PC=0x33333332 (LR hijack)

Earlier hardware runs "primed" a slot first, which latched it — so every later measurement observed a handler that never executed. Correct methodology is one observation per freshly opened slot. Still: the emulated hijack in (D) uses stubbed crypto; on hardware the real MAC fails and the uninitialised-context overrun smashes hdcp_verify_mac's canary first, so this is not yet a hardware result.

What is still stubbed (fidelity gaps)

Priority to close the gap: ~~(1) wire Bus so ASD RPCs execute in the real ASD dispatcher~~ done (harness/asd_rpc.py, 5/5 thunks routed and executing), (2) model the crypto service's real failure semantics, ~~(3) run TA init instead of patching globals~~ done (TA_CreateEntryPoint executed, dword_40237C no longer patched, sessions opened by real cmd 0x0E).

SYS_DRV does have init, and harness/fuzz_sysdrv.py was not running it -- it called a sub-initialiser that left the gate shut, so every iteration bounced off sub_E087E4 after 4 basic blocks while reporting a clean 5000/5000. It now runs the real init (sysdrv_env.run_init, opcode 0x1000) and raises if the gate is still closed. See "Independently rediscovered" in psp_out/FINDING-FEATURE-MASK-GET-UNBOUNDED-INDEX.md.

ASD has no init phase to run: its entry trampoline at 0xD19868 is mov r0,r2 / blx *(0xD19884) / svc 0x75, and *(0xD19884) == 0xD013B9 is the dispatcher itself. So (3) has no ASD counterpart. Two ASD code patches were examined while checking that: asd_feature_enabled is no longer patched (measured redundant -- it already returns 1 for ids 0..0x1F unpatched), and ~~asd_validate_ptr is still stubbed~~ also fixed: it is a genuine range check accepting only 0x400000..0x600000 (the caller's window sOS maps in for the RPC). fuzz_asd.py now allocates its argument buffers inside that window so the REAL check gates them, and asserts at startup that the validator both accepts those buffers and still rejects ASD scratch -- a stub that accepts everything would pass the first half alone. Effect: scalar-deref noise 533 -> 82 over 5000 iterations, at a measured cost of 53 distinct blocks (-4.4%) that were only reachable via pointers the real ASD refuses.

Extending

• New service: implement __call__(self, comp, req_ptr) and register it in Component.set_rpc_services({id: svc}).
• Cross-TA calls: build a Bus, add components, pass AsdRpcService(bus=bus) so HDCP RPCs execute inside the real ASD dispatcher.
• New harness: copy harness/hdcp_subcmd12.py; use ContentDiff for numbers.