AMD PSP reverse engineering, emulator and vulnerability research https://git.sl0p.foo/amd-psp-re.git/atom/fw/pseudo/wspe_command_surface.c?h=main 2026-09-29T14:11:16Z 2026-09-29T14:11:16Z user user@clank 2026-09-29T14:11:16Z urn:sha1:730b1761473553e912a4349bf2e1e587dec29940 GCP had a decompiled command-surface artifact and the other eleven did not, though the command surface is what an analyst reads first. fw/ta_surface.py emits one per TA into fw/pseudo/<ta>_command_surface.c. Two corrections were needed for these to be honest rather than merely present. First, prefer the address-keyed map: cmdmaps record handlers by name, captured before the renames, and the first run used the name map for GCP as well, resolving only 4 of its 17 handlers and silently replacing a good artifact with a worse one. The tool now prefers <ta>_ea.json where it exists. Second, separate function entries from labels inside functions: rap's cmd 1 points into start, two of auc's land inside another handler, and five of OPM's nine dispatch into the middle of larger functions, so printing the containing function as the handler would assert that start is rap's cmd 1 handler. Exact entries and internal labels are now separate sections, with the containing function reproduced in full under a warning that the command's code begins at the stated offset. IDA refuses to split those internal entries out, and undefining the owning function to force a split was not worth the risk so soon after repairing a corrupt database. OPM cmd 8 at 0x401320 is reported as entering opm_asd301_path+0x60 rather than asserted as a separate function, despite earlier notes calling it a merged handler. 62 exact handlers across the twelve, all decompiling, plus 9 internal-label entries each shipped with its containing code. TMZ has no command map, which is correct for a stub that answers every command id identically.