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 harnesses, l'analyse headless légère avec Ghidra, les mutateurs personnalisés et la comparaison de patches. C'est volontairement un atelier auditable plutôt qu'un simple wrapper à boutons : chaque commande AFL++ générée est visible avant exécution, et les harnesses générés sont des fichiers source ordinaires 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
officielle stable d'AFL++ et compile sa distribution complète ainsi que son backend QEMU
instrumenté, puis installe Ghidra headless, GDB natif/multiarch, GDB server, l'émulation
utilisateur/système QEMU, les dépendances de compilation/construction, un lanceur utilisateur, et
des entrées PATH de shell persistantes. AFL++ est téléchargé dans le répertoire local ignoré
AFLplusplus/ et n'est pas distribué avec 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
Le programme d'installation 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é vers 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, donc ouvrez un nouveau terminal, sourcez ~/.zshrc/~/.bashrc, ou lancez Rogue via le chemin absolu ~/.local/bin/rogue-framework affiché par le programme d'installation.
Le démarrage manuel depuis le checkout reste disponible :
python3 run.py
Pour un environnement modifiable :
python3 -m pip install -e .
rogue-framework
Les binaires dynamiques multi-architectures nécessitent un sysroot invité correspondant, sélectionné avec
QEMU_LD_PREFIX ; cela dépend intrinsèquement de la cible et de la distribution. Le chemin
analyzeHeadless de Ghidra peut être remplacé sous Tools → External tools.
Un projet .rgp est un JSON lisible et versionné contenant la définition portable du projet. Les artefacts volumineux et modifiables résident dans son espace de travail associé 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 permet de garder les fichiers du projet faciles à réviser et évite d'intégrer des corpus de crash, des résultats, des index d'analyse ou l'état de Ghidra dans le JSON. workspace.json lie le manifeste à l'identité correcte du workspace, 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.
Save As crée un clone indépendant avec de nouvelles identités de projet et de workspace. Rogue prépare et valide la destination avant de basculer le document ouvert, de sorte qu'un clonage é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 de manière atomique avec fsync, et maintiennent des instantanés de récupération après crash incluant les brouillons actifs de l'éditeur. Les harnais générés, les mutateurs, le JSON Ghidra, les résultats de patch-diff et les résultats minimisé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 des manifestes .fuzz hérités de schéma 0–2 et leurs compagnons .fuzz-work. La source héritée n'est jamais la destination canonique : la première sauvegarde la met à niveau vers un projet .rgp voisin et un workspace .rgp-work tout en conservant les fichiers hérités d'origine. Les nouveaux projets et les destinations Save As utilisent toujours .rgp.