Engenharia reversa com agente de IA: o que o REA faz e onde a lei para

Duzentas e duas mil estrelas no GitHub para um repositório criado em 14 de abril de 2026. Quarenta e nove mil forks. Cinco versões publicadas entre 8 e 11 de outubro. Cento e trinta e dois mil downloads do pacote no npm na semana de 5 a 11 de outubro. O nome do projeto é REA, de Reverse Engineer Anything, e a frase de abertura do README promete que, ao ver uma funcionalidade em um aplicativo de terceiro, você pede ao seu agente que entenda como ela funciona "até o nível do binário" e construa uma versão para o seu projeto.

A mesma página, umas linhas abaixo, diz o que o nome não diz: "a análise nativa pode usar uma instalação existente do Hopper, do Ghidra ou do IDA". O REA não descompila nada. Ele é um servidor MCP, o protocolo que os agentes de código usam para chamar ferramentas, e o que ele faz é colocar o Ghidra, o Hopper ou o IDA, que existem há anos, ao alcance do Claude Code, do Codex, do Cursor, do Gemini CLI e do Grok Build. A novidade não está no desmontador. Está em quem o opera.

Para quem tem um sistema sem código-fonte rodando em produção, essa distinção decide três coisas: o que a ferramenta entrega, o que sai da máquina quando o agente trabalha, e o que a lei brasileira e o contrato do software deixam fazer com o resultado.

O que o REA faz, e o que ele deixa para o Ghidra

O ciclo descrito no README tem quatro movimentos, e nenhum deles é novo para quem já fez engenharia reversa à mão:

1. O agente pergunta, em linguagem natural, sobre um alvo local: um executável, um app Electron, um pacote Android, um site.
2. O REA inspeciona pelo motor adequado e segue o código relevante: pseudocódigo, assembly, strings, símbolos, chamadas e referências nos binários nativos; módulos, imports, source maps, rotas e IPC no JavaScript e no Electron.
3. O REA devolve achados com evidência e limites, e é esse pacote que o agente lê, não o binário.
4. O agente explica, implementa e testa a partir dos achados, com as perguntas de acompanhamento que quiser.

A tabela de alvos da versão 6.4.0 é longa, e o que muda entre as linhas é o que precisa estar instalado:

Dois detalhes da tabela pesam mais que o resto. Os únicos alvos que o REA lê sozinho, sem motor externo, são JavaScript, .NET e os metadados de Go, Rust e Flutter. E o requisito mínimo de Node.js é a versão 22, o que deixa de fora quem ainda roda a 18 ou a 20. O projeto é MIT e distribuído no npm como rea-agents, com 31 versões publicadas desde 12 de julho; o README diz que ele "muda rapidamente" e manda manter a instalação atualizada. Cinco versões em quatro dias, de 8 a 11 de outubro, confirmam.

A evidência é o que separa isto de um chute bem escrito

A parte do projeto que merece atenção de quem contrata software não é o desmontador, é a frase "os resultados incluem a evidência e as limitações por trás de cada conclusão". Um modelo de linguagem lendo pseudocódigo inventa com facilidade: uma função chamada check vira "validação de licença" sem que nada no código sustente. O desenho do REA responde a isso devolvendo, junto com cada achado, de onde ele saiu e o que ficou sem resposta, e é essa trilha que o humano confere.

O projeto mostra três estudos de caso. No DX-Ball, um jogo dos anos 1990, o README afirma que a reconstrução em C de uma função de posicionamento de som "passa em 3.205 casos do x86 original e reproduz todos os 63 bytes da função compilada". No Notion, o rastreio vai da API de clipboard do renderer, pelo preload e pelo IPC, até o processo principal do Electron. No TH04, um jogo de PC-98 de 16 bits, a recuperação de um cálculo de ângulo. Os números do DX-Ball são do próprio projeto; a reportagem do Cyber Security News que os reproduziu em 10 de outubro escreveu que são "demonstrações reportadas, não prova de que todo alvo possa ser reconstruído", e é assim que eles entram aqui.

Há uma pesquisa brasileira que olha o mesmo problema pelo outro lado. O artigo Reversa, de Sanderson Oliveira de Macedo e Ronaldo Martins da Costa, publicado no arXiv em 18 de maio de 2026, propõe um pipeline de seis papéis de agente para transformar sistema legado em especificação operacional: mapear a superfície do projeto, analisar módulos, extrair regras implícitas, sintetizar a arquitetura, escrever especificações por unidade e revisar as afirmações geradas, com rastreabilidade entre código e especificação, marcação explícita de confiança e preservação das lacunas para validação humana. O REA parte do binário e chega ao código; o Reversa parte do código e chega à especificação. Os dois convergem no mesmo ponto: o agente só é útil quando diz de onde tirou cada frase.

Legado sem fonte: onde isto serve e onde não serve

O caso que importa para a empresa brasileira não é copiar a busca do app de notas do concorrente. É o sistema que roda há dez anos, cujo fornecedor fechou, e do qual sobrou um executável, um banco de dados e nenhuma linha de fonte. Já escrevemos por onde começar nesse cenário, e a resposta continua sendo o banco e a superfície de integração, não o binário.

O que vemos nos projetos de modernização de legado é que a engenharia reversa do executável resolve problemas pontuais: descobrir o formato de um arquivo que o sistema grava, o protocolo que ele usa para falar com um equipamento, a regra de cálculo que ninguém documentou. Para isso, um agente com Ghidra ao alcance encurta semanas de leitura de assembly, e a evidência por achado é o que permite entregar o resultado a quem vai assinar embaixo. O que ela não resolve é reconstruir o sistema inteiro: o próprio README, no estudo de caso mais detalhado, reconstrói uma função, não um programa.

Também não serve para o que roda fora da sua máquina. SaaS tem o cliente no seu navegador e o servidor em outro lugar; o REA inspeciona o cliente, os scripts e as observações de rede, e o servidor continua opaco. E não serve para quem não pode instalar o motor: o Ghidra é gratuito e de código aberto, o IDA Pro e o Hopper são comerciais, e o README é explícito em que o REA "não concede licença, chave nem ativação de ferramenta", com versões de demonstração sujeitas aos termos de cada fornecedor.

O que a Lei 9.609 permite, e o que o contrato proíbe

A engenharia reversa de software, no Brasil, não tem uma regra geral de permissão. A Lei 9.609/1998 protege o programa de computador como obra literária por 50 anos e lista, no artigo 6º, quatro atos que não ofendem o direito do titular: a cópia de salvaguarda; a citação parcial para fins didáticos; a semelhança entre programas que decorre de características funcionais, de normas técnicas ou de limitação da forma de expressão; e "a integração de um programa, mantendo-se suas características essenciais, a um sistema aplicativo ou operacional, tecnicamente indispensável às necessidades do usuário, desde que para o uso exclusivo de quem a promoveu". Não há, na lista, o que a Diretiva 2009/24 da União Europeia tem no seu artigo 6º: a descompilação para obter informação de interoperabilidade.

Nossa leitura é que o inciso IV é a porta mais próxima do caso do legado: integrar o sistema sem fonte ao resto da operação, para uso exclusivo de quem integra. A porta se fecha quando o objetivo é reproduzir a funcionalidade de um produto de terceiro para o seu produto, que é exatamente a promessa de abertura do README, e quando o contrato de licença proíbe engenharia reversa, cláusula frequente em licença de software comercial. O artigo 12 da mesma lei pune a violação com detenção de seis meses a dois anos ou multa, em crime que depende de queixa do titular. O próprio projeto escreve, no aviso de uso, que se destina a "pesquisa lícita, educação, interoperabilidade, preservação de software e análise de software que você possui ou está autorizado a examinar". A autorização é o que o agente não pode conferir por você.

O que sai da máquina, e para quem

O README responde "o REA faz upload do meu app?" com uma frase que vale ler duas vezes: "o REA analisa os alvos localmente. O seu agente recebe os resultados da ferramenta, e o provedor do modelo dele tem a própria política de dados". A análise é local. O pseudocódigo, as strings, os símbolos e as rotas que o Ghidra extraiu vão para o modelo que o agente usa, pela API da OpenAI, da Anthropic, do Google ou da xAI, nos termos de retenção e treinamento de cada contrato.

Para um binário próprio, isso é a mesma decisão de mandar código-fonte para um agente de código, que a maioria das equipes já tomou. Para um binário de terceiro, é uma segunda camada sobre a questão legal: o conteúdo de um software alheio passa a circular por um contrato de API que não é o da licença daquele software. E a captura em runtime, que o README diz executar "com as permissões do seu usuário", roda o alvo de verdade, com o que ele fizer no sistema de arquivos e na rede.

O que faríamos com um binário sem fonte

Com o que o REA entrega hoje, o uso que cabe no nosso trabalho é delimitado: um agente com o Ghidra ao alcance, sobre um executável que o cliente tem o direito de examinar, com uma pergunta fechada, como qual é o formato deste arquivo ou qual regra gera este número, e com a evidência de cada achado guardada junto do resultado, para quem assina a modernização saber de onde cada regra saiu. A reconstrução do sistema inteiro continua sendo projeto de software, com especificação, testes e um banco que já conta a maior parte da história.

A decisão concreta desta semana, para quem tem sistema sem fonte: levante o contrato de licença dele e marque a cláusula sobre engenharia reversa, se existir. Com ela na mão, a pergunta sobre a ferramenta vira pergunta sobre escopo, e não sobre risco.

Dos sistemas que rodam na sua operação hoje, quantos você teria autorização para abrir, e de quantos ainda existe alguém que saiba o que o binário faz?

Fontes e método

• REA: API do GitHub para o repositório morluto/rea em 13 de outubro de 2026 (estrelas, forks, data de criação, licença, releases e tags); README da branch principal lido na mesma data (alvos, requisitos, fluxo, estudos de caso, FAQ, aviso de uso e licença); registro do npm e api.npmjs.org para o pacote rea-agents (versões e downloads da semana de 5 a 11 de outubro). O marco de 125 mil estrelas vem do artigo da Eigent de 12 de outubro, sem hora; o de 180 mil é o texto do próprio README, sem data. Os dois ficam como marcos, não como taxa de crescimento.
• Estudos de caso: números do DX-Ball reproduzidos do README e do Cyber Security News de 10 de outubro, sem replicação independente.
• Reversa: arXiv 2605.18684, publicado em 18 de maio de 2026, resumo oficial.
• Lei: Lei 9.609/1998, artigos 2º, 6º e 12, no texto do Planalto; Diretiva 2009/24/CE, artigo 6º, citada pelo conteúdo geral, sem número.
• Experiência da X-Apps: projetos de modernização de legado, descritos sem nome de cliente e sem número.
• Validade: estrelas, forks e downloads valem em 13 de outubro de 2026; a lista de alvos vale para a versão 6.4.0.