Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
attestos — Bazzite più un layer di attestazione del boot basato su TPM. Lavori in corso: build non verificati, meccanismo UKI non risolto. Spec: github.com/plunder707/attested-gaming | Kitploit
Strumenti/GitHubGitHub/plunder707/attestos
Strumenti DifensiviCrittografiaSicurezza HardwareAutenticazioneAnalisi del Firmware
GitHubplunder707/attestos

attestos

Bazzite più un layer di attestazione del boot basato su TPM. Lavori in corso: build non verificati, meccanismo UKI non risolto. Spec: github.com/plunder707/attested-gaming

Vedi Repository
1201 mese faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

attestos

Immagine sperimentale di attestazione dell'avvio di Linux e harness di evidenze per testare ciò che un venditore anti-cheat potrebbe verificare invece di affidarsi a una allowlist basata sul nome della distribuzione.

Il meccanismo, il modello di minaccia e la specifica per i venditori vivono in plunder707/attested-gaming. Questo repository è l'immagine che produce le evidenze.


STATO: ANTEPRIMA DEI MECCANISMI DEL SORGENTE. NON INSTALLABILE NÉ AFFIDABILE PER LA PRODUZIONE.

Le esecuzioni di GitHub Actions 31157890393 e 31159951490 hanno compilato un'immagine QCOW2 derivata da Bazzite, l'hanno avviata sotto QEMU/OVMF con swtpm e senza rete guest, hanno creato handle EK/AK persistenti e verificato una quote grezza su SHA-256 delle PCR 7, 11, 12 e 15 dall'interno del guest. La sua ricevuta delimitata ha SHA-256 ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf. Un workflow di verifica separato 31160003873 ha esercitato il commit finale dell'agente b918392 di questo repository contro una TPM software isolata e ha superato l'arruolamento AK, la verifica della quote grezza, il rifiuto del replay, il rifiuto della manomissione della firma e il cablaggio TPM QEMU/OVMF.

Il risultato dell'avvio conferma anche il blocco della policy di Bazzite: nessun file UKI o segnale systemd-stub era presente, gli argomenti di lockdown previsti erano assenti e le PCR 11 e 15 sono rimaste a zero. Anche la PCR 12 era a zero, ma non si tratta di un fallimento indipendente: la riga di comando UKI incorporata appartiene alla PCR 11, mentre la PCR 12 registra gli input esterni della riga di comando e può correttamente rimanere a zero quando non ne vengono forniti. L'arruolamento delle chiavi Secure Boot, la misurazione della riga di comando basata su UKI, la provenienza hardware, il replay del registro eventi, il binding del trasporto e l'ammissione della boot-policy restano irrisolti. Nessuna delle due esecuzioni verdi stabilisce un sistema di attestazione funzionante per la produzione.

Un controllo positivo separato su immagine Fedora sigillata è passato due volte in run 31218059725 e di nuovo sul commit di testa della sorgente integrata in run 31219745053. Dimostra che l'harness può avviare un UKI immutabile firmato a monte, unire il percorso selezionato dal firmware e l'hash del file caricato all'ispezione pre-boot, osservare una PCR 11 non zero e rifiutare una mutazione non firmata di .cmdline. Si tratta solo di un controllo dell'harness: tutti i flag di fiducia del produttore, della policy e della produzione rimangono falsi, e non rende installabile l'anteprima Bazzite.

Il percorso separato dell'add-on di policy PCR 12 firmato è poi passato due volte in run 31234464516. L'UKI a monte e la PCR 11 sono rimasti byte-identici; entrambi gli avvii firmati hanno applicato lockdown=confidentiality module.sig_enforce=1 esattamente una volta e hanno riprodotto la PCR 12 ca62dd5f...a8f5; la manomissione post-firma è stata rifiutata e si è tornati alla baseline con PCR 12 a zero. Questo dimostra un meccanismo delimitato, non una gerarchia di chiavi distribuibile né una policy di fiducia del sistema operativo.

Questo sorgente è disponibile per la revisione e l'emulazione riproducibile. Nessuna immagine GHCR è pubblicata e non è una distribuzione affidabile installabile.

L'esperimento Bazzite completato è specificato in BOOTED_IMAGE_CANARY.md. Le istruzioni di riproduzione e compilazione del sorgente sono in BUILDING.md. Le evidenze di base UKI e i suoi criteri di ammissione indipendenti sono registrati in UKI_BASE_DECISION.md. L'esperimento dell'add-on di policy PCR 12 firmato è specificato separatamente in FEDORA_PCR12_ADDON_CANARY.md. L'ordine delle milestone e le regole di arresto sono tracciati in ROADMAP.md. Il controllo separato dell'harness su UKI caricato è specificato in FEDORA_SEALED_POSITIVE_CONTROL.md.


Cosa questo aggiunge a Bazzite

Non viene rimosso nulla e non viene patchato nulla. Quattro elementi si aggiungono sopra:

  1. tpm2-tools e tpm2-tss, di cui l'agente ha bisogno a runtime.
  2. Una riga di comando del kernel in /usr/lib/attestos/cmdline che porta lockdown=confidentiality e module.sig_enforce=1.
  3. attestos-provision, un'unità one-shot che crea identità RSA EK e AK persistenti e distinte all'interno della TPM e legge il certificato di endorsement dallo storage NV quando esiste.
  4. attestos-agent, attivato via socket su loopback, che risponde a una sfida rigorosa attestos.tpm/v1 di identità, attivazione o quote con evidenze TPM grezze. L'agente non restituisce mai un verdetto di fiducia.

Perché la base è Bazzite

Bazzite deriva da Fedora, e la famiglia Fedora è ciò che le whitelist anti-cheat bloccano attualmente. Dimostrare che l'attestazione funziona qui è il caso che vale la pena dimostrare. Costruire su SteamOS non dimostrerebbe nulla, perché SteamOS è già consentito, quindi una demo riuscita lì otterrebbe un accesso che ha già.

Bazzite è inoltre progettata per essere stratificata. È un'immagine OCI, quindi questo repo è un Containerfile e una GitHub Action piuttosto che una distribuzione con mirror e installer alle spalle.

La policy deve essere autenticata e misurata prima del kernel

Questa è la parte che decide se tutto ciò significa qualcosa. lockdown=confidentiality blocca /dev/mem, le kprobe contro un kernel in esecuzione e il caricamento di moduli non firmati. Questa garanzia non vale nulla se la policy vive solo in una configurazione del bootloader che l'utente può modificare. Altrimenti un utente può eliminare gli argomenti, avviare la stessa misurazione del kernel e presentare una quote che non dice nulla sulla policy mancante.

Una Unified Kernel Image lega kernel, initrd e la sua riga di comando incorporata in un unico binario PE firmato misurato nella PCR 11. Un add-on della riga di comando systemd firmato separatamente può estendere ulteriore policy nella PCR 12 lasciando invariato quell'UKI a monte. Entrambe le vie devono essere collegate all'artefatto esatto caricato e riprodotte dal verificatore; la presenza di un file o una PCR non zero non basta.

Bazzite non usa UKI, e ora è confermato piuttosto che sospettato. Il suo Containerfile esclude attivamente i pacchetti kernel UKI:

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

systemd-ukify non appare da nessuna parte nel repository. Quindi il file cmdline che questa immagine distribuisce è attualmente una dichiarazione di intenti e niente più: senza un UKI non c'è nulla che lo sigilli, un utente può modificarlo nel bootloader e la PCR 11 non misura ciò che il progetto assume che misuri.

Scarica lo strumento