LLM4Decompile – Binärcode-Dekompilierung mit LLMs

• Reverse Engineering mit großen Sprachmodellen

1. Einführung in LLM4Decompile und Decompile-Eval

• Unser Ziel ist es, das erste Open-Source-LLM speziell für die Dekompilierung zu erstellen und zu veröffentlichen sowie den ersten Dekompilierungs-Benchmark mit Fokus auf Re-Kompilierbarkeit und Wieder-Ausführbarkeit aufzubauen, um seine Fähigkeiten zu bewerten.
• Eine Million C-Code-Samples aus AnghaBench wurden mit GCC in Assemblercode kompiliert, wodurch ein Datensatz aus 4 Milliarden Token mit Assembler-Quellcode-Paaren aufgebaut wurde.
• Mit diesem Datensatz wurde das führende Code-LLM DeepSeek-Coder feinabgestimmt, und auf Basis von HumanEval-Fragen und Test-Samples wurde der Bewertungs-Benchmark Decompile-Eval erstellt.
• Die Bewertung erfolgt aus zwei Perspektiven: ob sich der dekompilierte Code erfolgreich erneut kompilieren lässt und ob er alle Assertions der Testfälle besteht.

2. Bewertungsergebnisse

Metriken

• Re-Kompilierbarkeit und Wieder-Ausführbarkeit sind wichtige Kennzahlen zur Überprüfung der Wirksamkeit des Dekompilierungsprozesses.
• Wenn sich dekompilierter Code erneut kompilieren lässt, ist das ein starker Hinweis auf syntaktische Integrität.
• Da Syntax allein nicht garantiert, dass ein Programm semantisch mit dem Original identisch ist, ist die Wieder-Ausführbarkeit ein wichtiger Maßstab zur Bewertung der semantischen Korrektheit.
• Re-Kompilierbarkeit und Wieder-Ausführbarkeit stehen für Syntax-Rekonstruktion und Bedeutungswahrung, was für nutzbare und robuste Dekompilierung essenziell ist.

3. Verwendung des Modells

• LLM4Decompile umfasst Modelle mit 1,3 bis 33 Milliarden Parametern, die auf Hugging Face verfügbar sind.
• Modellbeispiele: llm4decompile-1.3b, llm4decompile-6.7b, llm4decompile-33b, llm4decompile-6.7b-nsp, llm4decompile-6.7b-uo
• Das NSP-Modell wurde mit Assemblercode trainiert; die durchschnittliche Wieder-Ausführbarkeit liegt bei etwa 0,17.
• Das UO-Modell wurde ohne Vorwissen über das Optimierungsniveau (O0~O3) trainiert; die durchschnittliche Wieder-Ausführbarkeit liegt bei etwa 0,21.
• Beispiel für die Modellnutzung: C-Code in Binärdateien kompilieren, die Binärdateien in Assembler-Instruktionen disassemblieren und mit LLM4Decompile die Assembler-Instruktionen nach C übersetzen.

4. Verwendung von Decompile-Eval

• Die Daten sind im JSON-Listenformat unter llm4decompile/decompile-eval/decompile-eval.json gespeichert.
• Es werden Methoden angeboten, um die Bewertung auf einer einzelnen GPU mit einem einzelnen Prozess auszuführen, sowie mit TGI (10-fach schneller, mit Unterstützung für mehrere GPUs und Multiprozesse).

5. In Arbeit

• LLM4Binary: Geplant ist ein größerer Datensatz, um das Modell mit Assemblercode und C-Code vorzutrainieren.
• Decompiler-ALL: Geplant ist Unterstützung für mehr Sprachen/Plattformen und Konfigurationen (z. B. die Dekompilierung mehrerer Funktionen).

6. Lizenz

• MIT-Lizenz

Meinung von GN⁺

• LLM4Decompile stellt im Vergleich zu bestehenden Ansätzen zur Binär-Dekompilierung einen innovativen Ansatz vor und ermöglicht insbesondere durch den Einsatz großer Sprachmodelle eine präzisere und effizientere Dekompilierung.
• Diese Technik kann im Bereich der Software-Sicherheit sehr nützlich sein und bei der Analyse von Malware oder der Wartung von Legacy-Systemen helfen.
• Dass die Wieder-Ausführbarkeit des dekompilierten Codes nicht perfekt ist, deutet darauf hin, dass diese Technik noch Verbesserungspotenzial hat. Zusätzliche Forschung ist nötig, um Genauigkeit und Effizienz in realen Umgebungen zu steigern.
• Zu den bestehenden Tools mit ähnlichen Funktionen gehören kommerzielle und Open-Source-Dekompilierer wie Ghidra oder IDA Pro, LLM4Decompile bietet jedoch einen neuen, auf Machine Learning basierenden Ansatz.
• Bei der Einführung dieser Technik sollten die Qualität und Reichweite der Trainingsdaten, die Genauigkeit des Modells und die Ausführungsgeschwindigkeit berücksichtigt werden. Vorteile sind hohe Genauigkeit und Flexibilität, während die Komplexität großer Modelle und der Bedarf an Rechenressourcen Nachteile sein können.

[GN⁺]

Hacker-News-Kommentare

• Meinung zu den Ergebnissen der „Wiederausführbarkeit“:

  • Wiederausführbarkeit ist eine wichtige Methode zur Messung der semantischen Korrektheit. Dabei wird das dekompilierte Ergebnis erneut kompiliert und mit Testfällen ausgeführt, um zu bewerten, ob Programmlogik und Verhalten erhalten geblieben sind. Rekompilierbarkeit und Wiederausführbarkeit stehen für die Wiederherstellung der Syntax und den Erhalt der Semantik, was für nutzbare und robuste Dekompilierung essenziell ist.

• Frage zur Zuverlässigkeit des dekompilierten Ergebnisses:

  • Es ist eine ernsthafte Frage, ob dem dekompilierten Ergebnis vertraut werden kann. Durch die Rekompilierung kann anderer Maschinencode entstehen, und insbesondere neue Konstrukte zu identifizieren, die zu den entscheidenden Teilen des Codes gehören könnten, kann schwierig sein. Es stellt sich die Frage, ob es bei generativer Ausführung eine Möglichkeit gibt, dass das LLM für bestimmte Abschnitte einen Konfidenzwert meldet. Eine menschliche Überprüfung scheint notwendig zu sein.

• Hervorragender Anwendungsfall für LLM-Finetuning:

  • Das ist ein hervorragender Anwendungsfall für LLM-Finetuning, da sich aus offen verfügbarem C-Code leicht große Datensätze aus Ein-/Ausgabe-Paaren erzeugen lassen.

• Interesse am Training eines entwicklerbasierten Dekompilierungsmoduls:

  • Es ist interessant, ob sich ein Dekompilierungsmodul auf Basis von Anwendungen trainieren lässt, an denen ein bestimmter Entwickler gearbeitet hat. Zum Beispiel wurden Super Mario 64 und Zelda 64 vollständig dekompiliert, und bei anderen N64-Spielen laufen entsprechende Arbeiten noch. Es stellt sich die Frage, ob sich andere Spiele dieser Entwickler dadurch leichter dekompilieren lassen.

• Interesse an idealen Anwendungsfällen für Dekompilierer und an der Datensatzerstellung:

  • Ein idealer Dekompilierer würde proprietären Quellcode eliminieren. Wegen des Reichtums an öffentlich verfügbarem C-Code lässt sich leicht ein Datensatz aus Paaren von ASM und Quellcode erstellen.

• Vorstellung eines persönlichen laufenden Projekts für einen LLM-basierten Dekompilierer:

  • Jemand entwickelt derzeit einen LLM-basierten Dekompilierer für Python-Bytecode. Nicht viele Menschen arbeiten an dieser Forschungsrichtung, aber mit langen Kontextfenstern könnte sie interessant werden. Falls jemand ein Team kennt, das dafür offen ist, besteht Interesse an einer Zusammenarbeit.

• Bedenken hinsichtlich AI-basierter Ansätze und Benchmarks ohne Vergleich:

  • Es ist spannend, verschiedene Ansätze zu sehen, aber ohne einen Vergleich mit nicht-AI-basierten Ansätzen wie IDA Pro könnten die Benchmarks bedeutungslos sein. Es wäre interessant zu sehen, wie dieses Modell bei Metriken aus Security-Papers abschneidet.

• Interesse an der großen Differenz zwischen Rekompilierbarkeits- und Wiederausführbarkeitswerten:

  • GPT4 erreichte bei der Rekompilierbarkeit (syntaktisch korrekt) Werte im Bereich von 8x %, erzielte bei der Wiederausführbarkeit (konzeptionell korrekt) jedoch miserable 1x %, was erneut seine übermäßige Imitationsfähigkeit zeigt.

• Neugier auf den Vergleich mit anderen, nicht auf LLMs basierenden Dekompilierern:

  • Es stellt sich die Frage, wie der Vergleich mit nicht-LLM-Dekompilierern wie IDA oder Binja ausfällt. Zu sehen sind nur Vergleiche mit anderen LLMs.

• Neugier darüber, dass das 6b-Modell besser abschnitt als das 33b-Modell:

  • Es ist interessant, dass das 6b-Modell besser abschnitt als das 33b-Modell. Es stellt sich die Frage, ob das 33b-Modell mehr Trainingsdaten benötigt. Das 33b-Modell wurde zwar auf etwa 1 Million C-Programmen vortrainiert, DeepSeek-Coder jedoch auf 2 Billionen Tokens, also mit mehreren Größenordnungen mehr Daten.