Finally, the casket is opened: we (+@h0t_max and @_Dmit) have extracted Intel x86 microcode! One more Intel "top secret" information gets revealed...
https://t.co/gFYcILxnHL
@marcrygamerbr In C-states CPU doesn't execute anything, in C6 it's even power gated, but C6SRAM is accessible via LDAT. Usb2dbc can debug all IPs until DCI isn't turned off (Sx/S0ix)
Next are the most interesting:
EAR - CPU bringup stall in PCU fw
PHYSICAL_DEBUG_ENABLED - sets CONSET in DFX AGG
CFG_UNLOCK - activates NOA (Node Observation Architecture) bus in DFX Green
SAFE_MODE_BOOT - disables active state power management
@mayorhardin Until recently, all such NDA-ed info was a real secret, but now AI collects everything (open source code, LinkedIn, doc storages), all where sometimes private info leaks
What a huge field to research: rdmsr microcode for desktop CPUs speculates that CREGPLA (data struct describing each MSR, hardcoded in HW and obtained via MSR2CR uop) entry is valid!
Below is a fragment of CNL microcode simulation via Archsim tool for rdmsr instruction:
Ha-ha, Intel implemented a super protection😀 in the new CPUs (TGL+): pcode/ucode throws #MC (Machine Check) exception if DAM (Delayed Authentication Mode) is enabled and UEFI/BIOS signals BIOS Reset Complete...
🔥 Read the new article by our researcher Timofey Duditsky.
The write-up dives into the AMD Platform Configuration Blobs mechanism, shows how it works, and reveals the vulnerability CVE-2025-54502.
https://t.co/DQHz8M5bRN
AMD has published Security Bulletin AMD-SB-7054 with my vulnerability CVE-2025-54502. There has been no feedback on my research (as well as my mention), so I will publish my work as it is and as soon as possible.
@Gyzome Yes, all standard JTAG IRs (SAMPLE, PRELOAD and others) are supported at CLTAP, BSDL also exists for each CPU/PCH/SOC but unfortunatelly it's not public
@AbeiV No, we use Intel DCI CCA/DbC with Intel System Studio. There's very limited number of information available in public on the subject. All necessary info is under NDA...
@GabrielKerneis There's also a difference in the keys generation: GWK is created by simply xor from HW and FW 16- byte constants, while for FEK the hardware shuffle of 48 bytes embedded in HW and 16 bytes from FW is used
@GabrielKerneis As you can see from the phyton code, GWK is used to encrypt Fuse Key 0 (hence the "wrapping" in the name), while FEK decrypts Security Fuses for CSME
Yes, Intel has declared this first SGX implementation as obsolete and unsupported, but its fundamental break means that the HW Root of Trust approach is not unshakable. The full white paper is coming...
This is made possible by executing arbitrary microcode on the DFX-locked system. And although this was a truly challenging task, we were able to do it after researching in details the interaction between PMC and PUNIT