thisistfs/rogue-frameworkBancada de trabalho desktop para fuzzing com AFL++, emulação QEMU entre arquiteturas, desenvolvimento de harnesses, análise headless do Ghidra, mutadores personalizados e comparação de patches para desenvolvimento de exploits.
Rogue Framework é uma bancada de trabalho desktop para AFL++, fuzzing QEMU multi-arquitetura, desenvolvimento de harness, análise headless leve com Ghidra, mutadores personalizados e comparação de patches. É intencionalmente uma bancada de trabalho auditável em vez de um wrapper apenas com botões: cada comando AFL++ gerado é visível antes da execução, e os harnesses gerados são arquivos de código-fonte comuns que o pesquisador pode editar. Pretende ser "O BurpSuite dos desenvolvedores de exploits"
Rogue Framework atualmente tem como alvo Linux e Python 3.11+ com PyQt6.
No Kali Linux, o instalador configura o ambiente Python, clona o branch oficial
stable do AFL++ e compila sua distribuição completa e o backend QEMU
instrumentado, depois instala o Ghidra headless, GDB nativo/multiarch, GDB server, emulação
user/system do QEMU, dependências de compilador/build, um launcher de usuário e
entradas persistentes de PATH no shell. O AFL++ é baixado para o diretório local
AFLplusplus/ ignorado e não é distribuído como parte do Rogue Framework:
chmod +x install.sh
./install.sh
rogue-framework
Instale também os cross compilers comuns e os respetivos guest sysroots (o download é bastante maior) com:
./install.sh --with-cross-toolchains
O instalador é idempotente. Use ./install.sh --check para auditar uma instalação
existente ou ./install.sh --rebuild-afl para forçar uma reconstrução do AFL++/QEMU.
Use ./install.sh --update-afl para avançar explicitamente o checkout baixado
para a revisão estável oficial mais recente.
Execute-o como o usuário do desktop; ele solicita sudo apenas para pacotes apt. Um PATH
recém-gravado não pode alterar o shell pai já em execução, então abra um novo
terminal, carregue ~/.zshrc/~/.bashrc ou inicie o Rogue através do caminho absoluto
~/.local/bin/rogue-framework impresso pelo instalador.
A inicialização manual a partir do checkout permanece disponível:
python3 run.py
Para um ambiente editável:
python3 -m pip install -e .
rogue-framework
Binários dinâmicos multiarquitetura precisam de um sysroot de convidado correspondente selecionado com
QEMU_LD_PREFIX; isso é inerentemente específico do alvo/distribuição. O caminho do
analyzeHeadless do Ghidra pode ser substituído em Tools → External tools.
Um projeto .rgp é um JSON legível e versionado que contém a definição portátil do projeto. Artefatos grandes e mutáveis residem em seu workspace companheiro gerenciado:
example.rgp
example.rgp-work/
workspace.json
project.sqlite3
corpus/
output/
harnesses/
mutators/
analysis/
logs/
runs/
staging/
recovery/
backups/
objects/sha256/
Essa divisão mantém os arquivos do projeto passíveis de revisão e evita incorporar corpora de crash, descobertas, índices de análise ou estado do Ghidra no JSON. O workspace.json vincula o manifesto à identidade correta do workspace, enquanto o project.sqlite3 armazena o estado operacional/indexado. Referências gerenciadas usam workspace://; recursos explicitamente externos usam external://. Caminhos de ferramentas locais da máquina e o estado da interface são armazenados fora do projeto portátil.
Salvar Como cria um clone independente com novas identidades de projeto e workspace. O Rogue prepara e valida o destino antes de alternar o documento aberto, de modo que um clone com falha deixa o projeto de origem inalterado. Salvamentos canônicos usam uma concessão de escrita advisory, além de verificações de conflito por revisão/SHA-256, preservam manifestos anteriores válidos, publicam arquivos atomicamente com fsync e mantêm snapshots de recuperação de falhas, incluindo rascunhos ativos do editor. Harnesses gerados, mutadores, JSON do Ghidra, resultados de patch-diff e descobertas minimizadas também são publicados transacionalmente, para que uma substituição com falha não exclua o artefato válido anterior.
.fuzzO Rogue pode importar manifestos .fuzz legados de schema 0–2 e seus companheiros .fuzz-work. A origem legada nunca é o destino canônico: o primeiro salvamento a atualiza para um projeto .rgp irmão e um workspace .rgp-work, mantendo os arquivos legados originais. Novos projetos e destinos de Salvar Como sempre usam .rgp.