Todo desenvolvedor que já passou uma tarde dentro do Ghidra conhece o ritual: abrir o binário, esperar a análise, caçar a função certa entre mil, renomear símbolos um a um e torcer para que o pseudocódigo gerado faça algum sentido humano. É trabalho que exige método, e o método não mudou muito em anos. O que mudou foi a camada em volta, e é exatamente aí que entra o projeto que virou fenômeno no GitHub nas últimas semanas: o REA (Reverse Engineer Anything) (abre em nova aba).
A pergunta que este artigo persegue é simples de enunciar e difícil de responder: quando um projeto anuncia que seu agente de IA agora consegue "engenharia reversa de qualquer coisa", o que sobra de real depois que o entusiasmo da tagline passa? Minha resposta, adiantada com franqueza, é que o REA é uma camada de orquestração bem feita sobre ferramentas que já existiam — e que justamente por isso merece atenção, embora por razões diferentes das que alimentaram a viralização.
O que o projeto declara fazer
O site oficial (abre em nova aba) define a tarefa com precisão: engenharia reversa é descobrir como um software funciona examinando o programa em si, com o objetivo de entender um recurso bem o suficiente para explicá-lo, modificá-lo ou reconstruí-lo. O REA se posiciona como uma ponte entre isso e os agentes de código que dominam o fluxo de trabalho técnico hoje — Claude Code, Codex, Cursor, Gemini CLI, Windsurf e outros, somando mais de uma dúzia de clientes suportados segundo a FAQ oficial (abre em nova aba).
O mecanismo de ligação é o MCP, o Model Context Protocol — o padrão aberto que permite a um agente chamar ferramentas externas de forma estruturada. Um único comando, npx rea-agents@latest setup, registra a conexão MCP e instala a skill de investigação correspondente; o README (abre em nova aba) informa que a rotina faz backup da configuração existente antes de mexer em qualquer coisa. Depois, o fluxo é conversacional: você passa um caminho de destino e uma pergunta, e o agente chama o REA, que devolve achados com evidência — a documentação repete essa palavra, evidence, como princípio de design.
Os alvos declarados cobrem bastante terreno:
Binários nativos e bibliotecasFunções, assembly, pseudocódigo, chamadas, referências, constantesHopper, Ghidra ou IDAJavaScript e ElectronMódulos, imports, IPC, localização do código-fonteNenhum motor nativoPáginas de navegadorScripts, requisições, observações de runtimeDepuração localAssemblies gerenciados, APKs, firmwareInspeção estática e empacotadosVaria por casoA última coluna é a mais reveladora. Análise estática de JavaScript e .NET lê os arquivos que você fornece sem rodar a aplicação — trabalho que o próprio projeto faz. Binários nativos compilados, em contraste, exigem um descompilador de verdade, e o REA não traz nenhum: ele orquestra Hopper, Ghidra ou IDA, que você precisa ter instalado e licenciado por conta própria. No macOS, a FAQ adverte que a demonstração de primeira execução do Hopper ou a ativação da licença precisa estar concluída antes de qualquer análise não assistida — detalhe pequeno, mas que indica onde está a fronteira real do projeto.
Há também uma via alternativa que pouca gente notou: o REA funciona sem agente. A documentação mostra o CLI direto, como npx -y rea-agents@latest analyze-javascript-application apontado para uma pasta extraída ou um pacote ASAR do Electron, mais um comando de diagnóstico, doctor, que reporta o estado da configuração em JSON. Para quem desconfia de entregar contexto ao modelo, o caminho existe.
As limitações que os showcases não resolvem
O disclaimer do projeto (abre em nova aba) é, na minha avaliação, o documento mais honesto do repositório. Ele enumera os usos que o REA se propõe a servir — pesquisa de segurança, análise de malware e incidentes, divulgação coordenada de vulnerabilidades, CTFs, interoperabilidade, preservação de software, depuração de software próprio ou autorizado — e, com a mesma clareza, o que fica de fora: contornar DRM, verificações de licença ou anti-cheat; trapaças em jogos online; burlar autenticação e controles de acesso em sistemas não autorizados; copiar software proprietário; evadir políticas de uso dos provedores de modelos de IA. Nada de licença comercial, chave ou ativação de IDA Pro, Hex-Rays ou JEB: cópias cracked e chaves roubadas são explicitamente não autorizadas.
O texto do disclaimer também admite, sem rodeio, que descompilação, reconstrução e análise assistida por IA podem ficar incompletas ou incorretas, sem garantia de precisão ou compatibilidade. É o reconhecimento formal de uma verdade que qualquer pessoa que já comparou pseudocódigo gerado com comportamento real conhece: a saída é hipótese, não certeza.
Um exemplo hipotético ajuda a dimensionar o ganho prático. Suponha uma equipe herdando um serviço interno sem documentação, cujo único artefato disponível é o bundle de produção. Um agente com o REA pode mapear módulos, imports e pontos de IPC do pacote e devolver um relatório com localizações de código — o tipo de levantamento que consumiria dias manuais. O que ele não fará é recuperar o código-fonte original nem clonar a aplicação automaticamente; a análise do hysenlabs (abre em nova aba), publicada em setembro de 2026, é taxativa nesse ponto: o REA não decompila nada por si e produz pistas legíveis, código, strings, nomes, dossiês de função, registradas como evidência, não como verdade reconstruída.
Sobre a vitrine mais ambiciosa do README, a reconstrução do jogo DX-Ball que, segundo o próprio projeto, passa por 3.205 casos x86 originais e reproduz todos os 63 bytes de funções compiladas, cabe um alerta de leitura: é uma alegação do projeto, com estudo de caso e repositório vinculados, não uma validação independente. Reproduzir bytes exatos de funções compiladas é resultado notável se confirmado, mas "segundo o README" não é o mesmo que "verificado".
A viralização, examinada de perto
Aqui os números exigem sobriedade, porque contam uma história menos redonda do que os títulos sugerem. Capturas do repositório feitas no mesmo período retornaram valores em conflito: uma página do GitHub exibia cerca de 136 mil estrelas e 30,6 mil forks, enquanto outra captura da mesma URL, na mesma sessão, mostrava 15,9 mil estrelas, e nenhuma das duas carregava data do contador. A página do projeto no skills.sh (abre em nova aba) exibia 103,8 mil estrelas e marca "primeira aparição" em 18 de julho de 2026; a análise do hysenlabs, de 10 de setembro de 2026, registrava 95.365 estrelas e 21.272 forks. Nenhum desses números é uma resposta direta da API do GitHub capturada nesta apuração, e a discrepância entre capturas do mesmo site na mesma sessão é, por si só, um aviso.
O que se pode afirmar com mais segurança é a trajetória: de cerca de 95 mil estrelas em meados de setembro para mais de 100 mil segundo a exibição do skills.sh, com picos de contagem disputados entre capturas. Crescimento dessa ordem em semanas é raro. E há uma ironia factual digna de registro: a discussão no Hacker News de 10 de outubro de 2026 que celebrava o REA como repositório nº 1 em tendência somava 2 pontos e 2 comentários. A viralização não veio do debate técnico; veio do circuito de descoberta por agregadores e feeds, o que, convém dizer, é como a maioria das coisas viraliza hoje, dentro e fora da tecnologia.
Minha leitura: por que vale atenção mesmo com ceticismo
Dito isso, o meu veredito é positivo com qualificações. O valor do REA não está em descompilar melhor que o Ghidra, ele não descompila, apenas convoca quem descompila. Está em três coisas que a camada de orquestração entrega: primeiro, a padronização do fluxo de investigação em um único comando de setup, que elimina a fricção de configurar agente, protocolo e ferramenta manualmente; segundo, o registro sistemático de evidência, que obriga o agente a fundamentar afirmações em observações e a declarar limitações; terceiro, a cobertura de casos que ficavam no vazio entre ferramentas especializadas, como pacotes Electron e páginas de navegador observadas em runtime, a demonstração do site com o jogo do dinossauro do Chromium, via conexão de depuração local, mostra velocidade máxima de 13 com aceleração de 0,001 recuperados das constantes carregadas, o tipo de resposta concreta que justifica a abordagem.
Para profissionais, duas implicações práticas merecem peso na decisão de adotar. A primeira é de segurança: a política do projeto reconhece que a ponte local do provedor não é um sandbox e não protege contra processos maliciosos já em execução sob o mesmo usuário do sistema operacional, e, no Linux, dependências são instaladas via apt-get, dnf ou pacman como root ou por pkexec, embora o projeto afirme que nunca invoca sudo. A segunda é de confidencialidade, e esta me parece subestimada no entusiasmo geral: a análise roda localmente, mas os resultados das ferramentas chegam ao agente, e o agente passa pelo provedor do modelo, com a política de dados que ele tiver. Dossiês sobre binários proprietários do seu cliente fluindo para um serviço de nuvem são um risco contratual, não um detalhe de arquitetura.
Quem avalia o REA deveria lê-lo como leitura de um contrato: a camada é boa, os motores são de terceiros, as alegações de precisão são do próprio projeto e o escopo legal está desenhado com mais clareza do que a média. Num ecossistema onde qualquer wrapper de API ganha mil estrelas por semana, um projeto que orquestra engenharia reversa com registro de evidência e disclaimer jurídico compõe um padrão raro, e, mesmo com todos os asteriscos, é o tipo de infraestrutura que tende a sobreviver ao hype.
Perguntas frequentes
O REA decompila binários por conta própria?
Não. Para binários nativos, ele orquestra motores externos que você precisa ter instalado e licenciado: Hopper, Ghidra ou IDA. Já a inspeção estática de JavaScript, Electron e .NET é feita pelo próprio REA, lendo os arquivos fornecidos sem executar a aplicação.
Preciso comprar IDA Pro para usar a ferramenta?
Não. O disclaimer do projeto informa que o REA não fornece licença comercial de IDA Pro, Hex-Rays, Hopper ou JEB, e que cópias cracked e chaves roubadas não são autorizadas. A saída sem custo de licença é usar o Ghidra, que é gratuito e open-source.
Quais são os requisitos de instalação?
Conforme o README, é preciso Node.js 22.x (a partir de 22.19), 24.x (a partir de 24.11) ou versão 26 ou superior, além do npm. A instalação é feita com npx rea-agents@latest setup, seguida de reinício do agente para registrar a conexão MCP.
É legal usar o REA em qualquer software?
Não em qualquer software. O projeto se declara construído para análise legal, pesquisa de segurança, interoperabilidade, preservação, depuração de software próprio ou autorizado, e rejeita contornar DRM, verificações de licença, anti-cheat e controles de acesso. O disclaimer lembra que a engenharia reversa pode ser restringida pela jurisdição ou licença, e a responsabilidade pela autorização é de quem usa.
Fontes
- REA — Reverse Engineering for Your Coding Agent · rea.tools
- REA FAQ: Setup, Updates and Troubleshooting · rea.tools
- REA: Reverse Engineer Anything (README, morluto/rea) · raw.githubusercontent.com
- REA Disclaimer (morluto/rea) · raw.githubusercontent.com
- GitHub - morluto/rea · github.com
- reverse-engineer-anything — morluto/rea (skills.sh) · skills.sh
- REA Gives Claude Code and Codex an MCP Server for Reverse Engineering · ccleaks.com · 11/10/2026
- REA review: agent-driven reverse engineering via MCP and CLI · hysenlabs.com · 09/09/2026