Alles ueber UEFI BIOS Modding, Risiken und wie diese Plattform funktioniert.
Moderne Mainboards speichern Hunderte bis Tausende Einstellungen im UEFI-Firmware. Davon sind im BIOS-Setup-Menue typischerweise nur 5-20% sichtbar — der Rest ist vom Hersteller absichtlich versteckt.
BIOS Modding bedeutet, diese versteckten Einstellungen sichtbar zu machen und zu aendern, ohne das BIOS selbst zu veraendern. Die Einstellungen werden im NVRAM (Non-Volatile RAM) auf dem Mainboard gespeichert.
Das BIOS besteht aus kompiliertem x86-Maschinencode und kryptografisch signiertem Microcode. Es gibt mehrere Gruende, warum man den ROM-Code nicht direkt aendern sollte:
1. Kryptografische Signaturen — Intel Microcode ist mit RSA-2048 signiert. Jede Aenderung bricht die Signatur → die CPU laedt den Microcode nicht.
2. BIOS Guard / Boot Guard — Moderne Plattformen (ab Skylake) haben Hardware-basierte Integritaetspruefungen. Ein modifiziertes ROM wird beim Booten erkannt und abgelehnt → Brick-Gefahr.
3. Checksummen — Jedes FFS-Volume im UEFI-ROM hat eigene Checksummen. Binaeraenderungen ohne Neuberechnung → korruptes BIOS.
4. Komplexitaet — Ein BIOS-ROM enthaelt 200-500 DXE-Treiber, PEI-Module, SMM-Handler und Setup-Applikationen. Ein falscher Patch kann an voellig unerwarteter Stelle wirken.
IFR ist ein Binaerformat das beschreibt, wie das BIOS-Setup-Menue aufgebaut ist. Jedes Setting wird definiert durch:
VarStore + Offset — Wo der Wert im NVRAM gespeichert ist (z.B. CpuSetup:0x0043)
Typ — Checkbox, Dropdown (One-Of), Numerisch
Optionen — Moegliche Werte (z.B. 0x00 = Disabled, 0x01 = Enabled)
Flags — SUPPRESS_IF (versteckt), GRAYOUT_IF (ausgegraut)
Unsere Plattform parst diese IFR-Strukturen und macht alle Settings sichtbar — auch die mit SUPPRESS_IF.
setup_var.efi ist ein UEFI-Shell-Tool das einzelne Bytes im NVRAM liest und schreibt. Es braucht drei Informationen:
Die Plattform generiert automatisch:
verify.nsh — Liest alle wichtigen Offsets aus (NUR LESEN, keine Aenderung)
modify_bios.nsh — Schreibt die gewuenschten Aenderungen (aus dem Simulator exportiert)
verify.nsh ausfuehren!Jedes Setting wird automatisch einer Risiko-Stufe zugeordnet:
Da wir nur NVRAM-Werte aendern (kein ROM-Patching), gibt es mehrere Rettungswege:
1. CMOS Reset — Mainboard-Batterie fuer 30 Sekunden entfernen oder CMOS-Clear Jumper/Button nutzen. Setzt ALLE NVRAM-Werte auf Werkseinstellungen zurueck.
2. BIOS Recovery — Die meisten modernen Boards haben einen BIOS-Recovery-Modus (z.B. ASRock Instant Flash, ASUS FlashBack). Damit kann das BIOS komplett neu geflasht werden.
3. Dual BIOS — Einige Boards (z.B. Gigabyte) haben zwei BIOS-Chips. Wenn einer fehlschlaegt, bootet der zweite automatisch.
Jede Intel-CPU hat eine eindeutige CPUID-Signatur (z.B. 0xC0662 fuer Arrow Lake-S C0). Das BIOS liest diese beim Booten und entscheidet daraufhin welche Features freigeschaltet werden.
Das Problem: Server-CPUs (Xeon) teilen oft das gleiche Silizium wie Desktop-CPUs, haben aber kuenstliche Sperren:
Unser Ansatz: Statt die CPUID zu faelschen (was wegen Microcode-Signaturen nicht zuverlaessig funktioniert), identifizieren wir die versteckten OC-Settings und ermöglichen deren Freischaltung ueber NVRAM. Das ist sicherer und reversibler als Binaer-Patching.