REA Investigado: Como a Engenharia Reversa Assistida por IA Funciona

O que é REA—e por que as pessoas estão prestando atenção?

Você pode usar um aplicativo todos os dias sem saber como seus recursos funcionam por baixo da superfície. REA oferece aos assistentes de IA uma maneira de investigar esse comportamento—mesmo quando o código-fonte original não está disponível.

REA (Reverse Engineer Anything) é o projeto de código aberto em morluto/rea que conecta agentes de IA a fluxos de trabalho de análise de software. Expõe operações de análise através de uma interface de linha de comando—comandos de terminal digitados—e um servidor de ferramentas para aplicações de IA compatíveis. Um agente é uma aplicação de IA que pode usar ferramentas em uma tarefa de múltiplas etapas. REA fornece acesso a ferramentas de análise, não ao modelo de IA subjacente.

A distinção é importante: investigar uma aplicação finalizada, escrever uma implementação similar e recuperar seu código-fonte original são realizações diferentes. A utilidade do REA depende das evidências coletadas, das verificações aplicadas e das responsabilidades que permanecem. “Anything” é o nome do projeto, não uma garantia de que cada produto possa ser fielmente recriado.

Engenharia reversa: aprendendo com o programa finalizado

Engenharia reversa significa aprender como algo funciona examinando o resultado finalizado. Pense em uma máquina sem seus desenhos de design original: inspecionar suas peças e comportamento pode apoiar um novo design, mas não fornece os desenhos originais do designer. Da mesma forma, entender o comportamento do software não recupera o código-fonte que seus desenvolvedores escreveram.

Para um executável nativo, a forma pronta para o processador de um programa, um compilador traduz o código-fonte em instruções de máquina. Estas são operações que o processador entende. A compilação também pode otimizar o programa, reorganizando ou combinando trabalho enquanto preserva seu comportamento pretendido. O resultado é software executável, não um arquivo comprimido do projeto de origem.

Desassembly apresenta instruções de máquina como assembly legível. Decompilação vai além, inferindo lógica de nível superior, semelhante à fonte, chamada pseudocódigo. Ferramentas como Ghidra fornecem ambas as visualizações:

1) Forward production path:
Original source
       ↓
Compile / optimize
       ↓
Native executable

2) Separate analysis path:
Native executable
       ↓
Disassembly / decompilation
       ↓
Assembly / inferred pseudocode
  Original names, comments and structure may be missing
       ↓
Behavior to verify

Caso de código nativo: a compilação produz o executável; a análise infere uma visualização legível e comportamento para verificar. Não há um caminho reverso garantido para os arquivos de origem originais.

A perda de informação é desigual. Comentários e muitos nomes podem desaparecer, enquanto strings de texto, alguns nomes e metadados descritivos permanecem. A otimização pode tornar estruturas de origem familiares difíceis de reconhecer. Diferentes implementações de origem também podem produzir comportamento de máquina semelhante, portanto uma reconstrução plausível não precisa corresponder à expressão original do programador.

Nem toda aplicação é código de máquina nativo. JavaScript empacotado pode conter código-fonte legível ou código minificado, encurtado para distribuição. Ler material semelhante ao código-fonte já presente em um pacote é diferente de inferir pseudocódigo a partir de instruções de máquina. O que sobrevive determina quais questões a análise pode responder.

Como REA transforma uma pergunta em um loop de evidência

A investigação DX-Ball do projeto começou com uma pergunta prática: como a posição horizontal da tela de um tijolo determina o panorama de som, o equilíbrio entre áudio esquerdo e direito? A primeira visualização do decompilador mostrou uma chamada que converteu um número, mas omitiu a entrada e o cálculo por trás dela. Não foi o suficiente para explicar a posição do som.

A visualização de instruções revelou a entrada ausente e a aritmética. Inspecionar a função que a chamou mostrou que a entrada era a coordenada de tela do tijolo. Ler os valores armazenados forneceu os números fixos do cálculo e a configuração que dimensionou o panorama.

O resultado foi uma regra concreta: na escala usual, o centro da tela mapeia para panorama centralizado, enquanto posições em ambos os lados deslocam o equilíbrio para esquerda ou direita. O projeto de reconstrução poderia então escrever essa regra em C e compará-la com a função original.

Quatro papéis tornam essa investigação possível.

• Você define a pergunta autorizada.
• O agente escolhe acompanhamentos e interpreta resultados.
• REA fornece acesso a ferramentas e retorna evidência.
• Um mecanismo de análise ou parser inspeciona o artefato alvo—o arquivo ou pacote sendo examinado.

Os mecanismos nativos incluem Ghidra, Hopper e IDA.

A conexão usa Model Context Protocol (MCP), uma forma padrão para aplicações de IA alcançarem ferramentas e sistemas externos. O servidor MCP de REA é o software expondo essas operações, não uma máquina que você deve alugar. Uma skill fornece instruções de investigação para o agente; o servidor fornece acesso às operações em si. A troca central se parece com isto:

Your feature question
         ↓
Agent
         ↕ MCP
REA tool server
         ↕
Analysis engine / parser
         ↕
Target software

As solicitações viajam em direção ao alvo; a evidência retorna ao agente, que a usa para escolher a próxima pergunta. A troca se repete conforme a investigação se desenvolve.

O agente coordena esses acompanhamentos e conecta o código retornado e as referências em uma explicação. Os registros de evidência identificam os locais do arquivo e do código, separando observações de inferências e descobertas não resolvidas. Um revisor pode, portanto, rastrear a explicação de volta ao seu material de apoio. O agente também pode rascunhar código candidato e testes, como uma etapa separada do estabelecimento do que o original faz.

Para qualquer alvo, distinga inspeção estática, que lê artefatos sem executar o programa, de observação ou interação em tempo de execução, que o examina enquanto está em execução. Onde essa inspeção acontece também é separado de onde o modelo processa suas descobertas. Se o agente usar um modelo hospedado, os resultados retornados podem sair da máquina de análise.

Que tipos de software o REA pode inspecionar?

A visibilidade depende do alvo. Electron empacota software desktop usando tecnologias web, enquanto .NET e Android representam famílias de aplicações distintas com caminhos de análise diferentes. Cada um expõe informações diferentes, como mostra a tabela:

REA documenta cobertura de artefatos mais ampla além dessas categorias. Verifique a visão geral oficial do alvo e a documentação atual: os requisitos variam por mecanismo, plataforma host, alvo e versão. Estes descrevem fluxos de trabalho de inspeção disponíveis, não reconstruções verificadas de cada alvo.

Uma demonstração convincente não é uma reconstrução verificada

Demonstrações públicas dão uma visão mais concreta do que REA pode fazer. Em uma recriação de calculadora compartilhada online, análise assistida por IA produziu uma versão Python do GNOME Calculator. Ao lado de recriações visíveis como esta, projetos mais específicos comparam um cálculo reconstruído diretamente com o original.

Demonstração pública — relatada em segunda mão
A recriação se assemelhava ao GNOME Calculator e correspondia a um resultado aritmético básico. Problemas de redimensionamento relatados expuseram uma incompatibilidade visível que uma verificação aritmética bem-sucedida não detectaria.

Reconstrução de função relatada pelo projeto
O showcase DX-Ball relata 3.205 casos de comparação original-x86 para uma função de posição-para-som-pan, além de bytes compilados correspondentes usando um compilador histórico.

A calculadora demonstra uma recriação visível; DX-Ball documenta verificações de um cálculo específico. Cada resultado responde a uma pergunta diferente.

Para DX-Ball, as comparações cobriram posições de tela e várias intensidades de pan. Eles verificaram os valores de retorno da função C contra aqueles da execução das instruções originais. Compilar esse C com um compilador histórico também reproduziu os bytes da função. Estas são duas verificações distintas: concordância em saídas testadas e concordância na função compilada, sem exigir o texto de código-fonte original do programador.

GNOME Calculator também possui recursos avançados, financeiros e de programação. A comparação aritmética simples deixa esses recursos não avaliados, em vez de mostrar se funcionam ou falham na recriação. Seu código-fonte é público, portanto a revisão de código-fonte pode ser o ponto de partida mais direto quando responde sua pergunta de manutenção. A progressão útil é de semelhança visual para verificações de comportamento selecionado, depois comparações sistemáticas para o comportamento que você precisa.

Onde a promessa do “qualquer coisa” atinge seus limites

A falta de contexto de fonte pode tornar um componente difícil de interpretar. A otimização pode obscurecer sua lógica, enquanto a ofuscação torna deliberadamente o código mais difícil de entender. As dependências externas criam outra lacuna: alguns caminhos de execução precisam de entradas, serviços ou condições indisponíveis durante a investigação. Mesmo uma análise cuidadosa pode deixar casos extremos não resolvidos quando um recurso depende de comportamento fora do componente inspecionado.

Um contrapeso independente vem do relatório de Ishank Choudhary de 14 de outubro de 2026, cobrindo REA 6.4.0. Ele encontrou estrutura útil de aplicação Electron, mas perdeu conexões de pré-carregamento: o código de ponte vinculando uma página Electron com capacidades do lado do desktop. Ele testou ferramentas estáticas sem um agente ou mecanismos de análise nativa; os achados dizem respeito a esse lançamento e fluxo de trabalho, não a cada versão atual.

O relatório também descreveu relacionamentos omitidos do resumo da aplicação por causa de orçamentos de resultado—limites na saída retida. Alguns fatos permaneceram no nível de arquivo sem suas conexões aparecendo no resumo. Uma verificação concluída sem correspondência significava portanto que a análise retida não havia encontrado o relacionamento, não que o recurso estava ausente. Seus limites de cobertura explicaram a falha.

O esforço começa com a configuração do mecanismo de análise e fornecimento da potência de processamento e memória que ele precisa. O uso de modelo traz suas próprias considerações: o contexto determina quanto material ele pode considerar de uma vez, enquanto tokens são as unidades de texto que ele processa. Consultas repetidas adicionam esforço, seguidas de testes e reparos humanos após a primeira saída. Contas reais, necessidades de hardware e tempos de conclusão dependem do alvo e da pergunta. Medir a própria contribuição de REA para velocidade ou qualidade exigiria uma comparação controlada.

Aplicações úteis além de copiar um app

Para desenvolvedores, self-hosters e equipes de migração, o valor geralmente reside em responder a uma pergunta específica de manutenção ou compatibilidade. Os seguintes cenários são ilustrativos, não implantações testadas ou resultados deste editor.

🛠️ Desenvolvedor / mantenedor

Um mantenedor comparando duas versões autorizadas de um utilitário legado pode perguntar por que um resultado de importação mudou. REA poderia ajudar a localizar a lógica de análise e orientar verificações de regressão. Se o código-fonte completo já responder essa pergunta, comece por lá; caso contrário, valide a causa inferida contra o comportamento alterado.

🏠 Self-hoster

Um self-hoster trabalhando com um formato de arquivo local antigo pode usar REA para entender seus campos. Essas descobertas poderiam ajudar a definir uma ponte de compatibilidade implementada independentemente. Um substituto lawful e drop-in para a dependência proprietária ainda exigiria testes de casos não documentados e verificação dos direitos aplicáveis.

💼 Negócio / equipe de migração

Uma equipe de migração pode precisar saber se um comportamento de exportação necessário pode ser suportado antes de encomendar a implementação. REA poderia ajudar a estabelecer viabilidade técnica e esclarecer o que precisa ser construído. Essa descoberta pode informar uma decisão de investimento, enquanto estimativas de entrega, compromissos de suporte e compatibilidade total exigem avaliação adicional.

Educação e pesquisa de segurança autorizada podem usar a mesma abordagem. Antes de passar de uma explicação para uma ação adicional, defina o que pode ser inspecionado, executado ou compartilhado. Esse escopo governa a investigação mesmo quando a pergunta técnica parece direta.

O acesso técnico não estabelece autorização, privacidade ou confiança

A permissão para inspecionar um arquivo pode diferir da permissão para executá-lo, observar seu tráfego, publicar descobertas ou reutilizar material protegido. Os direitos dependem da lei aplicável e de contratos: direitos de interoperabilidade condicional, incluindo os dos EUA, não são regras mundiais, e possuir uma cópia não autoriza todas as operações.

A licença MIT da REA cobre código de autoria da REA, não aplicações de destino, ativos protegidos ou saída gerada automaticamente. Motores de análise comercial precisam de suas próprias licenças. O aviso de uso responsável define usos pretendidos e limites de suporte da comunidade sem alterar o MIT; código-fonte recuperado não se torna automaticamente código aberto ou redistribuível.

⚠️ Aviso: Riscos de privacidade e execução

A análise local pode enviar descobertas—incluindo código, credenciais ou dados pessoais—para o provedor de modelo do agente. Verifique dados de saída e termos do provedor antes de analisar destinos confidenciais. REA não é uma sandbox: análise estática pode expor vulnerabilidades de ferramentas, enquanto executar ou interagir com destinos pode alterar arquivos ou afetar contas e serviços. Revise as operações reais e contenção, não apenas onde as ferramentas são executadas.

Use fontes oficiais de pacotes e atualizações, mas também revise dependências, saída gerada, propriedade de manutenção e como as correções chegam. Aplique o mesmo escrutínio a software de fornecedor, projetos de código aberto e alternativas geradas por IA: origem oficial, preço, disponibilidade de fonte ou compilação a partir da fonte não podem substituir um histórico claro de proveniência e revisão.

O que REA significa para propriedade de software e a nuvem

Reconstruir software uma vez não financia seu futuro. Alguém deve manter as vulnerabilidades corrigidas e preservar a compatibilidade. Suportar usuários e desenvolver o produto também requerem trabalho contínuo. Investigação mais acessível pode complementar o trabalho de especialistas; estes exemplos não mostram desenvolvedores ou software pago se tornando obsoletos. Atualizações confiáveis e suporte responsável permanecem razões para escolher um produto, mesmo quando sua implementação se torna mais fácil de entender.

Fornecedores poderiam responder movendo mais funcionalidade para entrega apenas remota, mas as evidências aqui não estabelecem uma tendência impulsionada por REA. A distinção técnica é cliente versus servidor: um navegador recebe código de interface e respostas, enquanto a implementação do lado do servidor normalmente permanece com o operador.

Browser / client: delivered UI and scripts
Inspectable to the extent delivered / authorized
                   ↕
           Requests / responses
                   ↕
Server: application logic and database
Behavior observed ≠ exact private source revealed

Um limite de visibilidade, não um limite de segurança completo: recursos do navegador e respostas podem ser examinados; código backend normalmente permanece remoto. Dados expostos e outros problemas de segurança permanecem possíveis.

Essas respostas de API—dados trocados com o serviço—podem revelar o suficiente sobre o comportamento de um recurso para informar uma nova implementação. Essa rota depende de entradas e saídas observáveis em vez de acesso ao código backend. Manter o código remoto também não elimina bugs, dados expostos ou a possibilidade de investigação autorizada.

Com SaaS, software como serviço, um fornecedor opera a aplicação.

• Auto-hospedar uma aplicação autorizada oferece mais controle sobre a implantação. Você então assume a responsabilidade de corrigir e gerenciar o acesso.
• Backups, monitoramento e recuperação também se tornam parte da manutenção dessa aplicação em funcionamento.

Um AlexHost Ubuntu VPS é uma opção de infraestrutura para uma aplicação revisada ou ponte de compatibilidade. Acesso root completo oferece controle sobre o sistema operacional convidado. Isso não protege a aplicação automaticamente ou torna o processamento de modelo externo privado.

O essencial: investigação mais fácil, não recuperação automática

Uma janela de calculadora reconhecível pode ser um primeiro resultado promissor. As próximas questões são se o comportamento que você precisa foi verificado e quem o manterá. REA ajuda a investigar esse comportamento; implementação, verificação e operação confiável permanecem como trabalho separado.

Para leitura mais aprofundada, comece com o projeto REA oficial e seu showcase DX-Ball. Concentre-se em uma pequena questão autorizada e nas evidências por trás da resposta. Esse é um ponto de partida mais útil do que perguntar se a IA pode copiar um produto inteiro.