AMD PSP reverse engineering, emulator and vulnerability research https://git.sl0p.foo/amd-psp-re.git/atom/psp_out/f32_probe.py?h=main 2026-09-28T13:47:46Z 2026-09-28T13:47:46Z user user@clank 2026-09-28T13:47:46Z urn:sha1:576510347cdbe3eb6f3ed681a464edff00becb2d Answers "what can be loaded on this card, and which of it have we examined?" The component list is enumerated from the live stack (adev.fw.descs, adev.fw.sos_fw, the gfx11 RLC-autoload set, on-demand DMUB/TA/VCN) rather than from memory, and then measured: submitting a zero blob under every GFX_FW_TYPE_* separates "unsupported on this ASIC" (0xffff0006, 49 types) from "supported, our garbage failed authentication" (0xffff0008, 37 types). Nothing in the supported set is an unexamined image. The TA question closes as a negative: psp_13_0_0_ta.bin holds exactly four TAs, all already audited, so no SECUREDISPLAY/RAP/XGMI TA exists for this ASIC. HAZARD: that sweep wedged the PSP -- the sOS ring stopped responding and the SMU timed out, needing a cold ATX cycle. SMU/PPTABLE are the suspected trigger. Recorded in CONSTRAINTS.md so it is not repeated; the result is already banked. Also corrects the inventory's ISA map (IMU is Xtensa, MES/PFP/ME are RV64) and notes that every PSP-loaded payload carries a nested $PS1 header, so code starts at file 0x200 -- the generalisation of the DMCUB base error.