Einige Antworten hier sagten, dass Debug-Informationen es einfacher machen würden, die Software rückzuentwickeln. Wenn ich Visual C ++ verwende und eine ausführbare Datei mit Debugging-Informationen, aber ohne andere Dateien (.pdb) vertreibe, enthält sie interessante Dinge?
Ich habe mit einem hexadezimalen Editor nach der ausführbaren Datei geschaut und nichts wie Symbolnamen gefunden, jetzt nehme ich an, dass die .exe-Datei nur auf Informationen in den .pdb-Dateien verweist, oder?
Weißt du, ob es
enthält?Debug-Builds erzeugen tendenziell Ausgaben, die leicht mit Hochsprachenkonstrukten korreliert werden können. Sie können Variablen, Tests, Schleifen usw. einfach anhand des Maschinencodes identifizieren. Sie werden keine Namen von Variablen erhalten, aber das ist normalerweise eine der am wenigsten wichtigen Überlegungen beim Reverse-Engineering.
Optimierter Code, OTOH, Anordnung von Anweisungen, Entfaltung von Schleifen, Wiederverwendung von Slots für mehrere Variablen, gemeinsame Nutzung von Code-Blöcken zwischen Funktionen, Inline-Funktionen usw., so dass es schwieriger ist, die ursprüngliche Absicht zu erkennen. Es erschwert auch das Debuggen, selbst wenn Sie den Code besitzen, da die aktuelle Zeilenmarkierung oft sehr irreführend ist und Variablen dazu neigen, zu verschwinden oder zufälligen Mist zu zeigen.
Aber das macht das Reverse-Engineering unmöglich. Es ist nur mehr Arbeit, um die Bedeutung herauszukitzeln.
Build mit Debuginformationen ist nicht "debug build".
"Debugbuild" wird erstellt, wenn das _DEBUG-Symbol definiert ist. Wenn ja, gibt es viele Zeichenfolgen, die für den Reverse-Engineer nützlich sind (Behauptungen usw.).
Sie können also Release mit Debugging-Informationen in .pbd erstellen, und das Programm zu dekompilieren ist genauso schwierig wie ohne Debugging-Informationen.
Die ausführbare Datei sollte keine Variablennamen oder Zeilennummern enthalten. Es kann Funktions- / Elementnamen für solche Namen enthalten, die exportiert werden (wahrscheinlicher für eine lib / dll als eine exe).
Die Struktur des Codes wird "enger" dem ursprünglichen Quellcode ähneln - es ist unwahrscheinlich, dass der Code inline geschrieben wurde, Anweisungen neu geordnet wurden, Schleifen abgerollt wurden, usw.
Optimierungen machen Code schwerer verständlich (und erschweren auch die Korrelation zwischen der Quelle und der Assembly, wenn Sie Ihren eigenen Code mit Symbolen und Quellen debuggen).
Ein Debug-Build enthält keine Zeilennummern, Funktionsnamen oder Zeilennummern, diese gehören zur PDB. Jedes Mal, wenn Sie assert () verwenden, enthält der Code a Zeichenfolge, die Dateinamen und Zeilennummern enthält.
Vor langer Zeit wurde die Debug-Information an die ausführbare Datei angehängt (im sogenannten CodeView-Format). Heutzutage kommt es meistens separat in PDB-Dateien vor. Die exe selbst enthält in der Tat nur einen Link zur PDB.
PDBs gibt es normalerweise in zwei Geschmacksrichtungen: privat und öffentlich (aka stripped). Öffentliche (z. B. die von Microsoft bereitgestellten) haben normalerweise nur Namen der Funktionen und globalen Variablen. Private (z. B. diejenigen, die beim Erstellen Ihrer App mit Debug-Informationen erstellt wurden) können zusätzlich Typinformationen (Strukturen, Aufzählungen, Klassen, Variablentypen), Funktionsprototypen, lokale Variablennamen und -typen sowie Zeilennummerninformationen enthalten.
Wenn Sie Ihre PDBs untersuchen möchten, überprüfen Sie DIA2Dump im Ordner "DIA SDK" in Ihrer Visual Studio-Installation.
Tags und Links c++ debugging reverse-engineering