ccc
v2.1
Uma biblioteca e um conjunto de ferramentas de linha de comando para analisar símbolos de depuração de jogos PS2. A série de lançamentos 1.x focou em símbolos STABS nas seções .mdebug, enquanto a série de lançamentos 2.x também pode analisar símbolos ELF padrão e símbolos de vinculador SNDLL. O suporte DWARF está em andamento.
Desmontador de símbolos C++ com suporte para o novo esquema de manipulação Itanium C++ ABI (GCC 3+) e o antigo esquema GCC 2.
Desmontador MIPS central EE parcialmente funcional. Provavelmente não é muito interessante.
Analisador e dumper de tabela de símbolos. Ele pode extrair as seguintes informações:
Os seguintes formatos de saída são suportados:
Isto deve ser usado com ghidra-emotionengine-reloaded (>= 2.1.0 ou uma das compilações instáveis) para importar todas essas informações para o Ghidra. Observe que, apesar do nome, o analisador STABS deve funcionar para o R3000 (IOP) e possivelmente também para outros processadores MIPS.
Isso é semelhante ao stdump, exceto que organiza sua saída em arquivos de origem separados e possui vários recursos extras projetados para tentar tornar a saída mais próxima do código-fonte válido. Um arquivo SOURCES.txt deve ser fornecido no diretório de saída, que pode ser gerado usando o comando stdump files (você deve corrigir os caminhos manualmente para que sejam relativos ao diretório de saída e remover os endereços). Além disso, arquivos não vazios que não comecem com // STATUS: NOT STARTED não serão substituídos.
Se um arquivo FUNCTIONS.txt for fornecido no diretório de saída, como pode ser gerado usando o script CCCDecompileAllFunctions.java incluído para Ghidra, o código desse arquivo será usado para preencher os corpos das funções na saída. Neste caso, o primeiro grupo de declarações de variáveis locais emitidas serão aquelas recuperadas dos símbolos, e o segundo grupo será o código fornecido no arquivo de funções. Os nomes das funções são desmontados.
Os dados variáveis globais serão impressos de forma estruturada com base no seu tipo de dados.
Os tipos de dados serão classificados em seus arquivos correspondentes. Como essas informações não são armazenadas na tabela de símbolos, o uncc usa heurística para mapear tipos para arquivos. Os tipos serão colocados em arquivos .c ou .cpp quando houver apenas uma única unidade de tradução na qual o tipo aparece, e em arquivos .h quando houver várias (e, portanto, quando a heurística deve ser usada para determinar onde colocá-los).
Recomenda-se o uso de um formatador de código como clang-format ou astyle na saída.
cmake -B bin/
cmake --build bin/
mdebugread.c do gdb (leitura)ecoff.c de gás (escrita)include/coff/sym.h de binutils (cabeçalhos)stabs.c de binutils (leitura)stabsread.c do gdb (leitura)dbxread.c do gdb (leitura)dbxout.c do gcc (escrita)stab.def do gcc (códigos de símbolos) O código-fonte da biblioteca CCC e das ferramentas de linha de comando associadas é lançado sob a licença do MIT.
É usado o demangler GNU, que contém arquivos de origem licenciados sob a GPL e LGPL. RapidJSON é usado sob a licença do MIT. A biblioteca GoogleTest é usada pelo conjunto de testes sob a licença BSD de 3 cláusulas.
