O REA não é um decompilador novo. É um servidor MCP (Model Context Protocol, o padrão aberto que conecta agentes de IA a ferramentas externas) que dá ao seu agente de código acesso a ferramentas de engenharia reversa já consolidadas, como Ghidra e Hopper, com toda a análise rodando na sua máquina. O projeto, publicado no GitHub como morluto/rea (abre em nova aba), tem licença MIT, é escrito em TypeScript e é distribuído no npm (abre em nova aba) como rea-agents, em duas formas: uma CLI (rea) para o terminal e um servidor MCP que agentes como Claude Code, Cursor, Codex, Gemini CLI, Windsurf e Claude Desktop podem chamar diretamente.
A premissa comercial é simples: você vê uma funcionalidade num app fechado, não tem o código-fonte, e quer entender como ela funciona a ponto de reconstruí-la no seu produto. O exemplo que abre o site oficial é um clássico de calculadora: por que 200 + 10% dá 220 e não 210? A resposta, decompilando o binário instalado, é que o botão de porcentagem calcula o percentual sobre o primeiro número depois da soma. O REA existe para que o seu agente encontre essa regra sozinho, com evidência, e a reimplemente.
A página do repositório registra mais de 80 mil stars e 17,6 mil forks, com mais de 2.200 commits. Diretórios de terceiros citam números bem maiores, na casa dos 125 mil stars, o que sugere capturas feitas em datas diferentes; a contagem da página oficial do GitHub é o dado mais estável. Cobertura independente de outubro de 2026 o descreveu como projeto em alta no GitHub naquele mês. Números virais à parte, o que interessa aqui é o contrato técnico: o que o REA entrega, o que ele pede da sua máquina e como conferir que a investigação produziu algo verificável, e não alucinação bem escrita.
O que o REA realmente faz
O fluxo do REA se resume a três etapas: decompilar, entender, recriar. Na decompilação, a ferramenta abre o app e recupera código legível, strings, nomes de símbolos e outras pistas. No entendimento, o agente segue o código de uma parte do aplicativo a outra até conseguir explicar como a funcionalidade funciona. Na recriação, ele transforma o aprendido em código no seu projeto, na sua linguagem e no seu framework. Esse ciclo é agnóstico quanto ao alvo: binários nativos, apps Electron, assemblies .NET, sites e APKs Android estão entre os tipos documentados.
Por baixo, o REA não executa mágica própria. Quando o agente pede uma decompilação, o servidor MCP roteia a requisição para ferramentas como Ghidra, Hopper, IDA ou JADX, e para Chrome DevTools quando o alvo é web ou Electron. Ghidra foi lançada pela NSA em 2019, Hopper existe desde 2011 e IDA desde os anos 1990. Como aponta uma análise prática publicada no MindStudio (abre em nova aba), o REA é um conector que dá interface agêntica a ferramentas maduras, não uma tecnologia nova de decompilação. A diferença prática é que o agente não precisa operar a CLI de cada ferramenta nem gerenciar sessões específicas: o REA traduz tudo para um catálogo único. A cobertura técnica sobre o projeto fala em mais de 120 ferramentas MCP expostas por esse caminho.
Duas decisões de arquitetura separam o REA de simplesmente jogar um binário no contexto do modelo. A primeira é local-first: binários nunca são enviados a APIs de nuvem, decompilação e rastreamento acontecem na sua máquina. A segunda é o Evidence Bundle, um pacote de evidência que acompanha cada conclusão do agente, com offsets exatos de arquivo, instruções de assembly, cross-references (xrefs, a lista de posições de código que referenciam um símbolo) e source maps recuperados. Em vez de despejar meio milhão de linhas de assembly no contexto, o REA fatia o alvo em escopos pequenos por consultas de travessia. O resultado esperado é um agente que conclui menos por indução estatística e mais por verificação.
Tão importante quanto saber o que ele faz é saber o que ele não promete. O REA não recupera o código-fonte original e não clona apps: o que sai é pseudocódigo, assembly, símbolos, strings e relações entre funções, com a evidência atrás de cada conclusão. O objetivo é que o agente entenda uma funcionalidade bem o suficiente para explicá-la, modificá-la ou reconstruí-la de forma independente, não que ele recupere o artefato original.
Pré-requisitos para rodar o REA
A exigência de Node.js 22 ou mais recente vem do próprio repositório. Se a sua máquina ainda roda uma versão LTS anterior, atualize antes de instalar; o npx vai usar o que estiver no PATH.
O ponto de custo que costuma surpreender não é o REA em si, que é gratuito sob MIT. São duas fontes de gasto indireto. A primeira é o modelo: a investigação consome contexto do seu agente, então o custo aparece na fatura do Claude, do Cursor ou de quem quer que você use, proporcional ao tamanho do alvo. A segunda é o Hopper, um dos disassemblers integrados.
Sobre sistema operacional, vale saber antes de escolher o alvo: o suporte do REA ao Ghidra no Windows é descrito como experimental, então a análise de binários nativos do Windows é o terreno menos estável. Para alvos JavaScript, Electron e web, a plataforma da sua máquina pesa menos. E um detalhe prático para quem trabalha com documentação: o README oficial tem tradução em português do Brasil, além de mais de uma dúzia de outros idiomas.
Passo a passo: instalação e primeira investigação
O fluxo de instalação documentado no site oficial é curto e tem um ponto de controle deliberado: o agente mostra o plano antes de executar.
- Abra o terminal no diretório do seu projeto e execute o setup. Comando do site oficial:
npx rea-agents@latest setup. Sinal de sucesso: o comando inicia e o agente apresenta um plano de configuração para aprovação, não executa nada sem você aprovar. Alternativa igualmente documentada: colar no próprio agente o prompt pronto do site, que pede a instalação comnpx rea-agents@latest setup, o plano para aprovação e a verificação da instalação.
- Aprove o plano depois de lê-lo. O plano mostra o que será instalado e como o agente será conectado. Sinal verificável: o agente confirma cada etapa antes de rodá-la.
- Reinicie o agente. A instrução oficial é literal: aprove o plano e reinicie o agente. Sinal de sucesso: depois do restart, o agente reconhece as ferramentas do REA quando você as menciona.
- Peça ao agente que verifique a instalação, pedindo por exemplo que liste as ferramentas do REA disponíveis para ele. Sinal de sucesso: a resposta cita o servidor MCP do REA e as capacidades de inspeção, não um "tudo certo" genérico sem detalhe.
- Faça a primeira investigação com um alvo pequeno e resultado conhecido. O exemplo do site oficial serve:
Use REA to inspect Windows Calculator. Why does 200 + 10% give 220?Sinal de sucesso: a resposta explica a regra (o botão de porcentagem calcula o percentual do primeiro número após a soma, logo 10% de 200 são 20, somados aos 200 originais) e aponta evidência, como instruções do handler e chamadas relevantes.
- Exija evidência em vez de resposta seca. Uma investigação honesta devolve pseudocódigo com offsets, chamadas e uma lista do que não foi resolvido. No exemplo da calculadora, o agente deve ser capaz de dizer qual branch do código corresponde a qual operador, não apenas repetir a conta. Sinal de sucesso: cada afirmação tem uma âncora verificável no binário.
- Só depois de entender, peça a recriação. O segundo exemplo oficial pede ao agente que inspecione um jogo estilo dinossauro do Chrome, explique por que ele acelera, mostre a regra de velocidade e construa uma versão pequena com velocidade ajustável. Sinal de sucesso: a reconstrução reproduz a regra recuperada (no exemplo do site, começar em 6 e acelerar até 13) e se comporta igual ao original nos limites testados.
Se você usa Claude Code e prefere instalar via clone, o comando documentado em diretórios de skills é git clone https://github.com/morluto/rea. O caminho preferencial continua sendo o npx, porque ele puxa a versão corrente do pacote.
O site mantém uma seção de guias (abre em nova aba) com walkthroughs por tipo de alvo, que vale consultar antes de pegar um alvo complexo.
Como verificar que a investigação funcionou
"Funcionou" aqui tem dois níveis, e confundi-los é a raiz de boa parte da insatisfação com ferramentas agênticas. O primeiro nível é verificar a explicação. O segundo é verificar a reconstrução.
Para verificar a explicação, use o próprio Evidence Bundle contra ele mesmo. Pergunte ao agente qual offset de arquivo sustenta cada afirmação e confira se os offsets citados são consistentes entre si: se o agente diz que uma função em determinada posição é chamada por outra, o xref correspondente deveria listar ambas. Se as respostas vêm sem offsets, sem instruções e sem cross-references, você recebeu indução estatística, não engenharia reversa. A lista de unknowns também é sinal positivo, não negativo: uma investigação que admite o que não conseguiu resolver é mais confiável que uma que fecha tudo com elegância.
Para verificar a reconstrução, teste comportamento, não aparência. Na calculadora, a reconstrução precisa reproduzir a regra exata: percentual sobre o primeiro número depois da soma, em ambos os caminhos de operador. No jogo do exemplo oficial, a regra recuperada era começar em velocidade 6 e acelerar até 13, e a versão reconstruída permite ajustar esse valor num slider. Se a sua reconstrução "parece igual" mas não consegue enunciar a regra que o original segue, ela não foi verificada.
Um terceiro check, disponível para quem tem repertório: leia você mesmo uma das fatias de assembly ou pseudocódigo que o agente usou. Você não precisa ler tudo, precisa checar uma ligação: a chamada que o agente afirma que divide valores realmente leva à função de divisão? No exemplo do site, a investigação cruza o opcode 0x5b com a operação de divisão e 0x5c com multiplicação, seguindo depois as chamadas auxiliares até a regra final. Um único elo conferido por humano muda a confiança no conjunto.
Existe um fourth check documentado como boa prática em cobertura independente: projetos de recriação limpa (clean-room) separam o que foi aprendido do que é escrito, e o REA se destina explicitamente a esse uso, com registros estruturados de contratos e verificação de código contra casos de teste. Se o seu objetivo é reimplementação defensável, registre a evidência da investigação como documentação do processo, não como código.
Erros comuns e soluções
O agente não enxerga as ferramentas do REA depois do setup. Causa mais comum: faltou reiniciar. A instrução oficial manda reiniciar o agente após aprovar o plano, e esse passo é o que recarrega o catálogo MCP. Solução: feche e reabra o agente, depois repita a verificação do passo 4.
A primeira análise trava ou parece travada. Ghidra tem inicialização fria lenta em binários grandes: até 330 segundos, o que dá cinco minutos e meio de espera sem output antes do motor responder. Isso está documentado como comportamento conhecido, não como defeito. Solução: espere na primeira análise; as seguintes são mais rápidas. Se o alvo for gigantesco, quebre a pergunta: em vez de "como o app inteiro funciona", pergunte por uma funcionalidade específica, que o REA fatia em escopos menores.
Você está no Windows e a análise de binário nativo falha ou produz resultados estranhos. O suporte do REA ao Ghidra no Windows é experimental, conforme documentado na cobertura técnica do projeto. Solução: para binários nativos do Windows, prefira rodar a análise em Linux ou macOS, ou confine as investigações no Windows a alvos JavaScript, Electron e web, que têm caminhos de análise independentes do Ghidra.
O agente pede licença ao abrir o Hopper. Causa: Hopper é comercial para fluxos interativos. Solução: redirecione o agente para o caminho do Ghidra, gratuito, sempre que o alvo permitir; reserve o Hopper para os casos em que ele faz diferença e você está disposto a pagar a licença.
A resposta parece plausível mas não tem evidência. Causa: o agente alucinando, o modo padrão de falha de modelos em engenharia reversa. Um modelo que recebe um binário Mach-O e uma pergunta sobre checagem de licença tende a inventar rotinas criptográficas convencionais, desconectadas do fluxo real de controle. Solução: recuse respostas sem âncora e peça explicitamente o Evidence Bundle. A arquitetura do REA exige que conclusões liguem a evidência imutável, então uma resposta solta é um desvio do contrato, não uma limitação inerente.
O contexto estoura ou o agente começa a repetir assembly sem sentido. Causa: investigação mal delimitada. O REA fatia alvos em escopos por design justamente para evitar despejar centenas de milhares de linhas no contexto, mas a qualidade do escopo depende do prompt. Solução: pergunte por funcionalidade e comportamento, não por arquivo; deixe o agente navegar de função em função em vez de pedir varreduras completas.
Você esperou mais ganho do que obteve. Este é o erro mais importante e o menos técnico. A avaliação prática do MindStudio reconstruiu o app Preview do Mac com ajuda do REA e reproduziu zoom, anotação, desenho, rotação e salvamento de forma razoavelmente fiel. Mas o mesmo teste informal mostrou que um agente sem REA, trabalhando por screenshots e raciocínio sobre funcionalidade, fazia trabalho parecido e terminou mais rápido em uma comparação. A conclusão da avaliação foi que parte do hype se apoia em gráficos de stars, não em demonstrações fortes. Solução: use o REA onde ele tem vantagem estrutural, ou seja, alvos fechados em nível binário e nativo, e trate como dispensável para funcionalidades web que o seu agente já investiga por fora.
Limites documentados e expectativas realistas
Os limites declarados pelo projeto são claros: sem recuperação de código-fonte original, sem clonagem de apps. O que o agente recebe é pseudocódigo e evidência, e a recriação é um trabalho dele, sujeito a erro e a várias iterações. O próprio fluxo é circular: o agente decompila, obtém pseudocódigo e lista de desconhecidos, escreve implementação, testa contra o original e repete, funcionalidade por funcionalidade.
A discrepância entre contagens de stars é um lembrete útil de postura. A página do repositório mostra mais de 80 mil; diretórios e blogs citam 125 mil ou mais. Não é fraude, são capturas em datas diferentes, mas é o tipo de número que os anúncios de projeção usam sem datação. Quando um argumento a favor ou contra o REA depender de adoção, volte à fonte primária.
Um limite que nenhum README resolve: a legalidade de fazer engenharia reversa depende dos termos de licença do software alvo e da legislação aplicável, e isso varia por jurisdição e por caso de uso. A cobertura independente enquadra o REA como ferramenta para reimplementações clean-room e para auditoria de segurança de dependências de terceiros fechadas, o que são os usos mais defensáveis. Antes de investigar qualquer app comercial, leia o EULA do alvo e, em contexto corporativo, confirme com quem responde pela compliance da empresa.
A manutenção é trivial mas não é zero. O REA se atualiza pelo ciclo normal do pacote rea-agents no npm, e o catálogo de ferramentas MCP gerado vem documentado no repositório; vale conferir changelog e o catálogo quando uma análise específica se comporta diferente do esperado, porque a rota interna entre o seu pedido e o Ghidra pode ter mudado de versão.
Perguntas frequentes
O REA recupera o código-fonte original do app?
Não. O projeto declara explicitamente que não recupera o código-fonte original nem clona apps. Ele entrega pseudocódigo, assembly, símbolos, strings e relações entre funções, com evidência, e o objetivo é que o agente entenda e reconstrua funcionalidades de forma independente.
O REA é gratuito?
A ferramenta é open-source sob licença MIT e a instalação via npx rea-agents@latest setup é gratuita. Os custos indiretos são o consumo de modelo do seu agente de código durante as investigações e a licença comercial do Hopper, caso você use fluxos interativos com ele; Ghidra, o caminho nativo principal, é gratuito.
Quais agentes de código funcionam com o REA?
A documentação cita Claude Code, Cursor, Codex, Gemini CLI, Windsurf e Claude Desktop como clientes MCP suportados. O REA também expõe as mesmas funcionalidades como CLI, para uso direto no terminal sem agente.
Preciso saber ler assembly para usar o REA?
Não para começar: o design é que o agente leia as fatias de código e explique a funcionalidade em linguagem natural, com evidência. Entender o básico ajuda na verificação, porque permite conferir um elo do Evidence Bundle, como um offset ou uma chamada, em vez de confiar na narrativa do agente sem checagem.