# REA: o que é e como usar o MCP de engenharia reversa com Claude Code

> O REA é um servidor MCP e CLI que dá ao seu agente ferramentas para inspecionar binários, apps Electron, .NET, APKs e capturas de rede, sempre com evidências e limitações.

Por Lucas Roberto · Open source · publicado em 2026-10-13 · 11 min de leitura
Versão web: https://lucasroberto.com/blog/rea-o-que-e-e-como-usar-o-mcp-de-engenharia-reversa-com-claude-code

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](https://github.com/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](/blog/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:

```bash
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:

```bash
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:

```text
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](/blog/como-configurar-o-claude-code-em-projetos-laravel-claudemd-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](/blog/prompt-injection-e-lgpd-em-agentes-de-ia-no-laravel-como-proteger-dados-e-acoes). 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.

---

Lucas Roberto é desenvolvedor back-end e fundador da Granpag. Mais textos: https://lucasroberto.com/blog