REA: Engenharia Reversa com Agentes de IA

Antes de implementar uma funcionalidade parecida com a de outro sistema, você pode investigar como ela funciona. O REA, Reverse Engineer Anything, conecta agentes de IA a ferramentas de análise de software, por MCP ou terminal. O objetivo é apoiar conclusões com evidências, não apenas com uma descrição convincente.

Este artigo acompanha o infográfico e explica o que investigar, como interpretar os resultados e quais cuidados tomar. A documentação foi consultada em 14/10/2026. A criação desta publicação não instalou REA nem analisou aplicativos de terceiros.

O papel do agente e das ferramentas

O agente formula perguntas, chama ferramentas e interpreta os resultados. O REA fornece observações sobre o alvo analisado. Pelo MCP, o agente acessa essas operações; pelo terminal, você pode usar os fluxos correspondentes diretamente.

Uma boa pergunta delimita o trabalho: “Como esta busca trata palavras com acento?” é mais verificável do que “Explique tudo sobre este aplicativo”. Como prática de estudo, peça a localização da evidência e uma explicação sobre o que ainda não foi possível concluir.

O que pode ser analisado?

• JavaScript e Electron: relações entre módulos e rastreamento de funcionalidades por elementos como rotas, strings, APIs e canais IPC. Uma relação encontrada no código não deve ser confundida com comportamento observado em execução.
• Binários nativos: funções, instruções, chamadas, referências e pseudocódigo. A análise utiliza um provedor compatível, como Hopper ou Ghidra; a cobertura varia conforme a ferramenta e o sistema.
• Assemblies .NET: metadados, assinaturas e instruções CIL, a linguagem intermediária desses artefatos. O fluxo documentado inspeciona arquivos sem carregar ou executar o código do assembly.
• Sites: observação de uma página em navegador da família Chrome por CDP, com estrutura, scripts e metadados de rede. Isso não equivale a ter acesso ao código do servidor nem transforma uma captura em autorização para testar qualquer sistema.

O infográfico resume alguns alvos. Antes de começar, confira no guia específico quais dependências, permissões e limites se aplicam ao seu caso. “Pode analisar” não significa “recupera tudo”.

1. Investigar uma pergunta concreta

No fluxo apresentado, o agente consulta o alvo e acompanha o código relacionado à funcionalidade. Os resultados trazem evidências para orientar as próximas perguntas. Como exercício, escolha um programa próprio ou autorizado e registre o comportamento que você pretende compreender.

Por exemplo: em uma busca, anote as entradas usadas, os resultados esperados e os casos que causam dúvida. Preserve uma cópia de trabalho e mantenha os dados de teste separados dos dados reais. Esse planejamento é uma recomendação didática, não uma garantia automática do REA.

2. Entender e distinguir evidência de hipótese

O agente pode usar as descobertas para explicar a funcionalidade. Para revisar a explicação, separe o que foi observado do que foi inferido. Uma string chamada “search” é uma pista; sozinha, ela não demonstra todo o algoritmo de busca.

Na análise nativa, um caminho estático entre funções não prova que ele será executado em qualquer cenário. Resultados parciais ou dados indisponíveis precisam continuar explícitos. Peça ao agente que indique essas lacunas em vez de completar a explicação por suposição.

3. Criar uma implementação própria e testar

Depois de compreender a funcionalidade, você pode usar as descobertas como apoio para escrever e testar uma implementação adaptada ao seu projeto. Defina antes os requisitos: entradas aceitas, saída esperada e comportamento nos casos de erro.

Uma implementação semelhante precisa ser avaliada no seu contexto. Sugestão de revisão: compare os resultados de casos normais, entradas vazias, caracteres especiais e situações ambíguas. Não apresente o código gerado como equivalente ao original sem ter realizado essa comparação.

Exemplo didático: investigar uma busca autorizada

Considere um aplicativo de notas desenvolvido pela sua equipe. Você recebeu autorização para analisar sua busca e quer implementar uma funcionalidade semelhante em outro projeto. Este é um cenário fictício; nenhuma investigação foi executada neste artigo.

1. Delimite a pergunta: a busca considera título, conteúdo ou ambos? Diferencia maiúsculas e acentos?
2. Peça evidências: quais trechos e observações sustentam cada resposta? O que ainda está desconhecido?
3. Especifique sua versão: escolha conscientemente quais comportamentos fazem sentido no novo produto.
4. Teste: experimente termos presentes e ausentes, texto vazio, acentos e diferenças de caixa.
5. Revise: confira código, testes e direitos sobre os materiais antes de incorporar a implementação.

A pergunta proposta para o agente pode ser:

Analise apenas este aplicativo autorizado. Investigue como sua busca funciona, apresente as evidências e os limites da análise. Depois, proponha uma implementação própria para o meu projeto e testes para validar o comportamento. Não altere o aplicativo analisado.

Como começar: configuração não é análise concluída

O comando mostrado no infográfico continua presente no guia oficial de configuração consultado:

npx rea-agents setup

Use Node.js em uma versão compatível e npm, conforme os requisitos atuais. O assistente permite selecionar agentes, revisar caminhos e mudanças e aprovar a configuração antes da gravação. A autorização do npm para baixar o pacote e a aprovação do assistente são etapas distintas. Reinicie os agentes indicados ao final.

Para análise nativa, verifique o provedor necessário. O assistente pode oferecer instalação opcional do Hopper mediante aprovação ou trabalhar com uma instalação existente do Ghidra. Esses programas têm seus próprios requisitos e condições de uso.

O comando é apenas ilustrativo: não foi executado nesta produção editorial e não configura automaticamente um projeto do leitor. Comece com um alvo pequeno, autorizado e uma pergunta que possa conferir.

Limites: análise não é recuperação perfeita

O pseudocódigo de um binário é uma representação útil para investigação, não uma promessa de recuperar o código-fonte original. Evidências estáticas, inferências do provedor e observações em execução têm alcances diferentes. A documentação de responsabilidade também alerta que decompilação, reconstrução e análise assistida por IA podem estar incompletas ou incorretas.

O nome “Reverse Engineer Anything” não deve ser lido como garantia de clonar qualquer aplicativo. Confirme o que a ferramenta realmente retornou, revise as conclusões e teste qualquer implementação gerada antes de confiar nela.

Permissões, privacidade e responsabilidade

Analise apenas software próprio ou que você esteja autorizado a examinar. Ter um arquivo ou acesso público a um aplicativo não concede, por si só, permissão para todas as operações. O projeto rejeita usos como contornar licenças, proteções técnicas e controles de acesso, além de copiar código e recursos proprietários protegidos.

Autorização para ler um artefato não é necessariamente autorização para executá-lo, interceptar tráfego ou interagir com um serviço. Algumas operações podem modificar estado ou produzir atividade de rede. Reveja o escopo e use um ambiente apropriado para alvos não confiáveis.

O REA descreve análise local, mas os resultados chegam ao agente, cujo provedor de modelo possui sua própria política de dados. Como cuidado de projeto, não envie credenciais, dados pessoais ou material confidencial sem verificar as regras aplicáveis à sua equipe.

Use o agente para formular e verificar explicações. O resultado precisa mostrar o que foi encontrado, o que foi inferido e o que continua desconhecido.