Other x86 CPUs
Links to various x86 microcode-related projects, with exception to Intel Atom unrelated to P6 microarchitecture.
- github.com/chip-red-pill/uCodeDisasm↗
- github.com/chip-red-pill/glm-ucode↗
- pietroborrello.com/.../offensivecon_ucode.pdf↗
- github.com/pietroborrello/ghidra-atom-microcode↗
- github.com/pietroborrello/CustomProcessingUnit↗
- github.com/chip-red-pill/crbus_scripts↗
- github.com/chip-red-pill/udbgInstr↗
- github.com/712ccca9-0294-4352-b994-457977fd46b8↗
- www.righto.com/2023/07/undocumented-8086-instructions.html↗
- www.righto.com/2022/11/how-8086-processors-microcode-engine.html↗
- www.reenigne.org/blog/8086-microcode-disassembled/↗
- patents.google.com/patent/US4363091A/en↗
- en.wikipedia.org/wiki/NEC_V20↗
- www.ceibo.com/eng/datasheets/NEC-V20-V30-Users-Manual.pdf↗
- thechipletter.substack.com/p/intel-vs-nec-the-case-of-the-v20s↗
- gist.github.com/dbalsom/fd4dea23c35c509416f007de06d5e71e↗
- forum.vcfed.org/index.php?threads/the-nec-v20-microcode-rom.1254770/↗
The VIA C3 processor has a unique instruction called ALTINST[9] (encoded as 0F 3F), which serves as an entry point to an undocumented alternate instruction set. To enable the alternate instruction set, the ALTINST bit must first be set to 1 in the Feature Control Register (FCR) via WRMSR. Once enabled, executing 0F 3F performs a near branch to CS:EAX while simultaneously switching the processor into an internal mode,
interpreting subsequent instructions as the microcode and bypassing standard privilege checks. Alternate instructions is encoded within an LEA [EAX+EAX+disp32] opcode sequence (0x8D8400XXXXXXXX), where the 32-bit displacement field (XXXXXXXX) contains the actual micro-operation. If disabled (ALTINST=0), executing the 0F 3F opcode triggers an Invalid Instruction (#UD) exception.
- datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf↗
- en.wikipedia.org/wiki/Alternate_Instruction_Set↗
- www.bitsavers.org/components/viaTechnologies/C3-ais-appnote.pdf↗
- Christopher Domas. Hardware backdoors in x86 CPUs. Black Hat, 2018.
- Apparatus and method for limiting access to model specific registers in a microprocessor, December 25 2012. US Patent 8,341,419.
- Microprocessor that performs X86 ISA and arm ISA machine language program instructions by hardware translation into microinstructions executed by common execution pipeline, November 4 2014. US Patent 8,880,851.
- phrack.org/issues/72/17_md#article↗
Via C3 CPUIDs 670 (C5B), 671 (C5B), 672 (C5B), 673 (C5B)
VIA processors that natively support microcode patching and updates include all CPUs based on the VIA Isaiah architecture, such as the VIA Nano, VIA Nano X2, QuadCore VIA Nano, and VIA Eden X4. Some patches are available from github.com/platomav/CPUMicrocodes/tree/master/VIA↗
AMD K6
AMD's sixth-generation AMD-K6® processor is a high-performance CISC-on-RISC microprocessor based on NexGen advanced, six-issue RISC86® superscalar 32bit architecture. Microcode patches/updates are not possible on this CPU.
- en.wikipedia.org/wiki/AMD_K6↗
- US6336178 patentimages.storage.googleapis.com/a7/ab/95/8caa77bc3c8efd/US6336178.pdf↗
- Patent WO1997013195A1 Instruction decoder including emulation using indirect specifiers
- sci-hub.box/10.1109/ISSCC.1997.585321↗
- www.halfhill.com/byte/1996-1_amd-k6.html↗
- Bruce Shriver, Bennett Smith: The Anatomy of a High-Performance Microprocessor: A Systems Perspective
- www.ardent-tool.com/CPU/Docs_AMD.html↗
- martin.hinner.info/amdmicrocode/↗ ;)
- argp.github.io/public/133f02627cbd3771ad5d4b09729cfce7.pdf↗
- www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/koppe↗
- fiona.dmcs.pl/ak/2014_paper_microcode.pdf↗ (incl. K7)
- www.realworldtech.com/forum/?threadid=35566&curpostid=35566↗
If you know anything about AMD internal structure, please contact me.
Hello world for CPUID 00060FB2
CPU AMD K8 / Athlon 64 X2 / Brisbane BH-G2 (AM2)
The patch is not exactly perfect as endianity and register order should be adjusted. Maybe next time.
File : test-patches/test60FB2-cpuid0-helloworld.bin (512 bytes) === fmt AMD K8/K10 variant standard Header (64 bytes) === date : 0x09292006 (8198-09-41) patch_revision_id : 0xBADA55E5 patch_info : block=0x8000 nTriads=0x10 init=0x00 checksum : 0x5F09EE43 nb_dev_id : 0x00000000 sb_dev_id : 0x00000000 cpuid : val 0x000006B2 real 0x00060FB2; family 0xF (AMD K8) model 0x6B name Athlon 64 X2 / Brisbane BH-G2 (AM2) nb_rev : 0x00 sb_rev : 0x00 bios_api : 0x00 magic : 0xAAAAAA --- Match Registers --- match[0] : 0x000006AC -> ROM triad 0x6AC (-> RAM Triad 0) match[1] : 0xFFFFFFFF (unused) match[2] : 0xFFFFFFFF (unused) match[3] : 0xFFFFFFFF (unused) match[4] : 0xFFFFFFFF (unused) match[5] : 0xFFFFFFFF (unused) match[6] : 0xFFFFFFFF (unused) match[7] : 0xFFFFFFFF (unused) checksum K8/K10 : computed=0x5F09EE43 stored=0x5F09EE43 PASS === K8/K10 Triads (16 total, 28 raw bytes each) === 0: 1800C00080004865 | 1804C00080006C6C | 0500C00080000010 | FFFC2000 | mov ebx, 0x4865| mov t12d, 0x6C6C| sll ebx, 0x10| .sw_next 0 1: 0040C00080802600 | 1800400080006F20 | 1804C0008000776F | 0FFC2000 | or ebx, t12d| mov ecx, 0x6F20| mov t12d, 0x776F| .sw_next 0 2: 0500400080000010 | 0040400080802600 | 180080008000726C | FFFC2000 | sll ecx, 0x10| or ecx, t12d| mov edx, 0x726C| .sw_next 0 3: 1804C00080006421 | 0500800080000010 | 0040800080802600 | FFFE7FFF | mov t12d, 0x6421| sll edx, 0x10| or edx, t12d| .sw_complete FFF
Run:
$ ../conroe/mbtracer/mbctrl -r -D test-patches/test60FB2-cpuid0-helloworld.bin cpuid0 cpuid1 stat B9010000000F33C3 boot:boot cpuid=00060FB2 sig=00000000 patch:ok patch len=00000200 tscdiff=0000000000000B18 cmd-cpuid0:ok cpuid: eax=00000000 ebx=48656C6C ecx=6F20776F edx=726C6421 cmd-cpuid1:ok cpuid: eax=00060FB2 ebx=00020800 ecx=00002001 edx=178BFBFF cmd-stat:ok x86 working buf=00111000 sig=00000000BADA55E5 hex-cmd:B9010000000F33C3:ok cmd eax=00CDE383 ebx=A3B3C3D3 ecx=00000001 edx=00008290 esi=A6B6C6D6 edi=A7B7C7D7 ebp=A5B5C5D5 esp=0010C81C eflags=00000046 st0=7FC00000 st1=7FC00000 st2=7FC00000 st3=7FC00000 st4=7FC00000 st5=7FC00000 st6=7FC00000 st7=FFC00000 done t=19993 ms
Patchfile:
BiApCeVV2roAgBAAQ+4JXwAAAAAAAAAAsgYAAACqqqqsBgAA//////////////////////////// /////////5q3/3//f/7PTU7+////2T/3/v/////nX8D/9wC//+y///8/v/++If+f///+/4NE/H/+ /7MA/v97/9/7/3/9/99/f//Zf///f/7/TTb7P///PQDw//P/z3vP/vn///+/93//+v+z//7+//3+ /wAMAAAf+AfwfBPxP4+CP0Hwy2Dr/4F/AMM/gH+0lAwA+A/8Axv+AfzgP/APb/gH8ID/wD+/4R/A AP6/BwH8B/78D99ET/Cj4Ng6/DIfwH/g4N/wDwMALSXxAP7/bYAHf///Of/9+h/+/7/n/wf4efiV AYBcgX8A/zcR/8MA+BMEvwy2Dv7/DwB8+yk+RskAQP/AP4DhH8C//gP/AIZ/AP/4D/wDG/4B/OD/ ewDAf+Af3/AP4AD/gX9/wz+AAfwH/v4N/wAA8P89D+A/8PBv+Ac/gP/AwL/hH/8A/gMA/4Z/HgD4 //gH8B8D+Df84B/Afw/g3/CBfwD/P4B/w38PAPwP/AP4/gH8Gz/wD+D4B/Bv/8A/gOEfwL/+vwcA /Af+AQ3/AP7wH/gHN/wD+MB/4B/f8A/gAHZUAwD+A///hn8AA/gP/Pwb/gEP4D/w8G/4BwGAOqo=
At a structural level, AMD microcode patch files follow a consistent format consisting of a header, patch payload, and cryptographic metadata. The header includes CPU identification fields (family/model/stepping), patch revision, and metadata such as date or patch ID. This is followed by the microcode body itself, which contains instructions for an internal RISC-like control engine used by the CPU. The final portion includes a public key and a signature that is supposed to authenticate the patch.
The critical weakness lies in how this signature is verified. Instead of a robust cryptographic hash, the design uses AES-CMAC in a way that permits controlled collisions. Because the verification effectively compares derived hashes of public key material, an attacker can modify the patch payload and adjust padding or additional blocks to preserve the expected hash value. This allows arbitrary changes to the microcode while still passing signature checks. The patch format itself is flexible enough to accommodate such modifications (e.g., inserting extra blocks), which is what makes the forgery practical.
- nvd.nist.gov/vuln/detail/CVE-2024-56161↗
- www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html↗
- github.com/.../blob/master/pocs/cpus/entrysign/zentool/docs/intro.md↗
- github.com/.../blob/master/pocs/cpus/entrysign/zentool/docs/reference.md↗
- github.com/google/security-research/tree/master/pocs/cpus/entrysign/zentool↗
- youyou.moe/2025/10/entrisign-matisse/↗
- www.youtube.com/watch?v=sUFDKTaCQEk↗
- bughunters.google.com/blog/zen-and-the-art-of-microcode-hacking↗
- reflexive.space/zen2-ibs/↗
2048bits, expoent 0x10001.
Older patches use modulus:
C7 9C 87 25 DE F5 D3 87 79 46 DF B6 28 95 A5 99 9B DB 84 2A C5 8D 79 42 14 D8 FF 37 C8 FE 16 CC 38 35 82 3A 7B FC 9C 2D F7 46 AE 2D 71 CA DB 67 F8 8A 35 3C 69 CA 45 97 E8 47 52 89 D3 0F 4D FD 54 EA 69 9A 35 CA 7D A2 7F FE C1 71 70 29 A3 5F 52 20 DE 4D 15 D0 85 8E 87 88 93 08 CB E6 4B 9C 00 AA D6 D0 DC 00 2A 6D 46 54 1A CA 08 2E 9D 11 27 16 29 AD FA 91 5A 43 CC EC AD F7 87 54 3F 34 69 C5 6E 17 20 59 00 AA FE 0B AA 89 4F 4F E4 41 AD 77 A3 7D 5B 1B A4 4F 59 79 5A 1E 2A 97 A4 4B 8C 3E D4 C4 4F D7 B6 F1 88 90 93 37 50 73 5A C2 73 1A 15 8A 43 79 8D BA 7D 19 BD 53 41 55 D9 5C F2 12 3F A2 5E D2 10 48 61 2F 4C 22 9D 97 97 E5 D7 21 D2 38 1E 86 79 ED E9 77 B8 D2 A0 80 F0 FC B1 5F 1F B2 CA BC BB C2 85 5A 30 23 0A C1 D0 C6 5D A7 53 DD CD 0F C9 1C B9 60 74 F8 BA AD 80 C3
Newer patches use modulus:
98 93 86 B9 CC E0 F2 86 6B CE E6 A6 C1 08 F9 D9 3E 7F CB F6 A4 E2 DB 2B 2C 65 4C D2 D4 A9 55 14 B3 27 01 D9 3B E5 8C D2 CF A7 0A 58 5B 1D 16 B2 3B 11 EE 1E F0 EC 69 F2 A5 1D F5 46 0A 91 CE 36 89 1C C3 4B AB B5 3D A3 64 20 C4 30 03 02 9E 6A 59 B7 74 A5 68 61 F6 46 A6 03 3C 8F CE 32 A9 94 C1 AC 63 11 74 79 6F F4 BA 42 07 4F 38 89 AC 55 21 5B 6C C5 33 8A 31 6B 5E C6 39 B8 00 D2 92 6A BD 7F BF 24 12 8B 91 AC B8 68 51 86 06 32 BD 30 C8 B0 2A BB 8A DD 72 31 08 77 19 1D F5 41 82 2A C8 17 86 77 C1 CF 2D 1D 4D 09 C4 FE 8E 91 47 2C 85 6E 3D 80 B7 E1 34 E1 AB E2 5D 92 D0 86 A5 EF 20 96 7E B8 4D 8F 98 27 6B 1C A6 97 D2 C8 D5 2D EA FE 4E 2F 03 2F 2E 02 42 90 BA B1 F2 74 2C 54 69 DF 55 47 5A E3 61 58 24 8A C4 73 F2 73 E0 76 77 FC 42 5F BD DF F1 16 56 A5 09 BF 31 19 7E 21
After doing modexp on signature, both used pubkeys reveal PKCS1 padded 16-byte (128bit) hash.
If you know anything about AMD internal structure, please contact me.
A simple hardware core with its own native instruction set, and a software layer (Code Morphing Software, CMS) that makes the system appear like an x86 CPU. Instead of implementing the x86 instruction set directly in hardware, Crusoe executes a proprietary internal ISA and relies on CMS to dynamically translate x86 instructions into that native form at runtime. At the hardware level, Crusoe uses a VLIW (Very Long Instruction Word) architecture, where instructions are grouped into bundles (called molecules) containing multiple smaller operations (atoms). Each atom is roughly comparable to a simple RISC-like operation, and multiple atoms are issued together in a single wide instruction word (64- or 128-bit). This means the hardware itself is relatively simple: it executes explicitly parallel instruction bundles without doing complex scheduling, out-of-order execution, or branch prediction internally. Instead, those responsibilities are pushed into software. The key innovation is that the internal instruction set is not tied to x86 at all. The CMS layer acts as a dynamic binary translator and optimizer: it takes incoming x86 code, decodes it, and recompiles it into optimized sequences of native VLIW instructions. Frequently executed code paths are cached as translated blocks and progressively optimized, effectively behaving like a runtime JIT compiler specialized for the Crusoe core.
Because of this indirection, the native ISA can remain simple, regular, and RISC-like, while still supporting a complex external ISA such as x86.
From an instruction-set perspective, the native Crusoe ISA is characterized by:
- Fixed-width, RISC-like operations (“atoms”)
- Explicit parallel grouping into VLIW bundles (“molecules”)
- Software-controlled scheduling and register usage
- A relatively large register file managed by the CMS rather than exposed architecturally
- This design effectively turns the CPU into a software-defined processor. All complex behaviors traditionally implemented in hardware—such as instruction decoding, dependency analysis, instruction reordering, and even parts of exception handling—are implemented in CMS.
The consequence is a very small, power-efficient core, at the cost of relying heavily on sophisticated runtime translation software.
- en.wikipedia.org/wiki/Transmeta#Products↗
- theretroweb.com/.../crusoe-tm5700-tm5900-processor-6429903a6bb74624192317.pdf↗
- www.realworldtech.com/crusoe-exposed/↗
- classes.engineering.wustl.edu/cse362/images/c/c7/Paper_aklaiber_19jan00.pdf↗
- safari.ethz.ch/.../fetch.php?media=dehnert_transmeta_code_morphing_software.pdf↗
- www.cs.cornell.edu/courses/cs6120/2019fa/blog/transmeta/↗
- datasheets.chipdb.org/Transmeta/Crusoe/TM5800/TM5800_BIOSGuide_6-14-02.pdf↗
- linux-kernel.vger.kernel.narkive.com/.../crusoe-s-persistent-translation-on-l...↗
- www.xsim.com/papers/crusoe-talk-amasbt2009.pdf↗
- www.xsim.com/papers/crusoe-amasbt2009.pdf↗
- www.xsim.com/papers/transmeta-code-morphong-software.dehnert-cgo03.pdf↗
- www.xsim.com/papers/transmeta-scopes-2003.dehnert.pdf↗
- David R. Ditzel articles scholar.google.com/citations?user=wCpExhsAAAAJ&hl=en↗