A IA está aprendendo a reconstruir programas? Entenda a recompilação que viralizou na internet

Vídeos nas redes sociais sugerem que a inteligência artificial já consegue desmontar um programa como o Photoshop e devolvê-lo pronto, gratuito e equivalente ao original. A frase junta processos diferentes. Criar um editor de imagens com recursos parecidos, analisar um executável e converter um programa para outra plataforma são tarefas distintas. Todas podem receber ajuda de IA, mas nenhuma demonstra, por si só, que o código de um aplicativo proprietário foi recuperado.

O caso recente do PhotoCraft ajuda a entender a confusão. Seus responsáveis apresentam o projeto como um editor de imagens escrito em Rust e como uma implementação independente, baseada em especificações públicas e comportamento observado. É uma descrição dos próprios desenvolvedores, não uma auditoria independente de equivalência com o Photoshop. O repositório não apresenta o projeto como uma descompilação do código da Adobe. Ao mesmo tempo, ferramentas como o REA se propõem a conectar agentes de IA à análise de aplicativos e arquivos binários. A existência dessas ferramentas também não prova que um software inteiro tenha sido reconstruído com fidelidade.

Para entender o que de fato está em jogo, vamos acompanhar um programa fictício que soma dois números. As demonstrações abaixo são simplificações educativas; elas não mostram o código do Photoshop nem uma ferramenta real executando engenharia reversa.

Primeiro, como nasce um executável?

O ponto de partida costuma ser código-fonte: instruções escritas por pessoas em uma linguagem de programação. Um compilador pode analisar esse código, transformá-lo em representações intermediárias e produzir instruções para um processador. Um processo de construção também pode reunir bibliotecas, recursos e informações necessárias ao sistema operacional. O projeto LLVM documenta o uso de uma representação intermediária; seus backends geram código para destinos específicos. Esse é um exemplo de arquitetura de compilador, não uma sequência obrigatória para todos os programas.

No nosso exemplo, a intenção original cabe em uma linha: somar(a, b) = a + b. O executável contém uma forma de realizar a operação, porém pode não guardar os nomes escolhidos pelo programador, os comentários ou o arquivo original. Otimizações também podem reorganizar operações antes de gerar o resultado final.

Essa perda de contexto explica por que voltar de um executável para algo legível exige interpretação. Saber que uma sequência de instruções soma dois valores não revela necessariamente como o projeto inteiro foi organizado.

O que a engenharia reversa consegue observar?

Engenharia reversa é investigar como um sistema funciona a partir do que está disponível. No programa fictício, podemos inserir 2 e 3, observar a saída 5, examinar as instruções e testar outros valores. Uma ferramenta de análise pode mostrar funções, referências e fluxo de execução. O Ghidra, mantido pela NSA, oferece recursos de desmontagem, descompilação e análise gráfica.

As observações permitem criar hipóteses. Se o programa retorna 5 para 2 e 3, ele pode estar somando, mas um único teste não basta: outra regra também poderia produzir 5 nesse caso. Entradas negativas, números grandes, erros e condições de ambiente ajudam a distinguir comportamentos. Em programas reais, a dificuldade cresce com interfaces, arquivos, plugins, chamadas de rede, proteção e dependências externas.