decomp
1.0.0
Ziel dieses Projekts ist es, eine Dekompilierungspipeline zu implementieren, die aus unabhängigen Komponenten besteht, die über gut definierte Schnittstellen interagieren, wie in den Entwurfsdokumenten des Projekts weiter beschrieben.
git clone https://github.com/decomp/decomp
cd decomp
go install -v ./...Weitere Informationen finden Sie unter Beispiele bei Beispielen/Demo und diesen Kommentar.
Aus Sicht auf hoher Ebene werden die Komponenten der Dekompilierungspipeline konzeptionell in drei Module zusammengefasst. Erstens übersetzt das Front-End eine Quellsprache (z. B. X86-Assembly) in LLVM IR; Eine plattformunabhängige Zwischendarstellung auf niedriger Ebene. Zweitens strukturiert die Middle-End-Strukturen des LLVM IR, indem sie hochrangige Kontrollstromprimitive identifiziert (z. B. Schleifen vor dem Test, 2-Wege-Bedingungen). Zuletzt übersetzt das Back-End die strukturierte LLVM IR in eine hochrangige Zielprogrammiersprache (z. B. GO).
Das folgende Poster fasst die aktuellen Funktionen der Dekompilierungspipeline zusammen, wobei eine Zusammensetzung unabhängiger Komponenten verwendet wird, um LLVM IR in die Übersetzung zu übersetzen.
Übersetzen Sie den Maschinencode (z. B. X86 -Assembly) in LLVM IR.
Front-End-Komponenten von Drittanbietern.
Führen Sie die Kontrollflussanalyse am LLVM IR durch, um hochrangige Kontrollflussprimitive (z. B. Vor-Test-Schleifen) zu identifizieren.
https://godoc.org/github.com/decomp/decomp/cmd/ll2dot
Steuerung der Steuerungsdiagrammgenerierung.
Generieren Sie Kontrollflussdiagramme aus LLVM IR -Assembly ( *.ll -> *.dot).
https://godoc.org/github.com/decomp/decomp/cmd/Restructure
Steuerflusserwiederherstellungswerkzeug.
Wiederherstellen Sie den Steuerflussprimitive aus Kontrollflussdiagrammen ( *.dot -> *.json).
Übersetzen Sie strukturiertes LLVM IR in eine Zielsprache auf hoher Ebene (z. B. GO).
https://godoc.org/github.com/decomp/decomp/cmd/ll2go
GO -Code -Generierungstool.
Decompile LLVM IR -Assembly zum Quellcode ( *.ll -> *.go).
https://godoc.org/github.com/decomp/decomp/cmd/go-post
Gehen Sie nach dem Verarbeitungstool.
Post -Prozess -Go -Quellcode, um ihn idiomatischer zu machen ( *.go -> *.go).
Hauptaugenmerk von Version 0.2: projektweite Kompilierungsgeschwindigkeit .
Die Entwicklung von Dekompilierungskomponenten sollte Spaß machen.
Es scheint eine umgekehrte Korrelation zwischen einer riesigen C ++ - Bibliothek zu geben, und die Spaß mit der Entwicklung von Dekompilierungskomponenten zu haben.
Version 0.2 der Dekompilierungspipeline bemüht sich, dieses Problem zu lösen, indem eine LLVM -IR -Bibliothek in Pure Go eingesetzt wird. Vor dieser Veröffentlichung könnte die projektweite Zusammenstellung mehrere Stunden dauern. Jetzt vervollständigen sie in weniger als 1 Minute - die festgelegte Hardgrenze für alle zukünftigen Veröffentlichungen.
Erstveröffentlichung.
Hauptfokus von Version 0.1: Kompositionaldekompilation .
Dekompiler sollten komponierbar und Open Source sein.
Eine Dekompilierungspipeline sollte aus einzelnen Komponenten mit jeweils einen einzelnen Zweck und genau definierten Eingang und Ausgang bestehen.
Version 0.1 des Decomp-Projekts untersucht die Machbarkeit, eine Dekompilierungspipeline aus unabhängigen Komponenten zu komponieren, und das Potenzial, diese Komponenten dem Endbenutzer auszusetzen.
Weitere Hintergrundinformationen finden Sie in der Kompositionsdekompilation mit LLVM IR -Designdokument.
Hauptfokus von Version 0.3: Typ-bewusstes binäres Heben .
Dekompiler verlassen sich auf hochwertiges binäres Heben.
Die Qualität des Ausgangs IR des Binärhebens Front-End bestimmt grundlegend die Qualität der Ausgabe der gesamten Dekompilierungspipeline.
Version 0.3 zielt darauf ab, die Qualität des Output-LLVM IR durch die Implementierung eines typpflichtigen Binärhebens-Front-Ends zu verbessern.
Hauptfokus von Version 0.4: Kontrollflussanalyse .
Dekompiler sollten hochrangige Kontrollflussprimitive wiederherstellen.
Einer der primären Unterschiede zwischen der Ansammlung von niedrigem Niveau und dem Quellcode auf hohem Niveau ist die Verwendung von Steuerflussprimitiven auf hoher Ebene. zB 1-Wege, 2-Wege und N-Wege-Bedingungen ( if , wenn es, if-else und switch ), Pre- und Post-Test-Schleifen ( while und do-while ).
Version 0.4 versucht, hochrangige Kontrollströmungsprimitive mit robusten Kontrollflussanalysealgorithmen wiederherzustellen.
Hauptfokus von Version 0.5: Fehlertoleranz .
Dekompiler sollten robust sein.
Dekompilierungskomponenten sollten gut auf unerwartete Zustände und unvollständige Analysen reagieren.
Version 0.5 konzentriert sich auf die Stabilität und versucht, die Dekompilierungspipeline mithilfe einer semi-realen Weltsoftware zu testen (siehe Challenge Issue-Serie).
Hauptaugenmerk von Version 0.6: Datenflussanalyse .
Hauptfokus von Version 0.7: Typanalyse .
