AMD PSP reverse engineering, emulator and vulnerability research https://git.sl0p.foo/amd-psp-re.git/atom/data/rollback?h=main 2026-09-30T02:29:57Z 2026-09-30T02:29:57Z user user@clank 2026-09-30T02:29:57Z urn:sha1:908b91bce521bba192d509bb8897c4b627bcde5e Two results now sit side by side: a mechanically verified count underflow that is not reachable in the shipping build because its front half needs a larger payload than any application delivers, and the absence of version enforcement, which lets an attacker choose which build runs. Unreachability is a property of one build's gates, so the question becomes precise: in either older build, is the front half open? If it is, rollback plus the existing defect is an exercisable primitive rather than a documented but unreachable one. Both older bodies are plaintext by entropy so they are directly analyzable, and both are committed with hashes in the manifest. It is recorded as a lead rather than a result, with caveats stated: the defect shape exists in every build so the back half is only presumably open and must be confirmed per image, a string diff shows no added error messages so there is no cheap signal that a bounds fix landed in the window, and each detector must rediscover a known defect in that specific image before any negative from it is trusted.