A Revolução industrial na engenharia reversa.

O que mudou em agosto de 2026

Antes deste trabalho, eu tinha feito muita engenharia reversa manual. Eu inspecionaria uma função até ter uma explicação e, em seguida, testaria essa explicação em relação ao programa. Ir mais longe significava gastar mais do meu próprio tempo na próxima função. Também significava manter uma imagem cada vez maior na minha cabeça.

A maior parte do meu trabalho é sobre jogos. Eu os reconstruo para que seu comportamento possa ser entendido e eventualmente transportado para uma porta de software ou um mod. Esta é a experiência por detrás deste artigo. O método pode ser útil em outros lugares, mas cada campo precisa estabelecer o que pode verificar em relação a uma referência confiável.

Em agosto de 2026, comecei a explorar seriamente a RE orientada por agentes. Eu queria ver até onde um agente poderia chegar com acesso ao programa e às ferramentas de desenvolvimento comuns. A reconstrução de Touhou deu-me um projecto substancial para descobrir.

Os primeiros progressos foram surpreendentes. Uma investigação poderia continuar sem que eu escolhesse cada passo individual. Uma comparação com falha pode enviar o agente para outro chamador. Poderia escrever um pequeno diagnóstico e usar o resultado para decidir o que tentar a seguir. Dar-lhe essa liberdade fez a diferença: eu poderia dedicar mais atenção à direcção do projecto e à fiabilidade dos seus controlos.

O ritmo chamou minha atenção primeiro. Então comecei a me perguntar o que sobreviveria além do projeto atual. O próximo jogo beneficiaria de tudo o que acabámos de aprender?

TH08: baseando-se no trabalho humano

TH08 , Noite imperecível, começou como uma continuação de Reconstrução de GensokyoClub. A sua fonte pública deu-me uma base substancial. Veio com o conhecimento da construção e uma história de contribuições que preservei na continuação.

A história importada termina no posto de controlo público de 10 de agosto. A minha continuação independente teve início em 13 de agosto. Em 19 de agosto, o livro-razão registou a fonte para todas as 1.107 funções do jogo identificadas.

Um porto de reconstrução Linux jogável foi confirmado em 24 de agosto, cerca de onze dias após o início da continuação. Seguiu-se uma edição Web. A versão nativa Linux de 64 bits chegou em 30 de agosto.

O que me impressionou foi que o trabalho tinha chegado a um programa que as pessoas podiam executar. Para chegar lá, é necessário seguir problemas além de uma função individual. Mesmo quando duas funções pareciam corretas isoladamente, elas poderiam acidentalmente usar cópias separadas de Estado que deveriam ter sido compartilhadas.

Isso tornou os controlos de referência centrais para o trabalho. Eu chamo-lhes referências de verificação (oráculos). Uma comparação de códigos pode dizer-nos se uma função reconstruída reproduz as instruções originais. Uma verificação de tempo de execução pode nos dizer se uma rota exercida atinge o estado esperado. O agente propõe uma explicação e testa - a; uma incompatibilidade dá-lhe algo específico para investigar.

Uma correspondência exata com a constante errada

Uma referência de verificação (oracle) é um software que alguém escreveu. TH08 me deu um lembrete claro de quanto pode depender desse software.

Em setembro, um bug relatado por uma porta de Switch downstream levou de volta à coleta automática de itens. A fonte reconstruída verificou o poder do jogador contra 0.0. O original utilizado 128.0, o limiar de potência máxima.

A potência Normal não é negativa, pelo que a verificação da potência reconstruída foi efectivamente sempre satisfeita. Acima da linha de coleta, o jogo poderia atrair itens sem exigir potência máxima. As outras excepções na condição estavam correctas. Esta constante mudou o comportamento.

No entanto, a função já havia passado na comparação exata.

Uma reconstrução pode colocar uma constante em um endereço diferente. A ferramenta de comparação explicou isso ajustando os endereços nas instruções compiladas antes de compará-los com o original. Mas nunca verificou o valor de ponto flutuante armazenado no endereço referenciado.

Isso deixou um buraco no cheque. Poderia apontar a instrução reconstruída para o original 128.0 enquanto a fonte ainda disse 0.0. Os bytes de instrução corresponderam. A fonte significava algo diferente.

O Correção de 2 de setembro corrigiu a fonte e fez a comparação verificar os bytes reais da constante referenciada. A auditoria mais alargada em seguida, examinou 1.548 referências constantes de ponto flutuante. Encontrou outras doze referências incorrectas em cinco funções aceites.

A comparação verifica agora cada uma dessas constantes de ponto flutuante. Os seus testes incluem valores deliberadamente errados para garantir que são rejeitados. Tivemos também de rever os resultados que tinham passado pelo controlo mais fraco.

A referência de verificação (oráculo) também precisava de ser reconstruída. Repará-lo fazia parte da reparação do jogo.

Isso importa quando a equipa é essencialmente uma pessoa que trabalha com agentes. Não posso inspeccionar pessoalmente todas as linhas que produzem, pelo que muito da minha confiança depende dos seus controlos. O ponto cego de uma referência de verificação partilhada (oracle) pode afectar muitas investigações antes que eu perceba. Eu tenho que entender o que o verificador realmente verifica e testá-lo contra casos que deveriam falhar.

À medida que os trabalhos prosseguiam, esses controlos passaram a fazer parte do repositório. O mesmo aconteceu com as razões das alterações da fonte e das notas que permitiram que uma sessão posterior continuasse onde uma sessão anterior parou. O repositório de código-fonte estava a tornar-se a memória de trabalho do projecto.

Um lote bem sucedido proporcionou-nos tanto o código recuperado como um ambiente melhor para o próximo lote.

Duas ideias diferentes de reconstrução

De GensokyoClub README público explicita o seu desacordo com este tipo de trabalho. O aviso anuncia que o desenvolvimento adicional ocorrerá em particular até a conclusão. Uma passagem diz:

A ascensão de vigaristas (decompilações e portos de IA) neste espaço, tirando do nosso trabalho, pinta uma imagem ruim para futuros esforços de descompilação…

O aviso também descreve o impacto psicológico dos mantenedores. A sua política de contribuição exclui os pull requests produzidos principalmente com IA. Dedicaram o seu tempo livre a um trabalho difícil, e esse trabalho ajudou a tornar possível a minha continuação. Respeito o esforço por trás disso. O desacordo que quero discutir é sobre como a reconstrução deve prosseguir e como uma contribuição deve ser julgada.

No fluxo de trabalho manual que eu conhecia, desenvolver uma compreensão de uma função e reconstruí-la geralmente cabia à mesma pessoa. Um projecto baseou-se fortemente na experiência dessa pessoa. A confiança no colaborador importava porque grande parte do raciocínio acontecia enquanto eles trabalhavam.

Os projectos existentes já preservam o conhecimento na sua fonte e criam ferramentas. O que mudou para mim foi que um agente poderia usar esse conhecimento para prosseguir a próxima investigação por conta própria.

Na minha continuação, decido o objectivo e a norma para aceitar um resultado. O agente tem ampla liberdade para investigar. A sua reconstrução proposta tem então de sobreviver aos controlos pertinentes. Quero que outra pessoa possa examinar a razão pela qual escolhemos uma implementação, mesmo que um agente tenha feito a maior parte do trabalho.

Esta pode ser uma transição difícil. Anos de trabalho cuidadoso podem tornar-se a base para uma continuação que se move muito mais rapidamente. Isso levanta questões reais sobre o crédito. Também altera o que os mantenedores precisam saber antes de aceitar uma contribuição.

A analogia industrial ajuda-me a pensar nisso. Em um ofício, grande parte do processo depende da habilidade da pessoa que o realiza. O maquinário muda quando essa habilidade é necessária. Alguém ainda tem que projetar o processo e reconhecer quando sua saída está errada. Diferentes comunidades podem escolher quanto dessa mudança querem assumir.

A minha escolha é continuar abertamente, com a obra herdada creditada e a sua história preservada. Quero que o novo trabalho seja passível de revisão. Isso dá-nos uma forma de perguntar até que ponto esta abordagem pode ir e de aprender com o que corre mal ao longo do caminho.

Fonte: de GensokyoClub Aviso README, verificados em 10 de outubro de 2026, e Política de contribuição. A citação é um trecho abreviado. De TH08 créditos e proveniência registre o limite de continuação.

TH095: a experiência começa a compor

TH095 , Atire a bala, tornou o valor dessa experiência muito mais fácil de ver. Seu repositório começou em 29 de Agosto com zero funções de jogo confirmadas no livro-razão. Ainda tínhamos de aprender o jogo. Mas já sabíamos muito mais sobre como iniciar uma reconstrução e como mantê-la em movimento.

Até 7 de setembro, todas as 697 funções do jogo identificadas tinham origem. Em 8 de setembro, 696 tinham sido aceites como comparações exactas. Todo o programa teve ligação em 9 de setembro. A reconstrução Windows i386 foi marcada como jogável em 10 de setembro, cerca de doze dias após a inicialização.

Achei isso mais emocionante do que a velocidade do primeiro projeto. Um novo alvo poderia beneficiar do trabalho realizado noutro jogo. A experiência já estava presente nas Ferramentas e na forma como o projecto foi organizado.

Por exemplo, TH08 nos ensinou a prestar atenção ao programa montado cedo. Se várias funções recuperadas dependem do mesmo estado, as suas comparações isoladas deixam uma questão importante em aberto. Temos de vê-los a trabalhar em conjunto. Essa lição ajudou a moldar a forma como abordamos a construção de todo o programa do TH095.

Uma lição que fica na minha cabeça é útil enquanto lá estou. Uma vez que se torne uma verificação de que outra sessão pode ser executada, ela pode continuar ajudando depois que eu seguir em frente. O próximo agente pode utilizar o resultado sem repetir a investigação que o conduziu.

O bug constante de ponto flutuante também pertence a essa memória. Explica por que a verificação de uma referência também exige a verificação dos dados subjacentes. Manter essa correção com o código ajuda os projetos posteriores a evitar herdar o ponto cego do cheque antigo.

O método passa a fazer parte do material de partida para o próximo jogo. Podemos gastar mais do esforço do próximo projecto naquilo que é realmente novo sobre o seu objectivo.

O mesmo benefício está disponível para as pessoas que se juntam mais tarde. Eles podem inspecionar uma decisão e reexecutar sua verificação antes de continuar o trabalho. Não têm de reconstruir toda a história do projecto para descobrir porque é que a fonte se parece com ela.

TH04: o fluxo de trabalho sobrevive a uma arquitetura diferente

TH04 , Lotus Land Story, levou este trabalho para a era PC-98 dos. O alvo era agora um ambiente de 16 bits com quatro programas cooperantes. Compreender o seu comportamento de hardware exigiu provas diferentes dos jogos Windows. Existente Trabalho ReC98 deu-nos também aqui conhecimentos valiosos e material de origem.

A reconstrução do DOS está agora a funcionar. Em meus testes manuais, joguei rotas normais completas através de seus finais e verifiquei as defesas. O trabalho atual é uma porta nativa de 64 bits. O estabelecimento de uma versão DOS funcional dá, em primeiro lugar, a essa porta uma referência.

A arquitectura mudou o que precisávamos de investigar. Também mudou o compilador e o tempo de execução em relação aos quais verificamos nosso trabalho. Mas o agente ainda pode seguir uma pergunta até um resultado e deixar que esse resultado guie a próxima experiência.

Considere a transição da jogabilidade para um final. Precisamos de saber que estado atravessa essa fronteira e que programa é responsável por ela. Isso é algo que podemos investigar contra o produto DOS. Uma vez que as provas e os controlos estejam disponíveis, um agente pode resolver a questão da mesma forma que fez com um título Windows.

É por isso que TH04 é importante para o argumento. Uma mudança substancial da plataforma não nos obrigou a recomeçar com uma nova forma de trabalhar. A arquitetura definiu o problema; o fluxo de trabalho ainda nos deu uma maneira de resolvê-lo.

Para a porta de 64 bits, podemos agora examinar a nova implementação contra o comportamento já recuperado no DOS. O conhecimento da reconstrução dá ao porto algo em que se basear.

Estado do projecto em 10 de outubro de 2026: Reconstrução DOS E ensaios manuais · Porta de 64 bits. O porto continua em desenvolvimento.

Do código exato ao código legível

Uma vez que uma reconstrução funcione, quero que outra pessoa possa compreendê-la.

Para mim, a montagem e as compensações brutas podem parecer velhos amigos. Sei que esta é uma definição ligeiramente invulgar de " legível."A maioria das pessoas prefere seguir a lógica do jogo sem manter o layout da memória do executável na cabeça.

É aí que reconstrução semântica entra. Um campo recuperado pode ainda ser conhecido principalmente pela sua compensação. Seguimos a forma como o jogo o utiliza até podermos explicar o seu papel. Então podemos dar - lhe um nome significativo e um tipo que se encaixa na evidência. Mantemos o raciocínio com a fonte para que a próxima pessoa possa ver de onde veio essa interpretação.

Isso se torna especialmente importante para uma porta de software. Um endereço absoluto me diz onde algo vivia no antigo executável. Dá uma implementação de 64 bits pouca ajuda para decidir qual objeto deve possuir esse estado. Para mover o comportamento com segurança, precisamos recuperar a relação por trás do antigo acesso à memória.

A ordem que eu uso agora é:

1. Recuperar uma linha de base exacta. Compile as peças reconstruídas com o compilador histórico. Compare o código e os dados relevantes com o executável original. Registe diferenças não resolvidas para que a próxima fase tenha um ponto de partida claro.
2. Construa e jogue na plataforma original. Vincule essas peças ao programa real usando a arquitetura e o compilador originais. Exercite caminhos de jogo importantes. É aqui que podemos encontrar problemas com o estado compartilhado ou inicialização que uma comparação de função isolada perdeu.
3. Reconstruir a semântica contra ambas as referências. Tome uma parte coerente do jogo de cada vez e estabeleça o que significa a sua fonte recuperada. Melhorar a sua representação, preservando as comparações exatas e a construção histórica jogável.
4. Faça o porto moderno. Mova o comportamento estabelecido para o novo ambiente, como uma compilação nativa de 64 bits. O jogo de plataforma original reconstruído continua a ser uma referência para comparar o comportamento do Porto.

A construção jogável do segundo estágio torna-se um segunda referência de verificação (oracle) durante o terceiro. A primeira referência de verificação (oracle) verifica se a nossa fonte alterada ainda reproduz o código e os dados originais relevantes. A segunda verifica se o programa reconstruído continua a construir e a comportar-se correctamente ao longo dos caminhos que exercemos.

Eles pegam erros diferentes. Uma alteração de tipo pode alterar as instruções geradas. Uma mudança de propriedade pode deixar duas partes do jogo usando cópias diferentes do estado. Manter ambas as verificações disponíveis dá ao Agente uma falha concreta em investigar antes de levar mais longe um refatorador.

Um nome precisa de provas próprias. Uma comparação exacta não nos pode dizer se um campo significa realmente "tempo de invulnerabilidade"."Temos que estabelecer isso a partir de como o jogo escreve e usa. Se o significado permanece incerto, um nome neutro é mais útil para o próximo leitor do que um palpite confiante.

Aprendemos esta ordem através dos projectos. TH08 já tinha portas jogáveis antes de algumas de suas auditorias posteriores de plataforma histórica. Isso tornava certos defeitos mais difíceis de ver. O Fluxo de trabalho atual da fábrica coloca a construção da plataforma original em primeiro lugar, para que o trabalho semântico possa usá-la como referência antes do início da portabilidade.

A reconstrução exacta dá-nos uma referência. A reconstrução semântica torna utilizável o conhecimento recuperado. Um porto pode então basear-se em ambos.

O que torna esta mudança industrial

Estes projectos mudaram onde dediquei a minha atenção. Uma vez que os agentes puderam levar muito adiante uma investigação, melhorar o seu ambiente de trabalho tornou-se uma das coisas mais úteis que eu poderia fazer. Uma ferramenta melhor poderia ajudar em todas as funções posteriores que dela necessitassem.

A autonomia importa aqui. O próximo passo útil torna-se frequentemente claro apenas após uma experiência fracassada. Um agente precisa de liberdade suficiente para seguir esse resultado em algum lugar inesperado. Se tiver de esperar que eu prescreva cada passo, grande parte do trabalho continua ligada à minha atenção.

Espero que o agente faça hipóteses erradas. O que importa é saber se podemos testá-los e aprender com o resultado. Uma verificação com falha deve ajudá-lo a entender o erro o suficiente para tentar novamente. Ainda tenho de decidir se as provas acumuladas apoiam um marco do projecto.

REA dá ao agente acesso às ferramentas de análise. Uma pergunta sobre o chamador de uma função pode levar diretamente à inspeção desse chamador. O projecto de reconstrução fornece o compilador e as suas próprias verificações de referência. O agente pode usá-los para testar a fonte que propõe e ver onde está a sua explicação.

O bug TH08 mostra por que essas verificações merecem atenção própria de engenharia. Quando a mesma comparação é usada em centenas de funções, uma lacuna na TI pode se espalhar muito mais do que um erro em uma implementação. Testar o verificador melhora o feedback disponível para todos os trabalhos posteriores.

A analogia industrial tem aqui um exemplo histórico útil. Boulton e Watt introduziram um indicador do motor a vapor em 1796 para ajudar a ajustar as válvulas do motor. Uma versão de gravação rastreou a pressão através do curso do pistão. Disponibilizou o comportamento interno do motor para inspecção. As nossas ferramentas de comparação têm um propósito semelhante: permitem-nos examinar o que a máquina está a fazer enquanto a melhoramos.

Estamos na fase inicial desta mudança industrial. Grande parte da infra-estrutura ainda é imatura. Os agentes podem mover-se mais rapidamente do que os nossos controlos foram concebidos para suportar, pelo que o processo tem de se desenvolver paralelamente a eles. Quando encontramos um defeito numa ferramenta partilhada, temos de O reparar e rever os resultados que afectou. O próximo projecto pode então herdar uma ferramenta mais forte.

Há também um limite prático para qualquer conversa. Terminará antes de terminar uma grande reconstrução. O repositório de código-fonte tem de possibilitar a continuação de outra sessão sem perder o motivo da última decisão.

O Fábrica De Reconstrução De Touhou surgiu dessa necessidade. Dá aos projectos uma forma partilhada de levar adiante os seus controlos e lições. Trabalhar num jogo pode melhorar as condições de partida para outro.

É isso que me torna significativa a analogia industrial. A experiência começa a tornar-se parte de ferramentas que outros podem utilizar. Melhorar essas ferramentas muda o quanto a próxima pessoa—ou o próximo agente—pode fazer.

Os projectos que podemos agora considerar

O ritmo é importante porque muda a decisão de começar. Um jogo pode ser fascinante para fazer engenharia reversa e ainda exigir mais da minha própria atenção do que eu poderia realisticamente dar. Muitos projectos continuariam a ser ideias.

Agora posso ver uma forma de manter um projecto deste tipo a decorrer através de investigações repetidas. Conseguir uma reconstrução funcional torna uma porta de software mais prática. Recuperar semântica legível torna mais fácil para outra pessoa explorar um mod. O esforço colocado na compreensão do jogo pode continuar valendo a pena após a primeira versão ser executada.

Agora olho para um programa desconhecido e pergunto: que Acesso, feedback e conhecimento acumulado permitiriam que um agente trabalhasse de forma fiável?

Esta pergunta Leva-me a considerar projectos que anteriormente teria deixado em paz. Cada um pode melhorar a forma como abordamos o próximo. Quero continuar a explorar até onde isso nos pode levar.

Mais artigos · Explorar uma investigação TH04