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.
O Rogue Framework é uma bancada de trabalho desktop para AFL++, fuzzing QEMU entre arquiteturas, desenvolvimento de harnesses, análise headless leve do Ghidra, mutadores personalizados e comparação de patches. Ele é intencionalmente uma bancada auditável em vez de um invólucro de apenas botões: todos os comandos AFL++ gerados ficam visíveis antes da execução, e os harnesses gerados são arquivos-fonte comuns que o pesquisador pode editar. Ele se propõe a ser o "BurpSuite dos desenvolvedores de exploits".
O Rogue Framework atualmente tem como alvo o Linux e Python 3.11+ com PyQt6.
No Kali Linux, o instalador configura o ambiente Python, clona o branch
stable oficial do AFL++ e compila sua distribuição completa e o backend QEMU
instrumentado, depois instala o Ghidra headless, GDB nativo/multiarch, servidor GDB,
emulação QEMU de usuário/sistema, dependências de compilador/build, um lançador de
usuário e entradas persistentes de PATH no shell. O AFL++ é baixado para o diretório
local ignorado AFLplusplus/ e não é distribuído como parte do Rogue Framework:
chmod +x install.sh
./install.sh
rogue-framework
Instale também compiladores cruzados comuns e seus sysroots de convidado (este é um download muito 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-escrito não pode alterar o shell pai já em execução; portanto, abra um novo terminal, execute source em ~/.zshrc/~/.bashrc ou inicie o Rogue pelo caminho absoluto ~/.local/bin/rogue-framework impresso pelo instalador.
A inicialização manual a partir do checkout continua disponível:
python3 run.py
Para um ambiente editável:
python3 -m pip install -e .
rogue-framework
Binários dinâmicos entre arquiteturas precisam de um sysroot de convidado correspondente selecionado com QEMU_LD_PREFIX; isso é inerentemente específico de alvo/distribuição. O caminho do analyzeHeadless do Ghidra pode ser substituído em Ferramentas → Ferramentas externas.
Um projeto .rgp é um JSON legível e versionado contendo a definição portátil do projeto. Artefatos grandes e mutáveis vivem em seu workspace complementar gerenciado:
example.rgp
example.rgp-work/
workspace.json
project.sqlite3
corpus/
output/
harnesses/
mutators/
analysis/
logs/
runs/
staging/
recovery/
backups/
objects/sha256/
Essa separação mantém os arquivos do projeto revisáveis e evita incorporar corpora de crashes, descobertas, índices de análise ou estado do Ghidra no JSON. workspace.json vincula o manifesto à identidade correta do workspace, enquanto project.sqlite3 armazena estado operacional/indexado. Referências gerenciadas usam workspace://; recursos explicitamente externos usam external://. Caminhos de ferramentas locais da máquina e estado da UI 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 consultiva além de verificações de conflito de revisão/SHA-256, preservam manifestos bons anteriores, publicam arquivos atomicamente com fsync e mantêm instantâneos de recuperação de crash, incluindo rascunhos ativos do editor. Harnesses gerados, mutadores, JSON do Ghidra, resultados de diff de patch e descobertas minimizadas também são publicados transacionalmente, de modo que uma substituição com falha não exclui o artefato válido anterior.
.fuzz legadosO 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.