La rivoluzione industriale nel reverse engineering.

Cosa è cambiato nell'agosto 2026

Prima di questo lavoro, avevo fatto un sacco di reverse engineering manuale. Vorrei ispezionare una funzione fino a quando non ho avuto una spiegazione, quindi testare quella spiegazione contro il programma. Ottenere ulteriormente significava spendere più del mio tempo sulla funzione successiva. Significava anche mantenere un quadro sempre più grande nella mia testa.

La maggior parte del mio lavoro è sui giochi. Li ricostruisco in modo che il loro comportamento possa essere compreso e alla fine portato in una porta software o in un mod. Questa è l'esperienza dietro questo articolo. Il metodo può essere utile altrove, ma ogni campo deve stabilire cosa può verificare con un riferimento affidabile.

Nel mese di agosto 2026, Ho iniziato ad esplorare RE agente-driven seriamente. Volevo vedere fino a che punto un agente potesse arrivare con l'accesso al programma e agli strumenti di sviluppo ordinari. Touhou ricostruzione mi ha dato un progetto sostanziale in cui scoprire.

I primi progressi sono stati sorprendenti. Un'indagine potrebbe continuare senza che io scelga ogni singolo passo. Un confronto non riuscito potrebbe inviare l'agente a un altro chiamante. Potrebbe scrivere una piccola diagnostica e utilizzare il risultato per decidere cosa provare dopo. Dandogli quella libertà ha fatto la differenza: potrei dedicare più attenzione alla direzione del progetto e se i suoi controlli fossero affidabili.

Il ritmo ha attirato la mia attenzione per primo. Poi ho iniziato a chiedermi cosa sarebbe sopravvissuto oltre il progetto attuale. Il prossimo gioco trarrà beneficio da tutto ciò che abbiamo appena imparato?

TH08: costruire sul lavoro umano

TH08 , Imperituro Notte, è iniziata come una continuazione di La ricostruzione di GensokyoClub. La loro fonte pubblica mi ha dato un fondamento sostanziale. È venuto con la conoscenza della costruzione e una storia di contributi che ho conservato nella continuazione.

La storia importata termina al checkpoint pubblico 10 Agosto. La mia continuazione indipendente è iniziata il 13 agosto. Entro il 19 agosto, il libro mastro ha registrato la fonte per tutte le 1.107 funzioni di gioco identificate.

Una porta di ricostruzione Linux giocabile è stata impegnata il 24 agosto, circa undici giorni dopo l'inizio della continuazione. Ne è seguita un'edizione Web. La versione nativa Linux a 64 bit è arrivata il 30 agosto.

Quello che mi ha colpito è che il lavoro aveva raggiunto un programma che la gente poteva eseguire. Per arrivarci sono stati necessari problemi successivi oltre una singola funzione. Anche quando due funzioni sembravano corrette in isolamento, potevano accidentalmente utilizzare copie separate di stato che avrebbero dovuto essere condivise.

Ciò ha reso i controlli di riferimento centrali per il lavoro. Li chiamo riferimenti di verifica (oracoli). Un confronto di codice può dirci se una funzione ricostruita riproduce le istruzioni originali. Un controllo di runtime può dirci se un percorso esercitato raggiunge lo stato previsto. L'agente propone una spiegazione e la mette alla prova; una mancata corrispondenza gli dà qualcosa di specifico da indagare.

Una corrispondenza esatta con la costante sbagliata

Un riferimento di verifica (oracle) è un software che qualcuno ha scritto. TH08 mi ha dato un chiaro promemoria di quanto può dipendere da quel software.

Nel mese di settembre, un bug segnalato da una porta switch a valle ha portato di nuovo alla voce auto-collection. La fonte ricostruita controllava la potenza del giocatore contro 0.0. L'originale usato 128.0, la soglia di potenza massima.

La potenza normale non è negativa, quindi il controllo di potenza ricostruito è stato effettivamente sempre soddisfatto. Sopra la linea di raccolta, il gioco potrebbe attirare oggetti senza richiedere la massima potenza. Le altre eccezioni nella condizione erano corrette. Questa costante ha cambiato il comportamento.

Eppure la funzione aveva già superato il confronto esatto.

Una ricostruzione può mettere una costante a un indirizzo diverso. Lo strumento di confronto ha tenuto conto di ciò regolando gli indirizzi nelle istruzioni compilate prima di confrontarli con l'originale. Ma non ha mai controllato il valore in virgola mobile memorizzato nell'indirizzo di riferimento.

Questo ha lasciato un buco nell'assegno. Potrebbe puntare l'istruzione ricostruita a quella originale 128.0 mentre la fonte ha detto ancora 0.0. I byte di istruzione abbinati. La fonte ha significato qualcosa di diverso.

Il 2 Settembre fix corretto l'origine e fatto il confronto controllare i byte effettivi della costante di riferimento. A audit più ampio poi ha esaminato 1.548 riferimenti costanti in virgola mobile. Ha trovato altri dodici riferimenti errati su cinque funzioni accettate.

Il confronto ora controlla ogni costante in virgola mobile. I suoi test includono valori deliberatamente errati per assicurarsi che vengano rifiutati. Abbiamo anche dovuto rivedere i risultati che avevano superato il controllo più debole.

Anche il riferimento di verifica (oracle) doveva essere ricostruito. Ripararlo faceva parte della riparazione del gioco.

Questo è importante quando il team è per lo più una persona che lavora con gli agenti. Non posso ispezionare personalmente ogni linea che producono, quindi gran parte della mia fiducia si basa sui loro controlli. Un punto cieco di un riferimento di verifica condiviso (oracle) può influenzare molte indagini prima che me ne accorga. Devo capire cosa verifica effettivamente il controllore e testarlo contro casi che dovrebbero fallire.

Man mano che il lavoro continuava, quei controlli divennero parte del repository. Così hanno fatto i motivi per le modifiche alla fonte e le note che hanno lasciato che una sessione successiva riprendesse dove si fermava una precedente. Il repository del codice sorgente stava diventando la memoria di lavoro del progetto.

Un batch di successo ci ha dato sia il codice recuperato che un ambiente migliore per il batch successivo.

Due diverse idee di ricostruzione

Di GensokyoClub pubblico LEGGIMI rende esplicito il suo disaccordo con questo tipo di lavoro. L'avviso annuncia che ulteriori sviluppi avverranno privatamente fino al completamento. Un passaggio recita:

L'ascesa di grifters (AI decompilations and ports) in questo spazio che prende dal nostro lavoro dipinge una cattiva immagine per i futuri sforzi di decompilazione…

L'avviso descrive anche il pedaggio psicologico sui manutentori. La loro politica di contributo esclude le richieste pull prodotte principalmente con l'IA. Hanno messo il loro tempo libero in un lavoro difficile, e quel lavoro ha contribuito a rendere possibile la mia continuazione. Rispetto lo sforzo che c'è dietro. Il disaccordo che voglio discutere riguarda come dovrebbe procedere la ricostruzione e come dovrebbe essere giudicato un contributo.

Nel flusso di lavoro manuale che conoscevo, sviluppare una comprensione di una funzione e ricostruirla di solito cadeva nella stessa persona. Un progetto si basava molto sull'esperienza di quella persona. La fiducia nel contributore contava perché gran parte del ragionamento accadeva mentre lavoravano.

I progetti esistenti conservano già la conoscenza nella loro fonte e costruiscono strumenti. Ciò che è cambiato per me è che un agente potrebbe usare quella conoscenza per perseguire la prossima indagine da solo.

Nella mia continuazione, decido l'obiettivo e lo standard per accettare un risultato. L'agente ha ampia libertà di investigare. La sua ricostruzione proposta deve quindi sopravvivere ai relativi controlli. Voglio che un'altra persona sia in grado di esaminare il motivo per cui abbiamo scelto un'implementazione, anche se un agente ha fatto la maggior parte del lavoro.

Questa può essere una transizione difficile. Anni di attento lavoro possono diventare la base per una continuazione che si muove molto più velocemente. Ciò solleva domande reali sul credito. Cambia anche ciò che i manutentori devono sapere prima di accettare un contributo.

L'analogia industriale mi aiuta a pensare a questo. In un mestiere, gran parte del processo dipende dall'abilità della persona che lo esegue. Le macchine cambiano dove è necessaria questa abilità. Qualcuno deve ancora progettare il processo e riconoscere quando il suo output è sbagliato. Diverse comunità possono scegliere quanto di quel cambiamento vogliono assumere.

La mia scelta è di continuare apertamente, con l'opera ereditata accreditata e la sua storia preservata. Voglio che il nuovo lavoro sia rivedibile. Questo ci dà un modo per chiederci fino a che punto questo approccio può andare e per imparare da ciò che va storto lungo la strada.

Fonte: di GensokyoClub Avviso LEGGIMI, controllato il 10 ottobre 2026, e la sua politica contributiva. La citazione è un estratto abbreviato. Di TH08 crediti e provenienza registra il limite di continuazione.

TH095: l'esperienza inizia a comporre

TH095 , Spara il proiettile, ha reso il valore di quell'esperienza molto più facile da vedere. Il suo repository è iniziato il 29 agosto con zero funzioni di gioco confermate nel libro mastro. Dovevamo ancora imparare il gioco. Ma sapevamo già molto di più su come iniziare una ricostruzione e come mantenerla in movimento.

Entro il 7 settembre, tutte le 697 funzioni di gioco identificate avevano fonte. Entro l ' 8 settembre, 696 erano stati accettati come confronti esatti. L'intero programma collegato il 9 settembre. La ricostruzione Windows i386 è stata contrassegnata come giocabile il 10 settembre, circa dodici giorni dopo l'inizializzazione.

Ho trovato questo più eccitante della velocità del primo progetto. Un nuovo obiettivo potrebbe beneficiare del lavoro svolto su un altro gioco. L'esperienza era già presente negli strumenti e nel modo in cui il progetto è stato organizzato.

Ad esempio, TH08 ci aveva insegnato a prestare attenzione al programma assemblato in anticipo. Se diverse funzioni recuperate dipendono dallo stesso stato, i loro confronti isolati lasciano aperta una domanda importante. Dobbiamo vederli lavorare insieme. Quella lezione ha contribuito a modellare il modo in cui ci siamo avvicinati alla compilazione dell'intero programma di TH095.

Una lezione che rimane nella mia testa è utile mentre sono lì. Una volta che diventa un controllo che un'altra sessione può eseguire, può continuare ad aiutare dopo che sono andato avanti. L'agente successivo può utilizzare il risultato senza ripetere l'indagine che lo ha portato.

Il bug costante in virgola mobile appartiene anche a quella memoria. Spiega perché il controllo di un riferimento richiede anche il controllo dei dati dietro di esso. Mantenere tale correzione con il codice aiuta i progetti successivi a evitare di ereditare il punto cieco del vecchio controllo.

Il metodo diventa parte del materiale di partenza per la prossima partita. Possiamo spendere di più dello sforzo del prossimo progetto su ciò che è effettivamente nuovo sul suo obiettivo.

Lo stesso vantaggio è disponibile per le persone che si uniscono in seguito. Possono ispezionare una decisione e rieseguirne il controllo prima di continuare il lavoro. Non devono ricostruire la storia dell'intero progetto per scoprire perché la fonte sembra il modo in cui lo fa.

TH04: il flusso di lavoro sopravvive a un'architettura diversa

TH04 , Lotus Land Story, ha portato questo lavoro nell'era DOS PC-98. L'obiettivo era ora un ambiente a 16 bit con quattro programmi cooperanti. La comprensione del suo comportamento hardware richiedeva prove diverse dai giochi Windows. Esistente ReC98 lavoro ci ha dato preziose conoscenze e materiale sorgente anche qui.

La ricostruzione del DOS sta funzionando. Nel mio test manuale, ho giocato percorsi normali completi attraverso i loro finali e controllato i salvataggi. Il lavoro corrente è una porta nativa a 64 bit. Stabilire una versione DOS funzionante prima dà a quella porta un riferimento.

L'architettura ha cambiato ciò che avevamo bisogno di indagare. Ha anche cambiato il compilatore e il runtime rispetto al quale abbiamo controllato il nostro lavoro. Ma l'agente potrebbe ancora seguire una domanda fino a un risultato e lasciare che quel risultato guidi il prossimo esperimento.

Considera il passaggio dal gameplay a un finale. Dobbiamo sapere quale stato attraversa quel confine e quale programma ne è responsabile. Questo è qualcosa che possiamo indagare contro il prodotto DOS. Una volta che le prove e i controlli sono disponibili, un agente può elaborare la domanda come ha fatto su un titolo Windows.

Questo è il motivo per cui TH04 è importante per l'argomento. Un cambiamento sostanziale della piattaforma non ci ha costretto a ricominciare da capo con un nuovo modo di lavorare. L'architettura ha definito il problema; il flusso di lavoro ci ha comunque dato un modo per risolverlo.

Per la porta a 64 bit, possiamo ora esaminare la nuova implementazione contro il comportamento già recuperato su DOS. La conoscenza della ricostruzione dà al porto qualcosa su cui costruire.

Stato del progetto al 10 ottobre 2026: Ricostruzione DOS e test manuale · porta a 64 bit. Il porto è ancora in fase di sviluppo.

Dal codice esatto al codice leggibile

Una volta che una ricostruzione funziona, voglio che qualcun altro sia in grado di capirlo.

Per me, assemblaggio e offset grezzi possono sembrare vecchi amici. Mi rendo conto che questa è una definizione leggermente insolita di " leggibile."La maggior parte delle persone preferirebbe seguire la logica del gioco senza tenere in mente il layout della memoria dell'eseguibile.

Ecco dove ricostruzione semantica entrare. Un campo recuperato può ancora essere conosciuto principalmente dal suo offset. Seguiamo come il gioco lo utilizza fino a quando non possiamo spiegare il suo ruolo. Quindi possiamo dargli un nome significativo e un tipo che si adatta alle prove. Manteniamo il ragionamento con la fonte in modo che la prossima persona possa vedere da dove proviene quell'interpretazione.

Questo diventa particolarmente importante per una porta software. Un indirizzo assoluto mi dice dove viveva qualcosa nel vecchio eseguibile. Dà un piccolo aiuto all'implementazione a 64 bit nel decidere quale oggetto dovrebbe possedere quello stato. Per spostare il comportamento in modo sicuro, abbiamo bisogno di recuperare la relazione dietro il vecchio accesso alla memoria.

L'ordine che ora uso è:

1. Recuperare una linea di base esatta. Compilare i pezzi ricostruiti con il compilatore storico. Confronta il codice e i dati rilevanti con l'eseguibile originale. Registra le differenze irrisolte in modo che la fase successiva abbia un chiaro punto di partenza.
2. Costruire e giocare sulla piattaforma originale. Collega questi pezzi al programma reale usando l'architettura e il compilatore originali. Esercitare importanti percorsi di gioco. È qui che possiamo trovare problemi con lo stato condiviso o l'inizializzazione che un confronto di funzioni isolato ha mancato.
3. Ricostruire la semantica contro entrambi i riferimenti. Prendi una parte coerente del gioco alla volta e stabilisci cosa significa la sua fonte recuperata. Migliora la sua rappresentazione preservando i confronti esatti e la build storica giocabile.
4. Rendere il porto moderno. Spostare il comportamento stabilito nel nuovo ambiente, ad esempio una build nativa a 64 bit. Il gioco a piattaforma originale ricostruito rimane un riferimento per confrontare come si comporta la porta.

La build giocabile dal secondo stadio diventa un secondo riferimento di verifica (oracle) durante il terzo. Il primo riferimento di verifica (oracle) verifica se la nostra fonte modificata riproduce ancora il codice e i dati originali pertinenti. Il secondo verifica che il programma ricostruito costruisca e si comporti correttamente lungo i percorsi che esercitiamo.

Prendono diversi errori. Una modifica del tipo può alterare le istruzioni generate. Un cambio di proprietà può lasciare due parti del gioco utilizzando diverse copie di stato. Mantenere entrambi i controlli disponibili dà all'agente un fallimento concreto per indagare prima di portare un refactor ulteriormente.

Un nome ha bisogno di prove proprie. Un confronto esatto non può dirci se un campo significa davvero "tempo di invulnerabilità"."Dobbiamo stabilirlo da come il gioco lo scrive e lo usa. Se il significato rimane incerto, un nome neutro è più utile al prossimo lettore di un'ipotesi sicura.

Abbiamo imparato questo ordine attraverso i progetti. TH08 aveva già porte giocabili prima di alcuni dei suoi successivi audit della piattaforma storica. Ciò ha reso alcuni difetti più difficili da vedere. Il Flusso di lavoro corrente della fabbrica mette al primo posto la build della piattaforma originale, quindi il lavoro semantico può usarlo come riferimento prima dell'inizio del porting.

La ricostruzione esatta ci dà un riferimento. La ricostruzione semantica rende fruibile la conoscenza recuperata. Una porta può quindi costruire su entrambi.

Cosa rende questo un cambiamento industriale

Questi progetti sono cambiati dove ho speso la mia attenzione. Una volta che gli agenti hanno potuto portare avanti molte indagini, migliorare il loro ambiente di lavoro è diventata una delle cose più utili che potessi fare. Uno strumento migliore potrebbe aiutare con ogni funzione successiva che ne aveva bisogno.

L'autonomia conta qui. L'utile passo successivo diventa spesso chiaro solo dopo un esperimento fallito. Un agente ha bisogno di abbastanza libertà per seguire quel risultato da qualche parte inaspettato. Se deve aspettare che io prescriva ogni passo, gran parte del lavoro rimane legato alla mia attenzione.

Mi aspetto che l'agente faccia ipotesi sbagliate. Ciò che conta è se possiamo testarli e imparare dal risultato. Un controllo fallito dovrebbe aiutare a capire l'errore abbastanza bene da riprovare. Devo ancora decidere se le prove accumulate supportano una pietra miliare del progetto.

REA consente all'agente di accedere agli strumenti di analisi. Una domanda sul chiamante di una funzione può portare direttamente all'ispezione di quel chiamante. Il progetto di ricostruzione fornisce il compilatore e i propri controlli di riferimento. L'agente può usarli per testare la fonte che propone e vedere dove regge la sua spiegazione.

Il bug TH08 mostra perché quei controlli meritano attenzione ingegneristica. Quando lo stesso confronto viene utilizzato tra centinaia di funzioni, una lacuna in esso può diffondersi molto più di un errore in un'implementazione. Testare il checker migliora il feedback disponibile per tutti i lavori successivi.

L'analogia industriale ha qui un utile esempio storico. Boulton e Watt hanno introdotto un indicatore del motore a vapore nel 1796 per aiutare a regolare le valvole del motore. Una versione di registrazione tracciata pressione attraverso la corsa del pistone. Ha reso il comportamento interno del motore disponibile per l'ispezione. I nostri strumenti di confronto hanno uno scopo simile: ci permettono di esaminare ciò che il macchinario sta facendo mentre lo miglioriamo.

Siamo nelle prime fasi di questo cambiamento industriale. Gran parte dell'infrastruttura è ancora immatura. Gli agenti possono muoversi più velocemente di quanto i nostri controlli siano stati progettati per supportare, quindi il processo deve svilupparsi insieme a loro. Quando troviamo un difetto in uno strumento condiviso, dobbiamo ripararlo e rivedere i risultati che ha influenzato. Il prossimo progetto può quindi ereditare uno strumento più forte.

C'è anche un limite pratico a qualsiasi conversazione. Finirà prima che una grande ricostruzione sia terminata. Il repository del codice sorgente deve consentire a un'altra sessione di continuare senza perdere il motivo dell'ultima decisione.

Il Touhou Ricostruzione Fabbrica nasce da questo bisogno. Offre ai progetti un modo condiviso per portare avanti i loro controlli e lezioni. Lavorare su un gioco può migliorare le condizioni di partenza per un altro.

Questo è ciò che rende l'analogia industriale significativa per me. L'esperienza inizia a diventare parte di strumenti che gli altri possono utilizzare. Migliorare questi strumenti cambia quanto la prossima persona—o il prossimo agente-può fare.

I progetti che possiamo ora considerare

Il ritmo è importante perché cambia la decisione di iniziare. Un gioco potrebbe essere affascinante da decodificare e richiedere ancora più attenzione di quanto potrei realisticamente dargli. Molti progetti rimarrebbero idee.

Ora posso vedere un modo per mantenere un tale progetto in movimento attraverso ripetute indagini. Ottenere una ricostruzione funzionante rende una porta software più pratica. Il recupero della semantica leggibile rende più facile per qualcun altro esplorare un mod. Lo sforzo messo in comprensione del gioco può continuare a pagare dopo la prima versione viene eseguito.

Ora guardo un programma sconosciuto e chiedo: quale accesso, feedback e conoscenza accumulata permetterebbero a un agente di lavorare su questo in modo affidabile?

Questa domanda mi fa prendere in considerazione progetti che in precedenza avrei lasciato da solo. Ognuno può migliorare il modo in cui ci avviciniamo al prossimo. Voglio continuare a esplorare fino a che punto ci può portare.

Altri articoli · Esplora un'indagine TH04