A análise do REA é mesmo local? O que roda na sua máquina e o que chega ao agente

A análise do REA roda na sua máquina, mas isso não quer dizer que nada sai dela

Fala aí, beleza? Se você anda vendo agente de código fazendo engenharia reversa de app por aí, provavelmente já esbarrou no REA (Reverse Engineer Anything)

Ele é uma CLI e um servidor MCP de código aberto, publicado por morluto sob licença MIT, que deixa agentes como o Claude Code investigarem software sem ter o código-fonte

Aí vem a pergunta que importa pra quem mexe com binário de cliente, firmware de parceiro ou app coberto por acordo de confidencialidade (NDA): essa análise é local mesmo?

A resposta curta é sim, com um asterisco bem grande. Bora destrinchar isso 🙂

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Como o REA funciona: agente, servidor MCP local e ferramentas de análise

Antes do como, o porquê: um agente de código sozinho não sabe abrir um binário e entender o que tem lá dentro

Ele precisa de ferramentas, e é aí que entra o MCP

Que MCP? É o protocolo que deixa o agente conversar com ferramentas externas. Se você já usa algum servidor MCP no Claude Code, a ideia é bem semelhante: o agente chama, o servidor executa e devolve o resultado

No REA o fluxo fica assim:

• O agente pede uma análise para um servidor MCP local
• As ferramentas inspecionam o alvo
• O agente segue o código relevante até entender o que está acontecendo
• O agente recebe as descobertas com a evidência e as limitações declaradas por trás de cada conclusão

O projeto organiza a investigação em três etapas:

1. Decompilar: recuperar código legível, strings e nomes (se liga: isso é uma reconstrução pra leitura e análise, não o código-fonte original do app, falo mais disso lá embaixo)
2. Entender: seguir o código até explicar a funcionalidade
3. Recriar: transformar o aprendizado em funcionalidade adaptada à sua stack

Quais formatos o REA inspeciona?

A lista é bem ampla, por isso o nome Reverse Engineer Anything haha

• Binários nativos
• Apps JavaScript e Electron
• Assemblies .NET
• APKs Android
• Módulos WebAssembly
• Firmware
• Sites

O que roda na sua máquina durante a inspeção?

O README do projeto é direto: a análise roda no seu host local suportado e o REA não faz upload do app para um serviço de análise hospedado

Ou seja, o arquivo em si fica com você

O trabalho pesado acontece em ferramentas que estão na sua máquina:

• Análise nativa pode usar uma instalação existente de Hopper, Ghidra ou IDA. O setup pode instalar o Hopper mediante sua aprovação, já Ghidra e IDA precisam estar instalados antes
• Inspeção estática de JavaScript e .NET funciona sem nenhum motor de análise nativa
• Análise nativa profunda via Hopper e dossiês de funções completos, que o projeto lista entre os recursos atuais. O README não detalha se Ghidra e IDA chegam nesse mesmo nível, então não conte com isso sem conferir
• Captura controlada de processos
• Registros Evidence v2: pacotes de evidência reproduzíveis que dá pra importar, exportar e comparar

Tome cuidado com um detalhe: os formatos nativos e os sistemas host suportados variam conforme o provedor de análise, e o suporte ao Ghidra no Windows é experimental

Então antes de contar com um motor específico, confere no README se a combinação do seu sistema com a ferramenta está coberta

O que chega ao agente e ao provedor de modelo?

Aqui está o asterisco 👀

A análise é local, mas os resultados vão para o provedor de modelo do seu agente

Faz sentido, né? O agente precisa ler as descobertas pra raciocinar sobre elas, e quem faz esse raciocínio é o modelo, que normalmente está do lado do provedor

Na prática, o que sai da máquina é o que o REA devolve ao agente: descobertas, evidências e limitações

O que as fontes não detalham: quais trechos exatos viajam em cada chamada, qual o volume e qual política de retenção o provedor aplica a esse conteúdo

Por isso a postura segura é simples: trate tudo o que o REA entrega ao agente como dado que deixa a sua máquina

Essa mesma confusão entre local e nada sai aparece em outras ferramentas, tipo na discussão sobre o que é local-first de verdade no OpenDesign

O que muda para quem lida com binário sob acordo de confidencialidade?

Vamos ao ponto da decisão

O lado bom: o binário não vai pra um serviço hospedado do REA. Isso já reduz bastante a exposição em comparação com subir o arquivo inteiro pra algum site de análise

O lado que exige atenção: evidência derivada desse binário (strings, nomes, trechos recuperados, explicações de comportamento) chega ao provedor de modelo do agente

Antes de rodar em material sob NDA, se faz estas perguntas:

• O acordo cobre o envio de trechos ou descobertas derivadas do software a terceiros?
• Qual provedor de modelo o seu agente usa hoje?
• A política desse provedor é compatível com o que o contrato exige?
• Você tem autorização clara pra inspecionar esse software?

Sobre essa última, se liga: o próprio projeto avisa que não garante que uma recriação seja completa, idêntica ou autorizada

Se uma inspeção ou recriação é permitida depende do software e das circunstâncias, e a capacidade técnica do REA não responde essa pergunta. Essa responsabilidade é de quem usa

E isso aqui não é aconselhamento jurídico, beleza? Na dúvida sobre o contrato, quem responde é o jurídico da sua empresa ou do cliente

Quando a análise local do REA faz sentido (e quando repensar)?

Faz sentido quando:

• Você quer entender o comportamento de um app seu, ou de um software com permissão clara pra inspecionar
• Você precisa comparar versões de um mesmo alvo, aproveitando que os registros Evidence v2 podem ser exportados, importados e comparados
• O alvo é JavaScript, Electron ou .NET e você não quer instalar Hopper, Ghidra ou IDA só pra isso

Vale repensar quando:

• O acordo proíbe compartilhar qualquer informação derivada do software com terceiros
• Você não sabe qual provedor o agente usa nem como ele trata os dados
• A expectativa é recuperar o código original ou sair com um clone pronto

Sobre esse último ponto: o REA não afirma recuperar o código-fonte original nem clonar um app automaticamente

Aquele código legível da etapa de decompilar é material pra você ler e entender, não o fonte que o desenvolvedor escreveu

A saída é evidência pra entender comportamento. Nada de next, next e finish e o app do concorrente aparece no seu repo xD

O que você precisa para rodar o REA localmente?

• Node.js 22.x (>=22.19), 24.x (>=24.11) ou 26+, junto com o npm
• Motor de análise nativa (opcional, depende do formato): Hopper, Ghidra ou IDA. Pra JavaScript e .NET estáticos não precisa
• Agente com suporte a servidor MCP local: o setup configura Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros. Clientes fora dessa lista podem fazer o registro MCP manual

Como instalar e registrar o REA no seu agente?

São poucos passos, bora lá

Os passos abaixo são os mesmos do README pra qualquer agente que o setup configura, Claude Code incluso

1. Instale o pacote globalmente:

npm install --global rea-agents

Erro comum deste passo: usar uma versão do Node fora das faixas suportadas. Confere com node --version antes de instalar

2. Rode o setup, que registra o servidor MCP do REA e instala as instruções correspondentes:

npx rea-agents setup

Se o setup oferecer instalar o Hopper, ele pede sua aprovação. Ghidra e IDA não são instalados por ele, então precisam estar na máquina antes

3. Reinicie o agente

Erro comum deste passo: esquecer de reiniciar. Sem isso o agente não enxerga o servidor MCP recém registrado, e parece que nada foi instalado. Já vi muita gente perder tempo caçando bug que era só isso haha

Conclusão: vale usar o REA se confidencialidade importa?

O veredito honesto é: depende do seu acordo e do provedor do seu agente

A análise local do REA reduz bastante a exposição do binário, porque o arquivo não vai pra um serviço hospedado

Porém, as descobertas, evidências e limitações seguem pro provedor de modelo, e é isso que precisa caber no seu contrato

O caminho mais seguro é fazer três coisas, nessa ordem: revisar o contrato e a política do provedor que o agente usa, instalar o REA seguindo o repositório oficial em github.com/morluto/rea e testar primeiro num alvo que você tem autorização clara pra inspecionar

Feito isso, dá pra decidir com calma se ele entra no seu fluxo de trabalho 😀

Até o próximo post!