Deep Content #11 - REA: como a IA reconstrói funções sem o código-fonte original

Boa tarde. Bem-vindo novamente à InferêncIA News.

Quando você abre um programa antigo e percebe que uma função ainda faz falta, normalmente tem poucas opções: continuar usando, procurar uma alternativa ou tentar desenvolver algo parecido. Entender o que acontece dentro dele costuma exigir um trabalho especializado que nem sempre cabe no projeto.

O REA, sigla de Reverse Engineer Anything, entra nesse ponto. Ele conecta agentes de IA a ferramentas de engenharia reversa, a investigação de um software a partir do programa disponível. O agente pode examinar instruções, seguir relações entre funções e usar o que encontrou para propor uma implementação.

No Deep Content anterior, o REA apareceu numa seleção de projetos para usar com Claude. Agora vale abrir essa indicação: o que já foi reconstruído, como os autores verificaram o resultado e quais conclusões ainda seriam apressadas?

Há exemplos concretos. Também há uma distância considerável entre recuperar uma regra e entregar um aplicativo completo. A palavra “recriado” anda trabalhando bastante nas apresentações. Vamos conferir a descrição do cargo.

Um programa compilado contém instruções para o computador, mas geralmente não preserva o projeto original com seus comentários, organização e todos os nomes. Um descompilador transforma parte dessas instruções numa representação mais legível. Isso ajuda a investigar; não devolve automaticamente o código escrito pelo autor.

O README do REA descreve uma ligação entre essas ferramentas e o agente. O REA retorna pseudocódigo, instruções e referências; o agente interpreta os resultados, escolhe o que investigar em seguida e pode escrever código com base nessa análise.

Para o leitor que não desenvolve software, a mudança relevante é essa continuidade. A pergunta deixa de terminar numa explicação plausível: pode orientar uma investigação sobre o programa e uma comparação com uma nova implementação.

O REA oferece uma CLI, interface usada pelo terminal, e um servidor MCP, que permite ao agente chamar suas ferramentas. Uma skill fornece instruções de trabalho. São peças complementares: instruções orientam a investigação, enquanto a conexão disponibiliza as operações.

A documentação de instalação inclui Claude Code, o ambiente de programação que trabalha com arquivos e ferramentas. Isso é diferente de simplesmente colar um link numa conversa do aplicativo Claude. Para outro cliente, é preciso conferir o caminho de integração documentado.

Os quatro casos abaixo foram consultados nas fontes dos próprios projetos em 18 de outubro. Os marcos vão de agosto a outubro de 2026; não são quatro lançamentos desta semana. A apuração é documental, sem execução dos programas pela InferêncIA.

No DX-Ball, jogo de quebrar blocos para Windows, a posição de um evento na tela influencia de que lado o som é percebido. O estudo publicado pelo REA acompanha a recuperação dessa conta a partir do executável da versão 1.07.

O exemplo é útil porque o pseudocódigo inicial estava incompleto. A investigação precisou consultar as instruções e os dados usados pela função para reconstruir a expressão em C, uma linguagem de programação.

O projeto registra 3.205 comparações de comportamento com a função original e correspondência dos 63 bytes de código compilado dessa rotina, considerando os ajustes documentados de referências de endereço. São verificações delimitadas e mais informativas do que uma tela parecida.

O repositório identifica Codex, REA e Ghidra no fluxo de reconstrução. O agente investiga e refina a implementação; o compilador histórico e as comparações ajudam a rejeitar versões incorretas. A documentação não identifica um modelo específico para cada passo desse exemplo.

O recorte detalhado é de 7 de outubro. Ele demonstra a reconstrução de uma função dentro de um projeto maior, não que todo o DX-Ball tenha ficado pronto naquele momento.

O caso de Touhou 4, Lotus Land Story, investiga como o jogo distribui os ângulos de uma sequência circular de projéteis. O alvo é um programa de 16 bits para PC-98, um ambiente bem diferente de um computador atual.

A inspeção com REA registrada em 7 de outubro consulta instruções do executável. O estudo as relaciona ao C++ mantido pelo projeto e a verificações de compilação registradas em 3 de outubro: elas cobrem uma seção de 2.139 bytes que contém a função. Esse número pertence à seção, não apenas ao pequeno cálculo ilustrado.

Há um detalhe importante de autoria: o estudo explica que a reconstrução já tinha código e observações obtidas por scripts próprios. O REA acrescenta uma inspeção do original. A página não prova que a ferramenta tenha criado todo esse código do zero.

O README atual do TH04 separa compilar os quatro programas DOS de validar a experiência completa. Registra comparações de execução e pendências de imagem, temporização e outras rotas. Uma auditoria de 16 de outubro também aponta artefatos locais ausentes que precisam ser recuperados para repetir parte das verificações históricas.

É uma reconstrução extensa em desenvolvimento, com resultados e lacunas documentados.

O Touhou 8 amplia a escala. Seu repositório descreve uma continuação com agentes de IA, baseada no trabalho anterior do GensokyoClub e com o histórico de autoria preservado. Há uma versão Linux jogável. O registro de 24 de agosto documenta a introdução de um port para Linux.

Aqui, já estamos além de uma função isolada. Ainda assim, o projeto distingue a versão jogável da correspondência integral com o executável original, que continua em andamento. E o papel específico do REA em cada etapa dessa continuação não está estabelecido por essas fontes.

O episódio mais instrutivo aparece no relato do mantenedor publicado em 10 de outubro. Uma regra de coleta automática de itens usava zero onde deveria usar o limiar de poder máximo, 128. O comportamento mudava, embora a função tivesse passado pela comparação.

A verificação ajustava referências de endereço, mas não conferia o valor da constante apontada. O commit de correção de 2 de setembro trata o problema; uma auditoria posterior amplia a checagem das constantes.

O erro não apaga o trabalho realizado. Ele mostra por que “passou nos testes” precisa vir acompanhado de uma pergunta: quais erros esses testes seriam capazes de perceber?

O estudo sobre o Notion Desktop 7.6.1 segue o caminho usado para copiar texto e HTML. A análise conecta a interface, uma camada intermediária e o processo principal até a escrita na área de transferência do sistema.

O material apresenta posições no JavaScript empacotado, o canal de comunicação e trechos explicativos. Registra análise com REA 4.1.0; parte dos exemplos sobre dados de blocos vem de arquivos web guardados em 13 de julho, com testes de módulos extraídos. A data desses arquivos não estabelece o dia de publicação do estudo.

O alcance é claro: explicar um mecanismo de um aplicativo existente. Não há demonstração de um Notion refeito, com contas, sincronização, permissões e colaboração funcionando.

Esse tipo de investigação pode interessar a uma equipe que precisa documentar uma integração ou compreender o comportamento de um componente autorizado. Encontrar onde uma informação muda de formato já pode orientar uma decisão técnica, mesmo sem produzir um substituto para o software.

Também é importante reconhecer a concentração da evidência: os três projetos de jogos consultados estão ligados ao mesmo mantenedor. Seus registros permitem examinar o trabalho, mas não equivalem a avaliações independentes da ferramenta.

Depois desses exemplos, eu faria uma pergunta antes de compartilhar a próxima demonstração: o que exatamente voltou a funcionar?

Uma interface semelhante pode atender a um protótipo. Uma regra reconstruída pode resolver uma necessidade pequena. Um programa que compila permite uma primeira avaliação. Uma versão executável abre espaço para testar rotas completas. Cada entrega tem valor, desde que seja descrita pelo que foi demonstrado.

No caso de um aplicativo conectado, a tela revela só parte do trabalho. A experiência também depende do serviço remoto, do tratamento de dados, das permissões e das respostas a falhas. Reproduzir os botões não estabelece que essas partes foram reconstruídas.

Mesmo a equivalência de uma função exige contexto. Quais entradas foram comparadas? O resultado depende de uma biblioteca externa? O programa novo trata os estados compartilhados da mesma maneira? O caso do Touhou 8 mostra que uma comparação sofisticada pode deixar uma diferença relevante de fora.

Para quem vai contratar ou avaliar um projeto assim, vale pedir uma demonstração de ponta a ponta da tarefa que realmente importa. Se a proposta é migrar um sistema interno, o critério poderia ser importar uma amostra autorizada, processá-la, conferir os resultados e observar como uma falha é tratada. Esse é um exemplo de avaliação, não um resultado obtido nos projetos citados.

O uso que mais me interessa é o de uma organização que precisa compreender o próprio legado. Pode existir uma função importante num programa com documentação incompleta, ou uma integração que dependa de um formato antigo. Investigar uma parte delimitada pode ajudar a decidir se vale documentar, substituir ou manter.

Os casos dos jogos sugerem uma possibilidade para preservação: conhecimento sobre o comportamento pode ser registrado junto do código e servir de base para adaptações a outros ambientes. Isso continua dependendo dos materiais de origem, das permissões e da qualidade das verificações.

Há também uma consequência para quem cria produtos. Uma função visível pode se tornar mais fácil de estudar e reproduzir. Minha leitura é que isso aumenta a importância de olhar para a entrega inteira: confiabilidade, dados, integração com a rotina e suporte. Uma empresa ainda precisa fazer essas partes funcionarem para seus clientes.

Esse é um argumento sobre possíveis consequências, não uma previsão de que uma ferramenta específica acabará com o mercado de software. Os casos consultados não permitem medir uma redução geral de custo ou de prazo.

No ensaio de 13 de outubro sobre modelos e engenharia reversa, o mantenedor observa que agentes posteriores recebem código, tentativas anteriores e conhecimento acumulado. Essa herança dificulta atribuir todo o avanço à troca de modelo. É uma observação útil para empresas: parte do progresso pode estar na documentação e no ambiente de trabalho que a equipe construiu.

Na análise nativa, o REA depende de ferramentas como Ghidra, Hopper ou IDA, conforme o alvo e a configuração. Para JavaScript e Electron, há caminhos estáticos que dispensam um descompilador nativo. Compatibilidade e requisitos variam, como registra a documentação do projeto.

A licença MIT cobre o código autoral do REA. Ferramentas comerciais, modelos e outros componentes têm condições próprias. A instalação do projeto não fornece uma licença de Hopper ou IDA, nem torna gratuito o uso do agente. Sem um orçamento específico verificado, não há base para prometer quanto uma reconstrução custaria.

O FAQ informa que a análise é local, mas os resultados entregues ao agente ficam sujeitos à política do provedor do modelo. Esse percurso importa quando o material inclui código proprietário ou dados internos.

Um ponto de partida responsável é software próprio ou cuja análise tenha sido autorizada, com objetivo de manutenção, interoperabilidade ou preservação. Os direitos sobre o programa original e seus materiais continuam relevantes; a permissão para analisar não deve ser presumida como autorização para redistribuir.

Para uma equipe técnica nessa situação, uma pergunta inicial poderia ser:

Esse é um exemplo original de escopo para investigação, não uma ferramenta instalada nem um teste feito nesta edição.

Há trabalho concreto acontecendo: funções recuperadas com comparações registradas, versões jogáveis e mecanismos internos de aplicativos explicados. O passo seguinte é entender em quais condições esses resultados podem ser repetidos por outra equipe.

A mudança que merece atenção está na possibilidade de transformar um programa pouco documentado em algo mais compreensível. O agente pode ajudar a formular hipóteses e seguir pistas, enquanto a equipe define o que precisa preservar e como vai conferir. Em alguns projetos, isso pode tornar viável uma investigação que antes nem começaria.

Eu guardaria também o erro do Touhou 8. Ele lembra que automatizar a produção aumenta a importância de compreender a verificação. Um relatório sem diferenças só é tranquilizador quando sabemos o que entrou na comparação.

Se você trabalha com um sistema antigo, pense numa função pequena que sua equipe precisa entender melhor. Talvez o primeiro resultado útil seja documentar essa função antes de decidir o que fazer com ela.

Qual comportamento de um software você gostaria de conseguir explicar antes de pensar em substituí-lo? Responda este email contando o caso.

Filipe, o único humano nesta empresa.