LLM4Decompile – Binärcode-Decompilierung mit LLMs

 (github.com/albertan017)
2 Punkte von GN⁺ 2024-03-18 | 1 Kommentare | Auf WhatsApp teilen
  • LLM4Decompile ist ein Open-Source-Projekt für große Sprachmodelle, das Linux-x86_64-Binärdateien auf den GCC-Optimierungsstufen O0 bis O3 wieder in für Menschen lesbaren C-Quellcode zurückführt
  • Der Ansatz wandelt Binärdateien zunächst mit Objdump in Assembler um und lässt sie dann vom LLM in C-Code dekompilieren; zusätzlich gibt es die Reihe LLM4Decompile-Ref, die von Ghidra erzeugten Pseudocode verfeinert
  • Die Modelle sind in Größen von 1.3B bis 22B veröffentlicht, und llm4decompile-9b-v2 erreichte im Decompile-Benchmark eine Re-executability von 64.9%
  • Die Bewertungsmetrik ist die Re-executability, also ob der dekompilierte Code korrekt ausgeführt wird und vordefinierte Tests besteht; als Benchmarks dienen 164 C-Funktionen aus HumanEval-Decompile und 2.621 Funktionen aus ExeBench
  • Das Projekt veröffentlichte 2025 decompile-bench und SK²Decompile und wird weiter ausgebaut, um mehr Architekturen, Konfigurationen und Decompiler-Integrationen zu unterstützen

Ziel und unterstützter Umfang von LLM4Decompile

  • LLM4Decompile ist ein Open-Source-Projekt für große Sprachmodelle, das auf Decompilierung spezialisiert ist
  • Die aktuelle Version dekompiliert Linux-x86_64-Binärdateien in einem Bereich von GCC-Optimierungsstufen von O0 bis O3 in für Menschen lesbaren C-Quellcode
  • Das Projekt wird derzeit erweitert, um breitere Architekturen und Konfigurationen zu unterstützen
  • Es gibt zwei zentrale Nutzungsarten
    • LLM4Decompile-End: Modellreihe zur direkten Decompilierung von Binärdateien
    • LLM4Decompile-Ref: Modellreihe, die von Ghidra dekompilierten Pseudocode mit einem LLM verfeinert

Decompilierungs-, Trainings- und Evaluationsablauf

  • Der Kompilierungsprozess beginnt mit C-Quellcode und erzeugt über Präprozessierung, Kompilierung, Assemblierung und Linking eine ausführbare Datei
  • Die Decompilierung folgt diesem Prozess in umgekehrter Richtung und wandelt Binärcode zurück in Quelldateien um
  • Da ein LLM Binärdaten nicht direkt verarbeiten kann, muss die Binärdatei zunächst mit Objdump in Assemblersprache disassembliert werden
  • Das README erklärt, dass Binärdateien und disassembliertes ASM ineinander umwandelbar sind und daher als gleichwertig behandelt werden
  • Im Training wird der Verlust zwischen dekompiliertem Code und ursprünglichem Quellcode berechnet, und in der Evaluation wird die Funktionalität darüber geprüft, ob Test-Assertions bestanden werden

Bewertungsmetriken und Benchmarks

  • Die zentrale Metrik ist Re-executability
    • Sie prüft, ob der dekompilierte Code korrekt ausgeführt wird
    • Bewertet wird, ob alle vordefinierten Testfälle bestanden werden
  • HumanEval-Decompile ist eine Sammlung von 164 C-Funktionen, die nur von der Standard-C-Bibliothek abhängen
  • ExeBench ist eine Sammlung von 2.621 Funktionen aus realen Projekten
    • Sie enthält benutzerdefinierte Funktionen, Strukturen und Makros

Verfügbare Modelle und Leistung

  • LLM4Decompile umfasst Modelle mit 1.3B bis 33B Parametern; die Modelle sind auf Hugging Face veröffentlicht
  • Die Re-executability der wichtigsten Modelle ist wie folgt
  • Die Reihe V1.5 wurde mit einem größeren Datensatz von 15B Tokens und einer maximalen Tokenlänge von 4.096 trainiert und soll im Vergleich zu früheren Modellen eine Leistungssteigerung von mehr als 100% erreicht haben
  • Die Reihe V2 basiert auf Ghidra und wurde mit 2B Tokens darauf trainiert, von Ghidra erzeugten dekompilierten Pseudocode zu verfeinern
  • Für 22B-V2 wird angegeben, dass es zusätzlich 40.1% höhere Leistung als 6.7B-V1.5 zeigt

Kürzlich veröffentlichte Elemente

  • Am 4. Oktober 2025 wurde SK²Decompile veröffentlicht
    • Stufe 1, Structure Recovery beziehungsweise die Skeleton-Phase, wandelt Binärdateien oder Pseudocode in eine verschleierte Zwischenrepräsentation um
    • Stufe 2, Identifier Naming beziehungsweise die Skin-Phase, erzeugt für Menschen lesbaren Quellcode mit aussagekräftigen Bezeichnern
    • Modell-Links: sk2decompile-struct-6.7b, sk2decompile-ident-6.7
  • Am 20. Mai 2025 wurde decompile-bench veröffentlicht
    • Enthält 2 Millionen Binärdatei-Quellcode-Funktionspaare für das Training
    • Enthält 70.000 Funktionspaare für die Evaluation
    • Details stehen im decompile-bench-Ordner
  • Am 17. Oktober 2024 wurde decompile-ghidra-100k veröffentlicht
    • Enthält insgesamt 100.000 Trainingsbeispiele, jeweils 25.000 pro Optimierungsstufe
    • Bietet ein Trainingsskript, das auf einer einzelnen A100-40G-GPU in etwa 3,5 Stunden läuft
    • Die schnelle Reproduktionskosten liegen insgesamt unter 20 Dollar, bei einer erreichten Re-executability von 0.26
  • Am 23. September 2024 wurde LLM4Decompile-9B-v2 veröffentlicht
    • Fine-tuned auf Basis von Yi-Coder-9B
    • Erreichte im Decompile-Benchmark eine Re-executability von 0.6494

Nutzungsablauf

  • Der Schnellstart besteht aus dem Klonen des Repositorys, dem Erstellen einer Conda-Umgebung und der Installation von requirements.txt
  • Im Präprozessierungsschritt wird C-Code mit GCC zu einer Binärdatei kompiliert und anschließend mit objdump -d in Assembleranweisungen zerlegt
  • Der Funktionsname muss vom Beispiel func0 auf den Namen der zu dekompilierenden Funktion geändert werden
  • Für den Eingabe-Assembler wird folgende Form erwartet
    • <FUNCTION_NAME>:
    • anschließend mehrere Zeilen mit Assembleranweisungen
  • Im Decompilierungsschritt wird das Hugging-Face-Modell über transformers mit AutoTokenizer und AutoModelForCausalLM geladen, um aus dem Assembler-Prompt C-Code zu erzeugen
  • Auch die Nutzung mit Docker ist möglich
    • Nach dem Bauen des Images wird der Container mit GPU-Optionen gestartet
    • Es wird ein Ablauf zum Ausführen von demo.py im Verzeichnis ghidra bereitgestellt

Datenformat von HumanEval-Decompile

  • Die HumanEval-Decompile-Daten werden als JSON-Liste in llm4decompile/decompile-eval/decompile-eval-executable-gcc-obj.json gespeichert
  • Die Anzahl der Samples beträgt 164*4, also 164 Funktionen multipliziert mit den Optimierungsstufen O0, O1, O2 und O3
  • Jedes Sample hat 5 Schlüssel
    • task_id: Problem-ID
    • type: Optimierungsstufe, eine von O0, O1, O2 oder O3
    • c_func: C-Lösung der HumanEval-Aufgabe
    • c_test: C-Test-Assertions
    • input_asm_prompt: Assembleranweisungen und Prompt
  • Das Evaluationsskript befindet sich im evaluation-Ordner

Laufende Arbeiten und Lizenz

  • Zu den laufenden Arbeiten zählen größere Trainingsdatensätze und Bereinigungsprozesse, Unterstützung für populäre Sprachen, Plattformen und Konfigurationen, Unterstützung für ausführbare Dateien sowie die Integration von Decompiler-Werkzeugen wie Ghidra und Rizin
  • Größere Trainingsdatensätze und Unterstützung für ausführbare Dateien sind als am 13. Mai 2024 abgeschlossen markiert
  • Das Code-Repository steht unter der MIT License und der DeepSeek License
  • Das Paper ist unter arXiv:2403.05286 verfügbar; das Projekt bietet außerdem Materialien für Colab und YouTube

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-18
Meinungen auf Hacker News

  • Eine interessante Idee, aber ich frage mich, ob die Ergebnisse vertrauenswürdig sein können.
    Beim erneuten Kompilieren kann anderer Maschinencode entstehen, sodass Halluzinationen schwer zu erkennen sind; besonders beunruhigend wäre ein stilles Scheitern bei neuen Strukturen, die für den Code zentral sein könnten.
    Ich frage mich, ob es beim generativen Vorgehen eine Möglichkeit gibt, dass das LLM auch die Konfidenz für bestimmte Abschnitte meldet; am Ende dürfte wohl eine menschliche Prüfung nötig sein.

    • Genau deshalb ist Round-Tripping wichtig.
      Wenn man ein Binary zu Quellcode dekompiliert und daraus wieder ein Binary kompiliert, sollte das ursprüngliche Binary herauskommen; dann wiederholt man das, bis der Verlust auf ein akzeptables Niveau sinkt.
      Reinforcement Learning passt sehr gut zu solchen Problemen und ist tatsächlich dafür bekannt, bei diesem Typ von Aufgaben ungewöhnlich effektiv zu sein.
    • LLMs sind ihrem Wesen nach probabilistisch und funktionieren in nicht präzisen Bereichen wie Natural Language Processing ziemlich gut, aber sie für Decompilation oder Disassembly einzusetzen, halte ich persönlich eher für den Fall „falsches Werkzeug gewählt“.
      Es mag ein Experiment sein, um das heute verbreitete Meme „nehmen wir einfach ein LLM“ auszuloten; das stärkere Gegenargument ist jedoch, dass bestehende Decompiler mit deutlich weniger Rechenaufwand bereits besser sind.
    • Man kann ein formales Verifikationstool nehmen, das Eingabe, Ausgabe und einen formalen Beweis dafür akzeptiert, dass die Eingabe semantisch zur Ausgabe passt, und das LLM zusammen mit der Ausgabe auch diesen Beweis erzeugen lassen.
      Anschließend kann man mit dem Verifikationstool anhand des vom LLM gelieferten Beweises prüfen, ob das Ergebnis korrekt ist.
      Natürlich wäre es die größere Herausforderung, ein LLM zu bauen und zu trainieren, das solche Beweise erzeugen kann; aber es könnte eine sichere Methode sein, Halluzinationen abzufangen.
    • Man kann auch Differential Fuzzing einsetzen.
    • Selbst wenn es nicht vollständig vertrauenswürdig ist, reicht es beim Ändern von Binaries oft aus, nur einige wenige Funktionen anzupassen.
      Daher muss man nur diese paar Funktionen neu kompilieren.

  • Wenn man die Entwickler der Anwendung kennt, wäre es interessant, ob man mit ihrem früheren Code als Trainingsdaten ein Decompilation-Modul trainieren könnte.
    Super Mario 64 und Zelda 64 sind zum Beispiel vollständig dekompiliert worden, und andere N64-Spiele sind in Arbeit; daher frage ich mich, ob man die Entwickler der beiden Spiele mappen und sogar abschätzen könnte, wer welche Module geschrieben hat, um das bei der Decompilation anderer Spiele zu nutzen.
    Wenn das wirklich gut wird, könnte man davon träumen, alle Binary Blobs im eigenen PC zu entschlüsseln, Treiber offenzulegen und sogar das OS aufzubrechen.
    Man könnte sich sogar vorstellen, sich nicht mit Linux zufriedenzugeben, sondern Windows XP wiederzubeleben, moderne Sicherheit und App-Kompatibilität zurückzuportieren und Microsofts Windows 11 links liegen zu lassen.

    • Decompiler existieren bereits und sind auch leistungsfähig.
      Wenn ein LLM dasselbe leisten kann wie ein bestehender Decompiler, werden Anwälte das wahrscheinlich als gleichwertiges Verfahren ansehen.
      Das Kernproblem ist kein technisches, sondern ein rechtliches und politisches.
    • In meiner Bachelorarbeit habe ich ein ähnliches Thema behandelt; es gab Forschung dazu, dass man unter bestimmten Bedingungen allein anhand eines kompilierten Binaries einen Autorenidentifikations-Klassifikator trainieren kann, der errät, wer das Programm geschrieben hat.
      Ich kenne keine wirklich nützlichen praktischen Anwendungen davon, aber es ist faszinierend, dass der persönliche Coding-Stil selbst nach dem Kompilieren noch erhalten bleibt und man kompilierte Programme verschiedener Personen unterscheiden kann.
    • Den tatsächlich geschriebenen Code selbst wird man wohl nicht identifizieren können.
      Das Ergebnis wäre dem Original sehr ähnlich, aber viele Code-Style-Elemente gehen verloren, und auch der scheinbar verbleibende Stil dürfte meist eher Halluzination sein.

  • Da sich aus öffentlichem C-Code leicht große Datensätze mit Eingabe-/Ausgabe-Paaren erzeugen lassen, ist das ein sehr guter Anwendungsfall für LLM-Fine-Tuning.

    • Es könnte in dieser Situation auch ziemlich vorteilhaft sein, mit Coding-LLMs, etwa Modellen wie DeepSeek, sehr viel C-Code zu generieren, die Kompilierbarkeit zu prüfen und ihn als synthetische Trainingsdaten zu verwenden.
      Normalerweise ist die Qualität synthetischer Trainingsdaten eine große Sorge, aber hier ist der entscheidende Punkt, dass der Code kompiliert.

  • Wenn ich die Zahlen zur Wiederausführbarkeit in der Ergebnisgrafik richtig lese, ist die Idee großartig, scheint in der Praxis aber nicht gut zu funktionieren.
    https://raw.githubusercontent.com/albertan017/LLM4Decompile/...
    Ergänzend: Wiederausführbarkeit ist eine zentrale Metrik für semantische Korrektheit.
    Dabei wird das Decompilation-Ergebnis erneut kompiliert und mit Testfällen ausgeführt, um zu bewerten, ob Programmlogik und Verhalten erhalten geblieben sind; Rekompilierbarkeit und Wiederausführbarkeit stehen jeweils für syntaktische Wiederherstellung und semantische Erhaltung.

  • Dieses Problem ist in mindestens zweierlei Hinsicht interessant.
    Erstens könnte ein idealer Decompiler die Bedeutung von proprietärem Quellcode abschwächen.
    Zweitens gibt es reichlich öffentlich verfügbaren C-Code, sodass sich leicht gepaarte Datensätze aus Assembly und Quellcode erstellen lassen, zudem mit unterschiedlichen Optimierungsstufen, Compilern und Plattformen.
    Allerdings frage ich mich, warum die Autoren DeepSeek-Coder feinabgestimmt haben.
    Ich frage mich auch, ob man mit einem ähnlichen Datensatz ein LLM von Grund auf trainieren könnte, wie groß es sein müsste und ob es lokal lauffähig wäre.

    • Der meiste proprietäre Code läuft hinter Firewalls und wird daher von so einem Ansatz nicht stark betroffen sein.
      Selbst wenn die gewünschte Aufgabe dem Ausgangsmodell nicht sehr nahekommt, ist es fast immer besser, mit einem vortrainierten Modell zu starten als mit zufälliger Initialisierung.
    • Einen idealen Decompiler gibt es nicht.
      Weil Compiler Informationen verlieren, kann es ihn in gewissem Sinne niemals geben; selbst aus der großzügigen Perspektive eines „High-Level-Verständnisses des Ergebnis-Codes“ ist das ein Problem auf dem Niveau von künstlicher allgemeiner Intelligenz im Bereich Computersicherheit.
      Noch ist niemand auch nur in die Nähe davon gekommen.
    • Ein Sprachmodell von Grund auf zu trainieren, benötigt viele Daten.
      Llama2 wurde mit 2 Billionen Tokens entwickelt, dieser Datensatz liegt aber nur bei etwa 4 Milliarden Tokens.
      Auch die passende Modellgröße lässt sich nicht einfach festlegen; in den Experimenten zeigte ein Modell mit 7 Milliarden Parametern eine Ausführbarkeit von 21 %, während ein Modell mit 1 Milliarde Parametern nur 10 % erreichte.
      Die Rekompilierbarkeit ist bei beiden allerdings recht ähnlich.
      Ein Modell mit 1 Milliarde Parametern benötigt mindestens 2 GB GPU-Speicher und ist damit auf den meisten GPUs möglich; das 7-Milliarden-Modell braucht 14 GB und passt zur 3090/4090-Klasse.
      Für das 33-Milliarden-Modell ist bei einer einzelnen Karte eine A100 mit 80 GB eine Option; technisch wäre es wohl auch auf einem MacBook möglich, aber man würde es in der Praxis vermutlich nicht nutzen wollen.
    • Vermutlich liegt es am Unterschied zwischen Trainingskosten und Fine-Tuning-Kosten.
      Es könnte auch ein Ausgangspunkt sein, um die Idee zu validieren.

  • Ich arbeite an einem LLM-basierten Decompiler für Python-Bytecode: https://github.com/kukas/deepcompyle
    Es scheint nicht viele Leute zu geben, die in diese Forschungsrichtung arbeiten, aber ich denke, sie könnte ziemlich interessant werden, besonders jetzt, da lange Attention-Kontexte möglich werden.
    Falls jemand ein Team kennt, das sich mit diesem Gebiet beschäftigt, hätte ich Interesse an einer Zusammenarbeit.

    • Ich frage mich, ob der Einsatz von LLMs für Python-Bytecode Vorteile bringt.
      Meiner Erfahrung nach ist Python-Bytecode hoch genug abstrahiert, um direkt in Quellcode umgewandelt werden zu können.
    • Ich frage mich, warum Python.
      Python hat ein großes Ökosystem an Open-Source-Bibliotheken, aber ich sehe es nicht als häufige Sprache für Software, die in Binärform ausgeliefert wird.
    • Es gibt PyLingual, aber leider ist es nicht Open Source.
      Ich bin mir auch nicht sicher, ob es LLM-basiert ist.
    • Bei Decompiler-Arbeiten scheint es viel um C zu gehen.
      Es gibt anscheinend nicht viele Python-Projekte, die zu Binaries kompiliert werden.

  • Ich hatte vor, so etwas auszuprobieren.
    Irgendwann wird jemand eine Pipeline Binäreingabe → guter Quellcode als Ausgabe hinbekommen, aber ich glaube, das dauert noch ein paar Jahre.
    Das sehe ich so, weil am Ende dieses Problems offenbar kein großes Geld wartet, aber ich könnte mich irren.
    Ein guter Zwischenansatz wäre, eine Decompiler-Pipeline zu bauen, die Ghidra im Headless-Modus laufen lässt, und die strikte syntaktische Korrektheit des Decompilers mit den intuitiven Fähigkeiten eines LLM zu kombinieren.
    Wie bei AlphaGeometry sollten Decompiler und LLM die Schwächen des jeweils anderen ausgleichen: https://deepmind.google/discover/blog/alphageometry-an-olymp...
    Außerdem braucht es eine Art Klebstoff wie AICI, um die Erzeugung von C-Quellcode zu koordinieren: https://github.com/microsoft/aici
    Statt die Gewichte des LLM dafür zu nutzen, grammatikalisch korrekten C-Quellcode zu erzeugen, wäre es besser, es über Variablennamen, Snippet-Muster und Architekturentscheidungen nachdenken zu lassen, während Tools wie Ghidra oder LLVM den Rest übernehmen.
    Das ist zwar eher armchair commentary eines ehemaligen Doktoranden mit viel Handwaving, aber es ist großartig, dass sich diese Forscher darauf eingelassen haben, und da die Autoren die Ghidra-Integration als künftige Arbeit erwähnen, scheint die Richtung zu stimmen.

  • Interessant ist, dass das 6-Milliarden-Modell besser abschneidet als das 33-Milliarden-Modell.
    Ich frage mich, ob das bedeutet, dass das 33-Milliarden-Modell mehr Trainingsdaten braucht.
    Wenn man etwa eine Million C-Programme für das Pretraining mit DeepSeek-Coder vergleicht, das auf Billionen von Tokens trainiert wurde, liegen da Größenordnungen bei der Datenmenge dazwischen.
    Mich würde auch interessieren, wie es im Vergleich zu Nicht-LLM-Lösungen aussieht.

    • Dieser Trend hält bei LLMs schon eine Weile an.
      Die meisten LLMs sind stark untertrainiert, und 7-Milliarden-Modelle gehören unter den gängigen Modellen zu den weniger untertrainierten, weshalb sie sich in der LLM-Finetuning-Community weit verbreitet haben.
    • Ein 33-Milliarden-Modell zu trainieren ist nicht einfach.
      Beim naiven Finetuning, also einfachem Finetuning nach Standardschema, ist das Training großer Modelle schwierig, und nicht nur die Datenmenge, sondern auch Datenbereinigung, Lernrate, Decay und alle anderen Faktoren beeinflussen die Endleistung.
    • Ich bezweifle, dass man etwa eine Million C-Programme und 2 Billionen Tokens so direkt vergleichen kann.
      Dafür müsste man annehmen, dass die durchschnittliche Größe dieser C-Programme um mehrere Größenordnungen unter 2 Millionen Tokens liegt; das kann zwar tatsächlich so sein, klingt aber nach einer ziemlich optimistischen Annahme.

  • Ich frage mich, ob das, falls es gelingt, bedeutet, den Maschinencode des Compilers 1:1 zu replizieren.
    Dann würde vollständiger Code als Wahrscheinlichkeitsverteilung im latenten Raum existieren können.
    Oder, wahrscheinlicher, es könnte einfach die Logik replizieren und sie dann in die Zielsprache übersetzen.
    Binaries, für deren Kompilierung nichtdeterministische Eingaben wie Schlüssel oder Hashes nötig sind, dürften daran scheitern.
    Wirklich faszinierend.

  • Es überrascht mich, dass GPT-4 im Vergleich immer noch ziemlich gut abschneidet.
    Es erzeugt zwar viel besser kompilierbaren Code als dieses Modell, aber die Genauigkeit beim Reproduzieren von Code, der sich korrekt verhält, ist geringer.
    Trotzdem ziemlich beeindruckend.

    • GPT-4 ist sehr beeindruckend, obwohl es kein Modell ist, das direkt für Decompilation trainiert wurde.
      Wir verbessern das Modell weiter, also bitte die Updates im Auge behalten.
    • Wenn dieser Ansatz C++ genauso gut könnte wie C, wäre das beeindruckend; hier ist das aber nicht der Fall.