O REA recupera o código-fonte original?

Não. Nada recupera o código-fonte original a partir de um binário — os nomes de variáveis, os comentários e a estrutura que o autor escreveu desaparecem em tempo de compilação. O que os descompiladores produzem é pseudocódigo: uma aproximação legível do que o código de máquina faz. A contribuição do REA é trabalhar a partir dessas evidências de forma sistemática e escrever uma especificação do comportamento, que é o que uma reconstrução fiel realmente precisa.

É legal fazer engenharia reversa de um app?

Depende de quem é o dono do app, do porquê e de onde. Fazer engenharia reversa do seu próprio software, pesquisa de segurança de boa-fé e trabalho feito para alcançar interoperabilidade são amplamente aceitos e, em algumas jurisdições, legalmente protegidos; a licença de um produto pode restringir mais, e contornar DRM ou controles de acesso é proibido em muitos lugares, independentemente da intenção. A própria documentação do REA o limita à pesquisa autorizada e lícita — e você também deveria. Quando a resposta importa comercialmente, é uma pergunta para um advogado da sua jurisdição, não para uma ferramenta.

Ainda preciso ter o Ghidra instalado para usar o REA?

Para binários nativos, sim — o REA é uma camada de orquestração, não um motor. Ele controla um motor de análise instalado (Ghidra, IDA Pro ou Hopper) e verifica cada um com o seu comando doctor. Os APKs passam pelo JADX, e alguns alvos — aplicativos JavaScript e Electron, sites, capturas de rede — não precisam de nenhum motor nativo. A instalação leva uma tarde, uma única vez; a resistência do agente é a parte que você não conseguiria contratar.

Os agentes de IA podem fazer engenharia reversa do seu app?

By John · Former Microsoft engineer with 20 years of experience.

O REA — Reverse Engineer Anything — é um servidor MCP e uma ferramenta de linha de comando de código aberto que permite a um agente de programação operar software profissional de engenharia reversa: você aponta o agente para um app ou binário publicado e ele inspeciona o código com descompiladores reais, escreve como um recurso funciona na forma de uma especificação, reconstrói o recurso e confere a reconstrução em relação ao original. Tornou-se um dos projetos do GitHub que mais cresceram em outubro de 2026, e muda a economia de um fato antigo: tudo o que roda na máquina de um usuário pode ser lido por esse usuário. Este artigo explica o que o REA realmente é, a pilha de ferramentas que ele controla, o fluxo de trabalho que torna sua saída confiável e o que um desenvolvedor que publica software deve fazer a respeito.

O que é o REA

O REA (o repositório é morluto/rea, licenciado sob MIT, instalado a partir do npm como rea-agents) não é um descompilador. Ele não descompila nada por si só. É uma camada de orquestração que fala o Model Context Protocol — a mesma interface com a qual o trabalho de prontidão para agentes deste site lida pelo lado do site — e expõe operações de engenharia reversa como ferramentas que um agente de programação como Claude Code, Codex ou Cursor pode chamar: desmontar este binário, descompilar esta função, listar as strings, seguir as referências cruzadas, mostrar as evidências. O trabalho pesado é feito pelos motores abaixo dele, que o agente controla como um analista humano faria, exceto que pode se dar ao luxo de ser exaustivo.

Essa divisão de trabalho é o ponto central. A saída de um descompilador é enorme e em sua maior parte entediante; a habilidade escassa em engenharia reversa nunca foi executar a ferramenta, e sim decidir o que olhar em seguida e saber quando uma resposta está provada. O REA combina os motores com instruções de fluxo de trabalho — investigar em uma ordem definida, registrar evidências para cada afirmação, declarar o que não pôde ser resolvido — de modo que a saída do agente não é uma pilha de pseudocódigo, mas um conjunto de descobertas com comprovantes. Para binários nativos, ele controla Ghidra, IDA Pro ou Hopper; para pacotes Android, controla JADX; para o comportamento ao vivo, pode ler capturas HAR e do mitmproxy. Uma interface, muitos motores, e o agente fornece a resistência.

A pilha em um único mapa

O núcleo de análise. O Ghidra é o descompilador gratuito da NSA, licenciado sob Apache-2.0, e o motor padrão para a maioria das pessoas; o IDA Pro é o veterano comercial que muitos profissionais ainda preferem. O que é novo não é nenhuma das duas ferramentas, mas suas pontes: o GhidraMCP e o ida-pro-mcp expõem uma sessão em execução do Ghidra ou do IDA a um agente via MCP, para que o agente possa consultar o banco de dados de desmontagem diretamente, em vez de ler capturas de tela. O REA fica um nível acima deles, escolhendo motores e sequenciando o trabalho.

Móvel e aplicativos. O jadx descompila APKs do Android de volta para Java legível; o Apktool desempacota os recursos e o smali de um APK e pode reconstruí-lo; o Frida instrumenta um app em execução, interceptando funções enquanto elas executam — a metade dinâmica que a descompilação estática não consegue ver; e o ILSpy faz para assemblies .NET o que o jadx faz para APKs. (Para uma primeira olhada sem instalação nas declarações de um APK, em vez de no seu código, o APK Analyzer deste site lê o manifesto, as permissões e os certificados de assinatura no seu navegador.)

Binário e baixo nível. O radare2 e seu fork mais amigável rizin são frameworks de engenharia reversa programáveis e voltados ao terminal; o x64dbg é o depurador do Windows a que a maioria dos analistas recorre; o ImHex é um editor hexadecimal com uma linguagem de padrões para descrever formatos de arquivo; e o angr é um motor de execução simbólica que pode raciocinar sobre cada caminho através de uma função, em vez de uma única execução dela. Essas são as ferramentas para as perguntas que os descompiladores respondem mal: binários empacotados, formatos de arquivo estranhos, “esta entrada consegue sequer alcançar aquele ramo?”.

Rede e tempo de execução. O mitmproxy fica entre um app e seus servidores e registra a conversa — para muitos apps, o tráfego da API explica mais do que o código, e é o formato de captura que o REA lê nativamente. O dnSpy depura e edita aplicativos .NET ao vivo, e o raddebugger é o depurador gráfico moderno da Epic para Windows. Ao redor de tudo isso ficam os mapas: duas listas selecionadas, awesome-ai-reverse-engineering (122 repositórios da era dos agentes, cada um lido e avaliado) e a do próprio autor do REA, awesome-reverse-engineering, estão ligadas nas fontes abaixo.

O ciclo de sala limpa: especificar, reconstruir, verificar

O fluxo de trabalho que o REA incentiva é mais antigo que a IA: é a engenharia de sala limpa, a disciplina outrora usada para clonar uma BIOS sem copiá-la. O agente investiga o alvo e escreve SPEC.md — uma especificação do que o software faz, em linguagem simples, com as evidências de cada comportamento anexadas. Só então começa a reconstrução, a partir da especificação e não do código descompilado, e a reconstrução é julgada por critérios de aceitação: mesmas entradas, mesmas saídas, mesmos casos extremos. Quando o juiz diz não, o ciclo volta às evidências — não a um palpite — e investiga novamente.

É por isso que o artefato interessante é a especificação, não o pseudocódigo. Uma especificação com evidências pode ser verificada por um segundo agente, por uma suíte de testes ou por um humano; uma descompilação bruta não é nenhuma dessas coisas. É também o passo legalmente significativo: uma reconstrução a partir de uma especificação comportamental é um ato diferente de copiar uma implementação, razão pela qual o ciclo insiste em evidências e critérios em vez de impressões. Quem avalia ferramentas de agentes — para engenharia reversa ou para qualquer outra coisa — deve roubar esse padrão: o entregável é uma afirmação verificada, não uma resposta confiante.

O que isso significa se você publica software

Nada disso torna secreto o código do lado do cliente; ele nunca foi. Torna barata a sua leitura. Um analista habilidoso com o Ghidra sempre pôde extrair do seu app os endpoints da API, os interruptores de recursos e a lógica de licenciamento — ferramentas da classe do REA significam que um júnior com uma assinatura de agente pode fazer a primeira passagem em uma tarde. As consequências práticas são as de sempre, agora com prazos mais curtos: um segredo embutido em um binário publicado — uma chave de API, um endpoint privado, a única e verdadeira regra de desconto — está efetivamente publicado; a ofuscação eleva o custo de leitura, mas é um atraso, não uma barreira; e qualquer coisa de cujo segredo o seu negócio dependa deve viver no seu servidor, atrás de autenticação, não no app.

As defesas são igualmente pouco glamorosas e funcionam: mantenha segredos e decisões de preços e licenciamento no servidor, emita tokens de curta duração e escopo limitado em vez de chaves permanentes, use atestação de plataforma (Play Integrity, App Attest) onde o risco a justifique e presuma que o comportamento do seu cliente é totalmente observável ao projetar controles de abuso. Esta é a imagem espelhada da lição de prontidão para agentes deste site: lá, o ponto era que os agentes leem a superfície voltada para máquinas do seu site quer você a tenha projetado ou não; aqui, os agentes leem o binário do seu app da mesma maneira. Nos dois casos, a jogada vencedora é decidir deliberadamente o que a superfície voltada para máquinas diz.

Usos legítimos — e os limites

A engenharia reversa tem usos honrosos e estabelecidos, e a própria documentação do REA nomeia a mesma lista: analisar o seu próprio software (incluindo a cópia cujo código-fonte você perdeu), pesquisa de segurança e análise de vulnerabilidades, investigação de malware e de incidentes, interoperabilidade — fazer o seu produto funcionar com outro —, competições CTF e educação. Em muitas jurisdições, alguns desses usos são protegidos mesmo contra uma cláusula de licença que pretenda proibi-los, em particular a interoperabilidade e a pesquisa de segurança de boa-fé, embora os detalhes variem e este artigo não seja aconselhamento jurídico.

Os limites são igualmente claros. Uma licença MIT sobre as ferramentas não é uma licença sobre o alvo: ela não autoriza clonar o produto de um concorrente a partir do seu binário, derrotar o DRM ou a aplicação de licenças, nem distribuir o que você extrair. O ciclo de sala limpa da seção anterior existe precisamente para manter uma reconstrução do lado certo dessa linha — comportamento e evidências, não implementação copiada. As próprias ferramentas de análise deste site adotam a mesma linha em miniatura: estáticas, locais, somente leitura, sem execução, sem contorno — uma primeira olhada, com o trabalho pesado e juridicamente sensível deixado para ferramentas e pessoas que podem assumir a responsabilidade por ele.

Experimente você mesmo

O REA precisa do Node.js 22 ou posterior; um único comando — npx rea-agents setup — registra seu servidor MCP nos agentes de programação que encontra e instala as instruções de fluxo de trabalho correspondentes, e o próprio comando doctor do REA verifica cada motor (um motor nativo como o Ghidra deve estar instalado para binários nativos; o JADX cobre os APKs). Aponte-o para software que você possui ou uma amostra que você tenha permissão para inspecionar — um pequeno utilitário que você escreveu é o primeiro alvo perfeito — e pergunte a ele como um recurso funciona. Leia a especificação que ele produz antes de ler qualquer pseudocódigo: os links de evidência são onde está a verdade.

Se você quer a versão sem instalação do primeiro passo, é para isso que serve o Binary File Inspector deste site: solte um arquivo PE, ELF ou Mach-O na página e leia seus cabeçalhos, seções, importações e strings no seu navegador — sem upload, sem execução, sem cadeia de ferramentas. Ele não vai descompilar nada, e diz isso claramente; é a triagem de cinco minutos que lhe diz se vale a pena configurar o tratamento completo do REA, e com qual motor.