REA ou Ghidra, IDA e Hopper na mão: o que muda quando um MCP entra no meio da engenharia reversa?

O REA não descompila nada sozinho

Ele coloca um agente de IA para conduzir o Ghidra, o IDA ou o Hopper que já está instalado na sua máquina, e é isso que muda o jogo (ou não, dependendo de quem tu é)

Fala aí, beleza? O REA (Reverse Engineer Anything) é um servidor MCP local, com licença MIT, distribuído pelo npm como rea-agents, e entrou no GitHub Trending no início de outubro de 2026

A dúvida real é outra: vale trocar a condução manual do disassembler pela orquestração de um agente? Bora destrinchar isso com critério, sem hype 🙂

O que o REA faz (e o que ele não faz) na engenharia reversa

O REA é um conector MCP, não um motor novo de engenharia reversa

Quem descompila continua sendo o Ghidra, o Hopper ou o IDA: o REA só liga o agente de IA a essas ferramentas

Se você conhece um driver de banco de dados, é bem semelhante: o driver não guarda dado nenhum, ele só deixa a aplicação conversar com o banco

Na prática, o agente pede a análise por meio de um servidor local, segue o código relevante e recebe as conclusões junto com as evidências e os limites declarados

O que o agente enxerga via REA

Para executáveis e bibliotecas nativas, o REA expõe:

• pseudocódigo
• instruções assembly
• strings
• símbolos
• chamadas
• referências

Além dos binários nativos, ele também cobre apps JavaScript/Electron, assemblies .NET e sites, inclusive usando o Chrome DevTools para apps web e Electron

Quais agentes funcionam com o REA?

O setup configura Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros

Qualquer agente com suporte a servidores MCP locais pode usar o REA, e os clientes que o setup não configura usam o registro manual do MCP

Tome cuidado com os forks

Existem forks e cópias com o mesmo nome, por exemplo rea-githu/REA, que oferece um ‘zip para Windows’

A referência oficial é o repositório morluto/rea, mantido pelo desenvolvedor morluto

Em ferramenta que mexe com binário e roda na sua máquina, baixar zip de repositório aleatório é pedir pra ter dor de cabeça

Ferramenta nativa vs. agente via REA: controle, velocidade e rastreabilidade

A diferença central é quem conduz a análise: na ferramenta nativa é você, passo a passo; com o REA, o agente navega e você revisa o que ele concluiu

Critério	Ghidra, IDA ou Hopper na mão	Agente via REA
Quem conduz	Você, em cada clique e cada renomeação	O agente, a partir do que você pede
Controle por passo	Total	Indireto, você revisa as conclusões
Rastreabilidade	Anotações e comentários que você faz na ferramenta	Resultado + evidence_id + registro completo da evidência
Onde roda	Local	Local
Instalação	Só a ferramenta nativa	Ferramenta nativa + Node.js, npm e o REA
Maturidade por backend	A da própria ferramenta	Varia: IDA com suporte parcialmente verificado
Velocidade	Depende da sua experiência com o binário	Sem benchmark público comparando

Controle

Na mão, cada decisão é sua: qual função abrir, o que renomear, qual referência seguir

Com o REA, o agente escolhe o caminho e você controla pelo pedido e pela revisão, então o controle existe, mas é um degrau acima

Velocidade

Não existe benchmark público de velocidade ou precisão do REA contra a análise manual, então qualquer número aqui seria achismo

O que dá pra dizer com segurança é qualitativo: o agente tira de você o trabalho repetitivo de navegar por strings, símbolos e chamadas, e o ganho real depende do quanto você já é rápido nisso

Rastreabilidade

Esse é o ponto MAIS forte do REA

As ferramentas que produzem evidência devolvem três coisas juntas: o resultado, um evidence_id e o registro completo da evidência

Na ferramenta nativa, a rastreabilidade depende da sua disciplina em anotar tudo, e todo mundo sabe como isso termina numa sexta à noite haha

Onde roda e dependências

Nos dois casos a análise roda localmente, o binário não precisa sair da sua máquina para a descompilação

A diferença é a pilha: com o REA você soma Node.js, npm e o próprio REA em cima da ferramenta nativa, que continua obrigatória

Ghidra, IDA e Hopper com o REA: requisitos e limites de cada backend

A análise nativa usa uma instalação existente de Hopper, Ghidra ou IDA, e o REA não substitui nem inclui o IDA ou o Ghidra

Então a primeira pergunta não é ‘qual agente uso?’, é ‘qual backend funciona na minha plataforma?’

Ghidra com o REA

O Ghidra foi liberado pela NSA em 2019 sob licença Apache 2.0, é gratuito e roda em Windows, macOS e Linux

Porém, o requisito do backend Ghidra no REA é mais restrito: Ghidra 12.1.x já instalado, JDK de 64 bits 21 ou mais novo, em Linux ou macOS, x64 ou arm64

Ou seja, o fato do Ghidra rodar no Windows não quer dizer que o fluxo via REA esteja coberto lá

IDA com o REA

Desde 1º de outubro de 2024, a Hex-Rays usa licenciamento por assinatura anual em todos os produtos, e o IDA para de funcionar 30 dias depois do vencimento se a assinatura não for renovada

No REA, o suporte a IDA é parcialmente verificado: os fluxos reais iniciais cobrem Windows GUI e IDA 9.3 headless em Windows x64, e as demais combinações de engine e plataforma continuam sem verificação

Caso o headless reclame do caminho: pode ser preciso definir IDADIR com o caminho absoluto do IDA, se a instalação do idalib exigir

Hopper com o REA

O Hopper Disassembler é proprietário, com licença perpétua de pagamento único, e roda em macOS e Linux (não tem versão para Windows)

No macOS, o setup do REA pode instalar o Hopper em ~/Applications depois da sua aprovação, verificando o download oficial e sem precisar de Homebrew nem de privilégios de administrador

Nada é instalado sem você aprovar, o que é um detalhe bem massa pra quem tem medo de setup que sai fazendo coisa por conta própria

Quando faz sentido deixar o agente orquestrar a análise

Faz sentido quando o trabalho é navegar muito e decidir pouco, e quando você precisa provar de onde saiu cada conclusão

Cenários onde o agente ajuda

• Triagem inicial de um binário: levantar strings, símbolos e chamadas para entender o que aquilo faz antes de abrir função por função
• Seguir referências até o trecho relevante: o agente vai puxando as referências até chegar no código que importa para a sua pergunta
• Apps Electron e assemblies .NET: alvos que o REA cobre além dos binários nativos, incluindo o Chrome DevTools para apps web e Electron
• Documentar com evidência: cada conclusão chega com evidence_id e o registro completo, o que facilita relatório e revisão por outra pessoa

Quando continuar na mão

• Decisões finas: quando cada renomeação, cada tipo e cada hipótese precisam passar pela sua cabeça, o controle passo a passo da ferramenta nativa ganha
• Plataformas sem suporte verificado: IDA fora do Windows e Ghidra no Windows via REA não estão entre as combinações verificadas na documentação
• Quando a ferramenta por trás já é o gargalo: o REA herda o que o backend entrega, então ele não resolve um caso que o próprio disassembler não resolve

Veredito: REA para quem domina disassembler e para quem não domina

Pra quem domina, o REA é um acelerador de triagem com rastreabilidade de brinde

Pra quem não domina, ele baixa a barreira de entrada, mas não dispensa ler as evidências

Se você já domina Ghidra, IDA ou Hopper

Use o REA como camada de triagem e de registro: deixe o agente varrer strings, símbolos e chamadas e devolver as conclusões

Aí você pega o evidence_id, confere na ferramenta nativa e mantém o controle total onde a análise realmente importa

É tipo ter um estagiário muito rápido que anota tudo, mas que você ainda revisa antes de assinar embaixo

Se você não domina disassembler

O agente tira de você o trabalho de saber onde clicar e como navegar pelo binário, e isso é MUITO

Porém, o resultado só é confiável se você ler as evidências e os limites declarados que vêm junto com cada conclusão

E a parte chata continua: instalar um backend suportado na sua plataforma e cumprir os requisitos do REA, que são Node.js 22.x (>=22.19), 24.x (>=24.11) ou 26+, mais npm

Limitação que vale para os dois perfis

O REA herda a qualidade e as restrições da ferramenta por trás

Se o pseudocódigo do backend sai confuso, a conclusão do agente vai partir dessa mesma base, então nada de tratar a resposta como verdade absoluta

Vídeo: o REA explicado na prática

No vídeo abaixo eu explico na prática como o REA funciona como servidor MCP, ligando o agente de IA ao Ghidra, ao IDA ou ao Hopper que já está na sua máquina

Próximo passo: testar o REA sem mexer no seu fluxo atual

O jeito mais seguro é instalar o REA ao lado do que você já usa e comparar uma conclusão do agente com a mesma checagem feita na mão

1. Confira a versão do Node.js: precisa ser 22.x (>=22.19), 24.x (>=24.11) ou 26+, com npm instalado

node --version
npm --version

O erro comum aqui é ter um Node 22 antigo, abaixo do 22.19, e achar que está tudo certo só porque começa com 22

2. Garanta um backend suportado na sua plataforma: Ghidra 12.1.x com JDK 64 bits 21+ em Linux ou macOS, IDA nas combinações verificadas em Windows, ou Hopper

O erro comum deste passo é assumir que o REA traz o disassembler junto, e ele não traz

3. Rode o setup, sempre a partir do pacote oficial ligado ao repositório morluto/rea

npx rea-agents setup

No setup você escolhe os agentes, revisa as mudanças propostas e aprova

Ele adiciona o servidor MCP do REA e as instruções de fluxo, fazendo backup da configuração existente, mas leia o que vai mudar antes de aprovar, beleza?

4. Faça a prova real: peça ao agente uma conclusão simples sobre um binário que você conhece, pegue o evidence_id e confira o mesmo trecho direto no Ghidra, IDA ou Hopper

Se bater, você ganhou um acelerador confiável

Se não bater, você descobriu exatamente onde não dá pra delegar 😉

E aí, vai deixar o agente conduzir ou continua no clique a clique? Bora trocar uma ideia

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.