Lesezeit: 7 Min.
KI zerlegt Software in Minuten. Stimmt das Ergebnis?
Eine halbe Stunde. So lange brauchte ein Reverse Engineer im Oktober 2026, um aus dem fertigen Taschenrechner von Linux einen Nachbau zu bekommen. Er gab einer KI nur die ausführbare Datei, nicht den Programmtext. Der Nachbau rechnete richtig, die Oberfläche sah fast gleich aus 1.
Was heißt das für Firmen? KI zerlegt fremde Software schneller als je zuvor. Das hilft bei Altsystemen und Sicherheitsprüfungen, und es macht auch Ihre eigene Software leichter angreifbar. Dieser Text zeigt, was die Werkzeuge heute können, wo sie sich irren und was Sie daraus machen sollten.
Reverse Engineering heißt: ein Programm zurückrechnen
Ein Programm erreicht Sie als Datei voller Nullen und Einsen, dem Maschinencode. Der Text, den der Entwickler geschrieben hat, steckt darin nicht mehr. Reverse Engineering rekonstruiert aus dem Maschinencode, was das Programm tut. Das ist Detektivarbeit: Man stellt eine Frage, schaut nach und leitet daraus die nächste Frage ab. Ein Decompiler, also ein Programm, das Maschinencode in lesbaren Programmtext zurückübersetzt, liefert dafür nur einen Rohentwurf.
Firmen brauchen das aus drei Gründen. Sie müssen Altsysteme verstehen, deren Entwickler nicht mehr da sind. Sie wollen prüfen, ob eine eingekaufte Komponente sicher ist. Und sie müssen Systeme anbinden, deren Schnittstelle niemand dokumentiert hat.
Mit KI schrumpft die Arbeit von Tagen auf Minuten
Die KI-Werkzeuge haben diese Detektivarbeit jetzt eingebaut. Hex-Rays hat am 25.09.2026 einen offiziellen Server für IDA veröffentlicht. Er nutzt das Model Context Protocol (MCP), die Schnittstelle, über die KI-Programme andere Werkzeuge bedienen. Binary Ninja 6.0 bringt einen eigenen mit, für Ghidra gibt es Lösungen aus der Community. Die KI stellt die Fragen, die Analyseprogramme liefern die Antworten.
Das bekannteste Beispiel ist das Projekt REA („Reverse Engineer Anything“) 2. Es verbindet die Analyseprogramme mit einem KI-Agenten und hält ihn in der Schleife: fragen, nachsehen, die nächste Frage stellen. Im Test des Kanals Low Level baute Claude Code damit den Linux-Taschenrechner nach, rund 2.000 Funktionen in etwa 28 Minuten. Von Hand hätte der Autor nach eigener Schätzung einige Tage gebraucht 1.
Der Autor äußert drei Sorgen, und das sind Meinungen, keine Messungen. Wer pflegt Klone, die sich für wenig Geld erzeugen lassen? Wer prüft sie auf Schadcode? Und weichen Hersteller künftig in die Cloud aus, weil man dort nichts zerlegen kann? Zugleich begrüßt er, dass Software nicht mehr nur für Assembler-Kenner verständlich ist.
Lesbarer heißt nicht richtiger: Hier irrt die KI
Ein Tester von REA leitet daraus eine Regel ab: Jeder Befund wird als gesehen, vermutet oder unbekannt markiert, und nur Gesehenes dient als Grundlage 3. Die Regel ist klug, weil eine KI vermutet, ohne es zu sagen.
Zwei Studien vom September 2026 zeigen das in Zahlen. Forscher ließen eine KI die Ausgabe des Decompilers Ghidra überarbeiten. Danach ließ sich der Code häufiger übersetzen, nämlich zu 90 % statt zu 75 %. Er verhielt sich aber nur noch in 62 % der Fälle wie das Original, vorher waren es 74 % 4. Bei bis zu einer von zehn bekannten Sicherheitslücken verschwand sie sogar aus dem Code.
Lesbarer wurde der Code, richtiger nicht.
Die zweite Studie fand: Der Vorteil beim Benennen von Funktionen blieb fast gleich, obwohl man den Datenfluss im Code zerstört hatte. Der Autor deutet das so, dass die Modelle viele Namen schon kennen, statt sie aus dem Code herzuleiten 5. Bei unbekannter Software hilft das wenig. Gegen stark geschützte Programme (Klasse VMProtect) ist die KI zudem weitgehend machtlos.
Verlässlich wird KI, wenn ein Test mitprüft
Die guten Ergebnisse haben eines gemeinsam: Ein Test oder ein Parser begrenzt die KI. FirmAgent kombiniert zum Beispiel KI-Agenten mit Fuzzing, einem automatischen Test mit Zufallseingaben. Beim Aufräumen von JavaScript schlägt die KI nur Namen vor, das Umschreiben übernimmt ein Parser. Lässt man sie ganze Programme umschreiben, bricht die Qualität ein. Die Tabelle zeigt, wie belastbar die Zahlen sind.
| Messung | Ergebnis | Aussagekraft |
|---|---|---|
| FirmAgent (NDSS 2026): 14 Geräte-Firmwares | 182 Schwachstellen, 91 % davon korrekt | Studie der Autoren, nicht unabhängig wiederholt |
| JsDeObsBench (CCS 2025): ganze Programme umschreiben | Verschleierte Schadsoftware läuft nur in rund 15 % der Fälle korrekt | Benchmark, nur für diese Aufgabe |
| DARPA AI Cyber Challenge 2025 6 | 54 von 63 eingebauten Lücken gefunden, 43 behoben, rund 152 US-Dollar je Aufgabe | Neutraler Wettbewerb, aber mit eingebauten Lücken |
| Angaben von Anthropic, Google, OpenAI, XBOW | verschiedene | Herstellerangaben, nicht unabhängig prüfbar |
Cloud oder lokal? Das Pendel schwingt in beide Richtungen
Aus beiden Entwicklungen lässt sich eine These ableiten, und wir kennzeichnen sie als These. Erst hieß es: KI macht Angreifer besser, also wird die Cloud riskanter, und man holt Software wieder ins eigene Haus. Dann kam das KI-Reverse-Engineering: Lokale Programme lassen sich in Minuten zerlegen und nachbauen. Nun könnten Hersteller ihre Logik wieder auf Server verlagern, die niemand öffnen kann.
Belegt ist die erste Stufe. Eine CVE ist die Kennnummer einer bekannten Sicherheitslücke, und davon gibt es immer mehr:
| Quelle | Wert |
|---|---|
| Linux-Kernel, Versionen 6.9 bis 6.19 (Phoronix, nach einer nicht nachprüfbaren Folie von Greg Kroah-Hartman) 7 | rund 500 CVEs pro Release |
| Linux-Kernel ab Version 7.0 7 | über 1.000 CVEs pro Release |
| Linux-Kernel, 19. und 20.07.2026 8 | 432 CVEs in zwei Tagen |
| Microsoft, Juli und August 2026 9 | rund 570 und rund 400 Korrekturen |
| FIRST-Prognose für 2026 10 | rund 66.000 CVEs |
Nicht belegt ist, dass Firmen deshalb zu lokaler Software zurückkehren. Dafür fanden wir keine Messung. Dagegen sprechen drei Punkte:
- Cloud-Anbieter patchen zentral und einmal. Bei lokaler Software muss jeder Kunde selbst Updates einspielen, die Patch-Schuld wächst dort. - Die Flut trifft vor allem offenen Code und Programme, die sich zerlegen lassen. Ein Server ist schwerer einsehbar, aber nicht unangreifbar, denn auch Web-Dienste lassen sich von außen testen. - Frontend und Schnittstellen eines Dienstes bleiben analysierbar, nur die Serverlogik bleibt verborgen.
Unsere Einschätzung: Die Frage „Cloud oder lokal?“ löst das Problem nicht. Wichtiger sind schnelles, automatisches Einspielen von Updates und eine Liste der eingesetzten Komponenten.
Dazu gehört die Annahme, dass alles, was Sie ausliefern, zerlegt wird, und alles, was Sie betreiben, ständig getestet.
Rechtlich ist das Zerlegen fremder Programme eng begrenzt
Hinweis: Das sind Informationen, keine Rechtsberatung.
Drei Dinge sollten Sie wissen. Erstens erlaubt das Urheberrecht das Zerlegen ohne Zustimmung des Herstellers nur für Interoperabilität und zur Fehlerbehebung (§§ 69d, 69e UrhG, EuGH C-13/20 vom 06.10.2021). Reine Sicherheitsforschung zählt nicht dazu. Zweitens ist uns kein Gesetz und kein Urteil bekannt, das den Upload eines Programms zu einem KI-Anbieter regelt. Lokale Modelle umgehen vieles davon. Drittens gelten neue Meldepflichten für Hersteller.
| Regelwerk | Was gilt | Stand |
|---|---|---|
| Urheberrecht, §§ 69d, 69e UrhG | Zerlegen nur für Interoperabilität und Fehlerbehebung. Vertragsklauseln dagegen sind nach § 69g Abs. 2 unwirksam, außer bei der Fehlerbehebung nach § 69d Abs. 1. | in Kraft |
| Cloud-KI | Zu prüfen: Weitergabe an Dritte (§ 69e Abs. 2), Geschäftsgeheimnisse (§ 3 GeschGehG), Datenschutz | kein Gesetz, kein Urteil bekannt |
| Cyber Resilience Act | Hersteller melden Vorfälle: Frühwarnung nach 24 Stunden, Meldung nach 72 Stunden, Abschlussbericht nach 14 Tagen (ausgenutzte Lücken) oder einem Monat (schwere Vorfälle) | Meldepflicht seit 11.09.2026, übrige Pflichten ab 11.12.2027 |
| AI Act | Regeln für Allzweck-KI; Pflichten für Hochrisiko-Systeme laut Verordnung (EU) 2026/1744 später | Allzweck-KI seit 02.08.2025, Hochrisiko ab 02.12.2027 bzw. 02.08.2028 |
| § 202c StGB | Der BMJ-Entwurf vom 04.11.2024 hätte Sicherheitsforschung in §§ 202a, 202b und 303a ausgenommen | verfallen, keine Reform in Kraft |
| Anbieterprogramme | Anthropic: Cyber Verification Program; OpenAI: Trusted Access for Cyber | OpenAI seit 02/2026 |
Drei Schritte für den Einstieg
1. Beginnen Sie mit Aufgaben, bei denen ein Test das Ergebnis prüft, etwa Fuzzing oder erneutes Übersetzen. 2. Behandeln Sie jede KI-Ausgabe als Vorschlag und geben Sie sie erst nach einer Prüfung frei. 3. Protokollieren Sie jeden Schritt, damit Sie Ergebnisse später belegen können.
So arbeiten wir auch bei Zylveo: Sie beschreiben eine Aufgabe, Hermes zerlegt sie in Karten, und Sie sehen den Fortschritt im Projektboard. Und der Taschenrechner vom Anfang? Er rechnet richtig. Ob der Nachbau auch die seltenen Fälle trifft, weiß aber erst, wer ihn testet.
Stand: 19.10.2026. Herstellerzahlen sind nicht unabhängig geprüft; Rechtsfragen vor der Anwendung prüfen lassen. Bilder: KI-generiert (MiniMax image-01).
Literaturverzeichnis
1. Low Level: „I Tested The Viral Reverse Engineering Repo“, YouTube, 16.10.2026. https://www.youtube.com/watch?v=qFEuYUfauNY
2. REA („Reverse Engineer Anything“), GitHub-Repository morluto/rea, Stand 19.10.2026. https://github.com/morluto/rea
3. OpenClaw-Database: Reverse Engineer Anything (REA), five-step method, 15.10.2026. https://openclawdatabase.com/news/videos/2026-10-15-reverse-engineer-anything-rea-five-step-method-seen-inferred-unknown/
4. Decompile-Diverge, September 2026, arXiv:2609.05370.
5. Studie zur Memorization-Untergrenze bei LLM-Decompilierung, September 2026, arXiv:2609.17236.
6. DARPA: AI Cyber Challenge, Ergebnisse des Finales (08.08.2025). https://www.darpa.mil/news/2025/aixcc-results
7. Phoronix: Linux Kernel CVEs nearly 2000 (28.08.2026). https://www.phoronix.com/news/Linux-Kernel-CVEs-Nearly-2000
8. The Register: Linux kernel team publishes 432 CVEs in two days (22.07.2026). https://www.theregister.com/security/2026/07/22/linux-kernel-team-publishes-432-cves-in-two-days/5276497
9. Microsoft Security Response Center, CVRF-Feed Juli und August 2026. https://api.msrc.microsoft.com/cvrf/v3.0/cvrf/2026-Jul
10. FIRST: Vulnerability Forecast Update (15.06.2026). https://www.first.org/blog/20260615-vulnerability-forecast-update