Eine Bibliothek und eine Reihe von Befehlszeilentools zum Parsen von Debugging-Symbolen aus PS2-Spielen. Die Versionsreihe 1.x konzentrierte sich auf STABS-Symbole in .mdebug-Abschnitten, während die Versionsreihe 2.x auch Standard-ELF-Symbole und SNDLL-Linkersymbole analysieren kann. DWARF-Unterstützung ist in Arbeit.
C++-Symbol-Entangler mit Unterstützung sowohl für das neue Itanium C++ ABI (GCC 3+)-Mangling-Schema als auch für das alte GCC 2-Schema.
Halb funktionierender EE-Core-MIPS-Disassembler. Wahrscheinlich nicht allzu interessant.
Symboltabellen-Parser und Dumper. Es kann die folgenden Informationen extrahieren:
Die folgenden Ausgabeformate werden unterstützt:
Dies soll mit ghidra-emotionengine-reloaded (>= 2.1.0 oder einem der instabilen Builds) verwendet werden, um alle diese Informationen in Ghidra zu importieren. Beachten Sie, dass der STABS-Analysator trotz des Namens für den R3000 (IOP) und möglicherweise auch für andere MIPS-Prozessoren funktionieren sollte.
Dies ähnelt stdump, organisiert die Ausgabe jedoch in separaten Quelldateien und verfügt über eine Reihe zusätzlicher Funktionen, mit denen versucht wird, die Ausgabe näher an gültigen Quellcode zu bringen. Im Ausgabeverzeichnis muss eine SOURCES.txt
Datei bereitgestellt werden, die mit dem Befehl stdump files
generiert werden kann (Sie sollten die Pfade manuell korrigieren, sodass sie relativ zum Ausgabeverzeichnis sind, und die Adressen entfernen). Darüber hinaus werden nicht leere Dateien, die nicht mit // STATUS: NOT STARTED
beginnen, nicht überschrieben.
Wenn im Ausgabeverzeichnis eine FUNCTIONS.txt
Datei bereitgestellt wird, wie sie mit dem enthaltenen CCCDecompileAllFunctions.java
-Skript für Ghidra generiert werden kann, wird der Code aus dieser Datei verwendet, um die Funktionskörper in der Ausgabe zu füllen. In diesem Fall handelt es sich bei der ersten Gruppe ausgegebener lokaler Variablendeklarationen um diejenigen, die aus den Symbolen wiederhergestellt wurden, und bei der zweiten Gruppe handelt es sich um den in der Funktionsdatei bereitgestellten Code. Funktionsnamen werden entschlüsselt.
Globale Variablendaten werden basierend auf ihrem Datentyp strukturiert gedruckt.
Datentypen werden in die entsprechenden Dateien sortiert. Da diese Informationen nicht in der Symboltabelle gespeichert werden, verwendet uncc Heuristiken, um Typen Dateien zuzuordnen. Typen werden in .c
oder .cpp
Dateien abgelegt, wenn es nur eine einzige Übersetzungseinheit gibt, in der der Typ vorkommt, und in .h
Dateien, wenn es mehrere gibt (und daher Heuristiken verwendet werden müssen, um zu bestimmen, wo sie abgelegt werden sollen).
Es wird empfohlen, für die Ausgabe einen Codeformatierer wie clang-format
oder astyle
zu verwenden.
cmake -B bin/
cmake --build bin/
mdebugread.c
von gdb (Lesen)ecoff.c
aus Gas (Schreiben)include/coff/sym.h
aus binutils (Header)stabs.c
von binutils (Lesen)stabsread.c
von gdb (Lesen)dbxread.c
von gdb (Lesen)dbxout.c
von gcc (Schreiben)stab.def
von gcc (Symbolcodes) Der Quellcode für die CCC-Bibliothek und die zugehörigen Befehlszeilentools wird unter der MIT-Lizenz veröffentlicht.
Zum Einsatz kommt der GNU-Deangler, der unter der GPL und der LGPL lizenzierte Quelldateien enthält. RapidJSON wird unter der MIT-Lizenz verwendet. Die GoogleTest-Bibliothek wird von der Testsuite unter der 3-Klausel-BSD-Lizenz verwendet.