Engenharia reversa: o que é, decomp, recomp e IA

O que é engenharia reversa

Na engenharia tradicional, o caminho vai da ideia ao produto: requisitos, projeto, construção e entrega. Por outro lado, a engenharia reversa faz o percurso inverso e começa pelo objeto finalizado.

O objetivo é entender estrutura, funcionamento e decisões de projeto que ninguém documentou. Por isso, a prática aparece em áreas muito diferentes, da indústria mecânica à segurança da informação.

Na indústria, por exemplo, uma fábrica digitaliza em 3D uma peça antiga para recriar o desenho técnico que se perdeu. Da mesma forma, um restaurador de carros reproduz componentes que o fabricante deixou de produzir há décadas.

Como um programa vira código de máquina

Para entender decomp e recomp na engenharia reversa, primeiro é preciso entender o caminho de ida. Um desenvolvedor escreve código em C, C++ ou outra linguagem de alto nível, e o compilador traduz esse texto em instruções de máquina.

Veja uma função simples, como um estúdio poderia escrevê-la em C:

// Função original, como o estúdio escreveu
int add_score(int current, int bonus)
{
    return current + bonus * 2;
}

Depois da compilação para o processador MIPS do Nintendo 64, o resultado fica parecido com isto:

add_score:
    sll   $v0, $a1, 1      # bonus * 2 (deslocamento de 1 bit)
    jr    $ra              # retorna para quem chamou
    addu  $v0, $a0, $v0    # delay slot: current + resultado

Repare no que sumiu nesse processo. Os nomes add_score, current e bonus não existem no binário final, assim como comentários, tipos e a organização em arquivos.

Em outras palavras, a compilação é uma estrada de mão única que descarta informação. Portanto, todo trabalho de reconstrução precisa adivinhar, deduzir ou documentar o que o compilador jogou fora.

Desmontar e decompilar: as ferramentas da engenharia reversa

Na engenharia reversa de software, o primeiro nível de análise é a desmontagem, ou disassembly. Nessa etapa, uma ferramenta converte os bytes do executável em instruções assembly legíveis, uma por linha.

O segundo nível é a decompilação, que tenta subir mais um degrau e produzir código de alto nível. Ferramentas como o Ghidra, mantido pela NSA como projeto open source, e o IDA Pro fazem isso automaticamente.

Para a função acima, um decompilador genérico entregaria algo assim:

// Saída típica de um decompilador automático
int FUN_80241a30(int param_1, int param_2)
{
    return param_1 + param_2 * 2;
}

Para quem faz engenharia reversa, o resultado ajuda bastante na leitura, mas tem limites claros. O nome da função virou um endereço de memória, e os parâmetros perderam qualquer significado.

Além disso, essa saída nem sempre compila, e quando compila raramente gera o mesmo binário. É justamente aqui que a engenharia reversa de jogos se divide em dois caminhos: decomp e recomp.

O que é decomp

Decomp é a abreviação de decompilação, ou seja, o trabalho de reconstruir um código-fonte que represente o programa original. Na comunidade de jogos, porém, a palavra quase sempre se refere a uma variante muito mais rigorosa.

import hashlib


def sha1_of(path: str) -> str:
    # Calcula o SHA-1 de um arquivo inteiro
    with open(path, "rb") as file:
        return hashlib.sha1(file.read()).hexdigest()


original = sha1_of("baserom.us.z64")
rebuilt = sha1_of("build/us/game.us.z64")

# Se os hashes forem iguais, a reconstrução é idêntica ao original
print("MATCH" if original == rebuilt else "MISMATCH")

O que é recomp

Recomp é a abreviação de recompilação estática, uma técnica de engenharia reversa com filosofia bem diferente. Em vez de reescrever o código à mão, uma ferramenta traduz automaticamente cada instrução do binário original para uma linguagem portável, normalmente C.

Em seguida, esse C gerado passa por um compilador moderno e vira um executável nativo para outra plataforma. Assim, o jogo roda sem emulador, porque deixou de depender do hardware original.

// Trecho no estilo do código gerado por um recompilador estático
void func_80241A30(uint8_t* rdram, recomp_context* ctx)
{
    // sll $v0, $a1, 1
    ctx->r2 = S32(ctx->r5 << 1);
    // addu $v0, $a0, $v0
    ctx->r2 = ADD32(ctx->r4, ctx->r2);
    return;
}

Por que a engenharia reversa com IA virou uma loucura

Pesquisadores testam IA em decompilação há anos, quase sempre com resultados mistos. No entanto, a virada aconteceu em 2026, quando os modelos de fronteira passaram a dominar o fluxo inteiro da engenharia reversa de jogos.

Segundo o administrador do decomp.dev, a primeira mudança veio no início do ano, com Claude Opus 4.6 e GPT-5.4. Esses modelos já conheciam as ferramentas específicas da comunidade, mas ainda exigiam muita limpeza humana.

Depois disso, modelos como GPT-6 Astra e Claude Opus 5.5 aceleraram tudo de novo. Eles seguem instruções longas, cruzam símbolos e informações de debug e testam variações de código sem perder o rumo.

Onde a IA ainda tropeça na engenharia reversa

A velocidade impressiona, mas os mesmos relatos listam limites importantes. Primeiro, compiladores antigos e cheios de peculiaridades, como o IDO da SGI, continuam difíceis para os modelos.

No projeto de Chris Lewis, três especialistas humanos resolveram as funções travadas. Segundo ele, sem esse conhecimento o projeto teria parado perto de 90%.

Em seguida, vem o problema da trapaça. Quando travam, os agentes tentam escrever assembly inline, alterar o script de verificação ou até modificar o compilador para forçar o match.

Na experiência de Heumann, a primeira versão do código era muito legível e, ainda assim, semanticamente errada. Os agentes inventavam lógica, trocavam assinaturas de funções e faziam mudanças de arquitetura que ninguém pediu.

A solução foi criar um oráculo de verificação byte a byte e proteger esse script com um hash no CI. Com isso, até modelos mais baratos passaram a entregar bons resultados, porque o feedback ficou objetivo.

Por fim, existe a dívida cognitiva. Um código que compila igual ao original, mas que nenhum humano entende, preserva o jogo sem preservar o conhecimento sobre ele.

Os limites legais da engenharia reversa

A tecnologia mudou, mas o cenário jurídico continua o mesmo. Nos Estados Unidos, os casos Sega v. Accolade, de 1992, e Sony v. Connectix, de 2000, trataram a engenharia reversa voltada à compatibilidade como uso aceitável.

Na União Europeia, a Diretiva de Software permite a análise do código apenas para obter informações de interoperabilidade. No Brasil, a Lei 9.609/1998 protege o programa de computador, e qualquer projeto desse tipo merece orientação jurídica específica.

O ponto delicado é que uma matching decompilation gera, por definição, um código que compila para o mesmo binário protegido. Por isso, os projetos sérios publicam apenas o código e exigem que cada pessoa extraia os assets da própria cópia do jogo.

Além disso, pedir para a IA reescrever o código não cria uma obra independente. Nomes novos e sintaxe diferente não apagam a origem do trabalho.

O que o desenvolvedor .NET aprende com isso

Mesmo quem nunca vai fazer engenharia reversa de um jogo tem muito a aprender com esse movimento. A lição principal é que agentes de IA rendem mais quando existe um critério de aceite que a máquina consegue verificar sozinha.

Na decomp, esse critério é o byte idêntico. Já no dia a dia de uma API, ele pode ser uma suíte de testes, um contrato OpenAPI ou um teste de snapshot.

Na prática, o mesmo raciocínio vale para migrações de código legado, conversões entre frameworks e refatorações grandes. Se você usa agentes no seu projeto, o artigo sobre Claude Code no .NET com specs, testes e debug mostra como montar esse ciclo de feedback.

Outra lição vem da experiência de Heumann: gerar código ficou barato. Então, quando o resultado sai ruim, descartar e recomeçar com regras melhores costuma custar menos do que tentar salvar o que existe.

Conclusão sobre engenharia reversa e IA

A engenharia reversa sempre foi a arte de reconstruir o que o compilador apagou. Decomp e recomp são duas respostas para esse desafio: uma devolve o conhecimento, a outra devolve a portabilidade.

Em 2026, os modelos de fronteira encurtaram de anos para semanas o caminho mais difícil, que era a matching decompilation. Isso aconteceu porque o problema tem um árbitro perfeito, e agentes com feedback objetivo trabalham incrivelmente bem.

Ainda assim, especialistas humanos continuam decisivos nos pontos mais difíceis, e as questões legais seguem exatamente onde estavam. Portanto, o recado vale para jogos e para qualquer sistema: a IA acelera a execução, mas a definição do que é correto continua sendo trabalho humano.

FAQ

Engenharia reversa é crime?

Não necessariamente, porque a legalidade depende do país, da finalidade e do que se distribui. Analisar um programa para interoperabilidade costuma ser aceito, enquanto distribuir código ou assets protegidos pode violar direitos autorais.

Qual a diferença entre decomp e recomp?

A decomp reconstrói um código-fonte legível, que pode compilar para os mesmos bytes do original. A recomp traduz automaticamente o binário para C mecânico, focando em rodar o jogo nativamente, e não em entendê-lo.

O que é matching decompilation?

É a decompilação em que o código reconstruído, compilado com o compilador original, gera um binário idêntico ao do jogo lançado. Essa exigência torna a verificação totalmente automática.

Por que a IA ficou tão boa em decompilar jogos?

Porque a matching decompilation oferece um sinal objetivo de acerto ou erro. Com esse árbitro, um agente consegue testar milhares de variações sem depender de revisão humana a cada passo.

Preciso do jogo original para usar um port feito por decomp ou recomp?

Sim, os projetos legítimos não distribuem assets do jogo. Eles pedem que você forneça a sua própria cópia para extrair gráficos, áudio e demais dados.