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 workbench desktop per AFL++, fuzzing QEMU cross-architettura, sviluppo di harness, analisi headless leggera con Ghidra, mutatori personalizzati e confronto di patch. È volutamente un workbench auditabile piuttosto che un wrapper basato solo su pulsanti: ogni comando AFL++ generato è visibile prima dell'esecuzione e gli harness generati sono normali file sorgente che il ricercatore può modificare. Dovrebbe essere "Il BurpSuite degli exploit developer".
Rogue Framework attualmente supporta Linux e Python 3.11+ con PyQt6.
Su Kali Linux, l'installer configura l'ambiente Python, clona il ramo stable
ufficiale di AFL++ e compila l'intera distribuzione e il backend QEMU
strumentato, quindi installa Ghidra headless, GDB nativo/multiarchitettura, GDB
server, emulazione QEMU user/system, dipendenze di compilazione/build, un
launcher utente e voci persistenti di PATH di 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-compilatori comuni e i relativi sysroot guest (questo è un download molto più grande) con:
./install.sh --with-cross-toolchains
L'installer è idempotente. Usa per verificare un'installazione esistente oppure per forzare una ricompilazione di AFL++/QEMU. Usa per portare esplicitamente il checkout scaricato all'ultima revisione stabile ufficiale. Eseguilo come utente desktop; richiede solo per i pacchetti apt. Un PATH appena scritto non può alterare la shell padre già in esecuzione, quindi apri un nuovo terminale, esegui il sourcing di /, oppure avvia Rogue tramite il percorso assoluto stampato dall'installer.
./install.sh --check./install.sh --rebuild-afl./install.sh --update-aflsudo~/.zshrc~/.bashrc~/.local/bin/rogue-frameworkL'avvio manuale dalla directory di checkout rimane disponibile:
python3 run.py
Per un ambiente modificabile:
python3 -m pip install -e .
rogue-framework
I binari dinamici cross-architettura necessitano di un sysroot guest
corrispondente selezionato con QEMU_LD_PREFIX; questo è intrinsecamente
specifico per target/distribuzione. Il percorso di analyzeHeadless di Ghidra
può essere sovrascritto in Strumenti → Strumenti esterni.
Un progetto .rgp è JSON leggibile e versionato che contiene la definizione
portabile del progetto. Gli artefatti grandi e mutevoli vivono nel suo workspace
compagno gestito:
example.rgp
example.rgp-work/
workspace.json
project.sqlite3
corpus/
output/
harnesses/
mutators/
analysis/
logs/
runs/
staging/
recovery/
backups/
objects/sha256/
Questa separazione mantiene i file di progetto revisionabili ed evita di
incorporare crash corpus, 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 valida la destinazione prima di cambiare il documento
aperto, quindi un clone fallito lascia invariato il progetto sorgente. I salvataggi
canonici usano un lease di scrittura consultivo più controlli di conflitto
revisione/SHA-256, preservano i manifest validi precedenti, pubblicano i file
atomicamente con fsync e mantengono snapshot di ripristino da crash inclusi gli
abbozzi degli editor attivi. Anche harness, mutatori, JSON di Ghidra, risultati
del diff delle patch e risultati minimizzati vengono pubblicati in modo
transazionale, cosicché una sostituzione fallita non elimini il precedente
artefatto valido.
.fuzzRogue può importare manifest .fuzz legacy di schema 0–2 e i loro companion
.fuzz-work. La sorgente legacy non è mai la destinazione canonica: il primo
salvataggio la aggiorna a un progetto .rgp e un workspace .rgp-work
adiacenti, mantenendo i file legacy originali. I nuovi progetti e le destinazioni
di Salva con nome usano sempre .rgp.