Wenn KI jede App reverse-engineeren kann: Was bedeutet das für die Anwendungssicherheit?

Ein am 12. Oktober 2026 veröffentlichtes Fireship-Video fragt, ob jede Anwendung gerade „Open Source“ wird, ob ihre Urheber das wollen oder nicht.

Das Video beleuchtet KI-gestützte Softwareanalysen, darunter Reverse Engineer Anything (REA). REA verbindet Coding-Agenten über MCP mit Reverse-Engineering-Tools.

Die Idee ist spannend: Ein Agent kann helfen, eine kompilierte Anwendung zu untersuchen, Analyseergebnisse zu durchsuchen und Teile ihres Verhaltens zu erklären, ohne den Originalquellcode zu besitzen.

Das kann manche Untersuchungen beschleunigen. Proprietäre Software wird dadurch weder Open Source noch lässt sich damit garantiert der exakte Quellcode rekonstruieren oder eine Sicherheitslücke beweisen.

Jede Schlussfolgerung bleibt eine Hypothese, bis unabhängige Belege sie stützen. Für Application Security (AppSec) lautet die entscheidende Frage daher nicht, ob KI „jede App versteht“.

Entscheidend ist, wie sie Transparenz verbessert und zugleich Artefakte, Werkzeuge und Schlussfolgerungen in einem nachvollziehbaren Sicherheitsprozess hält.

Was Reverse Engineer Anything macht

REA verbindet KI-Coding-Agenten mit Reverse-Engineering-Funktionen.

Je nach Artefakt und Einrichtung lassen sich native Binärdateien, JavaScript- und Electron-Anwendungen, .NET-Assemblies, Android-Pakete, Firmware und weitere Formate untersuchen.

Für native Binäranalysen kommen etablierte Werkzeuge wie Ghidra, IDA oder Hopper infrage. Sie existierten schon vor heutigen KI-Agenten.

Sie disassemblieren Maschinencode, erstellen ungefähren Pseudocode, zeigen Verweise zwischen Funktionen und machen ausführbare Strukturen für die Untersuchung sichtbar.

REA nur für rechtmäßige und autorisierte Analysen verwenden. Laut Repository läuft die Werkzeuganalyse lokal. Analyseergebnisse werden jedoch an den konfigurierten Modellanbieter gesendet; dessen Datenschutzrichtlinien gelten.

REA erteilt keine Lizenzen für IDA oder Hopper, für die separate Lizenzen erforderlich sind. Die Agentenebene kann Fragen formulieren, relevante Ausgaben abrufen, Verweisen folgen und einen möglichen Implementierungspfad zusammenfassen.

Bei einem unbekannten Desktopprogramm kann ein Analyst so eingrenzen, wo eine Funktion verarbeitet wird, anschließend die betreffenden Funktionen prüfen und die Interpretation testen.

Der Agent unterstützt die Untersuchung; er rekonstruiert nicht automatisch das ganze Programm und bestätigt dessen Verhalten nicht.

Compiler verändern Informationen, Symbole können fehlen und dekompilierter Pseudocode kann unvollständig oder irreführend sein. Eine rekonstruierte Funktion ähnelt möglicherweise nur dem Originalverhalten.

Warum das für AppSec wichtig ist

Mehr Einblick ohne Quellcodezugriff

Unternehmen nutzen Anwendungen von Drittanbietern, native Bibliotheken, mobile Clients, Firmware und kommerzielle Produkte, deren Quellcode sie nicht einsehen können.

Binäranalyse kann zusätzliche Transparenz schaffen, wenn quellcodebasierte Methoden nicht möglich sind. Sie kann etwa einen verdächtigen Eingabepfad, fest codierte Daten oder unerwartete Funktionen für die weitere Prüfung sichtbar machen.

Eine verdächtige Funktion beweist noch keine Ausnutzbarkeit. Es muss geklärt werden, ob eine Eingabe sie erreichen kann, bei welcher Konfiguration und mit welcher Auswirkung.

Eine SBOM hilft, Komponenten zu identifizieren. Weder eine SBOM noch eine Binäranalyse allein beweist jedoch, dass eine Komponente sicher oder verwundbar ist.

Schnellere Hypothesenbildung

Reverse Engineering setzt Wissen über ausführbare Formate, Assembler, Speicherlayouts, Aufrufkonventionen und Compiler voraus.

KI kann Teile dieser Arbeit erleichtern: einen möglichen Eingabepfad über Funktionen verfolgen, eine riskante Operation finden oder zusammenhängende Ausgaben zusammentragen.

Das kann menschliche Prüfer auf Speicheroperationen, Kryptografie, native Parser und Vertrauensgrenzen lenken, an denen nicht vertrauenswürdige Daten privilegierte Funktionen beeinflussen. Werkzeugausgaben bleiben Hinweise.

Statische Analysen zeigen möglicherweise nicht den Laufzeitkontext, und Modellerklärungen können falsch sein.

Ein möglicher Ansatzpunkt für autorisierte Tests

Binäranalyse kann einen Penetrationstest unterstützen, wenn Eigentümer Ziel und Methoden ausdrücklich autorisiert haben.

Ein Analyst kann einen verdächtigen Pfad untersuchen und einen kontrollierten Test entwerfen, um Erreichbarkeit und Ausnutzbarkeit unter den vereinbarten Bedingungen zu prüfen.

REA ist für sich genommen keine vollständige autonome Pentest-Plattform. Reverse-Engineering-Funktionen garantieren weder das Auffinden noch das Ausnutzen oder Beheben einer Schwachstelle.

Tests müssen im schriftlich festgelegten Umfang bleiben; Sicherheitsbehauptungen brauchen reproduzierbare Belege.

Welche Sicherheitsannahme Reverse Engineering infrage stellt

Kompilierter Code ist schwerer zu lesen als Quellcode. Geheimhaltung der Implementierung ist aber keine Sicherheitsgrenze.

Prüft ein Desktop-Client Berechtigungen nur lokal und akzeptiert das Backend die Anfrage ohne eigene Prüfung, kann jemand den Client ändern oder den Dienst direkt aufrufen.

Das Grundproblem ist falsch gesetztes Vertrauen in clientgesteuertes Verhalten, nicht die Existenz eines Dekompilierers. Sicherheitskritische Autorisierung gehört an eine vertrauenswürdige Servicegrenze.

Das entspricht dem OWASP ASVS v5.0, V8 Authorization. Obfuskation, Anti-Debugging und Anti-Tampering können den Aufwand für Analyse oder Manipulation erhöhen.

Bei manchen mobilen Apps, Spielen und Client-Umgebungen sind sie als zusätzliche Schutzschicht sinnvoll.

Der OWASP MASVS-RESILIENCE behandelt solche Resilienzmaßnahmen als Ergänzung: Sie ersetzen keine sichere Authentifizierung, Autorisierung oder Kryptografie.

Auch Reverse-Engineering-Agenten können angegriffen werden

Ein KI-Agent kann eine Binärdatei mit angreiferkontrollierten Zeichenfolgen, Metadaten oder sonstigen Inhalten analysieren.

Gibt ein Werkzeug diese Inhalte aus und deutet der Agent sie als Anweisungen, kann das Artefakt durch indirekte Prompt-Injection eine Vertrauensgrenze überschreiten. Ein vereinfachter Ablauf:

1. Ein Agent erhält eine unbekannte Binärdatei zur Analyse.
2. Ein Reverse-Engineering-Tool extrahiert Zeichenfolgen, Metadaten oder Pseudocode.
3. Ein Teil der Inhalte ist darauf ausgelegt, ein KI-System zu beeinflussen.
4. Der Agent hält die Inhalte irrtümlich für vertrauenswürdige Anweisungen oder verlässliche Schlussfolgerungen.
5. Er könnte eine nicht autorisierte Aktion vorschlagen oder eine falsche Behauptung in den Bericht übernehmen.

Ein verwandtes Risiko ist falsche Bestätigung: Mehrere Werkzeugausgaben können denselben aus dem Artefakt stammenden Text wiederholen. Dadurch werden sie nicht zu unabhängigen Belegen.

Das arXiv-Preprint vom Juli 2026 „When Binaries Talk Back: Representation-Confusion Attacks on LLM-Assisted Reverse Engineering“ untersucht diese Risiken unter kontrollierten Bedingungen.

Das Experiment verwendete kontrollierte, synthetische Linux-ELF/x86-64-C-Programme und zwei Modelle.

Vor den vorgeschlagenen Laufzeitkontrollen meldet es, dass die Modelle in 35 von 40 adversarialen Testfällen eine von Angreifern präparierte unsichere Aktion vorschlugen.

REA selbst wurde nicht evaluiert, und diese Prozentwerte messen keine Häufigkeit realer Fehler. Das Ergebnis gilt für die konkreten Modelle, Aufgaben und Versuchsbedingungen der Autoren.

Die allgemeine Lehre: Das analysierte Artefakt bleibt nicht vertrauenswürdige Daten und darf keine Autorität über den Agenten erhalten. Ein sicherer Analyseprozess sollte:

• extrahierte Zeichenfolgen, Metadaten, Pseudocode und Dokumente als nicht vertrauenswürdige Eingaben behandeln;
• Werkzeugrechte begrenzen und für sensible oder außerhalb des Umfangs liegende Aktionen eine Freigabe verlangen;
• die Herkunft jeder Behauptung bis zum Artefakt und zur Werkzeugausgabe dokumentieren;
• wichtige Befunde mit unabhängigen, autorisierten Tests validieren; und
• unbekannte Binärdateien und generierten Analysecode von Zugangsdaten und Produktionssystemen isolieren.

Für die Absicherung von Agenten fällt dieses Risiko unter OWASP LLM01

Die Begrenzung von Agentenrechten entspricht OWASP LLM06

Ein evidenzbasierter Ablauf für KI-gestützte Binäranalyse

Ein zuverlässiger Prozess führt von der Beobachtung zur Validierung. Die folgenden sieben Phasen sind eine praktische Referenzarchitektur, keine Behauptung, dass REA oder Plexicus jede Phase umsetzt.

1. Autorisierungsumfang festlegen. Artefakte, Umgebungen, erlaubte Methoden und freigabepflichtige Aktionen dokumentieren.
2. Artefakt sichern. Hashes, Versionen, Architektur, Herkunft und verfügbare Komponenteninformationen erfassen, damit Ergebnisse dem konkreten Build zugeordnet werden können.
3. Mit geeigneten Werkzeugen analysieren. Importe, Symbole, Codepfade, Disassemblierung und Pseudocode untersuchen; Versionen und Grenzen der Werkzeuge festhalten.
4. Hypothesen bilden. KI nach verdächtigem Verhalten suchen lassen, aber jede Beobachtung als möglichen Befund markieren.
5. Isoliert validieren. Kontrollierte Tests innerhalb des Umfangs ausführen, um Erreichbarkeit und tatsächliches Vorliegen der Schwachstelle zu prüfen.
6. Belege und Auswirkungen dokumentieren. Testergebnisse, relevante Fundstellen, Umgebungsannahmen und beobachtete Folgen festhalten; Belege von Modellinterpretationen trennen.
7. Behebung überprüfen. Den ursprünglichen Zustand erneut testen und nach der Korrektur auf Regressionen prüfen.

Das Ergebnis sollte ein überprüfbarer Sicherheitsbefund sein, nicht nur eine überzeugende Erklärung.

Binäranalyse ergänzt andere AppSec-Methoden

Binäranalyse soll SAST oder DAST nicht ersetzen. Geeignete Belege verschiedener Methoden lassen sich kombinieren, um Anwendungsrisiken besser einzuschätzen.

So können sich Entwickler vorbereiten

• Autorisierung in vertrauenswürdigen Systemen erzwingen. Sensible Funktionen nicht allein durch Client-Prüfungen schützen.
• Geheimnisse in verteilten Anwendungen minimieren. Keine privilegierten, langlebigen Server-Zugangsdaten in herunterladbare Anwendungen einbetten.
• Native Komponenten absichern. Wo möglich speichersichere Entwürfe, Compiler-Härtung, Eingabevalidierung und passende Tests einsetzen.
• Verteilte Artefakte inventarisieren. Binärdateien, Firmware und Drittanbieterkomponenten in Risiko- und Reaktionsprozesse aufnehmen.
• Obfuskation als Zusatzschutz nutzen. Sie am Bedrohungsmodell ausrichten und nicht mit sicherer Architektur verwechseln.
• Analyse-Agenten schützen. Nicht vertrauenswürdige Artefakte dürfen keine Anweisungen überschreiben; Datei-, Netzwerk-, Zugangsdaten- und Ausführungsrechte unabhängig vom Modell beschränken.
• Reproduzierbare Belege verlangen. Eine selbstbewusste Erklärung ist keine bestätigte Schwachstelle.

Diese Maßnahmen entsprechen OWASP MASVS-RESILIENCE. Sie entsprechen auch OWASP ASVS v5.0, V8 Authorization.

Die finale veröffentlichte SSDF-Version ist NIST v1.1.

NIST SP 800-218 v1.2 (Rev. 1) war ein erster öffentlicher Entwurf vom Dezember 2025, keine finale Version: NIST SP 800-218 Rev. 1 IPD.

Wird KI jede Anwendung reverse-engineeren?

„Jede“ blendet große technische Unterschiede aus. Eine einfache Funktion, ein stark obfuskiertes natives Programm, ein verteilter Dienst und hardwareabhängige Firmware sind unterschiedlich schwer zu analysieren.

Ein Agent kann einen einzelnen Pfad rekonstruieren, ohne die ganze Anwendung zu verstehen, oder ähnlich aussehenden, aber nicht gleichwertigen Code erzeugen.

Plausibler ist, dass KI die Kosten für die Untersuchung bestimmter kompilierter Software senken kann. Das hilft Verteidigern und Forschern, kann aber auch Angreifern den Zugang erleichtern.

Entscheidend sind Umsetzung, Governance, Autorisierung und unabhängige Validierung – nicht die Behauptung, alle Software sei nun Open Source.

AppSec braucht Belege, nicht nur Transparenz

REA verbindet etablierte Reverse-Engineering-Werkzeuge mit KI-gestützten Abläufen. Relevant sind die Fragen, die sich daraus für Softwaretransparenz und den Umgang mit nicht vertrauenswürdigen Analyseartefakten ergeben.

Ein verdächtiger Codepfad ist erst der Anfang. Teams müssen weiterhin nachweisen, ob er erreichbar und ausnutzbar ist, welche Auswirkungen er hat und ob eine Korrektur greift.

KI kann Untersuchungen beschleunigen; Sicherheitsergebnisse erfordern Belege, Validierung und verantwortliche Behebung.

Das ist die Grundlage von Proof-Driven AppSec: von Beobachtungen zu validierten Befunden und überprüften Korrekturen.

Erfahre mehr über KI-gestützte Sicherheitstests, Deep Code Analysis und evidenzbasierte Anwendungssicherheit bei Plexicus.

Häufig gestellte Fragen

Kann KI Closed-Source-Software reverse-engineeren?

KI kann Disassemblierung, Dekompilierung und Verhaltensanalyse unterstützen. Sie garantiert weder den exakten ursprünglichen Quellcode noch nicht enthaltene serverseitige Komponenten.

Was ist Reverse Engineer Anything (REA)?

REA ist ein Open-Source-Toolkit, das KI-Coding-Agenten über MCP mit Reverse-Engineering-Funktionen verbindet. Unterstützte Artefakte und Integrationen hängen von der Einrichtung ab.

Kann KI-gestütztes Reverse Engineering Schwachstellen finden?

Es kann verdächtige Codepfade aufzeigen und Hypothesen bilden. Zusätzliche Analysen und autorisierte Tests sind nötig, um eine tatsächliche Schwachstelle zu bestätigen.

Macht Reverse Engineering proprietäre Apps unsicher?

Nein. Sicherheit sollte nicht von geheim gehaltener Implementierung abhängen. Reverse Engineering kann Schwächen offenlegen, wenn eine App clientseitigen Prüfungen oder verborgenem Verhalten vertraut.

Können Reverse-Engineering-Agenten von Prompt-Injection betroffen sein?

Ja. Angreiferkontrollierte Zeichenfolgen oder Werkzeugausgaben können einen Agenten beeinflussen, wenn sie als vertrauenswürdige Anweisungen gelten. Kontrollierte Experimente zeigen Risiken durch Repräsentationsverwechslung.

Kann KI Reverse Engineering Penetrationstests ersetzen?

Nein. Es kann autorisierte Tests unterstützen, aber Code zu untersuchen beweist noch keine Ausnutzbarkeit oder Auswirkungen unter Testbedingungen.

Quellen und weiterführende Informationen

• Fireship: Every app on Earth is now open source… whether it likes it or not
• Reverse Engineer Anything (REA)
• Ghidra
• When Binaries Talk Back: Representation-Confusion Attacks (Juli 2026)
• OWASP LLM01
  Prompt Injection
• OWASP LLM06
  Excessive Agency
• OWASP MASVS-RESILIENCE
• OWASP ASVS v5.0, V8 Authorization
• NIST SP 800-218: Secure Software Development Framework, v1.1 final
• NIST SP 800-218 Rev. 1 initial public draft