REA e engenharia reversa com IA: o que muda para quem vende software

Rhodion Souza Araújo, engenheiro de software e fundador da Rhodium Tecnologia

Quem criou o REA e quanto o projeto cresceu?

O desenvolvedor pseudônimo morluto criou o repositório morluto/rea em 14 de abril de 2026. Em 22 de outubro de 2026, a API do GitHub mostra 362 mil estrelas, 90 mil forks e 288 contribuidores. O pacote rea-agents teve 415 mil downloads no npm na semana de 12 a 18 de outubro.

Em julho, o primeiro "Show HN" do projeto fez 3 pontos no Hacker News. Em 10 de outubro, um novo post no Hacker News chegou a 814 pontos e 339 comentários. Entre 6 e 18 de outubro, o projeto publicou dez releases, da 4.1.0 à 6.7.0.

A curva do REA é estranha. Usuários do Hacker News anotaram a escalada dia a dia. Os forks somam perto de 25% das estrelas, uma proporção alta. Uso estrelas só como medida de atenção.

O autor do REA publica só como morluto, sem nome real. A conta no GitHub existe desde dezembro de 2020 e tem cerca de 9.600 seguidores. O morluto é, de longe, o maior contribuidor do repositório. Um comentarista do HN situa o autor na comunidade do RepoPrompt. Não achei entrevista nem perfil público além disso.

Quais ferramentas de engenharia reversa o REA integra?

O REA é uma camada de orquestração que integra ferramentas de engenharia reversa como Hopper, Ghidra, IDA Pro, JADX, Frida e Binwalk. A documentação do REA define o projeto como "um MCP para engenharia reversa entre binários, aplicações e comportamento em runtime".

O agente pergunta, o REA aciona a ferramenta adequada e a resposta volta com evidência, cobertura e lacunas declaradas.

O arquivo de licenças de terceiros do REA lista as ferramentas integradas por tipo de alvo:

O REA também tem análises próprias. Ele lê JavaScript e Electron de forma estática, com módulos, source maps, rotas e IPC. Lê metadados e instruções CIL de .NET sem instalar nada. Em binários Go e Rust, extrai a versão do compilador e as dependências embutidas. Cobre ainda certificados Authenticode, metadados IL2CPP da Unity, pacotes Godot, binários PyInstaller, assinaturas de APK, aplicativos Flutter e cabeçalhos de modelos GGUF.

O Binary Ninja não aparece em nenhum documento do repositório do REA. Por ora, quem usa essa ferramenta fica de fora.

Qual a diferença entre o REA e os MCPs de Ghidra e IDA?

O REA difere do GhidraMCP e do ida-pro-mcp porque um único servidor cobre vários tipos de alvo, trata a evidência como contrato e verifica reconstruções. O GhidraMCP (LaurieWired) e o ida-pro-mcp (mrexodia) existem desde março de 2025 e somam mais de 11 mil e 13 mil estrelas.

O ReVa, assistente MCP para Ghidra, existe desde 2023. Na pesquisa acadêmica, o LLM4Decompile (EMNLP 2024) treinou modelos de 1,3B a 33B parâmetros para decompilar binários. O DeGPT (NDSS 2024) usou LLMs para limpar a saída do Ghidra.

Os três diferenciais do REA:

1. Multi-alvo. Um único servidor cobre do binário de DOS ao aplicativo Electron, do APK ao firmware. Cada MCP anterior fala com uma ferramenta só.
2. Evidência como contrato. Cada resultado declara a origem, o nível de confiança e o que ficou de fora. O usuário pode exportar, importar e auditar bundles de evidência. Segundo a documentação do REA, um resumo de verificação aprovado "não pode promover Evidência inferida a uma observação de replay".
3. Reconstrução verificada e comparação de versões. O caso mais citado na documentação do REA é o do DX-Ball. A função de pan de som, reconstruída em C, passa em 3.205 casos do x86 original e reproduz os 63 bytes compilados. Outras ferramentas comparam versões de aplicativo, membros .NET entre builds e funções entre binários.

A crítica mais justa veio do blogueiro japonês zephel01, em 14 de outubro de 2026. Para ele, o REA "não é um analisador próprio, é um empacotador" de Ghidra, IDA, Hopper, Frida, JADX e Rizin. Concordo com a descrição e discordo da conclusão, porque o valor do REA está nesse empacotamento.

Por que o REA barateia a engenharia reversa?

O REA barateia a engenharia reversa porque um agente faz o trabalho braçal do analista, e o analista sempre foi o gargalo. O Ghidra é gratuito e open source desde 2019, e o IDA tem versão gratuita. Faltava quem soubesse ler assembly, entender convenções de chamada e seguir referências cruzadas por horas até achar a função certa.

A licença anual do IDA Pro Essential custa € 1.099, e a do IDA Pro Ultimate custa € 8.599, segundo a tabela de preços da Hex-Rays consultada em 22/10/2026. A licença é a parte barata. O custo maior sempre foi o analista sentado na frente da ferramenta, com anos de formação e salário alto.

O REA ataca esse custo com acesso padronizado às mesmas ferramentas. Um agente de IA abre o binário, segue chamadas, renomeia funções, testa hipóteses e compara com o comportamento em runtime. Penso num cofre com combinação de três dígitos. Agora qualquer pessoa tem um assistente que testa as mil combinações enquanto ela toma café.

Um comentário no HN resume a reação de quem é do ramo. Para o autor, a engenharia reversa foi possivelmente a primeira categoria de CTF de segurança a se tornar "completamente resolvível" por LLMs. Uso o REA no dia a dia como servidor MCP no Claude Code. A pergunta "como esse programa faz X?" deixou de ser um projeto e virou uma conversa.

A ofuscação de código ainda protege a propriedade intelectual contra o REA?

A ofuscação de código protege só em parte contra o REA, porque atrasa a análise sem impedi-la. Um agente custa alguns dólares por hora. Uma ofuscação que exigia semanas de um especialista passa a exigir uma tarde de tokens. A ofuscação ainda serve como sobretaxa, mas um modelo de negócio não pode depender dela.

A indústria de proteção já reagiu. Em 1º de outubro de 2026, a Thales lançou o Sentinel Envelope Plus e posicionou o produto contra a engenharia reversa assistida por IA. No teste divulgado pela Thales, um agente achou 8 de 10 vulnerabilidades plantadas num binário desprotegido. Levou 3 minutos e 10 segundos. No binário protegido, achou zero em 6 horas e 43 minutos e recomendou encerrar a investigação. O custo em tokens subiu quase mil vezes.

Faço duas ressalvas. O teste é do próprio fornecedor, sem replicação independente. E o argumento da Thales confirma a minha tese, porque trata a proteção como custo imposto ao atacante.

O REA permite clonar um produto de software?

O REA ajuda a copiar uma regra escondida no binário, como o cálculo de um preço ou o protocolo com um dispositivo. Para copiar a superfície de um produto, o agente nem precisa abrir o binário. Menus, atalhos, comportamento e formatos públicos bastam. As manchetes exageram a clonagem, e o caso mais famoso nem usou o REA.

Em outubro, Brandon Thomas, da ArtCraft, publicou clones open source em Rust da suíte Adobe e depois do Office, escritos com Claude. A imprensa misturou o caso com o REA. No Hacker News, a ArtCraft desmentiu: "não usamos engenharia reversa, não decompilamos binários, fazemos tudo 100% clean room". E disse que usar o REA num projeto tão exposto "provavelmente resultaria em processos". A Adobe não comentou, e a Microsoft só confirmou o recebimento do pedido de posicionamento.

O risco de cópia de uma regra escondida é real. Em 20 de outubro de 2026, a 404 Media publicou o relato de um fabricante de pedais de guitarra no Hacker News: "nas últimas 72 horas eu decompilei em um tiro só 3 produtos dos meus principais concorrentes". Na mesma matéria, o pesquisador Mike Nolan diz: "tudo que ouço de engenheiros de software é que software como serviço está morrendo como modelo de negócio". Discordo do Nolan e explico o motivo mais abaixo.

A cópia de funcionalidade com o REA também fica incompleta. Em 12 de outubro de 2026, o SystemDesign Academy publicou um teste do REA num aplicativo Electron de exemplo. As 30 localizações apontadas estavam corretas. Mas o REA detectou só 1 de 8 janelas e nenhuma das 4 ocorrências de nodeIntegration: true. O autor do teste conclui que achado ausente não prova ausência, e essa é a regra de ouro do REA.

O REA ajuda mais o atacante ou o defensor?

O REA ajuda o defensor e o atacante ao mesmo tempo, e essa é a parte que mais me preocupa. O defensor acha e corrige falhas em binários mais rápido. O atacante ganha a mesma velocidade para caçar falhas e comparar patches.

No lado defensivo, a Anthropic anunciou o Project Glasswing em 7 de abril de 2026. O projeto dá a parceiros como AWS, Apple, Google, Microsoft e a Linux Foundation acesso controlado ao Claude Mythos Preview. Eles usam o modelo para achar e corrigir vulnerabilidades, inclusive com testes de caixa-preta em binários. Entre outras falhas, o modelo achou uma de 27 anos no OpenBSD.

No lado ofensivo, o relatório de ameaças da Anthropic de setembro de 2026 descreve o caso GTG-10007. Os operadores obtiveram e decifraram imagens de firmware de fornecedores e carregaram as imagens em sessões de disassembler. Depois, usaram agentes em paralelo, "instruídos a exigir evidência", para caçar falhas. O resultado foi "mais de uma dúzia de possíveis zero-days em um único mês".

O patch diffing é a comparação do binário antes e depois de uma correção para descobrir onde estava o bug, e é o ponto mais sensível. O trabalho era lento e especializado. O REA compara versões e funções e devolve evidência. Assim, o intervalo entre a correção publicada e o primeiro exploit encurta. Se a sua empresa distribui binários e demora a atualizar a base instalada, esse intervalo joga contra ela.

O REA recupera sistemas legados sem código-fonte?

O REA ajuda a recuperar a regra de negócio de um sistema legado sem código-fonte, desde que cada função reconstruída passe por testes de equivalência. O fornecedor sumiu, o código-fonte se perdeu e a regra de negócio vive num binário que ninguém ousa tocar.

A recuperação desse comportamento exigia um projeto caro de engenharia reversa manual. Agora um agente faz o trabalho com supervisão humana. O padrão do REA é o que eu exigiria num projeto desses. O agente reconstrói a função, gera casos de teste e prova a equivalência com o original, como no DX-Ball. Sem essa verificação, você troca um sistema que ninguém entende por outro que ninguém testou.

Os números de migração com agentes ainda pedem humildade. Um estudo de caso no arXiv, de 2026, migrou um ERP em VB6 para C# com Claude Code. O ERP tinha mais de 20 anos de produção. A equivalência geral ficou em 70%, com 92% nas funcionalidades simples e 47% nas complexas. E esse projeto tinha código-fonte. Sem ele, espere números menores.

Como o REA audita licenças open source dentro de binários?

O REA audita licenças open source porque extrai de binários Go e Rust a versão do compilador, os módulos e as dependências embutidas. O REA também lê certificados de assinatura de binários Windows e assinaturas de APK. Com esses dados, uma auditoria de fornecedor descobre quais bibliotecas estão no binário, em que versão e sob qual licença.

O uso do REA para compliance vale para os dois lados. Quem compra software consegue verificar se o fornecedor embutiu uma dependência vulnerável ou uma biblioteca GPL que contamina a distribuição. Quem vende precisa assumir que o cliente, ou o concorrente, vai olhar.

Engenharia reversa com o REA é legal nos EUA, na Europa e no Brasil?

A engenharia reversa para interoperabilidade é permitida, com condições, nos Estados Unidos e na União Europeia. No Brasil, a Lei 9.609/98 não tem uma exceção expressa de descompilação como a europeia. Na minha leitura, copiar código decompilado para o seu produto não é defensável em nenhuma das três jurisdições. Não sou advogado, e esta leitura não substitui um parecer.

O próprio REA define um limite. O aviso de uso responsável do REA diz que o projeto não apoia contornar DRM ou checagem de licença. Também não apoia "copiar software proprietário ou reproduzir seu código e ativos protegidos". O aviso lembra ainda que o resultado de uma análise não dá direito algum sobre o programa original.

Estudar o comportamento de um software para interoperar é defensável na maioria das jurisdições. O REA aumenta o número de pessoas em condição de testar a lei.

O que o REA muda para quem vende software?

O REA dá prazo de validade ao diferencial que roda dentro do binário entregue ao cliente. Entender o que o código faz ficou barato, e reescrever um código já entendido sempre foi barato. Minha posição é diferente da manchete "o SaaS morreu". O fosso do negócio passa para cinco lugares fora do binário:

• Dados. O histórico, a base e o modelo treinado com o que só a sua empresa coleta.
• Execução no servidor. Uma regra que roda no seu backend não está no pacote que o cliente baixa. Um comentarista do Hacker News resumiu: "não existe mais obscuridade; o melhor que dá para fazer é manter o máximo possível no servidor".
• Operação. Uptime, suporte, atualização contínua e uma integração que funciona na segunda de manhã.
• Relação e serviço. Alguém que conhece o processo do cliente e responde quando algo dá errado.
• Distribuição e marca. A presença na frente do comprador antes do concorrente.

Discordo de quem decreta o fim do SaaS. No software como serviço, a regra de negócio fica no servidor do fornecedor. Quem perde valor é o software de prateleira cujo único diferencial era a dificuldade de entender o código. Para o comprador, a notícia é boa. O custo de trocar de fornecedor caiu, e o poder de negociação subiu.

Checklist do REA para quem vende e para quem contrata software

O checklist do REA tem nove ações para quem vende software e quatro para quem contrata software. Todas partem da premissa de que qualquer binário entregue ao cliente pode ser analisado por um agente com o REA, a custo baixo.

Checklist do REA para quem vende software

Aviso: o REA roda a análise localmente, mas os resultados vão para o agente e para o provedor do modelo de linguagem. Avalie esse risco antes de analisar um binário sensível.

1. Rode o REA no seu próprio binário antes do concorrente, ou contrate alguém para rodar.
2. Mapeie as regras de negócio que valem dinheiro, com o mesmo método de mapear um processo antes de automatizar.
3. Avalie mover para o servidor cada regra que hoje roda no cliente.
4. Remova do binário chaves, endpoints internos e credenciais.
5. Meça o custo que a ofuscação e a proteção pós-compilação impõem ao atacante. Esse custo é uma sobretaxa e não garante nada.
6. Encurte o ciclo de atualização dos clientes. Com patch diffing barato, uma correção publicada e não instalada vira mapa para o exploit.
7. Ative a atestação de plataforma onde couber. Na Apple, o App Attest gera chaves no Secure Enclave e detecta modificação do aplicativo. No Android, o Play Integrity verifica se o binário está inalterado e se o dispositivo é certificado.
8. Audite as dependências embutidas nos seus binários antes do cliente.
9. Na Europa, a cláusula contra descompilação para interoperabilidade é nula. Revise o EULA com um advogado.

Checklist do REA para quem contrata software

1. Pergunte ao fornecedor se a regra de negócio roda no seu ambiente ou no servidor dele.
2. Exija a lista de dependências e licenças. Agora você consegue conferir essa lista.
3. Negocie uma cláusula de saída e o acesso aos seus dados. A migração ficou mais barata, e isso pesa na mesa.
4. Para sistema legado sem código-fonte, exija reconstrução com testes de equivalência. A promessa de que "o agente entendeu tudo" não basta.

Perguntas frequentes sobre o REA