REA em CTF e pesquisa de segurança: onde um MCP de engenharia reversa encaixa no seu fluxo

Fala aí, beleza? Se tu já resolve desafio de reverse na mão, sabe que boa parte do tempo vai embora no vai e vem entre decompilador, terminal e anotações

E é exatamente nesse vai e vem que um agente pode entrar 🙂

O REA (Reverse Engineer Anything) é um toolkit open source que conecta agentes de código a ferramentas de análise via MCP

Que MCP? É o protocolo que deixa o agente chamar ferramentas externas, em vez de ficar só no chute em cima do texto que você cola no chat

Neste post eu te mostro onde o REA encaixa no fluxo de CTF e pesquisa de segurança, categoria por categoria

E já deixo claro desde o começo: a ideia aqui NÃO é prometer que o agente resolve o desafio sozinho, beleza?

REA em vídeo

Também gravei um vídeo sobre o REA no canal Hora de Codar. Dê o play abaixo ou assista no YouTube.

O que é o REA e por que ele chamou atenção da comunidade de segurança

O REA é um toolkit de engenharia reversa publicado por morluto no GitHub, no repositório morluto/rea

Ele é open source, sob licença MIT, gratuito e roda localmente na sua máquina

O projeto é escrito em TypeScript, e os mesmos fluxos rodam de dois jeitos: via MCP (pelo seu agente) e via CLI (direto no terminal)

Ou seja, se tu prefere scriptar na mão em vez de conversar com agente, também dá 😀

Um detalhe massa pra quem lê melhor em português: o repositório tem um README em PT-BR, o README_pt-BR.md

Sobre a repercussão: o REA apareceu no topo do GitHub Trending em outubro de 2026

E não foi só hype, gerou debate de verdade na comunidade sobre segurança de software e propriedade intelectual

Faz sentido, né? Uma ferramenta que facilita abrir qualquer coisa também facilita abrir o que não devia ser aberto… volto nesse ponto no veredito

Alvos de CTF que o REA analisa e o que cada um devolve

Aqui tá o mapa que interessa pra quem joga CTF: o tipo de alvo, o que o REA devolve e o que precisa estar instalado

Uma nota importante: a análise estática de JavaScript não precisa de motor nativo

O README ainda lista outros alvos, como assemblies .NET, módulos WebAssembly, apps Electron, bancos SQLite, capturas de rede salvas e sites

O detalhe de cada um tá no README do repositório, vale dar uma olhada antes de partir pra esses alvos

Como usar um MCP de engenharia reversa em cada categoria de CTF

Antes de entrar nas categorias, se liga: o foco aqui é ONDE o agente entra no raciocínio de cada tipo de desafio

Porque saber pedir a coisa certa vale mais do que decorar comando, beleza?

Rev de binário nativo: achando a função de verificação

No rev clássico, o trabalho chato é achar onde o binário compara o input com a flag

Aqui o agente brilha no cruzamento: tu pede pra ele juntar strings, símbolos e referências com o pseudocódigo e apontar a provável função de verificação

Algo como: cruza as strings de mensagem de sucesso e erro com as referências e me diz qual função decide o caminho

Depois disso, a validação é tua: abre a função no assembly e confere se a lógica bate com o que o agente descreveu

Pseudocódigo de decompilador às vezes simplifica coisa que importa, então Tome cuidado com confiar só nele!

Pwn: começando pelo layout ELF e pelas mitigações

Em pwn, a primeira pergunta nunca é como explorar, é o que está ligado nesse binário?

O REA faz a checagem de layout ELF e mitigações via pwntools, e o pwntools é quem traz o utilitário checksec

As mitigações típicas que um checksec verifica são estas:

• RELRO: protege a GOT contra sobrescrita (no modo completo, ela fica somente leitura)
• Stack Canary: um valor na pilha que denuncia o overflow antes do retorno da função
• NX: impede executar código em regiões de dados, como a pilha
• PIE: o binário é carregado em endereço base aleatório
• ASLR: randomiza endereços de pilha, heap e bibliotecas
• Fortify Source: troca funções perigosas por versões com checagem de tamanho

Por que isso define a estratégia? Porque cada combinação fecha uma porta e deixa outra aberta

Com NX ligado, shellcode na pilha já era, e tu parte pra ROP

Com PIE, tu vai precisar de um leak antes de montar qualquer cadeia, e por aí vai

Então o agente te entrega o cenário, e a decisão da técnica continua sendo tua 🙂

Crash gravado: triagem a partir de registradores e sinais

Pra crash Linux gravado, o REA devolve notas brutas, registradores e sinais de todas as threads gravadas, além de candidatos de mapeamento opcionais

Usar GDB ou pwndbg aqui é opcional

Esse material é o ponto de partida da triagem: qual sinal derrubou o processo, em qual thread, e o que estava nos registradores naquele momento

Se o ponteiro de instrução tá apontando pra lixo que parece vindo do teu input, já é uma pista forte de controle de fluxo, né?

Lembrando que esse fluxo é voltado pra crashes Linux gravados

Blockchain e EVM: mapeando um contrato sem código fonte

Desafio de smart contract sem fonte publicado é aquele bytecode gigante que ninguém quer ler na mão haha

O REA devolve seletores de dispatch, offsets de byte, argumentos inferidos e mutabilidade

Com isso tu monta o mapa das funções do contrato: quais existem, onde começam no bytecode, o que recebem e se alteram estado

A palavra-chave aqui é inferidos: argumento inferido é hipótese, então confere antes de montar a transação do exploit

Firmware e IoT: extração antes do mergulho

Em firmware, não adianta abrir o blob inteiro no decompilador e rezar

O caminho é extrair primeiro, e o REA devolve as regiões e os resultados de extração

Pra isso ele exige Binwalk ou Unblob, no Linux

Com as regiões separadas, aí sim tu escolhe qual binário extraído merece a análise nativa

Mobile: manifest e métodos decompilados de APK

Em desafio Android, o manifest costuma ser o primeiro lugar a olhar: activities expostas, permissões, componentes exportados

O REA devolve o manifest, os métodos decompilados, logs e capturas de tela

Isso exige JADX mais um JDK, e o adb pra parte do dispositivo

O combo de método decompilado com log do app rodando ajuda a ligar o que o código diz com o que realmente acontece em execução

Evidência junto da conclusão: por que isso importa para quem faz reverse

Se liga nisso, porque pra mim é a parte mais importante do projeto

O REA devolve cada descoberta acompanhada da evidência e das limitações por trás da conclusão

Isso vem em registros reproduzíveis Evidence v2 e em dossiês completos de função

Por que isso importa tanto? Porque em segurança, conclusão sem prova é palpite

Agente de IA é ótimo em soar confiante, e um esta função valida a flag dito com convicção pode estar simplesmente errado

Quando a evidência vem junto, tu consegue fazer o que todo reverser faz: conferir

O papel do humano no loop fica bem definido:

• Ler a evidência que o agente apresentou
• Abrir o mesmo ponto no motor de análise (Ghidra, IDA Pro ou Hopper)
• Só então escrever o exploit ou submeter a flag

É o mesmo princípio da revisão humana no fluxo de segurança: a IA acelera, mas a assinatura final é tua

E tem um bônus: as limitações declaradas te dizem onde NÃO confiar, o que vale MUITO quando o desafio tem ofuscação ou anti-debug

O que você precisa antes de colocar o REA no seu agente

A lista é enxuta, e o melhor: tu só instala o que o teu tipo de desafio usa

• Node.js e npm: base pra rodar o setup
• Um agente suportado: Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros
• Um motor nativo, se for analisar binário: Ghidra, IDA Pro ou Hopper já instalado (o setup pode instalar o Hopper opcionalmente, com a tua aprovação)
• Dependências por alvo: pwntools pra ELF e mitigações, GDB/pwndbg (opcional) pra crash gravado, Binwalk ou Unblob no Linux pra firmware, JADX + JDK e adb pra Android

Vai jogar só categoria de mobile? Não precisa sair instalando Binwalk

Vai focar em JavaScript? A análise estática nem pede motor nativo

Nada de montar um PC da Nasa de ferramentas antes da hora 😛

Como instalar o REA no Claude Code e em outros agentes

O setup é o mesmo pra Claude Code e pros outros agentes suportados, bora ver

1. Com Node.js e npm instalados, rode o setup:

npx rea-agents setup

2. Escolha os agentes onde quer o REA (Claude Code, Codex, Cursor, Gemini CLI, Grok Build ou outro suportado)

3. Revise as mudanças propostas e aprove

Nesse passo, o setup adiciona o servidor MCP do REA e as instruções de fluxo correspondentes (a skill de roteamento), fazendo backup da configuração existente

Erro comum deste passo: aprovar sem ler o que muda na configuração do agente

O backup existe, mas revisar é justamente o motivo de o setup pedir aprovação, então lê antes de sair no next, next e finish haha

Se tu prefere ter a CLI instalada globalmente, a alternativa é esta:

npm install --global rea-agents && rea setup

Erro comum depois da instalação: esperar análise de binário nativo sem ter um motor instalado

Sem Ghidra, IDA Pro ou Hopper, não tem pseudocódigo nem assembly, então confere isso antes de abrir o primeiro desafio de rev

Vale colocar um agente no loop de reverse engineering?

Veredito honesto, e sem experiência própria pra te vender: pelo que o projeto entrega, faz sentido pra quem JÁ resolve desafios na mão

O ganho tá na triagem, no cruzamento de strings, símbolos e referências e na documentação do raciocínio, que vem junto com a evidência

O que ele não faz: substituir saber ler assembly nem decidir a estratégia de exploração

Se tu não entende por que PIE muda o plano, o agente vai te entregar o dado e tu não vai saber o que fazer com ele

Pra quem tá começando em CTF, o risco é real: terceirizar o aprendizado

CTF é treino, e pular a parte de sofrer em cima do binário é pular justamente o que te deixa bom nisso

Outro ponto que não dá pra ignorar: use o REA só em alvos que você tem autorização pra analisar

Desafio de CTF, binário teu, pesquisa com escopo autorizado, beleza

Software de terceiros sem permissão entra exatamente no debate sobre propriedade intelectual que o lançamento levantou

E se o teu interesse vai mais pra análise de ameaças, vale ver também como a IA se sai em engenharia reversa de malware, que tem outras armadilhas

Próximo passo: teste o REA no próximo desafio que você já sabe resolver

Recapitulando: o REA conecta teu agente a Ghidra, IDA Pro, Hopper, pwntools, GDB/pwndbg, Binwalk, Unblob, JADX e adb, via MCP ou CLI

Ele cobre binário nativo, ELF e mitigações, crash Linux gravado, EVM, firmware e Android, sempre com evidência e limitações junto da conclusão

Minha sugestão de teste é simples: roda o npx rea-agents setup e aplica o agente num desafio que tu JÁ resolveu na mão

Aí compara a evidência que ele devolve com o caminho que tu fez

Se ele chegou no mesmo lugar e mais rápido, massa, tu ganhou um parceiro de triagem

Se errou, tu descobriu onde não confiar nele, o que também vale muiiito 😀

Pra qualquer dúvida de configuração, a referência oficial é o README_pt-BR.md no repositório

Até o próximo post!