AMD PSP reverse engineering, emulator and vulnerability research https://git.sl0p.foo/amd-psp-re.git/atom/bridge/build/handler_bytes.bin?h=main 2026-10-07T17:45:14Z 2026-10-07T17:45:14Z user user@clank 2026-10-07T17:45:14Z urn:sha1:89b342ab8dd6e8ed16b952836f8f607772a00e6f Add.6 proved the saved-LR overwrite on silicon but never evaluated its own aside that P=Q-3 yields PC = LR & ~0xFF with bit0 cleared, i.e. an ARM-state entry in the same 256-byte block. Evaluated it. 0x405000 ARM-decodes to ldmdaeq r8,{...,sp,...,pc} -- pc=*(r8), sp=*(r8-8), idx-0, executing under the measured flags, the only aligned entry in the build that loads both pc and sp off a non-stack base. It matters because Add.132/133/134 closed the ldm class only for bases {r4=ctx, r0/r5/sp} on the ctx+0x4f carve floor; r8 was never swept, being 0 on the UNLOAD path, and an r8 base sources from the host command buffer, which is below no floor. The route does not close the gap, for a reason worth recording. A later PUSH rewrites the word, so the write and the corrupted return must share a call chain. The FE09 zero-store's live frames yield only blocks 0x404000 and 0x402a00, neither a pivot. The CodecToken stamp cannot help either, and not for the frame-destruction reason the report gave: 0x404828 calls 0x404fe8 at 0x404962 and the stamp fn 0x404b5c at 0x404988, so the frame holding the 0x4050xx call sites is a sibling and already dead. The UNLOAD shortcut is separately closed -- no function on that path pushes or pops r8. Qualified the report's 'nothing reads the memory we fully control' to the states we can reach, and promoted re-entrancy to lead 0. Tooling note recorded: the first call-graph pass used recursive descent, silently missed the 0x404962 -> 0x404fe8 edge and returned a false EMPTY; rebuilt on a global over-approximating scan validated against the direct disassembly.