Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
attestos — Bazzite plus eine TPM-Boot-Attestierungsschicht. In Arbeit: Builds unverifiziert, UKI-Mechanismus ungeklärt. Spezifikation: github.com/plunder707/attested-gaming | Kitploit
Tools/GitHubGitHub/plunder707/attestos
DefensivwerkzeugeKryptographieHardware-SicherheitAuthentifizierungFirmware-Analyse
GitHubplunder707/attestos

attestos

Bazzite plus eine TPM-Boot-Attestierungsschicht. In Arbeit: Builds unverifiziert, UKI-Mechanismus ungeklärt. Spezifikation: github.com/plunder707/attested-gaming

Repository anzeigen
120vor 1 MonatNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

attestos

Experimentelles Linux-Boot-Attestierungs-Image und Beweis-Harness zum Testen, was ein Anti-Cheat-Anbieter verifizieren könnte, anstatt sich auf eine Zulassungsliste von Distributionsnamen zu verlassen.

Der Mechanismus, das Bedrohungsmodell und die Herstellerspezifikation befinden sich in plunder707/attested-gaming. Dieses Repository ist das Image, das die Beweise erzeugt.


STATUS: VORSCHAU DER QUELLMECHANIK. NICHT INSTALLIERBAR ODER PRODUKTIONSVERTRAUENSWÜRDIG.

Die GitHub-Actions-Läufe 31157890393 und 31159951490 erstellten ein von Bazzite abgeleitetes QCOW2, booteten es unter QEMU/OVMF mit swtpm und ohne Gastnetzwerk, richteten persistente EK/AK-Handles ein und verifizierten einen rohen Quote über SHA-256-PCRs 7, 11, 12 und 15 von innerhalb des Gasts. Die begrenzte Quittung hat SHA-256 ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf. Ein separater Verifizierer-Workflow 31160003873 übte den finalen Agent-Commit b918392 dieses Repositorys gegen einen isolierten Software-TPM aus und bestand AK-Enrollment, Rohattest-Verifizierung, Replay- Ablehnung, Signaturmanipulations-Ablehnung und QEMU/OVMF-TPM-Verdrahtung.

Das gebootete Ergebnis bestätigt auch den Bazzite-Policy-Blocker: Es war keine UKI-Datei oder kein systemd-stub-Signal vorhanden, die beabsichtigten Lockdown-Argumente fehlten, und die PCRs 11 und 15 blieben null. PCR 12 war ebenfalls null, aber das ist kein unabhängiger Fehler: Die eingebettete UKI-Befehlszeile gehört zu PCR 11, während PCR 12 externe Befehlszeileneingaben aufzeichnet und korrekt null bleiben kann, wenn keine geliefert werden. Secure-Boot-Schlüssel-Enrollment, UKI-gestützte Befehlszeilenmessung, Hardware-Provenienz, Event-Log-Replay, Transportbindung und Boot-Policy-Zulassung bleiben ungelöst. Keiner der grünen Läufe etabliert ein funktionierendes Produktionsattestierungssystem.

Eine separate positive Kontrolle mit versiegeltem Fedora-Image bestand zweimal in run 31218059725 und erneut auf dem Head des zusammengeführten Quellcodes in run 31219745053. Sie beweist, dass das Harness ein unveränderliches, upstream-signiertes UKI booten, den von der Firmware ausgewählten Pfad und den Hash der geladenen Datei in die Pre-Boot-Inspektion einbeziehen, einen von null verschiedenen PCR 11 beobachten und eine unsignierte .cmdline-Mutation ablehnen kann. Dies ist nur eine Harness-Kontrolle: Alle Hersteller-, Policy- und Produktionsvertrauensflags bleiben falsch, und es macht die Bazzite-Vorschau nicht installierbar.

Der separate signierte PCR-12-Policy-Addon-Testlauf bestand dann zweimal in run 31234464516. Das Upstream-UKI und PCR 11 blieben byte-identisch; beide signierten Boots wandten lockdown=confidentiality module.sig_enforce=1 genau einmal an und reproduzierten PCR 12 ca62dd5f...a8f5; die Manipulation nach der Signatur wurde abgelehnt und kehrte zur Null-PCR-12-Basislinie zurück. Dies beweist einen begrenzten Mechanismus, keine einsetzbare Schlüsselhierarchie oder Betriebssystem-Vertrauensrichtlinie.

Dieser Quellcode ist zur Überprüfung und reproduzierbaren Emulation verfügbar. Es ist kein GHCR-Image veröffentlicht und es ist keine installierbare vertrauenswürdige Distribution.

Das abgeschlossene Bazzite-Experiment wird in BOOTED_IMAGE_CANARY.md beschrieben. Reproduktions- und Quellbuild-Anweisungen befinden sich in BUILDING.md. UKI-Basisbeweise und ihre unabhängigen Zulassungskriterien sind in UKI_BASE_DECISION.md festgehalten. Das signierte PCR-12-Policy-Addon- Experiment wird separat in FEDORA_PCR12_ADDON_CANARY.md beschrieben. Die Meilensteinreihenfolge und Stoppregeln werden in ROADMAP.md verfolgt. Die separate Harness-Kontrolle für geladene UKIs wird in FEDORA_SEALED_POSITIVE_CONTROL.md beschrieben.


Was dies zu Bazzite hinzufügt

Es wird nichts entfernt und nichts gepatcht. Vier Dinge kommen obendrauf:

  1. tpm2-tools und tpm2-tss, die der Agent zur Laufzeit benötigt.
  2. Eine Kernel-Befehlszeile unter /usr/lib/attestos/cmdline mit lockdown=confidentiality und module.sig_enforce=1.
  3. attestos-provision, eine One-Shot-Unit, die im TPM eindeutige persistente RSA-EK- und AK-Identitäten erstellt und das Endorsement-Zertifikat aus dem NV-Speicher liest, wenn eines vorhanden ist.
  4. attestos-agent, socket-aktiviert auf Loopback, der eine strenge attestos.tpm/v1-Identitäts-, Aktivierungs- oder Quote-Herausforderung mit rohen TPM-Beweisen beantwortet. Der Agent gibt nie ein Vertrauensurteil zurück.

Warum die Basis Bazzite ist

Bazzite ist von Fedora abgeleitet, und die Fedora-Familie ist das, was Anti-Cheat- Zulassungslisten derzeit blockieren. Zu beweisen, dass Attestierung hier funktioniert, ist der Fall, der sich zu beweisen lohnt. Die Entwicklung auf SteamOS würde nichts demonstrieren, weil SteamOS bereits durchgelassen wird; ein erfolgreicher Demo dort würde sich also Zugang verschaffen, den es bereits hat.

Bazzite ist außerdem dafür ausgelegt, geschichtet zu werden. Es ist ein OCI-Image, daher ist dieses Repository ein Containerfile und eine GitHub Action und keine Distribution mit Spiegeln und Installationsprogrammen dahinter.

Die Policy muss vor dem Kernel authentifiziert und gemessen werden

Dies ist der Teil, der entscheidet, ob das Ganze eine Bedeutung hat. lockdown=confidentiality blockiert /dev/mem, Kprobes gegen ein laufendes Kernel und das Laden unsignierter Module. Diese Garantie ist nichts wert, wenn die Policy nur in einer Bootloader-Konfiguration lebt, die der Benutzer bearbeiten kann. Andernfalls kann ein Benutzer die Argumente löschen, dieselbe Kernel-Messung booten und einen Quote vorlegen, der nichts über die fehlende Policy aussagt.

Ein Unified Kernel Image bindet Kernel, Initrd und seine eingebettete Befehlszeile in eine einzige signierte PE-Binärdatei, die in PCR 11 gemessen wird. Ein separat signiertes systemd-Befehlszeilen-Add-on kann zusätzliche Policy in PCR 12 erweitern, während das Upstream-UKI unverändert bleibt. Beide Wege müssen mit dem exakt geladenen Artefakt verbunden und vom Verifizierer wiedergegeben werden; das Vorhandensein einer Datei oder ein von null verschiedener PCR reicht nicht aus.

Bazzite unterstützt kein UKI, und das ist nun bestätigt und nicht nur vermutet. Sein Containerfile schließt die UKI-Kernel-Pakete aktiv aus:

dnf5 -y config-manager setopt "*fedora*".exclude="mesa-* kernel-core-* \
    kernel-modules-* kernel-uki-virt-* steam"

systemd-ukify taucht nirgendwo im Repository auf. Die cmdline-Datei, die dieses Image mitliefert, ist derzeit also nur eine Absichtserklärung und nichts weiter: Ohne ein UKI gibt es nichts, das sie versiegelt, ein Benutzer kann sie im Bootloader bearbeiten, und PCR 11 misst nicht das, was das Design voraussetzt.

Tool herunterladen