ccc
v2.1
Une bibliothèque et un ensemble d'outils de ligne de commande pour analyser les symboles de débogage des jeux PS2. La série de versions 1.x était axée sur les symboles STABS dans les sections .mdebug, tandis que la série de versions 2.x peut également analyser les symboles ELF standard et les symboles de l'éditeur de liens SNDLL. Le support DWARF est en préparation.
Démangleur de symboles C++ avec prise en charge à la fois du nouveau schéma de modification Itanium C++ ABI (GCC 3+) et de l'ancien schéma GCC 2.
Désassembleur MIPS à noyau EE à moitié fonctionnel. Probablement pas très intéressant.
Analyseur de table de symboles et dumper. Il peut extraire les informations suivantes :
Les formats de sortie suivants sont pris en charge :
Ceci est destiné à être utilisé avec ghidra-emotionengine-reloaded (>= 2.1.0 ou l'une des versions instables) pour importer toutes ces informations dans Ghidra. Notez que malgré son nom, l'analyseur STABS devrait également fonctionner pour le R3000 (IOP) et éventuellement pour d'autres processeurs MIPS.
Ceci est similaire à stdump sauf qu'il organise sa sortie dans des fichiers source séparés et possède un certain nombre de fonctionnalités supplémentaires conçues pour essayer de rapprocher ladite sortie du code source valide. Un fichier SOURCES.txt doit être fourni dans le répertoire de sortie, qui peut être généré à l'aide de la commande stdump files (vous devez corriger les chemins manuellement afin qu'ils soient relatifs au répertoire de sortie et supprimer les adresses). De plus, les fichiers non vides qui ne commencent pas par // STATUS: NOT STARTED ne seront pas écrasés.
Si un fichier FUNCTIONS.txt est fourni dans le répertoire de sortie, tel qu'il peut être généré à l'aide du script CCCDecompileAllFunctions.java inclus pour Ghidra, le code de ce fichier sera utilisé pour remplir les corps de fonction dans la sortie. Dans ce cas, le premier groupe de déclarations de variables locales émises sera celles récupérées à partir des symboles, et le deuxième groupe sera issu du code fourni dans le fichier de fonctions. Les noms de fonctions sont démêlés.
Les données variables globales seront imprimées de manière structurée en fonction de leur type de données.
Les types de données seront triés dans leurs fichiers correspondants. Puisque ces informations ne sont pas stockées dans la table des symboles, uncc utilise des heuristiques pour mapper les types aux fichiers. Les types seront placés dans des fichiers .c ou .cpp lorsqu'il n'y a qu'une seule unité de traduction dans laquelle le type apparaît, et dans des fichiers .h lorsqu'il y en a plusieurs (et donc lorsque des heuristiques doivent être utilisées pour déterminer où les placer).
L'utilisation d'un formateur de code tel que clang-format ou astyle sur la sortie est recommandée.
cmake -B bin/
cmake --build bin/
mdebugread.c de gdb (lecture)ecoff.c du gaz (écriture)include/coff/sym.h de binutils (en-têtes)stabs.c de binutils (lecture)stabsread.c de gdb (lecture)dbxread.c de gdb (lecture)dbxout.c de gcc (écriture)stab.def de gcc (codes de symboles) Le code source de la bibliothèque CCC et des outils de ligne de commande associés est publié sous licence MIT.
Le démangleur GNU est utilisé, qui contient des fichiers sources sous licence GPL et LGPL. RapidJSON est utilisé sous la licence MIT. La bibliothèque GoogleTest est utilisée par la suite de tests sous la licence BSD à 3 clauses.
