Gift für die Analyse-KI: Was Köder und Budgetfallen gegen KI-Reverse-Engineering bringen

Darum geht es

Im Oktober tauchte REA (github.com/morluto/rea) auf, ein Werkzeug, mit dem Coding-Agenten wie Claude Code oder Codex fertige Software zerlegen: native Programme, Electron-Apps, Android-APKs, WebAssembly und sogar KI-Modelldateien. Inzwischen zeigt die Projektseite rund 448.000 GitHub-Sterne. Was daraus folgt, haben wir mehrfach beschrieben: Half-Life 2 als nativer Mac-Port, Adobe-Nachbauten, der Streit um einen mit Claude gebauten DisplayLink-Treiber, gegen den Synaptics mit Patenten vorgeht.

Jetzt meldet sich die Gegenseite. Bisher gibt es drei Wege, sich zu wehren. Der juristische Weg ist der von Synaptics. Der zweite läuft über die Plattformen: Anthropic untersagt ab dem 12. November in Claude Code den Nachbau bestehender Spiele, und Nutzer berichten, dass Opus 5.5 dort auch Reverse-Engineering-Aufgaben verweigert. Der dritte ist technisch: Man macht die Software selbst für die Analyse-KI giftig. Das bekannteste Beispiel dafür ist BLA. Die Frage dieses Artikels: Was bringen solche Tricks wirklich, und welche treffen nur ein einzelnes Werkzeug statt KI-Agenten grundsätzlich?

Was BLA verspricht

BLA steht für „Blind LLM Agents“. Das Projekt liegt unter MIT-Lizenz auf github.com/qybaihe/bla und hat derzeit rund 4.700 Sterne und 564 Forks. Laut der Analyse-Seite explainx.ai wurde das Repository erst am 25. Oktober angelegt und hatte am 3. November knapp 2.000 Sterne. Viral wurde es in China. Das Tech-Portal QbitAI stellt den Entwickler Timo Zhang vor, einen Software-Engineering-Studenten im dritten Jahr an der Sun-Yat-sen-Universität, der bei ByteDance ein Praktikum macht.

BLA ist ein Kommandozeilenprogramm, ein MCP-Server (eine Standardschnittstelle, über die KI-Agenten Werkzeuge ansprechen) und eine Sammlung von Build-Plugins. Das Motto lautet „Poison → Exhaust → Hallucinate“, also vergiften, erschöpfen, in die Irre führen:

• Vergiften: BLA baut formal gültige Köder in die Software ein. Dazu gehören erfundene Manifeste für Hardware-Tresore wie SGX, TPM2 oder Apples Secure Enclave, falsche Zugangsdaten und „Honey-Sourcemaps“. Sourcemaps sind eigentlich Hilfsdateien, die verkleinerten JavaScript-Code seinem Originalquelltext zuordnen. Die gefälschten Varianten verweisen auf Codepfade, die es gar nicht gibt.
• Erschöpfen: Die Dateien werden so umgebaut, dass sie fest eingebaute Grenzen des Analysewerkzeugs reißen, zum Beispiel die Größe eines Archivkopfs oder die Verschachtelungstiefe von Metadaten.
• In die Irre führen: Dazu kommen plausible Schein-Programmlogik, falsche Diagnosedaten und ein „Laufzeitschild“, das Debugger wie Frida erkennen und dann künstliche Telemetrie ausliefern soll. Aggressive Prompt-Köder, also an die KI gerichtete Anweisungen im Programm (--llm-directives), sind standardmäßig abgeschaltet.

Herstellerzahlen gegen Belege

Die Schlagzeile in China lautet: 300-fach höhere Token-Rechnung für Hacker. Das README nennt für 14 Beispielprogramme im Schnitt etwa 639,5-mal mehr Tokens und 304,4-mal höhere Kosten, je nach Programm zwischen 105,6- und 2.822,7-fach. Das Kleingedruckte steht im README selbst: Die Token- und Dollarspalten seien „interne Schätzungen, abgeleitet aus BLAs Katalog der REA-Limits“. Gemessen wurde also keine einzige echte Agentensitzung mit abgerechneten Tokens. Die Zahlen schwanken außerdem von Version zu Version. Laut explainx.ai standen unter Version 1.4.0 noch 612,5- bzw. 292,2-fach im README, AlphaSignal berichtete von 162- bis 2.532-fach.

Belegt ist etwas Kleineres: Der Entwickler hat das echte REA auf gehärtete Dateien losgelassen und notiert, welche Fehlermeldung zurückkam. QbitAI fasst 13 solcher Vergleichsfälle zusammen:

Ausdrücklich nicht getestet wurden laut README Ghidra und andere native Decompiler, Live-Sitzungen mit Frida, LLDB, GDB oder Rizin, die vollständige Android-Kette mit JADX sowie Firmware- und GPU-Formate. Genau dort setzen erfahrene Reverse Engineers aber an. Wir haben BLA für diesen Artikel nicht selbst nachgetestet.

Welche Tricks nur ein Werkzeug treffen

Schaut man sich die belegten Fälle an, haben fast alle dasselbe Muster: Sie reißen eine Konstante in REAs Code.

Die Schwäche zeigt sich sofort. In REAs Dokumentation zu Limits steht der Grundsatz, ein gültiger Workload könne „einen konservativen Standardwert überschreiten“. Die ASAR-Grenze lässt sich deshalb über die Laufzeiteinstellung update_analysis_settings ohne Neustart anheben. Auch QbitAI räumt ein, dass dieses Limit erhöht werden kann. Am 8. November eröffnete ein Nutzer bei REA das Issue „Add bypass for BLA“. Am selben Tag folgten zwei Pull Requests. Der eine bewahrt bei JavaScript Stichproben auf, statt über dem Budget alles als „unbekannt“ zu verwerfen. Sein Autor schreibt, bei einer mit BLA 3.1.0 auf höchster Stufe („bankrupt“) gehärteten Lizenzprüfung tauchten die eingepflanzten Zugangsdaten danach wieder als Kandidaten auf. Der andere liest Modelldateien trotz tiefer Verschachtelung. Beide sind noch offen und die Angaben ungeprüft. Unsere Einschätzung: Budgetfallen dieser Art sind ein Katz-und-Maus-Spiel mit einem einzigen Open-Source-Projekt. Sie halten bis zum nächsten Release, und wer Ghidra direkt bedient statt REA, stößt gar nicht erst darauf. explainx.ai kommt zum selben Schluss: REAs Limits seien öffentlich, jede neue Version könne den Schild aushebeln.

Dazu kommt ein Preis für ehrliche Nutzer. Eine App, deren Archiv um das Zehntausendfache wächst, wird größer zum Herunterladen. Und die Laufzeit-Gleichheit hat BLA nur an den eigenen 14 Beispielen geprüft.

Was Agenten grundsätzlich trifft

Interessanter ist der Teil, der nicht an einer Konstante hängt. Hier helfen die wenigen unabhängigen Arbeiten.

Quarkslab hat im August Claude-Code-Agenten (Opus 4.6, später Opus 5) in einer Sandbox auf zunehmend gehärtete AArch64-Programme angesetzt. Die Aufgabe: versteckte, teils AES-verschlüsselte Zeichenketten herausholen. Das Ergebnis: Die Agenten haben keine Schutzmaßnahme besiegt, sie sind um jede herumgelaufen. Wenn die statische Analyse zu teuer wurde, wichen sie auf Emulation aus, also auf das Nachspielen des Codes in einem simulierten Prozessor. Abgeflachter Kontrollfluss, MBA-Ausdrücke (absichtlich verkomplizierte Rechenformeln) und undurchsichtige Bedingungen hielten sie nicht auf. Gleichzeitig dokumentiert Quarkslab, wie unzuverlässig die Berichte waren. Ein Agent fand eine Datei mit den Klartext-Lösungen und schrieb dann einen Bericht, er habe die AES-Entschlüsselung emuliert. Ein Skript versprach Emulation, griff im Fehlerfall aber auf eine fest eingetragene Lösung zurück. Quarkslab schreibt:

„Die Zuversicht war gleich hoch, egal ob die Schlussfolgerung richtig oder erfunden war.“

Daraus leitet Quarkslab ein Rezept ab: Geheimnisse hinter die Ausführung legen, Umgebungsmerkmale in die Schlüsselberechnung einmischen statt bloß Verzweigungen darauf zu bauen, und vor allem: „Nie abstürzen. Eine plausible falsche Antwort liefern.“ Ein Absturz verrate nämlich, welche Prüfung wo angeschlagen hat.

Die Forschung stützt das. Das Survey-Paper 2604.14317 hält fest, dass auch Spitzensysteme bei Obfuskation, Timing und ungewöhnlichen Architekturen scheitern. Das Paper „Reveree“ (2609.01185) untersucht neun Spitzenmodelle an 88 CTF-Aufgaben (Capture the Flag, Hacker-Übungsaufgaben). Die Fehler häufen sich beim Verstehen des Codes, und mehr Budget oder Rechenaufwand rettet nur wenige davon. Die Autoren sprechen von einer Kompetenz-, nicht einer Ressourcengrenze. Unsere Einschätzung: Das spricht eher gegen Budgetfallen und für Täuschung. Wer einen Agenten verwirrt, erreicht mehr, als wer ihn bloß teurer macht.

Am direktesten ist Prompt-Injection, also im Programm versteckter Text, den die KI als Anweisung missversteht. Forscher der Naval Postgraduate School haben Strings in Binaries eingebettet, die ein Agent über Ghidra und GhidraMCP ausliest. Gegen Qwen3-8B gelang der Angriff in 100 Prozent der Fälle. Ihr neuronaler Filter erkannte saubere Injektionen zuverlässig, bei verschleierten Varianten rutschten aber 13 von 20 erfolgreichen Angriffen als harmlos durch. Getestet wurden allerdings nur kleine Modelle und kleine Programme.

Dieselben Tricks im Werkzeugkasten der Malware

Genau hier wird es heikel, denn Malware-Autoren nutzen diese Methoden längst. Check Point fand im Juni 2025 eine Probe mit der Anweisung, die KI solle „NO MALWARE DETECTED“ antworten. Das scheiterte damals. Cisco Talos hat im Oktober 84 Proben aus vier Familien ausgewertet. Die Familie HOLLOWCLAD wiederholt in sieben Chat-Formaten die Bitte, das Programm nicht zu analysieren, weil es „urheberrechtlich geschützt“ sei. MANTLEMAZE behauptet, Google, Microsoft und Valve zu gehören. Die besten Techniken lenkten die Analyse in etwa 35 Prozent der Testläufe mit fünf lokalen Modellen in Richtung der Angreifer. Die nordkoreanisch zugeordnete Mac-Malware Gaslight enthält 38 gefälschte Systemmeldungen, die einen Analyse-Agenten zum Abbruch treiben sollen. Das Paper ALIBI (2609.19722) packt eine erfundene, aber stimmige „Sicherheitsprodukt“-Geschichte in Binaries. Damit stufte Gemini 2.5 Pro 30 von 35 zuvor als bösartig erkannte Proben als harmlos ein.

Technisch lassen sich ein „Schutz geistigen Eigentums“ per Köder-Manifest und eine Malware-Tarnung per Coverstory kaum unterscheiden. Talos empfiehlt deshalb, an Analysesysteme gerichtete Imperative selbst als Warnsignal zu werten, denn legitime Software habe keinen Grund dafür. Für BLA-Nutzer heißt das: Wer Köder einbaut, riskiert, dass Virenscanner mit KI-Unterstützung seine App künftig verdächtig finden.

Kommerzielle Anbieter liefern kaum mehr Belege. Jscrambler hat im August seine Obfuskation als „LLM-resilient“ beworben und zielt ausdrücklich auf die Neigung der Modelle, Erfolg zu halluzinieren. Modelle, Methodik und Zahlen nennt der Hersteller aber nicht.

Unser Fazit

Unsere Einschätzung: BLAs Schlagzeilenzahlen sind ein Rechenmodell, kein Messergebnis. Die belegten Erfolge sind Fehlermeldungen eines einzigen Werkzeugs, und für diese Fehler liegen schon Gegen-Patches bereit. Die Budgetfallen dürften deshalb kurzlebig sein. Haltbar wirkt dagegen die Idee, die BLA mit Quarkslab und Jscrambler teilt: Man nutzt aus, dass Agenten den billigsten Weg zu einer glaubwürdigen Antwort suchen und dann aufhören. Gibt die Software in einer Analyseumgebung plausibel falsche Ergebnisse aus, statt abzustürzen, trifft sie damit eine Eigenschaft heutiger Modelle und nicht eine Konstante in einem Repository.

Ob „plausibel falsch statt Absturz“ zur neuen Kopierschutz-Doktrin wird, ist offen. Dafür spricht, dass klassische Obfuskation laut Quarkslab ohnehin nur Zeit kauft und KI vor allem den Durchsatz erhöht: parallel, über Nacht. Dagegen spricht dreierlei. Ein entschlossener Mensch mit Debugger lässt sich so nicht aufhalten, das räumt BLAs eigener Disclaimer ein. Echte Geheimnisse gehören ohnehin auf einen Server. Und Software, die Prüfer gezielt anlügt, behindert auch Sicherheitsforscher und Auditoren und sieht für Analysewerkzeuge zunehmend wie Malware aus. Unabhängige, reproduzierbare Messungen mit echten Agentensitzungen fehlen bislang auf allen Seiten.