La révolution industrielle dans l'ingénierie inverse.

Ce qui a changé en août 2026

Avant ce travail, j'avais fait beaucoup de rétro-ingénierie manuelle. J'inspectais une fonction jusqu'à ce que j'aie une explication, puis je testais cette explication par rapport au programme. Aller plus loin signifiait passer plus de temps sur la prochaine fonction. Cela signifiait aussi garder une image de plus en plus grande dans ma tête.

La majeure partie de mon travail concerne les jeux. Je les reconstruis pour que leur comportement puisse être compris et éventuellement transposé dans un port logiciel ou un mod. C'est l'expérience derrière cet article. La méthode peut être utile ailleurs, mais chaque champ doit établir ce qu'il peut vérifier par rapport à une référence fiable.

En août 2026, j'ai commencé à explorer sérieusement l'ER pilotée par les agents. Je voulais voir jusqu'où un agent pouvait aller avec l'accès au programme et aux outils de développement ordinaires. La reconstruction de Touhou m'a donné un projet substantiel pour le découvrir.

Les premiers progrès ont été surprenants. Une enquête pourrait continuer à avancer sans que je choisisse chaque étape individuelle. Une comparaison échouée peut envoyer l'agent à un autre appelant. Il pourrait écrire un petit diagnostic et utiliser le résultat pour décider quoi essayer ensuite. Lui donner cette liberté a fait la différence: je pouvais consacrer plus d'attention à l'orientation du projet et à la fiabilité de ses vérifications.

Le rythme a attiré mon attention en premier. Puis j'ai commencé à me demander ce qui survivrait au-delà du projet actuel. Le prochain jeu bénéficierait-il de tout ce que nous venions d'apprendre?

TH08: s'appuyer sur le travail humain

TH08, Nuit impérissable, a commencé comme une continuation de GensokyoClubreconstruction de. Leur source publique m'a donné une base substantielle. Il est venu avec la connaissance de la construction et un historique des contributions que j'ai conservé dans la suite.

L'historique importé se termine au point de contrôle public du 10 août. Ma continuation indépendante a commencé le 13 août. Le 19 août, le grand livre enregistrait la source des 1 107 fonctions de jeu identifiées.

Un port de reconstruction jouable de Linux a été engagé le 24 août, environ onze jours après le début de la continuation. Une édition Web a suivi. La version native Linux 64 bits est arrivée le 30 août.

Ce qui m'a frappé, c'est que le travail avait atteint un programme que les gens pouvaient exécuter. Y arriver nécessitait de suivre des problèmes au-delà d'une fonction individuelle. Même lorsque deux fonctions semblaient correctes isolément, elles pouvaient accidentellement utiliser des copies séparées de l'état qui auraient dû être partagées.

Cela a fait des vérifications des références un élément central du travail. Je les appelle références de vérification (oracles). Une comparaison de code peut nous dire si une fonction reconstruite reproduit les instructions d'origine. Une vérification d'exécution peut nous dire si une route exercée atteint l'état attendu. L'agent propose une explication et la teste; un décalage lui donne quelque chose de spécifique à étudier.

Une correspondance exacte avec la mauvaise constante

Une référence de vérification (oracle) est un logiciel que quelqu'un a écrit. TH08 m'a rappelé clairement à quel point on peut dépendre de ce logiciel.

En septembre, un bogue signalé par un port de commutateur en aval a renvoyé à la collecte automatique des éléments. La source reconstruite a vérifié la puissance du joueur par rapport 0.0. L'original utilisé 128.0, le seuil de puissance maximale.

La puissance normale n'est pas négative, de sorte que le contrôle de puissance reconstruit était effectivement toujours satisfait. Au-dessus de la ligne de collecte, le jeu pouvait attirer des objets sans nécessiter une puissance maximale. Les autres exceptions à la condition étaient correctes. Cette seule constante a changé le comportement.

Pourtant, la fonction avait déjà réussi la comparaison exacte.

Une reconstruction peut placer une constante à une adresse différente. L'outil de comparaison a tenu compte de cela en ajustant les adresses dans les instructions compilées avant de les comparer avec l'original. Mais il n'a jamais vérifié la valeur à virgule flottante stockée à l'adresse référencée.

Cela a laissé un trou dans le chèque. Il pourrait pointer l'instruction reconstruite vers l'original 128.0 alors que la source disait encore 0.0. Les octets d'instruction correspondent. La source signifiait quelque chose de différent.

Les Correctif du 2 septembre correction de la source et vérification de la comparaison des octets réels de la constante référencée. A audit plus large puis examiné 1 548 références constantes à virgule flottante. Il a trouvé douze autres références incorrectes dans cinq fonctions acceptées.

La comparaison vérifie maintenant chacune de ces constantes à virgule flottante. Ses tests incluent des valeurs délibérément erronées pour s'assurer qu'elles sont rejetées. Nous avons également dû revoir les résultats qui avaient réussi le test le plus faible.

La référence de vérification (oracle) devait également être reconstruite. La réparer faisait partie de la réparation du jeu.

C'est important lorsque l'équipe est principalement composée d'une seule personne travaillant avec des agents. Je ne peux pas inspecter personnellement chaque ligne qu'ils produisent, donc une grande partie de ma confiance repose sur leurs contrôles. L'angle mort d'une référence de vérification partagée (oracle) peut affecter de nombreuses enquêtes avant que je ne m'en aperçoive. Je dois comprendre ce que le vérificateur vérifie réellement et le tester par rapport aux cas qui devraient échouer.

Au fur et à mesure que le travail se poursuivait, ces vérifications sont devenues une partie du référentiel. Il en va de même pour les raisons des changements de source et des notes qui permettent à une session ultérieure de reprendre là où une session précédente s'est arrêtée. Le référentiel de code source devenait la mémoire de travail du projet.

Un lot réussi nous a donné à la fois du code récupéré et un meilleur environnement pour le lot suivant.

Deux idées différentes de reconstruction

GensokyoClub's LISEZ-MOI public rend explicite son désaccord avec ce genre de travail. L'avis annonce que d'autres développements auront lieu en privé jusqu'à leur achèvement. Un passage se lit comme suit:

La montée en puissance des arnaqueurs (décompilations et ports d'IA) dans cet espace, tirée de notre travail, donne une mauvaise image des futurs efforts de décompilation…

L'avis décrit également les conséquences psychologiques pour les responsables. Leur politique de contribution exclut les pull requests produites principalement avec l'IA. Ils ont consacré leur temps libre à un travail difficile, et ce travail a contribué à rendre ma continuation possible. Je respecte l'effort derrière cela. Le désaccord dont je veux discuter concerne la manière dont la reconstruction devrait se dérouler et la manière dont une contribution devrait être jugée.

Dans le flux de travail manuel que je connaissais, développer une compréhension d'une fonction et la reconstruire revenait généralement à la même personne. Un projet reposait fortement sur l'expertise de cette personne. La confiance dans le contributeur importait parce qu'une grande partie du raisonnement se produisait pendant qu'ils travaillaient.

Les projets existants préservent déjà les connaissances dans leur source et construisent des outils. Ce qui a changé pour moi, c'est qu'un agent pouvait utiliser ces connaissances pour poursuivre seul la prochaine enquête.

Dans ma suite, je décide de l'objectif et de la norme pour accepter un résultat. L'agent a une grande liberté pour enquêter. Sa reconstruction proposée doit ensuite survivre aux vérifications pertinentes. Je veux qu'une autre personne puisse examiner pourquoi nous avons choisi une implémentation, même si un agent a fait la majeure partie du travail.

Cela peut être une transition difficile. Des années de travail minutieux peuvent devenir la base d'une continuation qui avance beaucoup plus vite. Cela soulève de vraies questions sur le crédit. Cela change également ce que les mainteneurs doivent savoir avant d'accepter une contribution.

L'analogie industrielle m'aide à y réfléchir. Dans un métier, une grande partie du processus dépend de l'habileté de la personne qui l'exécute. Les machines changent là où cette compétence est nécessaire. Quelqu'un doit encore concevoir le processus et reconnaître quand sa sortie est erronée. Différentes communautés peuvent choisir la part de ce changement qu'elles souhaitent assumer.

Mon choix est de continuer ouvertement, avec le travail hérité crédité et son histoire préservée. Je veux que le nouveau travail soit révisable. Cela nous donne un moyen de nous demander jusqu'où cette approche peut aller et d'apprendre de ce qui ne va pas en cours de route.

Sources: GensokyoClub's LISEZ-MOI l'avis, vérifié le 10 octobre 2026, et son politique de contribution. La citation est un extrait raccourci. TH08's crédits et provenance enregistrez la limite de continuation.

TH095: l'expérience commence à s'accumuler

TH095, Tirez sur la balle, a rendu la valeur de cette expérience beaucoup plus facile à voir. Son dépôt a débuté le 29 août avec zéro fonction de jeu confirmée dans le grand livre. Nous devions encore apprendre le jeu. Mais nous en savions déjà beaucoup plus sur la façon de commencer une reconstruction et de la faire avancer.

Au 7 septembre, les 697 fonctions de jeu identifiées avaient une source. Au 8 septembre, 696 avaient été acceptées comme comparaisons exactes. L'ensemble du programme s'est lié le 9 septembre. La reconstruction Windows i386 a été marquée jouable le 10 septembre, environ douze jours après l'initialisation.

J'ai trouvé cela plus excitant que la vitesse du premier projet. Une nouvelle cible pourrait bénéficier du travail effectué sur un autre jeu. L'expérience était déjà présente dans les outils et dans la manière dont le projet était organisé.

Par exemple, TH08 nous avait appris à prêter attention au programme assemblé très tôt. Si plusieurs fonctions récupérées dépendent du même état, leurs comparaisons isolées laissent une question importante ouverte. Nous devons les voir travailler ensemble. Cette leçon a aidé à façonner la façon dont nous avons abordé la construction de l'ensemble du programme de TH095.

Une leçon qui reste dans ma tête est utile pendant que j'y suis. Une fois que cela devient une vérification qu'une autre session peut s'exécuter, cela peut continuer à m'aider après que je sois passé à autre chose. L'agent suivant peut utiliser le résultat sans répéter l'enquête qui y a conduit.

Le bogue de la constante à virgule flottante appartient également à cette mémoire. Cela explique pourquoi la vérification d'une référence nécessite également de vérifier les données qui la sous-tendent. Conserver cette correction avec le code aide les projets ultérieurs à éviter d'hériter de l'angle mort de l'ancien chèque.

La méthode devient une partie du matériel de départ pour le prochain match. Nous pouvons consacrer plus d'efforts au prochain projet sur ce qui est réellement nouveau à propos de sa cible.

Le même avantage est disponible pour les personnes rejoignant plus tard. Ils peuvent inspecter une décision et réexécuter sa vérification avant de poursuivre le travail. Ils n'ont pas à reconstituer l'historique complet du projet pour savoir pourquoi la source ressemble à ce qu'elle est.

TH04: le flux de travail survit à une architecture différente

TH04, Histoire de Lotus Land, a pris ce travail dans le PC-98 Ère DOS. La cible était maintenant un environnement 16 bits avec quatre programmes coopérants. Comprendre son comportement matériel nécessitait des preuves différentes de celles du Windows jeux. Existant Travail ReC98 nous a donné des connaissances précieuses et du matériel source ici aussi.

La reconstruction DOS fonctionne maintenant. Lors de mes tests manuels, j'ai joué des itinéraires normaux complets jusqu'à leurs fins et vérifié les sauvegardes. Le travail actuel est un port natif 64 bits. L'établissement d'une version DOS fonctionnelle donne d'abord à ce port une référence.

L'architecture a changé ce que nous devions étudier. Cela a également changé le compilateur et le moteur d'exécution par rapport auxquels nous avons vérifié notre travail. Mais l'agent pourrait toujours suivre une question jusqu'à un résultat et laisser ce résultat guider l'expérience suivante.

Considérez la transition du gameplay à une fin. Nous devons savoir quel État franchit cette frontière et quel programme en est responsable. C'est quelque chose que nous pouvons étudier contre le produit DOS. Une fois que les preuves et les vérifications sont disponibles, un agent peut résoudre la question autant qu'il l'a fait sur un titre Windows.

C'est pourquoi TH04 est important pour l'argument. Un changement substantiel de plateforme ne nous a pas obligés à recommencer avec une nouvelle façon de travailler. L'architecture définissait le problème; le flux de travail nous donnait encore un moyen de le résoudre.

Pour le port 64 bits, nous pouvons maintenant examiner la nouvelle implémentation par rapport au comportement déjà récupéré sur DOS. Les connaissances issues de la reconstruction donnent au port de quoi s'appuyer.

État du projet au 10 octobre 2026: Reconstruction DOS et tests manuels · port 64 bits. Le port reste en développement.

Du code exact au code lisible

Une fois qu'une reconstruction fonctionne, je veux que quelqu'un d'autre puisse la comprendre.

Pour moi, l'assemblage et les décalages bruts peuvent ressembler à de vieux amis. Je me rends compte que c'est une définition un peu inhabituelle de “lisible."La plupart des gens préféreraient suivre la logique du jeu sans garder en tête la disposition de la mémoire de l'exécutable.

C'est là reconstruction sémantique entre. Un champ récupéré peut encore être connu principalement par son décalage. Nous suivons comment le jeu l'utilise jusqu'à ce que nous puissions expliquer son rôle. Ensuite, nous pouvons lui donner un nom significatif et un type qui correspond aux preuves. Nous gardons le raisonnement avec la source afin que la personne suivante puisse voir d'où vient cette interprétation.

Cela devient particulièrement important pour un port logiciel. Une adresse absolue me dit où quelque chose vivait dans l'ancien exécutable. Cela donne une implémentation 64 bits peu d'aide pour décider quel objet doit posséder cet état. Pour déplacer le comportement en toute sécurité, nous devons récupérer la relation derrière l'ancien accès mémoire.

L'ordre que j'utilise maintenant est:

1. Récupérez une ligne de base exacte. Compilez les pièces reconstruites avec le compilateur historique. Comparez le code et les données pertinents avec l'exécutable d'origine. Enregistrez les différences non résolues afin que la phase suivante ait un point de départ clair.
2. Construisez-le et jouez-le sur la plate-forme d'origine. Reliez ces éléments au programme réel en utilisant l'architecture et le compilateur d'origine. Exercez des chemins de jeu importants. C'est là que nous pouvons trouver des problèmes d'état partagé ou d'initialisation qu'une comparaison de fonction isolée a manqués.
3. Reconstruisez la sémantique par rapport aux deux références. Prenez une partie cohérente du jeu à la fois et établissez ce que signifie sa source récupérée. Améliorez sa représentation tout en préservant les comparaisons exactes et la construction historique jouable.
4. Faire le port moderne. Déplacez le comportement établi dans le nouvel environnement, tel qu'une version native 64 bits. Le jeu de plateforme original reconstruit reste une référence pour comparer le comportement du port.

La construction jouable de la deuxième étape devient un deuxième référence de vérification (oracle) pendant la troisième. La première référence de vérification (oracle) vérifie si notre source modifiée reproduit toujours le code et les données d'origine pertinents. La seconde vérifie que le programme reconstruit se construit toujours et se comporte correctement le long des chemins que nous exerçons.

Ils attrapent différentes erreurs. Un changement de type peut modifier les instructions générées. Un changement de propriétaire peut laisser deux parties du jeu utilisant des copies d'état différentes. Garder les deux vérifications disponibles donne à l'agent un échec concret à enquêter avant de poursuivre un refactor.

Un nom a besoin de preuves qui lui sont propres. Une comparaison exacte ne peut pas nous dire si un champ signifie vraiment "temps d'invulnérabilité"."Nous devons établir cela à partir de la façon dont le jeu l'écrit et l'utilise. Si la signification reste incertaine, un nom neutre est plus utile au prochain lecteur qu'une supposition confiante.

Nous avons appris cet ordre à travers les projets. TH08 avait déjà des ports jouables avant certains de ses audits ultérieurs de plate-forme historique. Cela rendait certains défauts plus difficiles à voir. Les Flux de travail actuel de l'usine place la construction de la plate-forme d'origine en premier, de sorte que le travail sémantique puisse l'utiliser comme référence avant le début du portage.

La reconstruction exacte nous donne une référence. La reconstruction sémantique rend les connaissances récupérées utilisables. Un port peut alors s'appuyer sur les deux.

Qu'est-ce qui en fait un changement industriel

Ces projets ont changé où j'ai passé mon attention. Une fois que les agents ont pu mener une grande partie de l'enquête, l'amélioration de leur environnement de travail est devenue l'une des choses les plus utiles que je pouvais faire. Un meilleur outil pourrait aider avec chaque fonction ultérieure qui en avait besoin.

L'autonomie compte ici. L'étape suivante utile ne devient souvent claire qu'après une expérience ratée. Un agent a besoin de suffisamment de liberté pour suivre ce résultat dans un endroit inattendu. S'il doit attendre que je prescrive chaque étape, une grande partie du travail reste liée à mon attention.

Je m'attends à ce que l'agent fasse de fausses hypothèses. Ce qui compte, c'est de savoir si nous pouvons les tester et apprendre du résultat. Une vérification échouée devrait l'aider à comprendre suffisamment bien l'erreur pour réessayer. Je dois encore décider si les preuves accumulées soutiennent une étape importante du projet.

REA donne à l'agent l'accès aux outils d'analyse. Une question sur l'appelant d'une fonction peut conduire directement à l'inspection de cet appelant. Le projet de reconstruction fournit le compilateur et ses propres vérifications de références. L'agent peut les utiliser pour tester la source qu'il propose et voir où son explication tient la route.

Le bogue TH08 montre pourquoi ces vérifications méritent leur propre attention technique. Lorsque la même comparaison est utilisée sur des centaines de fonctions, une lacune informatique peut se propager beaucoup plus loin qu'une erreur dans une implémentation. Tester le vérificateur améliore les commentaires disponibles pour tous ces travaux ultérieurs.

L'analogie industrielle a ici un exemple historique utile. Boulton et Watt ont introduit un indicateur de machine à vapeur en 1796 pour aider à régler les soupapes du moteur. Une version d'enregistrement a tracé la pression à travers la course du piston. Il a rendu le comportement interne du moteur disponible pour inspection. Nos outils de comparaison ont un objectif similaire: ils nous permettent d'examiner ce que fait la machinerie pendant que nous l'améliorons.

Nous en sommes aux premiers stades de ce virage industriel. Une grande partie de l'infrastructure est encore immature. Les agents peuvent se déplacer plus rapidement que ce que nos contrôles ont été conçus pour prendre en charge, le processus doit donc se développer à leurs côtés. Lorsque nous trouvons un défaut dans un outil partagé, nous devons le réparer et revoir les résultats qu'il a affectés. Le projet suivant peut alors hériter d'un outil plus puissant.

Il y a aussi une limite pratique à toute conversation. Il se terminera avant qu'une grande reconstruction ne soit terminée. Le dépôt de code source doit permettre à une autre session de continuer sans perdre la raison de la dernière décision.

Les Usine de Reconstruction de Touhou est né de ce besoin. Cela donne aux projets un moyen partagé de faire avancer leurs vérifications et leurs leçons. Travailler sur un jeu peut améliorer les conditions de départ d'un autre.

C'est ce qui rend l'analogie industrielle significative pour moi. L'expérience commence à faire partie des outils que d'autres peuvent utiliser. L'amélioration de ces outils change ce que la personne suivante—ou l'agent suivant—peut accomplir.

Les projets que nous pouvons maintenant envisager

Le rythme est important car il change la décision de commencer. Un jeu pourrait être fascinant à désosser et exiger encore plus de ma propre attention que je ne pourrais raisonnablement lui accorder. De nombreux projets resteraient des idées.

Maintenant, je peux voir un moyen de faire avancer un tel projet à travers des enquêtes répétées. Obtenir une reconstruction fonctionnelle rend un portage logiciel plus pratique. La récupération d'une sémantique lisible permet à quelqu'un d'autre d'explorer plus facilement un mod. Les efforts déployés pour comprendre le jeu peuvent continuer à porter leurs fruits après l'exécution de la première version.

Je regarde maintenant un programme inconnu et demande: quels accès, commentaires et connaissances accumulés permettraient à un agent de travailler de manière fiable sur ce sujet?

Cette question me fait envisager des projets que j'aurais auparavant laissés seuls. Chacun peut améliorer la façon dont nous abordons le suivant. Je veux continuer à explorer jusqu'où cela peut nous mener.

Plus d'articles · Explorez une enquête sur le TH04