thisistfs/rogue-frameworkBanco di lavoro desktop per il fuzzing con AFL++, emulazione QEMU multi-architettura, sviluppo di harness, analisi headless con Ghidra, mutatori personalizzati e confronto di patch per lo sviluppo di exploit.
Rogue Framework è un ambiente di lavoro desktop per AFL++, fuzzing QEMU cross-architettura, sviluppo di harness, analisi headless leggera con Ghidra, mutatori personalizzati e confronto di patch. È intenzionalmente un ambiente di lavoro verificabile anziché un semplice wrapper con pulsanti: ogni comando AFL++ generato è visibile prima dell'esecuzione, e gli harness generati sono normali file sorgente che il ricercatore può modificare. Si propone di essere "Il BurpSuite degli sviluppatori di exploit"
Rogue Framework attualmente supporta Linux e Python 3.11+ con PyQt6.
Su Kali Linux, l'installer configura l'ambiente Python, clona il branch ufficiale
stable di AFL++ e compila la sua distribuzione completa e il backend QEMU
strumentato, quindi installa Ghidra headless, GDB nativo/multiarch, GDB server, l'emulazione
user/system di QEMU, le dipendenze per compilazione/build, un launcher utente e
voci PATH persistenti per la shell. AFL++ viene scaricato nella directory locale
ignorata AFLplusplus/ e non è distribuito come parte di Rogue Framework:
chmod +x install.sh
./install.sh
rogue-framework
Installa anche i cross compiler comuni e le relative sysroot guest (questo è un download molto più grande) con:
./install.sh --with-cross-toolchains
L'installer è idempotente. Usa ./install.sh --check per verificare un'installazione esistente oppure ./install.sh --rebuild-afl per forzare una ricompilazione di AFL++/QEMU.
Usa ./install.sh --update-afl per avanzare esplicitamente il checkout scaricato all'ultima revisione stabile ufficiale.
Eseguilo come utente desktop; richiede sudo solo per i pacchetti apt. Un PATH appena scritto non può modificare la shell padre già in esecuzione, quindi apri un nuovo terminale, esegui il source di ~/.zshrc/~/.bashrc, oppure avvia Rogue tramite il percorso assoluto ~/.local/bin/rogue-framework stampato dall'installer.
L'avvio manuale dal checkout rimane disponibile:
python3 run.py
Per un ambiente modificabile:
python3 -m pip install -e .
rogue-framework
I binari dinamici cross-architecture richiedono un sysroot guest corrispondente selezionato con
QEMU_LD_PREFIX; questo è intrinsecamente specifico per target/distribuzione. Il percorso
analyzeHeadless di Ghidra può essere sovrascritto in Tools → External tools.
Un progetto .rgp è un JSON leggibile e versionato che contiene la definizione portabile del progetto. Gli artefatti di grandi dimensioni e modificabili risiedono nel suo workspace companion gestito:
example.rgp
example.rgp-work/
workspace.json
project.sqlite3
corpus/
output/
harnesses/
mutators/
analysis/
logs/
runs/
staging/
recovery/
backups/
objects/sha256/
Questa suddivisione mantiene i file di progetto verificabili ed evita di incorporare corpora di crash, risultati, indici di analisi o stato di Ghidra nel JSON. workspace.json collega il manifest alla corretta identità del workspace, mentre project.sqlite3 memorizza lo stato operativo/indicizzato. I riferimenti gestiti usano workspace://; le risorse esplicitamente esterne usano external://. I percorsi degli strumenti locali alla macchina e lo stato dell'interfaccia utente sono memorizzati al di fuori del progetto portabile.
Salva con nome crea un clone indipendente con nuove identità di progetto e workspace. Rogue prepara e convalida la destinazione prima di passare al documento aperto, così un clone fallito lascia invariato il progetto di origine. I salvataggi canonici utilizzano un lease di scrittura advisory più controlli di conflitto basati su revisione/SHA-256, preservano i manifest precedenti validi, pubblicano i file in modo atomico con fsync e mantengono snapshot di ripristino da crash, inclusi le bozze attive dell'editor. Gli harness generati, i mutator, il JSON di Ghidra, i risultati dei diff di patch e i risultati minimizzati vengono anch'essi pubblicati in modo transazionale, così una sostituzione fallita non elimina l'artefatto valido precedente.
.fuzzRogue può importare manifest .fuzz legacy di schema 0–2 e i relativi companion .fuzz-work. L'origine legacy non è mai la destinazione canonica: il primo salvataggio la aggiorna a un progetto .rgp e a un workspace .rgp-work adiacenti, conservando i file legacy originali. I nuovi progetti e le destinazioni di Salva con nome usano sempre .rgp.