REA: como agentes de IA conectam ferramentas de engenharia reversa

O REA não é um novo decompilador universal. Seu diferencial está em reunir agentes, CLI, MCP, workflows, sessões, evidências e ferramentas especializadas em um fluxo comum.

Quando vi o REA pela primeira vez, uma coisa pareceu mais interessante do que a promessa de “reverse engineer anything”: ele junta ferramentas que já existiam.

Ghidra, Hopper e IDA analisam binários nativos. JADX e Apktool trabalham com Android. GDB, pwndbg e pwntools ajudam com processos, ELF e crashes. TShark e mitmproxy observam tráfego. WABT inspeciona WebAssembly. Frida instrumenta aplicações em execução. O desafio é que uma investigação real atravessa várias dessas superfícies.

Parte do tempo vai para entender o alvo. Outra parte vai para mover endereços, pseudocódigo, capturas e hipóteses entre ferramentas e lembrar por que cada descoberta importava. O REA tenta reduzir exatamente essa fricção.

O que o REA é — e o que ele não é

A arquitetura fica mais clara quando separamos quatro papéis. O desenvolvedor define a pergunta e o escopo. O agente escolhe próximos passos e interpreta resultados. O REA expõe CLI e MCP, descobre provedores, mantém sessões, normaliza respostas e preserva evidências. As ferramentas especializadas realizam decompilação, assembly, referências, inspeção de aplicações, captura ou análise de runtime.

1pergunta e escopo2  → agente e modelo3    → REA: CLI, MCP, workflows, sessões e Evidence4      → provedores e analisadores especializados5        → alvo autorizado67evidências, hipóteses, implementação e testes retornam pelo fluxo

Dizer que o REA substitui Ghidra, Hopper ou IDA seria incorreto: a análise nativa profunda continua dependendo desses provedores. Também seria limitado tratá-lo como um wrapper fino. O projeto possui analisadores próprios ou incorporados para alguns domínios, como JavaScript e Electron, .NET/CIL, metadados de binários Go, SQLite e inventário de artefatos.

Como uma investigação pode acontecer

1. Definir o alvo autorizado, a pergunta e o limite da análise.
2. Identificar quais provedores estão disponíveis para aquele formato ou plataforma.
3. Localizar strings, símbolos, funções, módulos ou comportamentos candidatos.
4. Seguir chamadas, referências e fronteiras entre processos ou camadas.
5. Registrar endereços, hashes, trechos, limitações e pontos desconhecidos.
6. Propor uma explicação ou implementação sem confundi-la com o código-fonte original.
7. Comparar o resultado com o comportamento observado e ampliar os testes.

CLI e MCP usam os mesmos workflows. Isso permite iniciar uma inspeção no terminal, produzir resultados estruturados e continuar a investigação com um agente. Snapshots, versões, hashes e provedores tornam o caminho mais fácil de repetir — desde que a equipe realmente registre essas informações.

Evidence é o ponto mais interessante

Modelos são bons em produzir explicações plausíveis. Engenharia reversa exige explicações sustentadas por artefatos. O modelo de Evidence do REA tenta manter essa diferença visível ao carregar origem, operação, endereço ou trecho, confiança, limitações e relações com outras evidências.

• Observado: veio diretamente do artefato ou de uma execução específica.
• Inferido: é uma interpretação consistente, mas não foi observado diretamente.
• Derivado: combina outras evidências ou resultados.
• Desconhecido ou indisponível: a ferramenta não conseguiu sustentar a conclusão.

Evidence não elimina alucinações. Ela cria uma estrutura para confrontá-las. Pseudocódigo incompleto, análise estática e poucos testes continuam exigindo revisão.

O que os showcases realmente demonstram

No caso de DX-Ball 1.07, a investigação seguiu uma chamada de áudio até a função que convertia posição em panning. Como o primeiro pseudocódigo era incompleto, foi necessário conferir caller, instruções e constantes. A reconstrução em C passou por 3.205 casos contra a função x86 original e reproduziu os 63 bytes compilados da função, após considerar relocações.

O showcase do Notion percorre uma funcionalidade de clipboard em uma aplicação Electron: renderer, preload, IPC e processo principal. O caso de Touhou 4 analisa instruções de 16 bits de um jogo PC-98, recupera cálculos de ângulo e compara a reconstrução em C++ com a saída do compilador histórico.

Esses exemplos mostram investigações estreitas, evidenciadas e testadas. Eles não demonstram que qualquer aplicativo pode ser transformado em um clone completo com um único prompt.

Oito ganhos possíveis da integração

• Menos transporte manual de endereços, referências e resultados entre interfaces.
• Continuidade de contexto para perguntas de acompanhamento.
• Fluxo iniciado por uma pergunta, não por uma navegação sem direção.
• Evidências, limitações e desconhecidos anexados às conclusões.
• Reprodutibilidade por versão, hash, snapshot, provedor e comandos.
• Integração entre JavaScript, IPC, bibliotecas nativas, formatos e runtime.
• Workflows que ajudam no aprendizado sem substituir conhecimento técnico.
• Ponte mais curta entre hipótese, implementação e teste diferencial.

Local-first ajuda, mas não significa isolamento total

O REA afirma analisar os alvos localmente. Isso evita que o aplicativo seja enviado automaticamente a um serviço hospedado pelo projeto, mas os resultados consultados pelo agente continuam sujeitos à política de dados do provedor do modelo. Strings, pseudocódigo, caminhos, metadados e capturas podem conter informação sensível.

Local também não significa sandbox. Análise dinâmica pode executar ou interagir com processos, dispositivos, rede e arquivos usando as permissões do usuário. Artefatos desconhecidos precisam de ambiente apropriado, isolamento e escopo explícito. O setup modifica registros MCP e instala instruções para o agente; o plano e os backups devem ser revisados antes da aprovação.

Um projeto ambicioso e ainda jovem

Este artigo usa como snapshot o pacote rea-agents 6.4.0, verificado em 13 de outubro de 2026. O repositório apresenta documentação extensa, contratos tipados, CI, política de segurança e muitas trilhas de teste. São sinais positivos de investimento em engenharia interna.

Ao mesmo tempo, o próprio README alerta que o REA muda rapidamente e recebe correções frequentes. Uma demonstração responsável deve fixar versão do REA e do Node.js, agente e modelo, provedor de análise, sistema operacional, arquitetura, hash do alvo, comandos, snapshots e testes usados como oráculo.

REA, Adobe e o cuidado com associações não demonstradas

A repercussão recente sobre engenharia reversa com IA também envolveu projetos open source para fluxos associados a aplicativos da Adobe. Até este levantamento, não encontrei evidência primária de que ArtCraft, PhotoCraft ou os demais projetos tenham usado REA. Eles fazem parte de uma onda semelhante de desenvolvimento assistido por agentes, mas coexistência temporal não demonstra causalidade.

A licença MIT do código do REA não concede direitos sobre o alvo analisado, marcas, ativos, formatos protegidos ou ferramentas comerciais integradas. Autorização e licenças continuam sendo problemas separados.

Como eu avaliaria o REA sem repetir o marketing

1. Escolher um artefato próprio, open source ou explicitamente autorizado.
2. Escrever uma pergunta estreita cuja resposta possa ser verificada.
3. Registrar versão, ambiente, agente, modelo, provedor, hash e comandos.
4. Executar uma linha de base manual ou usando diretamente a ferramenta especializada.
5. Repetir a investigação com REA e comparar tempo, contexto preservado e qualidade das evidências.
6. Transformar a conclusão em implementação ou teste quando isso fizer sentido.
7. Revisar falsos positivos, pontos desconhecidos, alterações no alvo e efeitos de permissões.

Esse experimento ainda é um próximo passo. Minha análise aqui é sobre documentação, arquitetura declarada e showcases públicos — não uma alegação de validação prática independente do produto.

Conclusão

O REA não torna qualquer software automaticamente copiável e não transforma um modelo em analista infalível. Ele faz algo mais específico: conecta agentes a ferramentas maduras, preserva contexto, organiza evidências e aproxima investigação, implementação e testes.

Isso pode reduzir trabalho mecânico e tornar conclusões mais auditáveis. Também exige disciplina com autorização, versões, permissões, privacidade, licenças e validação. A ferramenta não remove o analista; muda onde o analista concentra atenção.