REA e ArtCraft: como a IA ajuda a entender e reconstruir software

Capa conceitual gerada por IA. Não representa uma interface ou demonstração real.

Resumo: Um caso do DX-Ball e os aplicativos do ArtCraft ajudam a separar três etapas que a empolgação costuma misturar: investigar um programa, reconstruir uma função e verificar o resultado.

Imagine que uma empresa depende de um programa antigo. Ele funciona, mas ninguém sabe explicar uma regra importante: por que calcula determinado valor, como exporta um arquivo ou qual informação usa para decidir. O código-fonte pode ter desaparecido. A documentação, quando existe, descreve a tela e deixa a lógica na penumbra.

A engenharia reversa começa nesse ponto: investigar o sistema existente para compreender sua organização e seu funcionamento. Com agentes de IA conectados a ferramentas de análise, parte desse trabalho ganha outra velocidade. A pergunta decisiva, porém, continua sendo humana: qual evidência sustenta a explicação e como verificar a reconstrução?

A ideia é antiga; o parceiro de investigação mudou

Em janeiro de 1990, Elliot J. Chikofsky e James H. Cross II publicaram uma taxonomia que distingue engenharia reversa, recuperação de projeto e reengenharia. A distinção ajuda a separar duas atividades: compreender um sistema e modificá-lo ou reconstruí-lo. Uma explicação sobre como um programa funciona não equivale, por si só, a uma nova versão confiável.[1]

Pense em um equipamento desmontado sobre uma bancada. Identificar suas peças é um avanço. Entender como trabalham juntas é outro. Montar uma alternativa que produza o mesmo resultado exige uma terceira etapa. No software, as peças incluem instruções, arquivos, dados e relações entre funções.

O que o REA entrega ao agente

REA significa Reverse Engineer Anything. O projeto conecta agentes a ferramentas de inspeção por MCP, um protocolo de comunicação entre o agente e ferramentas externas. Ele contempla programas nativos, aplicações JavaScript/Electron, componentes .NET e sites. Na análise nativa, pode trabalhar com Hopper, Ghidra ou IDA, ferramentas que ajudam a examinar instruções e recuperar representações do código.[2]

O resultado pode incluir pseudocódigo, instruções, chamadas e referências a dados. Pseudocódigo é uma representação que facilita a leitura da lógica; pode estar incompleto. O agente usa as evidências para formular perguntas adicionais, explicar o comportamento e propor uma implementação. A análise do REA ocorre localmente, mas seus resultados chegam ao agente; o fornecedor do modelo tem sua própria política de dados.[2]

Essa divisão importa na prática. A ferramenta localiza evidências. O agente interpreta. O código proposto precisa de verificação. Se misturarmos essas etapas, uma resposta bem escrita pode ganhar indevidamente o status de resultado comprovado.

O DX-Ball mostra por que a evidência faz diferença

O estudo de caso do DX-Ball 1.07 examina uma função que transforma a posição horizontal na tela em um valor de pan, controle associado à posição do som entre esquerda e direita. O descompilador apresentou a função sem parâmetros, embora ela recebesse uma entrada. Foram as instruções que revelaram esse dado; acompanhar a função que fazia a chamada permitiu identificá-lo como a coordenada horizontal. A leitura das constantes no executável completou o cálculo.[3]

A expressão recuperada foi (x × 1,5625 − 500) × escala, seguida de conversão para inteiro. Com escala 1, as posições 0, 320 e 640 produzem −500, 0 e 500. Esses números são valores de controle; não representam diretamente volume ou uma medida física do som.[3]

O projeto relata 3.205 comparações com a função x86 original: 641 posições inteiras, de 0 a 640, em cinco escalas. Relata também correspondência dos 63 bytes da função compilada com Visual C++ 4.0, após os ajustes de referências descritos na verificação. São duas evidências complementares sobre essa função, não a comprovação de que o jogo inteiro foi reconstruído.[3]

O repositório de reconstrução descreve um ciclo de inspeção, expressão da lógica em C/C++, compilação e comparação. Uma diferença orienta a investigação seguinte. Há requisitos de ambiente e arquivos originais fornecidos separadamente.[4]

A lição ultrapassa o jogo: uma hipótese fica mais forte quando pode ser confrontada com o sistema que pretende explicar. Repetir o resultado correto em algumas entradas ajuda; registrar exatamente quais entradas e condições foram verificadas permite avaliar o alcance dessa ajuda.

Análise estática e dinâmica respondem a perguntas diferentes

Na análise estática, examinamos arquivos e código sem executar a aplicação. Na dinâmica, observamos o que acontece durante a execução. Um caminho identificado no código pode depender de condições que não ocorreram no teste. Uma execução bem-sucedida mostra um caminho percorrido, sem necessariamente revelar todos os caminhos possíveis.

O tutorial JavaScript/Electron do REA acompanha uma exportação de notas: a chamada sai da página, atravessa uma comunicação entre processos e chega à gravação de um CSV, arquivo de dados em texto. A documentação distingue o caminho inferido pelo código da observação em execução. Nomes calculados ou relações ambíguas podem permanecer sem solução na análise estática.[8]

Para avaliar uma exportação, portanto, proponho combinar perguntas: onde o código indica que o arquivo será salvo? Onde ele foi realmente salvo? O que acontece sem permissão de escrita? O teste deve verificar a condição de erro, além do caminho que funciona.

Onde ArtCraft e PhotoCraft entram nessa história

O artigo anterior sobre ArtCraft apresentou sete aplicativos. Na consulta de 12 de outubro de 2026, o catálogo oficial lista 12: PhotoCraft, VectorCraft, FilmCraft, LightCraft, PdfCraft, EffectCraft, DesignCraft, WordCraft, SoundCraft, DeckCraft, CADCraft e GridCraft. As cinco entradas adicionais abrangem texto, áudio, apresentações, CAD e planilhas. O catálogo identifica estágios iniciais, como alfa e desenvolvimento; quantidade não significa maturidade profissional.[5]

O PhotoCraft se apresenta como uma reimplementação independente do Photoshop em Rust, linguagem de programação. Seu README declara uso de especificações públicas e comportamento observado, sem código ou recursos proprietários. Também descreve controle por interface, linha de comando, canal JSON e MCP. São declarações do projeto; elas não demonstram que o REA foi usado para criar o PhotoCraft.[6]

O mesmo README reconhece que o aplicativo está em alfa e ainda não substitui o Photoshop no trabalho profissional diário. Um menu conectado a um comando não prova equivalência de comportamento. A expressão clean-room, usada pelo projeto para caracterizar sua implementação, também não dispensa a avaliação de licenças e direitos envolvidos.[6]

A conexão entre os projetos é conceitual: investigar comportamentos, reconstruir funcionalidades e tornar aplicativos acessíveis a agentes. Compreender esse encontro é mais útil do que concluir que toda alternativa aberta já consegue substituir uma ferramenta consolidada.

Uma aplicação acessível ao agente precisa mostrar o resultado

A documentação do FilmCraft descreve modos de operação sem janela e de conexão ao aplicativo aberto. As ferramentas permitem inspecionar o projeto, executar comandos e renderizar quadros para verificar o resultado. O ciclo sugerido inclui inspeção, ação, observação e desfazer quando necessário.[7]

Há uma consequência concreta de permissões: a documentação informa que o servidor no modo sem janela não oferece os parâmetros de confinamento de pastas mencionados ali e pode ler e escrever onde o usuário consegue. Não se deve supor uma restrição de diretório inexistente.[7]

Para o leitor que deseja experimentar, a avaliação pode começar pequena. Abaixo, proponho três tarefas com resultados observáveis. Elas não foram executadas neste artigo.

Registrar versão, sistema operacional, arquivos de entrada e resultado evita que “funcionou aqui” vire uma promessa universal. Para uma equipe, esse registro também facilita decidir se o ganho de tempo compensa as limitações encontradas.

Entender um comportamento não concede todos os direitos sobre ele

O aviso de uso responsável do REA inclui pesquisa, educação, interoperabilidade e preservação, dentro de análises autorizadas. Rejeita usos como contornar proteções e copiar material proprietário em violação de direitos. É a posição do projeto, não um parecer jurídico sobre cada situação.[8]

Antes de reconstruir uma funcionalidade para distribuição, é preciso avaliar autorização, licenças e materiais usados. Uma licença aberta da ferramenta de análise não transfere direitos sobre o programa analisado.

O avanço está em aproximar explicação e verificação

REA e ArtCraft apontam para um cenário em que agentes participam mais diretamente da investigação e da operação de software. Essa participação pode reduzir o trabalho de localizar relações, testar hipóteses e executar tarefas repetitivas. Sua utilidade depende de preservar a ligação entre pergunta, evidência, implementação e resultado.

No DX-Ball, a explicação ganhou força porque foi confrontada com a função original. No PhotoCraft, as limitações declaradas ajudam a dimensionar a expectativa. No FilmCraft, a possibilidade de observar o resultado faz parte do fluxo de automação. Para quem trabalha ou ensina tecnologia, o critério é concreto: pedir a evidência, definir o teste e examinar o que aconteceu. A IA pode acelerar a investigação; a confiança precisa acompanhar aquilo que conseguimos verificar.