v1.5.2 Upload Galerie FAQ

FAQ — Haeufig gestellte Fragen

Alles ueber UEFI BIOS Modding, Risiken und wie diese Plattform funktioniert.

Was ist BIOS/UEFI Modding?

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.

UEFI BIOS Firmware — Gesamtstruktur Sichtbare Settings (5-20%) Boot-Reihenfolge, XMP, Lueftersteuerung, Secure Boot ... Versteckte Settings (80-95%) — SUPPRESS_IF / Grayed Out OC Ratio Limits, Voltage Overrides, CFG Lock, Power Limits, PCIe Bifurcation, VT-d, IGD, ME, Microcode-Updates, CSM ... NVRAM (aenderbar) ROM Code (signiert) Microcode (RSA) ▲ setup_var.efi ✕ nicht aenderbar ✕ nicht aenderbar
Wichtig: Wir aendern NICHT das BIOS selbst (ROM-Code), sondern nur die Werte im NVRAM — das ist vergleichbar mit dem Aendern einer Einstellung im normalen BIOS-Menue, nur eben fuer versteckte Optionen.
Wie funktioniert der Modding-Workflow?
📤 ROM hochladen IFR-Analyse 🔍 Settings entdecken Simulator / Browser 🛡️ Verify (USB-Stick) verify.nsh → report.txt Modifizieren modify_bios.nsh Schritt 1: ROM-Analyse Die BIOS-ROM wird geparst. Aus den IFR-Strukturen (Internal Forms Representation) werden alle Settings extrahiert — auch versteckte. Schritt 2: Hardware-Verifikation verify.nsh liest die aktuellen NVRAM-Werte per UEFI Shell aus (NUR LESEN). Die report.txt bestaetigt, dass die Offsets zum echten BIOS passen. Schritt 3: Modifikation (auf eigene Gefahr!) modify_bios.nsh schreibt einzelne Bytes im NVRAM um. Jeder Befehl aendert genau einen Wert an einem bekannten Offset. Beispiel: setup_var.efi CpuSetup:0x0043 0x00 → CFG Lock deaktivieren
Warum kann/sollte man nicht das BIOS direkt bearbeiten? Wichtig

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.

Warum ROM-Patching gefaehrlich ist ROM Code aendern Signatur bricht ❌ Boot Guard prueft Signatur ungueltig ❌ Board bootet nicht = Brick 🧱 Unser Ansatz: NVRAM-Werte aendern (kein ROM-Patching) Signatur bleibt intakt ✓ | Boot Guard zufrieden ✓ | Reversibel per BIOS-Reset ✓
Unser Ansatz aendert nur NVRAM-Werte — das ist das Gleiche was passiert wenn du eine Einstellung im BIOS-Menue aenderst. Der ROM-Code bleibt unberuehrt.
Was ist IFR (Internal Forms Representation)?

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)

FlagsSUPPRESS_IF (versteckt), GRAYOUT_IF (ausgegraut)

Beispiel IFR-Eintrag: One Of: CFG Lock VarStore: CpuSetup Offset: 0x0043 Width: 1 Options: 0x00 = Disabled 0x01 = Enabled [DEFAULT] Flags: SUPPRESS_IF (im BIOS-Menue versteckt)

Unsere Plattform parst diese IFR-Strukturen und macht alle Settings sichtbar — auch die mit SUPPRESS_IF.

Was ist setup_var.efi und wie funktioniert es?

setup_var.efi ist ein UEFI-Shell-Tool das einzelne Bytes im NVRAM liest und schreibt. Es braucht drei Informationen:

# LESEN (nur anzeigen): setup_var.efi CpuSetup:0x0043 → CpuSetup:0x43=0x01 # CFG Lock ist aktiviert # SCHREIBEN (aendern): setup_var.efi CpuSetup:0x0043 0x00 → CpuSetup:0x43=0x00 # CFG Lock jetzt deaktiviert

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)

Achtung: setup_var.efi aendert Werte direkt im NVRAM, OHNE Validierung. Ein falscher Offset oder Wert kann den Boot-Vorgang verhindern. Daher immer erst verify.nsh ausfuehren!
Was bedeuten die Risiko-Stufen? Safe Med High/Crit

Jedes Setting wird automatisch einer Risiko-Stufe zugeordnet:

Safe (Sicher) — Aenderungen die keine Stabilitaetsprobleme verursachen. Beispiele: Boot-Logo, Luefter-Modus, USB-Optionen, Sprache.
MED (Mittel) — Aenderungen die das Systemverhalten aendern aber nicht direkt gefaehrlich sind. Beispiele: C-States, SpeedStep, Virtualisierung (VT-d/VT-x).
HIGH (Hoch) — Aenderungen die zu Instabilitaet fuehren koennen. Beispiele: Spannungen (Voltage), Ratio-Limits, Power Limits, BCLK.
CRIT (Kritisch) — Aenderungen die den Boot verhindern koennen. Beispiele: CFG Lock, Microcode-Updates deaktivieren, ME deaktivieren, Flash-Schutz.
Was tun wenn das System nicht mehr bootet?

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.

Zusammenfassung: Ein NVRAM-Reset (CMOS Clear) loest fast alle durch Modding verursachten Probleme. Es ist NICHT moeglich, das Board durch NVRAM-Aenderungen dauerhaft zu beschaedigen — ein CMOS-Reset stellt immer den Originalzustand her.
Was ist CPUID-Spoofing und wofuer dient es? Beta

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:

Desktop (Core Ultra 9 285K) ✅ Multiplikator frei ✅ BCLK Overclocking ✅ Spannungs-Override ✅ XMP Speicher-Profile ✅ Power Limit Override CPUID: 0xC0662 Server (Xeon W-x500) ❌ Multiplikator gesperrt ❌ BCLK gesperrt ❌ Spannung limitiert ❌ Nur JEDEC/RDIMM ❌ Power Limit fest CPUID: 0xC066x (gleicher Die!)

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.

Hinweis: Diese Funktion befindet sich in der Beta-Phase. Nicht alle Server-CPUs lassen sich auf diese Weise entsperren — manche Sperren sind im Microcode (CPU-intern) hartcodiert und koennen nicht per NVRAM umgangen werden.