thisistfs/rogue-frameworkPoste de travail de bureau pour le fuzzing AFL++, l'émulation QEMU multi-architecture, le développement de harness, l'analyse headless avec Ghidra, les mutateurs personnalisés et la comparaison de correctifs pour le développement d'exploits.
Rogue Framework est un atelier de bureau pour AFL++, le fuzzing QEMU multi-architecture, le développement de harnais, l'analyse headless légère de Ghidra, les mutateurs personnalisés et la comparaison de correctifs. Il s'agit volontairement d'un atelier auditable plutôt que d'un simple wrapper à boutons : chaque commande AFL++ générée est visible avant l'exécution, et les harnais générés sont de simples fichiers source que le chercheur peut modifier. Il est censé être « Le BurpSuite des développeurs d'exploits ».
Rogue Framework cible actuellement Linux et Python 3.11+ avec PyQt6.
Sur Kali Linux, l'installateur configure l'environnement Python, clone la branche stable officielle d'AFL++ et compile sa distribution complète ainsi que le backend QEMU instrumenté, puis installe Ghidra headless, GDB natif/multiarch, le serveur GDB, l'émulation QEMU user/system, les dépendances de compilation/construction, un lanceur utilisateur et des entrées PATH persistantes dans le shell. AFL++ est téléchargé dans le répertoire local ignoré AFLplusplus/ et n'est pas distribué dans Rogue Framework :
chmod +x install.sh
./install.sh
rogue-framework
Installez également les compilateurs croisés courants et leurs sysroots invités (le téléchargement est bien plus volumineux) avec :
./install.sh --with-cross-toolchains
L'installateur est idempotent. Utilisez ./install.sh --check pour auditer une installation existante ou ./install.sh --rebuild-afl pour forcer une reconstruction d'AFL++/QEMU. Utilisez ./install.sh --update-afl pour avancer explicitement le checkout téléchargé jusqu'à la dernière révision stable officielle. Exécutez-le en tant qu'utilisateur du bureau ; il ne demande sudo que pour les paquets apt. Un PATH nouvellement écrit ne peut pas modifier le shell parent déjà en cours d'exécution : ouvrez donc un nouveau terminal, sourcez ~/.zshrc/~/.bashrc, ou lancez Rogue via le chemin absolu ~/.local/bin/rogue-framework affiché par l'installateur.
Le démarrage manuel depuis le checkout reste disponible :
python3 run.py
Pour un environnement éditable :
python3 -m pip install -e .
rogue-framework
Les binaires dynamiques multi-architecture nécessitent un sysroot invité correspondant sélectionné avec QEMU_LD_PREFIX ; c'est intrinsèquement spécifique à la cible/distribution. Le chemin de analyzeHeadless de Ghidra peut être remplacé dans Outils → Outils externes.
Un projet .rgp est un JSON lisible et versionné contenant la définition portable du projet. Les artefacts volumineux et mutables vivent dans son espace de travail compagnon géré :
example.rgp
example.rgp-work/
workspace.json
project.sqlite3
corpus/
output/
harnesses/
mutators/
analysis/
logs/
runs/
staging/
recovery/
backups/
objects/sha256/
Cette séparation maintient les fichiers de projet révisables et évite d'intégrer des corpus de crashs, des résultats, des index d'analyse ou l'état de Ghidra dans le JSON. workspace.json lie le manifeste à la bonne identité d'espace de travail, tandis que project.sqlite3 stocke l'état opérationnel/indexé. Les références gérées utilisent workspace:// ; les ressources explicitement externes utilisent external://. Les chemins d'outils locaux à la machine et l'état de l'interface sont stockés en dehors du projet portable.
Enregistrer sous crée un clone indépendant avec de nouvelles identités de projet et d'espace de travail. Rogue prépare et valide la destination avant de basculer le document ouvert, de sorte qu'un clone échoué laisse le projet source inchangé. Les sauvegardes canoniques utilisent un bail d'écriture consultatif ainsi que des vérifications de conflit par révision/SHA-256, préservent les manifestes précédents valides, publient les fichiers atomiquement avec fsync et maintiennent des instantanés de récupération après crash, y compris les brouillons d'éditeur actifs. Les harnais, mutateurs, JSON Ghidra, résultats de diff de correctifs et résultats minimisés générés sont également publiés de manière transactionnelle afin qu'un remplacement échoué ne supprime pas l'artefact valide précédent.
.fuzz héritésRogue peut importer les manifestes .fuzz hérités des schémas 0 à 2 et leurs compagnons .fuzz-work. La source héritée n'est jamais la destination canonique : la première sauvegarde la convertit en projet .rgp voisin et en espace de travail .rgp-work, tout en conservant les fichiers hérités d'origine. Les nouveaux projets et les destinations d'Enregistrer sous utilisent toujours .rgp.