Seu agente de IA agora lê código que você não escreveu

Imagine pedir pro Claude Code ou Cursor: “me explica como esse app exporta dados em CSV”. Sem código-fonte. Sem documentação. Só o binário compilado. Parece ficção, mas é exatamente isso que o REA faz, e o projeto acumulou mais de 13 mil stars no GitHub em menos de uma semana.

REA, sigla para Reverse Engineer Anything, é um servidor MCP open source que conecta agentes de IA a ferramentas clássicas de engenharia reversa como Ghidra, IDA Pro e Hopper. O resultado? Você conversa com seu agente em linguagem natural e ele destrincha binários, apps Electron, APKs Android, smart contracts e até firmware de IoT.

O que é MCP e por que isso muda tudo

Model Context Protocol (MCP) é o padrão aberto que permite que agentes de IA descubram e usem ferramentas externas através de um servidor local. Pense nele como uma ponte: de um lado está o Claude Code (ou Cursor, Codex, Gemini CLI), do outro estão ferramentas especializadas como o Ghidra.

Antes do MCP, se você quisesse usar IA para entender um binário, precisava descompilar manualmente, copiar o pseudocódigo, colar no chat, e torcer pro modelo entender o contexto. Com o REA, o agente faz tudo sozinho: pede a análise, recebe o resultado estruturado, e te entrega conclusões com evidências.

A parte crucial: tudo roda local. Os binários nunca saem da sua máquina. O que vai pro modelo é apenas o resumo da análise, não o código descompilado inteiro.

O que o REA consegue analisar

A lista de alvos suportados é absurdamente ampla:

O detalhe que chamou minha atenção: para binários nativos, você não precisa de licença paga. O Ghidra, que é open source e mantido pela NSA, resolve o trabalho pesado. IDA Pro e Hopper são opcionais.

Instalação em 1 comando

A instalação é ridiculamente simples:

npx rea-agents setup

Esse comando registra o servidor MCP no seu agente, instala as instruções de workflow, e faz backup da configuração existente. Depois é só reiniciar o agente.

Se preferir instalar globalmente:

npm install --global rea-agents
rea --help

Requisitos mínimos: Node.js 22.x (versão 22.19 ou superior), Node.js 24.x (24.11+) ou Node.js 26+. Para análise de binários, precisa do Ghidra instalado.

Os agentes suportados nativamente incluem Claude Code, Cursor, Codex, Gemini CLI, Grok Build e qualquer outro compatível com MCP.

Como funciona na prática

Eu sei que a parte técnica pode parecer abstrata. Vamos a um exemplo concreto.

Digamos que você encontrou um app de notas com uma funcionalidade de exportação CSV e quer entender exatamente como ele monta o arquivo.

Passo 1: Análise estática

npx rea-agents analyze-javascript-application /caminho/do/app --json

O REA varre os arquivos, monta um grafo de dependências, identifica módulos, mapeia canais IPC (no caso de Electron), e retorna tudo em JSON estruturado. Num fixture de teste de 1.648 bytes, o REA gerou 907 KB de análise estruturada com 21 findings em 1,3 segundo.

Passo 2: Rastrear uma feature específica

npx rea-agents trace-application-feature /caminho/do/input.json --format json

O tracer segue o caminho completo: renderer, preload, canal IPC, processo principal, formatter, arquivo CSV. No caso de teste, retornou 29 nós com cobertura completa do código-fonte.

Passo 3: Pedir pro agente reimplementar

Com o Claude Code conectado via MCP, você pode simplesmente pedir: “Com base na análise do REA, reimplemente a lógica de exportação CSV desse app.”

O agente lê os findings, entende a lógica de escaping (como aspas duplas são tratadas dentro de títulos), e gera uma implementação independente. Nos testes, 14 cenários (campos vazios, Unicode, quebras de linha, condições combinadas de escaping) resultaram em saída byte-a-byte idêntica ao original.

Os 3 case studies que impressionaram

O repositório do REA inclui três estudos de caso que mostram o potencial real da ferramenta.

DX-Ball: reconstruindo cálculo de som

O agente analisou o binário do jogo DX-Ball e reconstruiu o cálculo de pan de áudio (posicionamento estéreo do som com base na posição da bola). O resultado: 3.205 casos de teste validados contra 63 bytes de função compilada. A reimplementação bateu em todos.

Notion: rastreando a clipboard bridge

Esse é o mais impressionante para quem trabalha com Electron. O REA rastreou como o Notion implementa copy/paste: preload injeta handler, IPC transmite para o processo principal, que formata e entrega pro clipboard do sistema. O mapeamento completo dos canais IPC e a separação entre renderer e main process ficaram explícitos na análise.

TH04: recuperando lógica de jogo DOS de 16 bits

Um jogo DOS de 16 bits. O agente recuperou o cálculo de “bullet ring” (padrão circular de projéteis) e comparou com a saída do compilador original. Engenharia reversa arqueológica, essencialmente.

Segurança e limitações (que ninguém está falando)

Toda ferramenta que facilita engenharia reversa levanta questões legais e éticas. O REA coloca um aviso claro: o uso deve ser para “pesquisa legítima de engenharia reversa” e o usuário é responsável por obter autorizações necessárias.

Na parte técnica, existem limitações reais que vale conhecer:

Estático não é dinâmico. O REA analisa código como ele existe no disco. Uma conexão recuperada entre módulos não garante que aquele código executa em runtime, que a feature é alcançável em todos os estados, ou que uma configuração de segurança é enforçada.

Escopo finito. A análise cobriu casos finitos com arrays densos e IDs numéricos. Valores JavaScript exóticos podem produzir resultados diferentes.

44 incógnitas no grafo semântico. No caso de teste mais amplo, o grafo reteve 25 chamadas dinâmicas e 19 alvos ambíguos que o REA não conseguiu resolver. Isso é normal em análise estática, mas significa que o resultado não é completo em 100% dos cenários.

Nada substitui validação manual. A recomendação oficial: “escolha uma feature com output observável, inspecione os locais de código citados, anote o comportamento, e compare a menor reimplementação útil contra inputs que possam expor uma explicação errada.”

Por que explodiu agora

O timing do REA é perfeito. O ecossistema MCP amadureceu, Claude Code, Cursor e Codex já suportam servidores MCP nativamente, e a comunidade de segurança percebeu que agentes de IA podem acelerar drasticamente workflows de engenharia reversa que antes levavam dias.

Tem também o fator “democratização”. Antes, engenharia reversa exigia anos de experiência com assembly x86, entendimento profundo de calling conventions, e paciência para navegar milhares de funções descompiladas no Ghidra. O REA não elimina a necessidade de conhecimento, mas reduz absurdamente a barreira de entrada.

Um pesquisador de segurança pode pedir: “encontre todas as funções que manipulam input do usuário sem sanitização nesse binário” e o agente faz o trabalho braçal de navegar pelo código descompilado.

Comparação: REA vs. usar Ghidra sozinho

Claro que um analista experiente vai pegar nuances que o agente perde. Mas para 80% do trabalho repetitivo de “entender o que esse binário faz”, o REA automatiza o processo.

Como configurar com Claude Code

Se você usa Claude Code, a configuração é direta. Após o npx rea-agents setup, o MCP server é registrado automaticamente. Na próxima sessão, o Claude Code já reconhece as ferramentas do REA.

Para uma análise de binário nativo, você precisa do Ghidra instalado:

# No Ubuntu/Debian
sudo apt install ghidra

# No macOS com Homebrew
brew install --cask ghidra

Depois, é só abrir o Claude Code no diretório do binário e pedir a análise:

> Analise o binário ./app e me explique como a autenticação funciona

O agente vai chamar as ferramentas do REA via MCP, descompilar com Ghidra, e retornar a análise com evidências de cada conclusão.

Para apps Electron (como Notion, Discord, VS Code, Slack), não precisa de Ghidra. O analisador JavaScript do REA reconstrói grafos de dependência, parseia nós AST, e mapeia canais IPC entre processos renderer e main, mesmo com código minificado.

Implicações para segurança ofensiva e defensiva

Do lado defensivo, o REA é uma ferramenta poderosa para análise de malware. Recebeu um binário suspeito? Joga no REA e pede pro agente: “identifique comportamentos maliciosos, exfiltração de dados, e comunicação com servidores externos.”

Do lado ofensivo (em contexto autorizado: pentesting, bug bounty, CTF), o REA acelera a descoberta de vulnerabilidades em binários compilados. Encontrar buffer overflows, use-after-free, e lógica de autenticação fraca fica ordens de magnitude mais rápido.

Para CTFs especificamente, o REA é quase trapaça. Desafios de engenharia reversa que levariam horas podem ser resolvidos em minutos com o agente navegando pelo código descompilado.

Casos de uso que ninguém menciona

Fora os cenários óbvios de segurança, o REA abre portas para usos que pouca gente considerou.

Auditoria de dependências. Aquela lib binária que seu projeto usa e que ninguém entende o que faz por dentro? O REA pode destrinchar. Imagine descobrir que uma SDK de analytics está fazendo chamadas HTTP para servidores que não constam na documentação.

Migração de software legado. Empresas que têm sistemas compilados de 15, 20 anos atrás, sem código-fonte, sem documentação, sem ninguém que lembre como funciona. O REA não vai te dar o código original de volta, mas pode mapear a lógica de negócio o suficiente para reconstruir.

Aprendizado. Quer entender como o SQLite implementa B-trees? Como o curl faz negociação TLS? Antes você teria que ler milhares de linhas de C. Agora pode pedir pro agente: “me explique como o SQLite decide quando fazer split de um nó B-tree” e ele vai direto na função relevante do binário.

Competição e benchmarking. “Como o concorrente implementa rate limiting no backend dele?” Eticamente questionável em alguns contextos, completamente legítimo em outros (interoperabilidade, compatibilidade, pesquisa). A ferramenta é neutra, o uso é que define.

O que falta no REA hoje

Apesar de todo o hype, o REA ainda tem gaps consideráveis.

Análise dinâmica é limitada a observação de processo via PTY no Linux/macOS. Não tem hooking de funções, tracing de syscalls, ou instrumentação de runtime como Frida. Para análise de malware sofisticada, você ainda precisa de um sandbox dedicado.

Suporte a Windows é experimental. A análise de binários via Ghidra funciona, mas o tracing de processos e a extração de ASAR (para apps Electron no Windows) ainda têm arestas.

Não há suporte a iOS. Binários Mach-O de iPhone, apps do App Store decryptados, frameworks do sistema: nada disso está no escopo atual. Dado o crescimento do ecossistema Apple, é uma lacuna relevante.

Performance com binários grandes pode ser um problema. Um executável de 200MB vai gerar uma análise do Ghidra que pode ultrapassar o limite de contexto do agente. O REA mitiga isso enviando apenas resumos, mas em binários complexos o agente pode perder nuances por não ter o quadro completo.

O futuro da engenharia reversa é conversacional

O que o REA representa vai além de uma ferramenta. É a primeira implementação séria de engenharia reversa guiada por IA via MCP. Outros projetos vão seguir esse modelo, com integrações mais profundas, suporte a mais plataformas, e capacidades de análise dinâmica.

A tendência é clara: as ferramentas de segurança estão migrando de interfaces gráficas complexas para conversas com agentes. Ghidra, Burp Suite, Wireshark, todas essas ferramentas vão ganhar wrappers MCP nos próximos meses. O REA é só o começo.

O repositório está em rea.tools sob licença MIT. Se você trabalha com segurança, análise de malware, ou simplesmente quer entender como um app funciona por dentro, a instalação leva menos de um minuto. E depois de experimentar, fica difícil voltar pro fluxo manual.

Fonte de inspiração: REA: Reverse Engineer Anything (trending no Hacker News com 469+ pontos)