O REA (Reverse Engineer Anything) é um servidor MCP e uma CLI que dá ao seu agente de IA, seja Claude Code, Codex, Cursor ou Gemini CLI, ferramentas para inspecionar binários nativos, apps JavaScript/Electron, assemblies .NET, APKs Android, capturas de rede e sites sem precisar do código-fonte. Serve para quem precisa entender como um software se comporta por dentro e quer que o agente devolva a conclusão junto com as evidências e as limitações. O pacote é instalado com npx rea-agents setup e roda a análise localmente.

Este post foi escrito a partir da leitura do código e da documentação do repositório morluto/rea. Não executei a ferramenta. Onde a documentação não deixa algo claro, eu aviso.

O que é o REA e para que ele serve?

Engenharia reversa é o processo de entender como um software funciona a partir do artefato compilado ou empacotado, e não do código-fonte. O REA empacota esse trabalho como um servidor MCP. MCP (Model Context Protocol) é o protocolo que permite a um agente de IA chamar ferramentas externas de forma padronizada. Se você já leu meu post sobre como criar um servidor MCP no Laravel para expor dados do seu app ao Claude, a ideia é a mesma, só que o que fica exposto aqui é um arsenal de análise de binários.

A proposta do README é direta: você vê uma funcionalidade num aplicativo, pede ao agente para investigá-la com o REA, e ele inspeciona o alvo, explica o comportamento, mostra as evidências e pode escrever uma implementação parecida para o seu projeto. As mesmas ferramentas estão disponíveis pelo terminal, com o comando rea.

Na data deste post, o repositório tem 147.756 estrelas no GitHub e licença MIT. O código é TypeScript, com pontes (bridges) em Java, Python e Swift para conversar com ferramentas externas.

Como o REA funciona por dentro?

Pela estrutura de arquivos, o REA tem quatro peças principais.

  1. Núcleo em TypeScript (pacote npm rea-agents): expõe as ferramentas MCP e os comandos da CLI. O README afirma que CLI e MCP usam os mesmos fluxos de trabalho. Existe um catálogo gerado de ferramentas (scripts/generate-mcp-tool-catalog.mjs) e um contrato de erros em JSON Schema (docs/error-contract.schema.json), o que indica que os resultados têm formato definido e não são texto livre.
  2. Bridges para motores de análise: a pasta bridge/ tem os adaptadores para cada ferramenta externa. Há bridge/ghidra/ReaGhidraBridge.java e vários scripts auxiliares do Ghidra (MIPS, DOS, NativeAOT, binários raw), bridge/hopper_bridge.py para o Hopper, bridge/android/ReaJadxBridge.java para o JADX, bridge/mitmproxy/capture.py para capturas de rede, bridge/native/rea_lldb_tracer.py para rastreamento com LLDB e scripts para pwntools e pwndbg.
  3. Providers: provider é o motor de análise nativa que o REA usa para descompilar e desmontar binários. As opções documentadas são Hopper, Ghidra e IDA. Para JavaScript estático e .NET, nenhum provider é necessário.
  4. Skill de investigação: em .agents/skills/reverse-engineer-anything/SKILL.md ficam as instruções que o agente segue, com referências separadas por tipo de alvo: android-applications.md, javascript-applications.md, native-and-artifacts.md, runtime-observation.md, evidence-workflows.md e connection-and-recovery.md. O setup instala essa skill junto com o registro do MCP.

O fluxo descrito é: o agente pergunta sobre um alvo local, o REA inspeciona e rastreia o código com as ferramentas de análise, e devolve achados com evidências, referências e pontos desconhecidos. O agente usa isso para fazer perguntas de acompanhamento, explicar o comportamento ou escrever e testar uma implementação.

Um detalhe que me chamou atenção: a pasta .github/workflows/ tem pipelines como real-ghidra-windows.yml, real-hopper.yml, real-go-binary.yml e real-web-network-captures.yml. Pelos nomes, são testes contra ferramentas e binários reais, e não só mocks. Para uma ferramenta que depende de tanto software de terceiros, é um bom sinal.

O que dá para analisar com o REA?

O REA exige Node.js 22.x (>=22.19), 24.x (>=24.11) ou 26+, além do npm. O resto depende do alvo. Selecionei da tabela do README os itens que mais aparecem no dia a dia de um dev back-end:

Alvo O que o REA retorna Requisitos
Binários nativos Pseudocódigo, assembly, strings, símbolos, chamadas e referências Hopper, Ghidra ou IDA
JavaScript / Electron Módulos, imports, source maps, rotas, IPC e add-ons nativos Node.js e npm
Assemblies .NET Metadados, instruções CIL, dependências nativas declaradas, comparação de builds Nenhum (só estático)
Capturas de rede salvas Requisições, respostas, payloads expostos e locais de origem HAR; mitmdump no Linux para capturas nativas do mitmproxy
Bancos SQLite Tabelas, colunas, índices, views, triggers e linhas selecionadas Node.js 24.x >=24.15 ou 26+
APKs Android Manifesto, classes, métodos descompilados e referências JADX headless e JDK completo
Binários Go Versão do compilador, módulos, replacements e build settings Nenhum (inspeção estática embutida)
Sites Estrutura da página, scripts, observações de rede e screenshots Navegador da família Chrome
Comportamento de processos Saída do terminal, interações, encerramento e sistema de arquivos Linux/macOS com PTY nativo

A lista completa ainda inclui WASM, bytecode EVM, crashes do Linux, dispositivos Android via adb, projetos JEB, firmware e Flutter.

Como instalar o REA?

O caminho documentado para quem usa agente é este:

  1. Garanta Node.js numa das versões suportadas e npm instalado.
  2. Rode npx rea-agents setup.
  3. Escolha os agentes, revise as alterações propostas e aprove. O setup adiciona o servidor MCP e as instruções de workflow, e faz backup da configuração existente.
  4. Reinicie o agente.

Para usar a CLI com frequência:

npm install --global rea-agents
rea --help

Para atualizar, o README recomenda rea update (instalação global via npm ou Bun) ou npx rea-agents@latest setup quando o setup foi feito via npx. O projeto avisa que muda rápido e que as releases trazem correções frequentes.

O registro manual do MCP, para clientes que o setup não cobre, fica em docs/installation.md. O conteúdo desse arquivo não estava no material que li, então não vou reproduzir o JSON de configuração. Existe também um install.sh na raiz e um scripts/print-mcp-config.mjs, mas não li o conteúdo deles.

Para análise nativa, você precisa configurar um provider antes. O setup pode instalar o Hopper se você aprovar. Ghidra e IDA precisam já estar instalados. Para binários grandes, há duas variáveis de ambiente para aumentar o tempo de inicialização: REA_GHIDRA_STARTUP_TIMEOUT_MS e REA_HOPPER_STARTUP_TIMEOUT_MS.

Exemplo de uso: entendendo um app Electron

O exemplo mais acessível é a análise estática de JavaScript/Electron, porque não depende de Hopper nem Ghidra. Pense numa ferramenta desktop interna da empresa cujo repositório se perdeu, mas cujo instalador ainda roda nas máquinas do suporte. Pelo terminal:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

O caminho pode ser um diretório extraído ou um arquivo ASAR, que é o formato de pacote que o Electron usa para empacotar o código da aplicação. Segundo o README, o resultado traz módulos, imports, os limites do Electron (main process, preload, renderer) e as evidências de cada relação.

Pelo agente, o padrão de prompt sugerido é pedir a investigação de uma funcionalidade específica, com evidências:

Investigue como a exportação de relatórios funciona neste app, mostre as evidências e liste o que ficou sem confirmação.

A parte "liste o que ficou sem confirmação" é escolha minha, mas casa com o desenho da ferramenta: os resultados incluem as limitações de cada conclusão. Num contexto de sistema financeiro, é justamente isso que separa uma hipótese de algo em que você pode confiar.

Quando vale a pena usar o REA (e quando não vale)

Vale a pena quando:

  1. Você herdou um artefato sem código-fonte: um assembly .NET de uma integração antiga, um app Electron interno, um binário Go de um serviço legado. A inspeção estática de .NET e JavaScript não executa nada, o que reduz o risco.
  2. Você precisa entender o que um SDK fechado manda pela rede: com uma captura HAR do seu próprio ambiente, o REA lista requisições, respostas e payloads expostos. É útil para auditar o que sai da sua aplicação.
  3. Você quer inspecionar um SQLite local de um app desktop ou mobile seu, sem montar ferramenta nenhuma.
  4. Você já trabalha com agentes e quer que a análise venha com rastro de evidências, em vez de o modelo "adivinhar" o comportamento a partir do nome das funções.

Não vale a pena quando:

  1. Você tem o código-fonte. Ler o código é sempre mais barato e mais confiável que descompilar.
  2. O objetivo é contornar licença, DRM ou termos de uso de software de terceiros. O próprio projeto diz que o REA é para pesquisa legal, educação, interoperabilidade, preservação e análise de software que você possui ou tem autorização para examinar.
  3. Seu ambiente é Windows e o alvo é nativo: o suporte do Ghidra no Windows está marcado como experimental na documentação.
  4. Você precisa de uma resposta auditável para compliance: pseudocódigo de descompilador é aproximação. Use como pista, não como prova final.

Cuidados antes de instalar o REA

Ferramentas, skills e servidores MCP rodam com as permissões de quem os instala. Pelo que li no repositório, estes são os pontos de atenção:

  1. O setup altera a configuração dos seus agentes. Ele registra o MCP e instala a skill, com backup e pedido de aprovação. Revise o diff antes de aceitar, como você faria com qualquer mudança no seu ambiente do Claude Code com CLAUDE.md, hooks e comandos.
  2. Captura em runtime executa o alvo. A documentação deixa claro que a inspeção estática só lê arquivos, mas a captura em runtime inicia ou interage com o alvo usando as permissões do seu usuário. Captura de processos usa PTY, a observação de sites dirige um navegador Chrome, e as ferramentas de Android via adb podem transferir arquivos e APKs para o dispositivo. Rode alvos desconhecidos numa VM ou máquina descartável.
  3. Comandos de shell e processos externos. O REA dispara Ghidra, Hopper, JADX, mitmdump, LLDB, pwntools e afins. Há também um addon nativo para Windows (native/windows/src/process.cc, filesystem.cc) que, pelos nomes, lida com processos e sistema de arquivos. É o esperado para a função, mas significa acesso amplo à máquina.
  4. A análise é local, mas o resultado vai para o modelo. O FAQ é honesto: o REA não faz upload do app, mas o agente recebe os resultados, e o provedor do modelo tem a própria política de dados. Strings, payloads de HAR e linhas de SQLite podem conter dados pessoais ou tokens. Se houver dado de cliente, isso é assunto de LGPD.
  5. Conteúdo do alvo vira contexto do agente. Strings embutidas num binário ou num bundle JavaScript entram no contexto do LLM. Um artefato malicioso pode carregar texto pensado para manipular o agente. Essa é uma inferência minha, não algo que a documentação trate, e é o mesmo problema que discuti em prompt injection e LGPD em agentes de IA no Laravel. Não deixe o agente com permissão de escrita ampla enquanto ele analisa algo que você não controla.
  6. Variáveis de ambiente. As documentadas são REA_GHIDRA_STARTUP_TIMEOUT_MS, REA_HOPPER_STARTUP_TIMEOUT_MS e REA_JEB_MCP_URL. A última aponta o REA para um cliente JEB servindo MCP, ou seja, uma conexão com outro serviço local que você mesmo sobe.
  7. Versão fixada. Os exemplos usam npx rea-agents@latest, que sempre baixa a última versão publicada. É prático, mas numa máquina de trabalho eu prefiro instalar uma versão específica e atualizar de forma consciente.
  8. Licenças de ferramentas comerciais. IDA, Hopper e JEB têm licenças próprias. O README avisa que o REA não concede licença nenhuma e que trials continuam sujeitos aos termos do fornecedor, inclusive restrições de automação.

Conclusão prática

Se o seu problema é entender um artefato que você tem direito de examinar e cujo código não está à mão, o REA parece uma das formas mais organizadas de colocar um agente nesse trabalho, porque devolve evidências e limitações, e não só uma narrativa. Eu começaria pelo que não executa nada: analyze-javascript-application num app Electron interno, ou a inspeção de um assembly .NET ou de um HAR do seu próprio ambiente. Faça isso numa máquina sem credenciais de produção, revise o diff do setup e trate pseudocódigo como hipótese a validar com teste. Deixe a análise nativa com Ghidra ou Hopper e a captura em runtime para quando a análise estática não bastar, e aí já dentro de uma VM.