Reverse Engineering mit KI: Was ich 2026 glaube und was nicht

Titelbild: Illustration, KI-generiert (MiniMax image-01).

Ich wollte wissen, ob KI beim Reverse Engineering inzwischen mehr ist als ein Demo-Effekt, und habe mir den Stand vom Oktober 2026 angesehen: Papers, Hersteller-Ankündigungen, ein virales GitHub-Repo und die Rechtslage. Mein Ergebnis in einem Satz: Die Werkzeuge sind deutlich besser geworden, den Zahlen würde ich aber weniger trauen als den Pressemitteilungen.

Was sich wirklich geändert hat

Die Anbindung ist Alltag geworden. Hex-Rays hat am 25.09.2026 einen offiziellen, quelloffenen IDA-MCP-Server veröffentlicht, Binary Ninja 6.0 (03.09.) bringt einen eigenen MCP-Server mit, und für Ghidra gibt es Community-Server wie GhidraMCP 2.0 (10.10.). Ein Agent kann damit selbst durch eine Datenbank navigieren, Funktionen umbenennen und Hypothesen aufschreiben. Laut einem einzelnen Pressebericht (CTech, 18.10.) kauft Hex-Rays außerdem das Startup HexAI; bestätigt ist das offiziell nicht. Ich lese das als Signal, wohin der Markt geht.

Was mich skeptisch macht

Auf dem Papier sieht es gut aus: LLM4Decompile-9B (v2, überarbeitet Ghidra-Ausgabe) erreicht laut README 64,9 % „Re-Executability“; frühe End-to-End-Modelle lagen 2024 bei rund 21 %, gemessen wird dabei allerdings nicht dasselbe. Zwei Studien vom September haben mir die Euphorie genommen:

• Decompile-Diverge (arXiv 2609.05370): KI-Nachbearbeitung von Ghidra-Ausgabe erhöhte die Quote kompilierbaren Codes von 75 auf 90 %. Der Anteil mit korrektem Verhalten sank von 74 auf 62 %. Bei bis zu einem Zehntel verschwand eine bekannte Schwachstelle aus dem Code. Lesbarer, aber öfter falsch.
• Memorization-Floor (arXiv 2609.17236): Der Gewinn bei der Namenswiederherstellung blieb auch dann bestehen, wenn der Datenfluss zerstört war. Der Autor deutet das als Vorwissen des Modells statt Herleitung; verwandte Arbeiten dokumentieren Kontamination bei HumanEval-basierten Benchmarks.

Bei optimiertem Code schrumpft der Nutzen laut einer dort zitierten Arbeit (Originalquelle nicht prüfbar), bei VMProtect-artigen Schutzverfahren ist die Lage weitgehend ungelöst. Meine Konsequenz: KI-Erklärungen behandle ich wie den Kommentar eines flotten Kollegen, der gern zu selbstsicher ist. Prüfen, bevor man darauf baut.

Wo es überzeugt

Überzeugend finde ich die Fälle, in denen etwas Hartes das Modell begrenzt. FirmAgent (NDSS 2026) koppelt Fuzzing und Agenten und fand in 14 Firmware-Images 182 Schwachstellen bei 91 % Präzision. Bei minifiziertem JavaScript funktioniert der Weg über Parser plus Namensvorschläge, während Modelle, die ganze Programme umschreiben, laut JsDeObsBench bei obfuskierter Malware nur in rund 15 % der Fälle lauffähigen Code behalten.

Die DARPA AI Cyber Challenge (08.08.2025) ist der einzige neutral bewertete Datenpunkt, den ich gefunden habe: 54 von 63 eingebauten Lücken gefunden (86 %), 43 gepatcht (68 %), rund 152 USD pro Aufgabe (DARPA). Alles andere, die 500 Funde von Anthropic oder die Zahlen von Google, OpenAI und XBOW, sind Herstellerangaben. Sie können stimmen, ich kann sie aber nicht unabhängig prüfen. Dass Malware zur Laufzeit ein Sprachmodell befragt (laut Google PROMPTSTEAL, APT28 zugeschrieben), nehme ich ernst, weil es dokumentierte Fälle gibt.

Das virale Repo: REA

Im Oktober sorgte REA („Reverse Engineer Anything“, MIT-Lizenz, github.com/morluto/rea) für Aufmerksamkeit. Der Kanal Low Level, hinter dem laut eigener Aussage ein Reverse Engineer und Schwachstellenforscher mit rund zwölf Jahren Erfahrung steht, hat es in „I Tested The Viral Reverse Engineering Repo“ (16.10.2026) getestet.

Technisch ist REA kein neuer Decompiler, sondern ein Harness: Ghidra, IDA oder Hopper liefern Pseudo-Code, REA verbindet sie per MCP mit dem Agenten und hält die Schleife am Laufen, die Reverse Engineering ausmacht. Frage stellen, Decompiler befragen, Evidenz lesen, nächste Frage ableiten. Danach schreibt ein Code-Modell das Programm neu. Die Neuerung ist also weniger ein Algorithmus als ein sauber geführter Arbeitsablauf.

Sein Test: Aus dem GNOME-Rechner (rund 2.000 Funktionen) baute Claude Code mit REA in etwa 28 Minuten einen Nachbau in Python. Rechnen klappte identisch, die Oberfläche war nah dran, mit Skalierungsfehlern. Von Hand wären es für ihn ein paar Tage gewesen. Dabei ist das Original Open Source, der Test zeigt also die Technik, nicht den Nachbau proprietärer Software.

Interessant finde ich seine Sorgen, auch wenn sie Meinung sind und keine Messung:

• Wer pflegt die Klone? Wenn Software für wenig Tokenkosten nachgebaut werden kann, bleibt offen, wer Fehler behebt und dafür bezahlt wird.
• Lieferkette: Ein zahlender Hersteller verliert Kunden, wenn er Schadsoftware ausliefert. Ein anonymer Klon hat dieses Gegengewicht nicht.
• Reaktion der Hersteller: Mehr Cloud- und Webdienste, die man nicht lokal zerlegen kann.

Zugleich begrüßt er, dass Reverse Engineering nicht mehr den wenigen vorbehalten ist, die Assembler lesen. Diese Ambivalenz teile ich.

Als Methode hat ein anderer Tester (OpenClaw-Database) fünf Schritte abgeleitet: ein Verhalten wählen, das Zielsystem benennen, die Rohanalyse verdichten, jeden Befund als gesehen, vermutet oder unbekannt markieren und nachbauen und testen. Der vierte Punkt ist genau die Disziplin, die ich nach den Studien oben für nötig halte.

Die Erfolgsmeldungen sind Selbstberichte. Die GitHub-Seite zeigte am 19.10.2026 rund 330.000 Sterne und 83.600 Forks; das sagt etwas über Aufmerksamkeit, nichts über Qualität. Laut README ist REA für Forschung, Lehre, Interoperabilität, Software-Erhalt und die Analyse eigener oder freigegebener Software gedacht; kommerzielle Werkzeuge brauchen eigene Lizenzen, und geknackte Kopien oder Lizenzumgehung sind ausdrücklich nicht gedeckt.

Meine These: Das Pendel zwischen SaaS und lokaler Software

Beim Zusammenlegen der beiden Themen fällt mir ein Muster auf:

1. Zuerst hieß es: KI macht Angreifer besser, also wird SaaS riskanter. Siehe die Flut an Linux-Patches. Also zurück zu eigenständigen, lokalen Apps.
2. Dann kam Reverse Engineering. Lokale Programme lassen sich mit KI in Minuten zerlegen und nachbauen. Genau deshalb fürchtet Low Level, dass Hersteller ihre Logik wieder auf Server verlagern, die niemand zerlegen kann.

Das Pendel schwingt hin und her, ohne dass eine Seite sicherer wird. Die Denkfigur finde ich brauchbar, ich muss sie aber sauber von den Belegen trennen.

Belegt (Stufe 1): Die Patch-Flut ist real. Laut Phoronix (28.08.2026), das sich auf eine Folie von Greg Kroah-Hartman beruft, lag der Linux-Kernel von 6.9 bis 6.19 bei rund 500 CVEs pro Release, ab 7.0 bei über 1.000 und bei 7.2 über 1.500 (Phoronix; die Folie selbst ist ein Bild ohne Text und war nicht nachprüfbar). Am 19./20.07.2026 meldete das Kernel-Team binnen zwei Tagen 432 CVEs (The Register). Torvalds nannte die private Sicherheitsliste „almost entirely unmanageable“ (Mai 2026). Microsoft veröffentlichte im Juli rund 570 und im August rund 400 CVE-Fixes (laut MSRC-Datenfeed), und FIRST prognostiziert für 2026 rund 66.000 CVEs. Als Ursache gilt vor allem das Durchleuchten des Quellcodes mit KI-Werkzeugen; viele Kernel-Funde sind nachrangig oder fragwürdig.

Belegt (Stufe 2): KI-gestütztes Reverse Engineering ist massentauglich geworden (siehe REA).

Nicht belegt: Dass Unternehmen wegen der Patch-Flut tatsächlich zu lokaler Software zurückkehren. Dazu habe ich keine Messung gefunden. Es ist eine plausible Hypothese, kein Befund.

Gegenargumente:

• Die Patch-Flut trifft lokale Software härter. Ein SaaS-Anbieter patcht zentral, einmal. Bei lokal betriebener Software muss jeder Kunde selbst einspielen; die Patch-Schuld wächst dort.
• Offener Code ist leichter zu durchsuchen. Die Flut trifft vor allem Quelloffenes (Kernel) und dekompilierbare Binaries. Ein Server-Backend ist schwerer einsehbar, aber nicht unangreifbar: Black-Box-Tests im Web funktionieren ebenfalls (XBOW stand laut eigenem Blog im Juni 2025 auf Platz 1 der US-Rangliste bei HackerOne).
• SaaS ist nicht dicht. Frontend, Apps und API-Schnittstellen lassen sich analysieren; nur die Serverlogik bleibt verborgen.

Ich würde die Architekturfrage deshalb nicht daran festmachen. Wichtiger finde ich schnelles, automatisiertes Patchen, ein Inventar dessen, was man einsetzt, und die Annahme, dass alles, was man ausliefert, analysiert wird, und alles, was man betreibt, ständig getestet.

Die Rechtsfrage, die kaum jemand stellt

Ich bin kein Anwalt; das hier sind Informationen, keine Rechtsberatung.

Dekompilieren ist in Deutschland nach §§ 69d, 69e UrhG eng begrenzt: Interoperabilität sowie Fehlerbehebung (EuGH C-13/20, 06.10.2021, nur soweit nötig und im Rahmen der Lizenzbedingungen). Reine Sicherheitsforschung ist kein Interoperabilitätszweck. Ob man ein fremdes Binary an einen Cloud-Anbieter schicken darf, regelt nach meinem Kenntnisstand weder ein Gesetz noch ein Urteil. Zu prüfen wären die Weitergabe an Dritte (§ 69e Abs. 2), der Geschäftsgeheimnisschutz (§ 3 GeschGehG) und die DSGVO. Für sensible Binaries heißt das für mich: lieber lokale Modelle.

Neu ist, dass der Cyber Resilience Act seit 11.09.2026 Meldepflichten für Hersteller enthält (Frühwarnung nach 24 Stunden, Meldung nach 72 Stunden, Abschlussbericht je nach Fall nach 14 Tagen oder einem Monat). Und eine Entschärfung der Strafbarkeit von Sicherheitsforschung ist nicht in Kraft: Der BMJ-Entwurf vom 04.11.2024 hätte §§ 202a, 202b und 303a betroffen (nicht § 202c selbst) und ist mit der Wahlperiode verfallen.

Mein Fazit

1. KI-Reverse-Engineering ist ein guter Beschleuniger, aber kein Orakel.
2. Ich vertraue Ergebnissen, die ein Test, ein Fuzzer oder ein Neukompilieren bestätigt, und sonst niemandem, auch dem Modell nicht.
3. Herstellerzahlen lese ich als Marketing, bis jemand Unabhängiges nachgemessen hat.
4. Die Rechtslage hinkt hinterher. Wer beruflich damit arbeitet, sollte sie klären, bevor ein Binary hochgeladen wird.

Ich beobachte weiter, vor allem ob die Benchmark-Kritik zu besseren Messungen führt.

Stand: 19.10.2026. Quellen: Hex-Rays, Binary Ninja, arXiv, DARPA, NDSS, MSRC, FIRST, EuGH. Keine Rechtsberatung.