Braucht Reverse Engineering ein größeres Modell?

Was leistungsfähigere Modelle verändert haben

Seit August 2026 erforsche ich, wie viel Reverse Engineering ein Agent mit Zugriff auf ein Programm und einer Möglichkeit zur Überprüfung seiner Arbeit durchführen kann. Der größte Teil meiner Erfahrung stammt aus der Rekonstruktion von Spielen, insbesondere Touhou. Da ich die Modelle geändert habe, haben die Repositorys aufgezeichnet, was jede Sitzung wiederherstellen konnte.

Ein Großteil dieser Arbeit zielt auf eine exakte Rekonstruktion ab: Wir kompilieren die gepflegte Quelle unter einer historischen Toolchain mit festen Versionen und prüfen, ob sie die Zielfunktion reproduziert. Wenn ein späteres Modell erfolgreich ist, wo frühere Arbeiten ins Stocken geraten sind, zeigen die Quelländerungen, was diesen Fortschritt ermöglicht hat.

Die temporären Variablen benötigten überlappende Lebensdauern

Ein Großteil der Logik einer TH09-Angriffsfunktion war bereits rekonstruiert, aber der Compiler speicherte temporäre Ergebnisse immer noch anders als das Original. Das verbleibende Problem bestand darin, wie lange diese Ergebnisse am Leben bleiben mussten und wann ihr Speicher wiederverwendet werden konnte.

Ein GPT-6-Sol-Sitzungsdatensatz hat diese Nichtübereinstimmung gemeldet, nachdem mehrere gewöhnliche Quellcode-Anordnungen getestet wurden. Als GPT-6.1-Sol das Problem erneut untersuchte, schlug es eine nützliche Hypothese über die Lebensdauer dieser temporären Variablen vor.

Die Funktion erzeugte temporäre Ergebnisse und kopierte sie in Animationspositionen. In C++ bleibt ein temporäres Ergebnis bestehen, bis der Ausdruck, der es verwendet, beendet ist. Durch die Gruppierung der realen Operationen in einem Ausdruck blieben diese Ergebnisse zusammen erhalten, sodass der Compiler nicht mehr denselben Speicher für alle wiederverwenden konnte.

Ein Ergebnis wird weiterhin gemeinsam mit einem Wert gespeichert, der später für Kollisionsprüfungen verwendet wird. Indem man diesem Wert seine eigene Lebensdauer zuordnete, wurde die verbleibende Überlappung behoben. Nach mehreren gezielten Experimenten bestätigte eine saubere Neukompilierung aus dem Quellcode, dass die vollständige Funktion übereinstimmte.

Mich interessiert, wie sich Entdeckung und Tests gegenseitig unterstützten. Die Hypothese über die temporäre Lebensdauer von Objekten gab dem KI-Agenten eine neue Richtung. Das Feedback des Compilers half dabei, diese Hypothese in eine passende Quellcode-Anordnung zu verfeinern.

Ein anderes Kontrollflussdiagramm

Eine zweite TH09-Funktion zeigt, warum eine neue Richtung wichtig sein kann. Hier ging es darum, wie mehrere Verzweigungen dieselben abschließenden Operationen nutzen. GPT-6.1-Sols frühere Arbeit brachte Teile der Funktion zur Übereinstimmung, doch die Verzweigungen liefen noch anders zusammen als im Original.

GPT-6-Astra hat das umgebende Kontrollflussdiagramm geändert. Die Hauptwege führten nun zu einer gemeinsamen finalen Aktualisierung und Rückkehr. In dieser Quellstruktur kombinierte der Compiler die Zweige auf die gleiche Weise wie im Original. Die vollständige Funktion stimmte überein und eine separate Neuerstellungsprüfung bestätigte dies.

Durch die Änderung der Darstellung wurde ein produktiverer Suchraum eröffnet. Beide Fälle geben mir einen Grund, die allgemeine Modellfähigkeit ernst zu nehmen: Ein Agent kann lange Zeit lokale Variationen ausprobieren, bevor er eine bessere Möglichkeit findet, die umgebende Arbeit auszudrücken.

Die späteren Sitzungen übernahmen allerdings auch früheren Quellcode und aufgezeichnete Fehlversuche. Diese Vorarbeit war Teil ihres Vorteils. Die Historie macht die Entdeckungen und ihre Prüfungen nachvollziehbar. Ein kontrollierter Vergleich würde helfen, den Beitrag des Modells vom Beitrag der übernommenen Erfahrung zu trennen.

Das macht die Frage für mich interessant. Einige Fortschritte wurden durch die Suche nach einer neuen Vertretung erzielt. Ein Großteil der verbleibenden Arbeit bestand darin, verschiedene Quellcode-Anordnungen mit einem vertrauten Compiler zu testen. Wie viel davon erfordert ein breites Denkvermögen? Wie viel könnte ein Modell lernen, wenn es wiederholt mit diesem Compiler und Code arbeitet?

Warum könnte ein spezialisiertes KI-Modell gut funktionieren?

Touhou gibt uns einen konkreten Grund zu der Annahme, dass diese Erfahrung hilfreich sein wird. Ein Großteil des Spielcodes stammt vom selben Autor, ZUN, daher sind wiederkehrende Gewohnheiten eine vernünftige Ausgangsannahme. Die Repositories untermauern dies mit nützlichen Beispielen: Verwandte Schleifen und Hilfsanordnungen haben spielübergreifend Hypothesen geliefert.

Diese Quellmuster werden spezifischer, wenn wir den Compiler einbeziehen. Unter einer bestimmten Version und einem bestimmten Optionssatz können kleine Änderungen in der Quelle zu wiederholbaren Unterschieden im Maschinencode führen. Einige dieser Unterschiede sind überraschend unklar.

In TH095 beispielsweise könnte sogar der Name einer lokalen Variablen Einfluss darauf haben, wo VC7.1 sie gespeichert hat. Das Verschieben der Deklaration hat das Speicherlayout nicht gelöst. Allerdings hatte eine frühere Hintergrundfunktion ein Namensmuster offenbart, das die Wahl des Compilers beeinflusste. Das legte eine vielversprechendere Hypothese für die Rekonstruktion von Supervisor::LoadDat nahe.

Durch die Wiederverwendung dieses Musters für die Dateigrößenvariable wurde das erforderliche Layout erstellt, ohne dass Speicherplatz hinzugefügt werden musste. Die gesamte Funktion stimmte dann überein.

Dies ist ein sehr spezifisches Detail, das einem allgemeines KI-Modell möglicherweise nicht bekannt ist, wenn es zum ersten Mal auf das Problem stößt. Ein auf diesen Compiler spezialisiertes Modell könnte viele solcher Fälle erkennen und herausfinden, welche Quellcodevarianten es wert sind, zuerst getestet zu werden.

Die Chance wird besonders deutlich bei finalen Matching-Problemen, bei denen wir das Verhalten bereits verstehen. Wir fragen uns dann, welche gewöhnliche Quellcodeanordnung dieser Compiler in die beobachteten Anweisungen umwandelt. Durch die Spezialisierung könnte das Modell diese Formen effizienter vorschlagen, während das Ziel weiterhin bestimmt, welche Hypothesen bestehen bleiben.

Nützliche Muster müssen ihren Kontext behalten. TH08 verwendet eine frühere Visual C++-Version als TH095 und TH09. TH04 verwendet einen anderen Compiler aus der DOS-Ära. Für die Rekonstruktion des Spielercodes waren unterschiedliche Hypothesen über Quellcodemuster und die Art und Weise erforderlich, wie kompilierter Code mit einer ausführbaren Datei verknüpft wurde. Wenn wir denselben Autor haben, haben wir zunächst eine Erwartung, aber jedes Ziel sagt uns, ob es zutrifft. Ein spezielles Modell müsste diese Kontexte unterscheiden.

Wo sollte diese Erfahrung gespeichert werden?

Bevor ich mich entscheide, diese Muster durch Modelltraining zu lehren, würde ich mir das Wissen ansehen, das wir bereits im Repository speichern. Im vorherigen Aufsatz habe ich darüber geschrieben, dass es zum Arbeitsgedächtnis des Projekts wird. Dieser Speicher umfasst Compiler-Lektionen sowie die Quelle und fehlgeschlagene Experimente, die sie nützlich gemacht haben.

Durch das Abrufen dieses Datensatzes kann ein Agent mit einem bekannten Ergebnis beginnen und prüfen, wie wir zu diesem Ergebnis gelangt sind. Es können auch Alternativen vermieden werden, die im gleichen Kontext bereits gescheitert sind. Der Ausgangspunkt verbessert sich, ohne die trainierten Parameter des Modells zu ändern.

Bei der Rekonstruktion der Funktion von TH09 zum Erstellen von Feinden hat eine GPT-6-Luna-max-Sitzung eine Hypothese aus dem zugehörigen TH08-Quellcode übernommen. Dieser frühere Code schlug vor, wie die Schleife organisiert und Fehler darin behandelt werden sollten. Die eigenen Beweise von TH09 lieferten die spielspezifischen Details. Neuaufbauten aus der Quelle bestätigten, dass die vollständige Funktion übereinstimmte.

„Das Modell kannte diese Compiler-Eigenart nicht“ und „Das Modell konnte sie nicht verwenden“ sind unterschiedliche Probleme. Das erste Problem kann durch das Abrufen gelöst werden, aber die Umwandlung dieser Tatsache in einen nützlichen Kandidaten erfordert noch Arbeit. Und wenn der Quellcode des Kandidaten fehlschlägt, muss das Modell entscheiden, was das Ergebnis für seinen nächsten Versuch bedeutet. Die Kenntnis des relevanten Musters ist nur der Anfang dieses Prozesses.

Aus diesem Grund würde ich in jeden Vergleich ein kleineres allgemeines KI-Modell mit gutem Abruf einbeziehen. Wenn wir ihm die gleiche Erfahrungsbibliothek zur Verfügung stellen, können wir herausfinden, was die Schulung bringt: bessere Kandidatengenerierung, bessere Entscheidungen nach Feedback oder beides.

Lernen Sie das nächste nützliche Experiment

Diese Entscheidungen nach Feedback sind das, was ich am liebsten studieren würde. Bei der Agentenrekonstruktion schlägt das Modell eine Erklärung vor und testet sie anhand des Programms. Selbst wenn der Quellcode des Kandidaten fehlschlägt, kann das Ergebnis die verbleibenden Möglichkeiten einschränken und ein nützlicheres nächstes Experiment vorschlagen.

Das Beispiel der temporären Ergebnisse zeigt auch das. Der endgültige Quellcode enthält die Anordnung, die funktioniert hat. Der Weg dorthin enthält jedoch zusätzliche Informationen: Jedes der folgenden Experimente zeigte, was noch geändert werden musste.

Ausgewählte Experimente aus der Angriffsfunktionsrekonstruktion oben, gruppiert nach dem, was sie uns gelehrt haben.

Eine Trainingsaufzeichnung, die diese Reihenfolge beibehält, kann mehr lehren als die endgültige Quelle allein. Es verbindet jede vorgeschlagene Änderung mit einem beobachteten Ergebnis und der nächsten Entscheidung. Es ist auch wichtig, ineffektive Variationen beizubehalten: Sie teilen einem späteren Agenten mit, welche Hypothesen in diesem Zusammenhang bereits getestet wurden.

Ich möchte, dass das Modell lernt, Feedback zu nutzen. Ein neutrales Ergebnis ist ein Grund, die Variation noch einmal zu überdenken. Eine veränderte Nichtübereinstimmung kann auf eine andere Ursache hinweisen. Wenn lokale Änderungen nicht mehr informativ sind, sollte der Agent in der Lage sein, die Quellendarstellung noch einmal aufzurufen oder die Beweise erneut zu prüfen.

Zu lernen, diese Entscheidungen zu treffen, erfordert Autonomie. Manchmal besteht der nützliche nächste Schritt darin, einen anderen Aufrufer zu überprüfen, anstatt eine weitere Bearbeitung zu kompilieren. Eine starre Abfolge erforderlicher Umschreibungen würde diese Wahlmöglichkeit zusammen mit einem Teil des Verhaltens, das das Modell lernen soll, aufheben.

Warum Reverse Engineering für Reinforcement Learning interessant ist

Rekonstruktion mit klar abgegrenztem Umfang bietet eine praktische Umgebung, um diese Entscheidungen zu untersuchen. Bei festgelegtem Ziel und Compiler liefern viele Quellcodeexperimente schnelles, wiederholbares Feedback. Der Agent kann einen Kandidaten kompilieren, die Abweichungen prüfen und daraus den nächsten Schritt wählen.

Reinforcement Learning könnte diesen Entscheidungsprozess durch das erhaltene Feedback trainieren. Ein durch eine definierte Prüfung angenommener Kandidat gibt uns ein konkretes Ergebnis, während wir anhand der Abfolge der Versuche sehen können, wie viel Arbeit es gekostet hat, dieses zu erreichen.

Es gibt bereits Forschungsergebnisse, die diese Richtung unterstützen. LLM4Decompile untersucht Modelle, die auf die Dekompilierung spezialisiert sind. AutoDecompiler trainiert die Multi-Turn-Verfeinerung mithilfe von Compiler- und Ausführungsfeedback. Der Schwerpunkt ihrer Studien liegt auf der Wiederherstellung des Programmverhaltens. Für diese Arbeit würde ich sie als Ausgangspunkt für die damit verbundene Aufgabe verwenden, eine Quelle zu finden, die mit der Ausgabe eines historischen Compilers übereinstimmt.

Um eine so klar definierte Aufgabe zu erfüllen, müssen wir jedoch möglicherweise zunächst feststellen, welche Ressourcen eine Funktion besitzt, oder eine neue Methode zur Beobachtung des Programms während der Ausführung entwickeln. In TH08 beispielsweise führte ein Kollisionsunterschied dazu, wie das ursprüngliche Programm Gleitkommaberechnungen verarbeitete. Bevor der Agent eine nützliche Korrektur testen konnte, musste er herausfinden, was gemessen werden sollte.

Dies deutet auf eine weitere Rolle eines allgemein leistungsfähigen Modells hin: Es hilft dabei, das Problem überhaupt überprüfbar zu machen. Sobald diese Prüfung vorliegt, können wir untersuchen, wie weit eine erlernte Suchrichtlinie damit kommen kann.

Wenn der Prüfer falsch ist

Wenn wir eine Prüfung für das Training verwenden, wird auch ihr Prüfungsumfang Teil der Lernumgebung. Ich nenne eine solche Referenz oder einen solchen Prüfer ein Oracle. Selbst eine wiederholbare Antwort müssen wir danach beurteilen, was sie tatsächlich überprüft.

TH08 hat gezeigt, wie viel sich außerhalb dieser Abdeckung verbergen kann. Einige rekonstruierte Funktionen haben ihre exakten Vergleiche mit falschen Gleitkommakonstanten bestanden. Der Komparator passte die verschobenen Adressen an, bevor er die Anweisungen überprüfte, überprüfte die Werte hinter diesen Adressen jedoch nur, wenn sie explizit zur Überprüfung aufgezeichnet wurden. Andere wörtliche Verweise könnten ohne Prüfung ihrer Werte bestehen bleiben.

Um diese Lücke zu schließen, wurden bei einer umfassenderen Prüfung falsche Konstanten in Funktionen gefunden, die bereits die Überprüfung bestanden hatten. In einer Berechnung fügte der rekonstruierte Quellcode 1.0f hinzu, während das Original 32.0f hinzufügte.

Ein Modell, das durch die alte Verifizierungsprüfung belohnt wurde, könnte lernen, eine falsche Rekonstruktion zu erzeugen. Wir haben mit diesem Prüfer kein RL-Modell trainiert. Der von uns beobachtete Fehler lag in der Prüfung selbst. Aber wenn wir es als Belohnung nutzen würden, würde derselbe blinde Fleck Teil der Lernumgebung werden.

Ein Funktionstest kann einen ähnlichen blinden Fleck haben. Untersuchungen mit differenziellem Fuzzing auf LLM-Decompilern ergaben Verhaltensunterschiede außerhalb der bereitgestellten Tests. Wir müssen daher einen bestandenen Test im Hinblick auf die Fälle verstehen, in denen er durchgeführt wird. Ebenso muss eine Befehlsübereinstimmung im Hinblick auf die Bytes und Daten verstanden werden, die sie überprüft.

Bevor ich eine Art Verifizierungsprüfung als Belohnung verwende, würde ich sie mit absichtlich falschen Ergebnissen testen. Ich würde die Endabnahme auch getrennt vom Quellcode durchführen, den der KI-Agent bearbeiten kann. Das Modell muss die Verifizierung bestehen, indem es das Programm korrekt rekonstruiert. Andernfalls könnte das einfache Kopieren eines Byte-Arrays vom Ziel ein naives Bewertungssystem täuschen, ohne dass nützlicher Quellcode wiederhergestellt wird.

Die Verbesserung des Lernenden und die Verbesserung seines Prüfers gehören zum selben Forschungsproblem. Je besser der Lernende darin wird, das Feedback, das wir ihm geben, zu optimieren, desto wichtiger wird auch das Verständnis dieses Feedbacks.

Ein Vergleich, der sich lohnt

Wenn diese Prüfungen vorhanden sind, würde ich den Vergleich für eine feste VC7.1-Aufgabenfamilie starten. Zunächst würde ich Grundlinien für ein starkes allgemeines KI-Modell und ein kleineres Modell festlegen. Das Hinzufügen von Repository-Wissen zum kleineren Modell würde zeigen, welche Änderungen sich beim Abruf ergeben. Von dort aus würden wir durch eine überwachte Spezialisierung und eine RL-trainierte Version untersuchen können, was Training hinzufügt.

Um diese Vergleiche aussagekräftig zu machen, würde jedes Modell die gleichen Zieldaten und Tools erhalten. Für die ausbildungsspezifischen Vergleiche würde ich das Basismodell und das verfügbare Wissen ebenfalls unverändert lassen. Wiederholte Versuche würden dabei helfen, eine zuverlässige Suchstrategie von einer Kandidatenlösung zu unterscheiden, die zufällig erfolgreich ist.

Ich würde dann zwei Startbedingungen trennen: die Rekonstruktion einer Funktion aus ihren Anweisungen und die Beseitigung der letzten paar Unterschiede in der gepflegten Quelle. Bei der zweiten Aufgabe könnte ein spezialisiertes KI-Modell hervorragend geeignet sein, während ein allgemeines KI-Modell einen Großteil der dafür erforderlichen Arbeit übernimmt. Eine getrennte Messung würde diese Arbeitsteilung offenbaren.

Für beide Aufgaben sind Testbeispiele erforderlich, die vom Training und Abruf ausgeschlossen sind. Verwandte Touhou-Spiele teilen den Engine-Code. Der Ausschluss eines Spiels vom Training könnte dennoch dazu führen, dass nahezu identische Funktionen im Trainingsset verbleiben. Stattdessen würde ich ganze Gruppen verwandten Quellcodes ausschließen und ihre verifizierten Antworten sowohl aus den Trainingsdaten als auch aus der Abrufbibliothek heraushalten.

Das Ergebnis wären vollständige, unabhängig verifizierte Übereinstimmungen. Gleiche Budgets für Kandidaten oder Kompilierungsversuche helfen, die Suchqualität zu vergleichen. Gesamtzeit und Gesamtkosten einschließlich Kompilierung zeigen, ob diese Qualität einen effizienten Arbeitsablauf ermöglicht. Trainingskosten sollten separat erfasst werden.

Beide Messungen sind wichtig. Ein billiger Vorschlag kann zu einem teuren Arbeitsablauf führen, wenn er mehr Kompilierungen verursacht, die keine nützlichen Informationen liefern. Umgekehrt kann ein langsameres Modell wirtschaftlicher sein, wenn es früher ein nützliches Experiment findet. Der Vergleich sollte diese Kosten einbeziehen.

Akzeptierte Ergebnisse zu zählen hilft auch, Zwischenfortschritte einzuordnen. Ein Replay-Save-Kandidat aus TH09 wirkte vielversprechend, weil die kompilierte Funktion die erwartete Größe hatte. Der vollständige Vergleich fand aber noch erhebliche Unterschiede. Eine andere Anordnung der Befehle kann einen Kandidaten näher am Ziel erscheinen lassen, ohne das eigentliche Problem zu lösen. Solche Diagnosen können das nächste Experiment leiten; eine Belohnung für mehr Nähe würde ich jedoch anhand der vollständigen Abnahmeprüfung validieren.

Mich würde das Muster dieser Ergebnisse interessieren. Wenn ein spezialisiertes KI-Modell in einer bekannten Compilerfamilie gut funktioniert, überlebt dieser Vorteil dann auch eine Änderung der Toolchain? Und wenn beide KI-Modelle eine gute Retrievalfähigkeit haben, wie viel bringt das Training dann noch? Die Antworten würden uns helfen zu entscheiden, wo welche Art von Modell am nützlichsten ist.

Was für einen KI-Agenten lässt dies vermuten?

Wenn sich herausstellt, dass die Modelle in verschiedenen Phasen hilfreich sind, könnte ein umfassender Agent mit Zugriff auf ein spezielles KI-Modell eine nützliche Lösung sein. Sobald eine Aufgabe zu einer vertrauten Compiler-Suche wird, könnte sie das spezialisierte KI-Modell nach Kandidaten fragen. Wenn die Ergebnisse keinen Sinn mehr ergeben, könnte der breitere Agent zum Zielbeweis zurückkehren oder die Messung selbst untersuchen.

In dieser Vereinbarung wird die Spezialisierung zu einem Instrument, das der Agent im Verlauf der Untersuchung wählen kann. Der Agent behält die Freiheit, die Richtung zu ändern, die die früheren Durchbrüche ermöglicht hat.

Dies ergibt sich natürlich aus dem industriellen Wandel, den ich im vorherigen Aufsatz beschrieben habe. Die Möglichkeit, viel mehr Experimente durchführen zu können, verändert die Art und Weise, wie wir die Arbeit organisieren. Es gibt uns auch einen Grund zu fragen, welche Entscheidungen ein breites Urteilsvermögen erfordern und welche sich durch wiederholte Erfahrung mit einem bestimmten Handwerk verbessern.

Vorerst hat sich das stärkste allgemeine KI-Modell seinen Platz in meinem Arbeitsablauf verdient, indem es Probleme löste, die ich ungelöst gelassen hatte. Gerade diese Erfolge machen mich neugierig: Wie viel hing von seiner breiten Fähigkeit ab? Wie viel könnte ein Modell übernehmen, das auf diese Art der Rekonstruktion spezialisiert ist?

Die Repositorys bieten uns eine Möglichkeit, die Frage zu testen. Ich möchte diesen Datensatz verwenden, um den Vergleich zu erstellen und zu sehen, was wir lernen.