Progetto Barzakh (برزخ)

"Barzakh" (برزخ) — una barriera tra due regni; il confine invisibile che separa il mondo dei vivi dal mondo degli spiriti. Qui rappresenta la barriera tra offesa e difesa, tra vulnerabilità e rilevamento.

La piattaforma di ricerca sulla sicurezza del firmware UEFI open-source più completa

Emulazione offensiva da Ring 0 a Ring -4 | 132 motori di rilevamento | Validazione avversaria a ciclo chiuso

⚠️ PROGETTO DI RICERCA ACCADEMICA — SOLO SICUREZZA DIFENSIVA

Questa piattaforma esiste per studiare le minacce al firmware e costruire difese contro di esse. Contiene emulazioni offensive attive con kill-switch basati sull'hardware. Accedendo a questo repository, accetti di utilizzarlo esclusivamente per scopi legittimi di ricerca sulla sicurezza e didattici.

📋 Cos'è Barzakh?

Barzakh è una piattaforma full-stack per la ricerca sulla sicurezza del firmware che modella le TTP dei bootkit del mondo reale attraverso ogni anello di privilegio — dai driver UEFI DXE (Ring 0) fino a SMM, Intel ME, AMD PSP, controller DMA della piattaforma (Ring -3) e minacce microarchitetturali della CPU (Ring -4). Abbina ogni tecnica offensiva a un corrispondente motore di rilevamento, creando un sistema a ciclo chiuso in cui ogni attacco è sia riproducibile che rilevabile.

Capacità principali:

21 moduli offensivi EDK II che coprono le architetture x86_64, AArch64/Apple Silicon e RISC-V
132 rilevatori specializzati con euristiche specifiche per il firmware e analisi strutturale (che coprono firmware UEFI, Intel/AMD, ARM, RISC-V, Android, Apple/iOS, wireless, baseband delle telecomunicazioni e satellitare)
Integrazione con la threat intelligence — feed IOC, un motore di regole basato su un sottoinsieme di YARA (wildcard, salti, condizioni booleane), esportazione di eventi MISP e mappatura MITRE ATT&CK
Analisi tramite machine learning — rilevamento di anomalie con isolation forest e un classificatore logistico malevolo/benigno, addestrabile sul corpus avversario
Cronologia delle scansioni e knowledge base — cronologia delle scansioni basata su SQLite con diff/trend e una knowledge base del firmware condivisibile (anonimizzabile)
Dashboard e API REST — barzakh-server fornisce una dashboard web e un'API JSON (porta 8420) con scansioni pianificate e trend del punteggio di rischio
Monitoraggio continuo — barzakh-agent sorveglia i target del firmware, registra la cronologia e inoltra i risultati ai SIEM (Elastic ECS, ArcSight CEF, QRadar LEEF) o ai webhook
127 generatori di payload avversari per la validazione automatizzata dei veri positivi
Copertura completa del Ring -4 — microcodice della CPU, esecuzione speculativa, canali occulti termici/di alimentazione, voltage glitching, interfacce di debug, rowhammer
Percorso di test in laboratorio hardware — progressione documentata dalla simulazione al silicio reale

Avversari di riferimento modellati

Minaccia	Tecnica	Copertura Barzakh
BlackLotus (CVE-2023-24932)	Bypass di Secure Boot tramite shim vulnerabile	Rilevatore `blacklotus` + payload `blacklotus_mok`
LogoFAIL (CVE-2023-40238)	Overflow del parser di immagini nel firmware UEFI	Rilevatore `logofail` + payload `logofail_image`
PixieFail (CVE-2023-45229+)	Buffer overflow nello stack di rete in EDK2	Rilevatore `pixiefail` + payload `pixiefail_dhcp`
CosmicStrand	Persistenza DXE su flash SPI	Integrità FV + regione SPI + rilevatore di persistenza
LoJax	Primo impianto SPI osservato in the wild	Rilevatore ME/SPI + analisi del flash descriptor
MoonBounce	DXE core modificato nella flash SPI	Hook sui Boot Services + diffing dei firmware volume
MosaicRegressor	Framework di persistenza UEFI	Multi-stadio: manomissione FV + PE inject + trampoline
Hacking Team (RCS)	Rootkit UEFI con Option ROM	Rilevatore Option ROM + analisi dell'espansione PCI
FinSpy	Modifica del bootloader UEFI	Intercettazione di ExitBootServices + scansione della memoria
Bootkitty (2024)	Primo bootkit UEFI Linux, bypass della firma GRUB	Rilevatore `linux_bootchain` + payload `bootkitty_grub_patch`
CVE-2024-7344	Reloader firmato che carica payload PE non firmati	Rilevatore `reloader` + payload `secureboot_reloader`
CVE-2023-1017/1018	Buffer overflow nell'implementazione di riferimento TPM 2.0	Rilevatore `tpm_command` + payload `tpm_ref_overflow`

🏗️ Architettura

🧩 Componenti principali

1. BootkitPkg — Emulazione offensiva (C11, EDK II)

21 moduli EDK II su 3 architetture (x86_64, AArch64, RISC-V) che emulano ogni tecnica di persistenza firmware nota:

Core x86_64 (13 moduli)

Modulo	Ring	Tecnica
`DxeInject`	0	Iniezione di driver in fase DXE — hook LoadImage/StartImage + SetVariable, persistenza FV, emulatore flash SPI con backend FVB2/Boot Guard, kill-switch
`ExitBootHook`	0	Intercettazione di ExitBootServices + hooking MSR
`SpiChipsetEmulator`	-1	Simulazione dell'interfaccia SPI a livello di chipset
`SmmPersistence`	-1	Installazione di handler SMM e persistenza in SMRAM
`CapsuleHijack`	-1	Abuso del meccanismo di aggiornamento tramite capsule UEFI
`AcpiTableInject`	-2	Iniezione di tabelle ACPI per l'accesso alla memoria del kernel
`VirtualAddressMapHook`	-2	Hooking degli EFI Runtime Services
`PciOptionRom`	-2	Impianto di Option ROM PCI
`MeSpiManipulation`	-3	Manipolazione della regione flash SPI di Intel ME
`HeciIntercept`	-3	Intercettazione del canale di comunicazione Host-ME
`MeDmaAttack`	-3	DMA avviato da ME verso la memoria host
`AmtSolChannel`	-3	Canale covert Serial-over-LAN AMT
`FtpmCommandForge`	-3	Falsificazione di comandi fTPM AMD tramite mailbox PSP

AArch64 / Apple Silicon (7 moduli)

Modulo	Tecnica
`Aarch64DxeInject`	Iniezione DXE ARM64 con payload consapevoli del livello EL
`ExceptionVectorHook`	Rilocazione della tabella delle eccezioni VBAR_EL1
`El3SecureMonitor`	Intercettazione delle chiamate al Secure Monitor EL3
`TzascManipulation`	Bypass del TrustZone Address Space Controller
`DeviceTreeInject`	Modifica del Device Tree Blob per la persistenza
`IbootTrustChain`	Sovversione della catena di fiducia di Apple iBoot
`SepMailboxIntercept`	Intercettazione della mailbox Apple SEP (Secure Enclave)

RISC-V (1 modulo)

Modulo	Tecnica
`RiscVDxeInject`	Iniezione di firmware in modalità M su piattaforme RISC-V

Tutti i moduli offensivi vengono distribuiti con SIMULATION_MODE = TRUE — modellano il comportamento senza eseguire operazioni reali sull'hardware. Consulta docs/LAB_TESTING.md per il percorso controllato verso i test su hardware reale.

Barzakh

Più Popolari