Ich versuche, ein Kontrollflussdiagramm der Assemblierergebnisse zu erstellen, die über einen Aufruf von objdump -d zurückgegeben werden. Derzeit ist die beste Methode, die ich gefunden habe, jede Zeile des Ergebnisses in eine verknüpfte Liste zu setzen und die Speicheradresse, den Opcode und die Operanden für jede Zeile zu trennen. Ich teile sie aus, indem ich auf die normale Natur der objdump-Ergebnisse angewiesen bin (die Speicheradresse ist von Zeichen 2 bis Zeichen 7 in der Zeichenfolge, die jede Zeile darstellt).
Sobald dies erledigt ist, starte ich den eigentlichen CFG-Befehl. Jeder Knoten in der CFG enthält eine Anfangs- und Endspeicheradresse, einen Zeiger auf den vorherigen Basisblock und Zeiger auf alle untergeordneten Basisblöcke. Ich gehe dann durch die objdump-Ergebnisse und vergleiche den Opcode mit einem Array aller Kontrollfluss-Opcodes in x86_64. Wenn der Opcode ein Steuerfluß ist, zeichne ich die Adresse als das Ende des Basisblocks auf und addiere abhängig von dem Opcode entweder zwei Kindzeiger (bedingter Opcode) oder einen (Aufruf oder Rückgabe).
Ich bin dabei, dies in C umzusetzen, und es scheint, als würde es funktionieren, fühlt sich aber sehr schwach an. Hat jemand irgendwelche Vorschläge oder etwas, das ich nicht in Betracht ziehe?
Danke, dass Sie sich die Zeit genommen haben, dies zu lesen!
bearbeiten:
Die Idee besteht darin, Stacktraces von Systemaufrufen, die von DynamoRIO generiert wurden, mit der erwarteten CFG für eine Zielbinärdatei zu vergleichen. Ich hoffe, dass der Aufbau so erleichtert wird. Ich habe das, was verfügbar ist, nicht wiederverwendet, weil A) ich nicht wirklich darüber nachgedacht habe und B) ich den Graphen in eine brauchbare Datenstruktur bringen muss, damit ich Pfadvergleiche machen kann. Ich werde mir einige Utilities auf der Seite ansehen, auf die Sie sich geeinigt haben, danke, dass Sie mich in die richtige Richtung weisen. Vielen Dank für Ihre Kommentare, ich schätze es wirklich!
Sie sollten eine AWL verwenden, die für die Programmanalyse entwickelt wurde. Es gibt ein paar.
Das DynInst-Projekt (dyninst.org) hat einen Lifter, der von ELF-Binärdateien in CFGs für Funktionen / Programme übersetzen kann (oder es tat das letzte Mal, als ich schaute). DynInst ist in C ++ geschrieben.
BinNavi verwendet die Ausgabe von IDA (Interactive Disassembler), um eine IL aus Kontrollflussdiagrammen zu erstellen, die IDA identifiziert. Ich würde auch eine Kopie von IDA empfehlen, damit Sie CFGs visuell überprüfen können. Sobald Sie ein Programm in BinNavi haben, können Sie seine IL-Darstellung einer Funktion / CFG erhalten.
Funktionszeiger sind nur der Anfang Ihrer Probleme, um das Kontrollflussdiagramm statisch zu identifizieren. Sprungtabellen (die Arten, die in bestimmten Fällen für Schalter-Fall-Anweisungen erzeugt werden, von Hand in anderen) werfen ebenfalls einen Schraubenschlüssel hinein. Jeder Code-Analyse-Rahmen, den ich kenne, befasst sich mit denen in einem heuristischen Ansatz. Dann haben Sie Ausnahmen und Ausnahmenbehandlung sowie selbst modifizierenden Code.
Viel Glück! Sie erhalten bereits eine Menge Informationen aus dem DynamoRIO-Trace, ich schlage vor, dass Sie so viele Informationen wie möglich aus diesem Trace verwenden ...
Ich habe deine Frage gefunden, weil ich daran interessiert war, nach dem gleichen zu suchen. Ich habe nichts gefunden und ein einfaches Python-Skript dafür geschrieben und es auf GitHub geworfen: Ссылка
Beachten Sie, dass ich einige Heuristiken habe, um mit Funktionen umzugehen, die niemals zurückkehren, den gcc Stack Protector auf 32bit x86, etc ... Sie können solche Dinge wollen oder auch nicht.
Ich behandle indirekte Aufrufe ähnlich wie Sie tun (im Grunde haben Sie einen Knoten im Graphen, der eine Quelle ist, wenn Sie von einem indirekten zurückkehren).
Dies ist hoffentlich hilfreich für alle, die ähnliche Analysen mit ähnlichen Einschränkungen durchführen möchten.
Tags und Links c assembly x86-64 objdump control-flow-graph