Anti-Jammer-Thread

[Krishty]

State of the Art ist seit einigen Jahren das Ghidra der NSA. Das kostet im Gegensatz zu IDA nichts.

Ghidra hat eine offene Architektur, man lädt sich also bspw. das Plugin zum Disassemblieren und Dekompilieren von PlayStation-Executables herunter.

Das kommt mit einer Erkennung aller Standardfunktioneren der Sony-C-Laufzeitbibliothek, die damals ausgeliefert wurden und in jedem PSX-Executable ähnlich gelinkt sind. Damit sind schonmal alle Aufrufe an sprintf() und scrnBlit() und malloc() und Hunderte mehr im Dekompilat als solche gekennzeichnet.

Weiterhin sind auch ihre Rückgabetypen gekennzeichnet, Ghidra weist dann also jeder Variable, die aus malloc() befüllt wird, rekursiv void * zu. Und jeder, die in strcpy() gereicht wird, char *. Damit sind schonmal 80–90 % aller Zeiger, Integer, und Gleitkommazahlen (hatte die PSX nur extrem begrenzt) im Dekompilat unterscheidbar. Man weiß zwar noch nicht, ob es ein signed oder unsigned int ist, oder welcher konkrete Datentyp hinter einem Zeiger steckt, aber das macht alles gehörig einfacher.

Und das hatten wir alles 2019, als wir Driver reverse engineered hatten, ohne KI.

Mit Debug-Symbolen bekommt man dann nochmal die Namen aller Funktionen dazu. 2019 war das ein scheiß Akt, die Debug-Informationen ins passende Format für Ghidra zu konvertieren, aber mittlerweile gibt es für so ziemlich alle Formate Ghidra-Plugins.

Jetzt kommen die neuen KI-Assistenten und Agenten, die in den letzten Jahren entstanden sind.

Was Jonathan erwähnt – der KI sagen, dass links unten ein HUD sein sollte, und das im Code finden – wird bei PS2-Spielen bspw. von https://github.com/hkmodd/PCSX2-MCP versprochen. Häng deinen Agenten an PCSX2-MCP und Ghidra, und lass ihn werkeln. Ich hab’s noch nicht selber ausprobiert, nur grob verfolgt wie andere das machen.

… dann hängt man einen SDL-basierten Wrapper für PlayStation-Standardfunktionen dran (gibt’s zu hauf im Internet; für ReDriver2 hatte Soapy damals Psy-Cross weiterentwickelt https://github.com/OpenDriver2/PsyCross) und schon ist der vibe-coded Port fertig.

[Jonathan]

Okay, es ist ein Missverständnis mit dem Begirfflichkeiten: C-Code generieren ist "out of scope" für einen Disassembler, denn der erzeugt nur Assemblercode. Alle normalen Debugger kriegen das wunderbar hin und denke gibt auch dedizierte Projekte. Deswegen meinte ich, dass es simpel ist.

Ah, ja, natürlich. Zwei ganz unterschiedliche Dinge, Assemblercode anzeigen kann in der Tat nicht so schwierig sein.

Nochmal bezüglich templates: Natürlich war das ein bisschen weitgegriffenes Wunschdenken. ABER: Wenn man einmal C-Code mit sinnvollen Namen und so hat, ist der Rest ja quasi nur noch Umstrukturieren. Da würde ich KI schon recht viel zutrauen. "Kann man diesen Code kompakter uns lesbarer machen, indem man ähnliche Teile zusammen fasst?" - Fast gleiche Funktionen die nur unterschiedliche Typen haben werden sicherlich erkannt. Außerdem kann man ja die Anforderungen lockern. Sagen wir, man könnte aus einem Haufen Funktionen eine Klasse machen, aber dann würde nach dem erneuten kompilieren immer noch ein this-Zeiger kopiert werden müssen - macht mein Programm vielleicht 0.2% langsamer, und das ist heute egal. Dadurch kommt hinten dann sicherlich nicht der identische Code raus, der vor 20 Jahren tatsächlich geschrieben wurde, aber das Verhalten bleibt gleich, er ist gut strukturiert und lesbar und performancetechnisch immer noch total ok.

Vollautomatisch würde ich das wohl eh nicht machen wollen, am Ende muss ja der Mensch entscheiden, was tatsächlich lesbar ist. Aber solche Vorschläge finden und auf Entwicklerwunsch automatisch umsetzen und auf Korrektheit testen halte ich für recht realistisch.

[Spiele Programmierer]

Weiterhin sind auch ihre Rückgabetypen gekennzeichnet, Ghidra weist dann also jeder Variable, die aus malloc() befüllt wird, rekursiv void * zu. Und jeder, die in strcpy() gereicht wird, char *. Damit sind schonmal 80–90 % aller Zeiger, Integer, und Gleitkommazahlen (hatte die PSX nur extrem begrenzt) im Dekompilat unterscheidbar. Man weiß zwar noch nicht, ob es ein signed oder unsigned int ist, oder welcher konkrete Datentyp hinter einem Zeiger steckt, aber das macht alles gehörig einfacher.

Ja das ist lieb, aber in einem echten Programm sind doch die wenigsten Zeiger char, Integer oder Gleitkommazahlzeiger. Stattdessen ist es ein Zeiger auf ein Spielobjekt, welches von einem dynamischen Typ in einem Spiel-Manager-Objekt liegt, welches in einem Levelobjekt liegt, welches...
Es reicht nicht rekursiv Funktionen und Register zu verfolgen. Du musst auch durch Speicheroperationen durchschauen. Da wird es erst lustig und das ist wo dann alles mögliche passieren kann.
Oder reden wir einfach von so alten Spielen, wo noch alles in globalen Arrays ohne OO-Hölle lag?

Was Jonathan erwähnt – der KI sagen, dass links unten ein HUD sein sollte, und das im Code finden – wird bei PS2-Spielen bspw. von https://github.com/hkmodd/PCSX2-MCP versprochen. Häng deinen Agenten an PCSX2-MCP und Ghidra, und lass ihn werkeln. Ich hab’s noch nicht selber ausprobiert, nur grob verfolgt wie andere das machen.

Ich bin da sehr skeptisch. 0 issues, 11 Sternchen, Readme sieht nach KI-Slop aus. Das eigentliche soll wohl auch eine externe KI lösen, aber hat diese KI überhaupt schon so viel debugging und Reverse-Engeneering-Erfahrung? Ich finde das von Jonathan beschrieben Szenario recht komplex. Ich wäre da echt erstaunt, wenn das quasi automatisch geht.

… dann hängt man einen SDL-basierten Wrapper für PlayStation-Standardfunktionen dran (gibt’s zu hauf im Internet; für ReDriver2 hatte Soapy damals Psy-Cross weiterentwickelt https://github.com/OpenDriver2/PsyCross) und schon ist der vibe-coded Port fertig.

Implizierst du, dass dein Dekompilator bereits Code erzeugen kann, der bis auf Funktionsaufrufe direkt wieder für x86 kompiliert?
Falls ja, dann bin ich auf jeden Fall beieindruckt. SO habe ich das nicht in Erinnerung bei uns.

ABER: Wenn man einmal C-Code mit sinnvollen Namen und so hat, ist der Rest ja quasi nur noch Umstrukturieren.

Ja, wenn nicht geinlined ist, die Namen ähnlich sind und es analog aussieht.
Inlining ist wohl der größte Spielverderber.

erneuten kompilieren immer noch ein this-Zeiger kopiert werden müssen - macht mein Programm vielleicht 0.2% langsamer, und das ist heute egal.

Wieso soll eine Klasse das Programm 0.2% langsamer machen?