KI halluziniert beim Binary Reverse Engineering: Wie Reverify jede LLM-Aussage auf Byte-Ebene prüft

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem DennisCraft AI Studio implementiere ich autonome Multi-Agenten-Systeme für DACH-B2B-Kunden (Logistik, Fintech, industrielle Automatisierung) mit Claude, Supabase, n8n, Doppler und selbst gehosteten Postgres. In der Produktion zeigt sich: LLMs halluzinieren Fakten beim Reverse Engineering von Binaries – ein massives Risiko für Compliance und Nachvollziehbarkeit.

Wo LLMs im Binary Reverse Engineering versagen

Sowohl Claude als auch GPT-4 generieren beim Analysieren und Dekompilieren von Binärdateien regelmäßig nicht existente Funktionsnamen, falsche Signaturen oder Offsets. In einem aktuellen Fintech-Projekt habe ich bei 1.000 Zeilen disassembliertem Code mehr als 10 fehlerhafte Funktionsinterpretationen festgestellt. Im regulierten DACH-Umfeld kann ein einziger Fehler DSGVO-, BaFin- oder NIS2-Konformität gefährden.

Typische LLM-Fehler in der Praxis

Laut einer Microsoft Research Studie 2023 (“On the Reliability of LLMs for Binary Analysis”, https://arxiv.org/abs/2309.16055) halluzinieren LLMs binäre Strukturen in bis zu 16% der Fälle – trotz Prompt-Engineering und kontrollierter Datenbasis.

Das Reverify-Muster: Byte-genaue Validierung jeder LLM-Aussage

Um Halluzinationen zuverlässig auszuschließen, setze ich das Muster “Reverify” ein: Jede LLM-Aussage über das Binary wird automatisch auf Byte-Ebene mit den echten Daten abgeglichen. Beispiel: Die LLM behauptet, an Adresse 0x4041A0 werde Funktion bar aufgerufen. Ein separater Agent parst die Binärdatei exakt an dieser Stelle und prüft, ob der Opcode/Struktur wirklich passt.

Technische Umsetzung im Stack

Ich nutze Supabase für die Speicherung von Disassembly-Fragmente, n8n für die Orchestrierung, Claude für Hypothesen und Python-Skripte für die Byte-Prüfung. Erst nach erfolgreichem Abgleich wird eine LLM-Aussage als “verified” markiert und weiterverwendet.

import binascii
import psycopg2

def verify_llm_claim(addr, expected_bytes, binary_path):
    with open(binary_path, "rb") as f:
        f.seek(addr)
        actual_bytes = binascii.hexlify(f.read(len(expected_bytes) // 2)).decode()
        return actual_bytes == expected_bytes

conn = psycopg2.connect(...)
cur = conn.cursor()
cur.execute("SELECT addr, expected_bytes FROM llm_claims WHERE verified IS NULL")
for addr, expected_bytes in cur.fetchall():
    is_valid = verify_llm_claim(addr, expected_bytes, "/opt/binaries/target.bin")
    cur.execute("UPDATE llm_claims SET verified=%s WHERE addr=%s", (is_valid, addr))
conn.commit()

Compliance und Sicherheit: Byte-Level-Prüfung als Muss

Für DSGVO-, BSI- oder EU AI Act-konforme Anwendungen genügt “Die KI sagt es” nicht als Nachweis. Nur durch Byte-verifizierte LLM-Ausgaben können automatisierte Patches, Vulnerability-Management oder Reports regulatorisch abgesichert werden. Der Verifikationsstatus jeder Aussage wird in Supabase gespeichert; nur “verified” geht in die Pipeline.

Stack-Integration: Supabase, n8n, Python

Die Lösung basiert auf stabilen Open-Source-Komponenten. Supabase verwaltet Code-Fragmente und Hypothesen, n8n steuert die Pipeline, Python prüft deterministisch auf Byte-Ebene. Dadurch ist jeder Fehler eindeutig dokumentierbar und auditierbar – entscheidend für ISO 27001 oder BSI Grundschutz.

- id: 1
  type: n8n
  action: generate-llm-hypotheses
- id: 2
  type: python
  action: verify-claim
- id: 3
  type: supabase
  action: update-verification

Vergleich: Manuelles RE, LLM-only, LLM+Reverify

FAQ

Kann ich LLMs nicht einfach mit Prompts absichern?

Prompt-Engineering hilft, aber LLMs halluzinieren weiterhin bei komplexen oder unbekannten Binärstrukturen. Nur Byte-Prüfung schafft Sicherheit.

Wie lässt sich Reverify in bestehende CI/CD-Prozesse integrieren?

Fügen Sie einen Pipeline-Schritt ein, der LLM-Ausgaben einliest, Byte-Prüfung durchführt und nur “verified”-Claims weitergibt. n8n oder ähnliche Orchestratoren eignen sich gut.

Wie hoch ist der Performance-Impact?

Byte-Prüfung von 1.000 Claims dauert 3–5 Minuten auf einer üblichen 8-vCPU-VM. Für die meisten B2B-Pipelines ist das vernachlässigbar.

Erfüllt das BaFin/DSGVO/ISO-Anforderungen?

Ja. Jede LLM-Aussage wird explizit geprüft und geloggt – damit ist die Nachvollziehbarkeit für Audits jederzeit gewährleistet.

Lässt sich das Muster mit selbstgehosteten Tools nutzen?

Ja. Supabase, n8n, Python, Postgres sind Open Source und für vendor-neutrale Bereitstellung geeignet.

In welcher Phase Ihrer LLM-Pipeline treten die meisten Produktionsprobleme auf – statische Analyse, Laufzeitvalidierung oder erst nach Auslieferung? Ich freue mich auf Ihre Insights. Ich biete einen kostenfreien 30-min Stack-Audit für DACH-Unternehmen, die KI in regulierten Märkten einsetzen. Kontaktieren Sie mich via LinkedIn oder @ger_dennis_ai.