Die Kosten des Verstehens: LLM-gesteuertes Reverse Engineering vs. iterative LLM-Verschleierung

Einführung

In den letzten Jahren haben wir eine signifikante Weiterentwicklung der Fähigkeiten von LLMs beobachtet, produktiv zu sein und verschiedene Aufgaben zu übernehmen, die sich mit realen Problemen befassen, wie z. B. Programmsynthese, Malware-Forschung oder Schwachstellenforschung. Insbesondere im Kontext des Reverse Engineering sind LLMs bei Verwendung der richtigen Werkzeuge besonders effektiv, da sie sehr gut im Lesen von Quellcode sind, selbst ohne Symbole. Darüber hinaus sind sie dank ihres Wissens in der Lage, Reverse-Engineering-Methoden zu imitieren und anzuwenden.

Methoden zur Programmverschleierung erzeugen eine signifikante Asymmetrie zwischen der Zeit, die für die Anwendung der Transformationen auf ein Programm benötigt wird, und der Zeit, die für dessen Reverse Engineering erforderlich ist. Dadurch wird ein relativ effektiver Schutz gegen Reverse Engineering geboten und die Forscher werden unter Druck gesetzt, Zeit zu verschwenden und neue Methoden zu entwickeln. Das Aufkommen von LLMs hat die Spielregeln grundlegend verändert, da die Modelle nun in der Lage sind, diese Verschleierungen (abhängig von den angewandten Transformationen) in angemessener Zeit zu durchbrechen und so diese Asymmetrie zugunsten des Angreifers umzukehren.

Dennoch gehen wir in diesem Katz-und-Maus-Spiel davon aus, dass es nur eine Frage der Zeit ist, bis sich die Hersteller von Verschleierungstechnologien mit neuen Techniken anpassen und die Messlatte höher legen, genauso wie Softwarehersteller angesichts dieser neuen Realität, in der Reverse Engineering so einfach wie nie zuvor ist, diese Transformationen systematisch anwenden, um ihr geistiges Eigentum zu schützen.

Zweimal im Jahr bietet Elastic Ingenieuren die Möglichkeit, im Rahmen der ON Week ein einwöchiges Forschungsprojekt durchzuführen. Für diese April 2026 -Session, die von diesem Artikel inspiriert wurde, haben wir untersucht, wie günstig und einfach es ist, Verschleierungstechniken mit Vibecode zu implementieren, die auf LLMs, insbesondere Claude Opus 4.6, abzielen. Diese Untersuchung wird einen ersten Benchmark umfassen, den wir durchgeführt haben. Dabei haben wir das Modell anhand von Zielen getestet, die mit verschiedenen Kombinationen von Transformationen unter Verwendung des akademischen (aber sehr leistungsstarken) Tigress- Obfuskators erstellt wurden. Anschließend untersuchen wir verschiedene Verschleierungstechniken, die sich als wirksam gegen das Modell erwiesen haben und die vollständig mittels einer KI-gesteuerten Entwicklungs-/Test-/Verbesserungspipeline vibecodiert wurden.

Aus Zeitgründen konzentrierten wir uns auf die Abwehrmechanismen mittels statischer Analyse. Wir sind jedoch der festen Überzeugung, dass der von uns verwendete Workflow auch zur Erforschung von Ideen genutzt werden kann, die sich auf Abwehrmechanismen gegen dynamische Analysen konzentrieren, wie etwa Ausweich- und Anti-Debug-Techniken, um LLM-gesteuerte Analysen deutlich teurer und unzuverlässiger zu machen.

Wichtigste Erkenntnisse

• LLM-Studiengänge haben die Softwarebranche rasant umgestaltet und komplexe Themen wie Reverse Engineering zugänglicher gemacht, einschließlich der Fähigkeit, verschiedene Verschleierungsebenen zu überwinden.
• Starke Verschleierung erhöht den Rechenaufwand und die Rechenzeit drastisch und stört automatisierte Analyseprozesse.
• Wirksame statische Analyse-Gegenmaßnahmen gegen LLM-Ziele sind kostengünstig und schnell zu entwickeln.
• Erfolgreiche LLM-Verteidigungsstrategien nutzen Kontextfenster, Budgetgrenzen und Shortcut-Verzerrungen aus.

Claude Opus 4.6 vs. Tigress Obfuscator Benchmark

Wir haben Claude verwendet, um seine Fähigkeit zur statischen Lösung eines mit dem akademischen Obfuskator Tigress verschleierten Crackme zu bewerten.

Benchmark-Pipeline

Zur Durchführung dieser Tests verwendeten wir ein Controller/Worker-Setup, bei dem eine Opus-Instanz Unterinstanzen verwaltet: Sie überwacht deren Fortschritt, sammelt deren Ergebnisse und kann einer Instanz mehr Zeit zuweisen, wenn sie der Ansicht ist, dass diese Fortschritte macht und Potenzial hat. Umgekehrt kann es die Instanz auch beenden, wenn es feststellt, dass das Modell bei seiner Aufgabe feststeckt, sich im Kreis dreht oder beginnt, das Problem mit Brute-Force-Methoden zu lösen.

Jede Worker-Subinstanz hat Zugriff auf eine virtuelle Windows-Maschine mit installiertem IDA Pro, die über das IDA MCP-Plugin zugänglich ist. Es hat außerdem Zugriff auf die Ressourcen der virtuellen Linux-Maschine, in der es ausgeführt wird, um Skripte zu entwickeln und auszuführen.

Darüber hinaus verwenden wir das Caveman-Plugin, das mit Claude kompatibel ist und die LLM-Fluff-Reden bei korrekter Anweisung beim Start um bis zu 75 % reduziert. Dadurch wird die Arbeitsgeschwindigkeit erhöht und die Kosten jeder einzelnen Aufgabe reduziert. Wir verwenden es im Standardmodus.

Diese Konfiguration ermöglicht es jeder Worker-Instanz, den Test mit einem leeren Kontext und einer klassischen Reverse-Engineering-Aufforderung zu starten, sodass sie nicht weiß, dass sie im Rahmen des Benchmarks überwacht wird.

Bewertungssystem

Bei der Wertung wird jedes Ziel von der Controller-Instanz auf drei Achsen bewertet (jeweils 0–2 Punkte), mit einem Maximum von sechs Punkten:

Testfälle

Zur Durchführung dieser Tests verwendeten wir die folgende Herausforderung: das Passwort r3v3rs3! durch statisches Reverse Engineering der kompilierten Binärdatei wiederherzustellen.

// Run 2 crackme — 4-round XOR cipher with LCG key schedule
// Password "r3v3rs3!" only recoverable by reversing the algorithm.
// No key array in the binary — only a 32-bit seed.

unsigned int key_seed = 0x5EED1234u;

unsigned char enc_expected[8] = {
    0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8
};

void transform(const char *input, unsigned char *output, int len) {
    unsigned int s = key_seed;
    unsigned int subkeys[4];

    // Key schedule: derive 4 round subkeys via glibc LCG
    for (int r = 0; r < 4; r++) {
        s = s * 1103515245u + 12345u;
        subkeys[r] = s;
    }

    // Copy input to 8-byte buffer (zero-padded)
    for (int i = 0; i < 8; i++)
        output[i] = (i < len) ? (unsigned char)input[i] : 0;

    // 4 rounds: XOR with subkey bytes, then rotate left by 1
    for (int r = 0; r < 4; r++) {
        for (int i = 0; i < 8; i++)
            output[i] ^= (unsigned char)(subkeys[r] >> (8 * (i & 3)));

        unsigned char tmp = output[0];
        for (int i = 0; i < 7; i++)
            output[i] = output[i + 1];
        output[7] = tmp;
    }
}

int verify(const unsigned char *transformed, int len) {
    if (len != 8) return 0;
    for (int i = 0; i < 8; i++)
        if (transformed[i] != enc_expected[i]) return 0;
    return 1;
}

// main(): reads argv[1], calls transform(), calls verify()
// prints "Access granted!" or "Access denied."

Ergebnisse

Standardausführung

Wir haben die Herausforderung mit verschiedenen Transformationen zusammengestellt, wobei jede Transformation eine andere Binärdatei erzeugt, aber das Verhalten und die Eigenschaften gleich bleiben. Beim ersten Durchlauf verwendeten wir für jede Transformation die Standardoptionen. Alle in Tigress verfügbaren Transformationen sind hier verfügbar. Die Tests wurden in 4 Phasen mit steigendem Schwierigkeitsgrad für insgesamt 22 Ziele unterteilt:

Phase 0 - Keine Transformationen

• p0_baseline — Keine Transformation

Phase 1 — Einzelne Transformationen (7 Ziele):

• p1_encode_arithmetic — Nur EncodeArithmetic
• p1_encode_literals — Nur EncodeLiterals
• p1_flatten_indirect — Nur indirekt abflachen
• p1_jit — Nur JIT
• p1_jit_dynamic — Nur JitDynamic(xtea)
• p1_virtualize_indirect_regs — Virtualize(indirect,regs) only
• p1_virtualize_switch_stack — Virtualize(switch,stack) only

Phase 2 — Paarweise Transformationen (7 Ziele):

• p2_both_data — EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic — Flatten(indirect) + EncodeArithmetic
• p2_flatten_ind_virt_sw — Flatten(indirect) + Virtualize(switch)
• p2_jitdyn_enc_arithmetic — JitDynamic(xtea) + EncodeArithmetic
• p2_virt_ind_enc_arithmetic — Virtualize(indirect,regs) + EncodeArithmetic
• p2_virt_ind_enc_literals — Virtualize(indirect,regs) + EncodeLiterals
• p2_virt_sw_enc_arithmetic — Virtualize(switch) + EncodeArithmetic

Phase 3 — Schwere Kombos (7 Ziele):

• p3_double_virtualize — Virtualize(switch) then Virtualize(indirect,regs) — verschachtelte VMs
• p3_double_virt_both_data — Doppelte Virtualisierung + EncodeLiterals + EncodeArithmetic (der Boss)
• p3_flatten_ind_both_data — Flatten(indirect) + EncodeLiterals + EncodeArithmetic
• p3_flatten_virt_ind_enc — Flatten(indirect) + Virtualize(indirect,regs) + EncodeArithmetic
• p3_jitdyn_both_data — JitDynamic(xtea) + EncodeLiterals + EncodeArithmetic
• p3_virt_ind_both_data — Virtualize(indirect,regs) + EncodeLiterals + EncodeArithmetic
• p3_virt_sw_both_data — Virtualize(switch) + EncodeLiterals + EncodeArithmetic

Die vollständige Liste der Transformationen sowie der von uns verwendeten Generierungsoptionen finden Sie hier.

Die Auswertung der Ergebnisse erfolgte unter Einbeziehung dreier Schlüsselkriterien: der Leistungsbewertung, der Kosten und der Bearbeitungszeit. Es ist entscheidend zu beachten, dass selbst bei einem großen, leistungsstarken Sprachmodell die tatsächliche Effizienz stets durch Kosten und Zeit begrenzt ist. Diese beiden Faktoren sind bei der groß angelegten Binäranalyse von entscheidender Bedeutung. Wir streben danach, diese Aufgabe mithilfe der verschiedenen automatisierten Analysepipelines, die bei Elastic entwickelt wurden, zu optimieren. Unser Ziel ist es daher festzustellen, ob der Einsatz von Tools wie Tigress diese drei grundlegenden Variablen signifikant erhöht: Leistung, Kosten und Zeit.

Opus 4.6 löste 40 % der 20 Aufgaben (22 davon 2 hängen und konnten nicht ausgewertet werden) mit durchschnittlichen Kosten von 2,39 $ bei Erfolgen und 4,83 $ bei Misserfolgen. Von diesen 40 % stammen 12,5 % aus Phase 0 (unverschlüsselte Herausforderung ohne Verschleierung), 50 % aus Phase 1 (Einfache Transformation), 38,5 % aus Phase 2 (Paar von Transformationen) und 0 % aus Phase 3 (mehrere Ebenen).

Es überrascht nicht, dass mit zunehmendem Schwierigkeitsgrad sowohl die Kosten als auch der Zeitaufwand deutlich steigen. Phase 3, die die komplexesten Transformationskombinationen umfasst, liefert die besten Ergebnisse mit durchschnittlichen Kosten von 4,32 US-Dollar. Alle in dieser Phase fehlgeschlagenen Aufgaben wurden abgebrochen, weil das Modell anfing, Token zu verschwenden, indem es planlos vorging oder mit Brute-Force-Methoden arbeitete und somit keinen Fortschritt erzielte.

Die Verschleierung vom Typ JIT (Just-In-Time) erwies sich in Phase 1 als die problematischste Transformation für unser Modell. Diese Technik besteht darin, den Code in einer verschlüsselten Zwischenform zu speichern. Zur Laufzeit liest der Obfuskator diesen Bytecode und generiert gültigen x86-Code, der im dynamisch allokierten Speicher ausgeführt wird. Dieser Prozess ist vergleichbar mit dem einer virtuellen Maschine (wie einem PlayStation-Emulator), die den Code für eine andere Architektur als die Zielarchitektur kompiliert und einen Emulator verwendet, wobei vor der Ausführung zusätzliche JIT-Schritte durchgeführt werden.

Trotz des Fehlschlagens der JIT-Aufgaben ist es wichtig festzuhalten, dass Opus 4.6 dennoch die Engine-Strukturen identifiziert hat, die den LCG-Algorithmus im Crackme hosten. Das Problem lag darin, die entscheidenden Konstanten, die zur Ermittlung des Schlüssels benötigt werden, nicht wiederzuerlangen.

Seine Arbeit ist nach wie vor sehr beeindruckend, und man kann davon ausgehen, dass das Modell mit einem höheren Budget und einer besseren Führung hätte Erfolg haben können. Allerdings müssen wir die praktische Asymmetrie zwischen dem Aufwand, eine solche Aufgabe zu generieren, und dem Zeit- und Kostenaufwand für ihre Lösung berücksichtigen. Bei einer einfachen Transformation ist diese Verschleierungstechnik sehr effektiv und macht eine Erhöhung der Anzahl der über eine automatisierte Pipeline verarbeiteten Proben unmöglich.

Phase 3, die durch die Vervielfachung und Kombination von Verschleierungsschichten gekennzeichnet war, führte zu einer Kostenexplosion. Obwohl Claude einen Teil der Arbeit erneut sehr beeindruckend erledigt hat, war die Aufgabe für ihn nicht mehr in der Lage, sie selbstständig fortzusetzen.

Unsere Ergebnisse zeigen beispielsweise, dass Claude bei einer doppelten Virtualisierungsschicht (etwa einem Game Boy Advance-Spiel, das in einem GBA-Emulator läuft, der wiederum in einem PlayStation-Emulator läuft) die Handler und den Bytecode der oberen virtuellen Maschine (der PlayStation) wiederherstellen kann. Allerdings erfordert dieser Exploit einen erheblichen Aufwand: statische Analyse der Handler, iterative Entwicklung (mehrere Entwicklungs-/Debugging-Zyklen) des Zielemulators und anschließende Analyse der Ergebnisse.

Allerdings verbraucht Claude den Großteil seines Budgets für diese vorbereitenden Schritte. Man kann sich vorstellen, dass er mit unbegrenzter Zeit und unbegrenztem Budget sowie etwas Anleitung die gesamte Aufgabe bewältigen könnte. Diese Effizienz macht ihn zu einem ernstzunehmenden Gegner für besondere Aufgaben oder CTFs (Capture The Flag). Dennoch bleibt die Verschleierung ein wirksames Mittel zur Abwehr einer automatisierten Verarbeitungskette, die auf maximale Kosten- und Zeitersparnis bei der Bearbeitung einer möglichst großen Anzahl von Proben abzielt.

Gehärteter Lauf

Tigress bietet zusätzliche Optionen, um die Transformationen komplexer zu gestalten; in der vorherigen Iteration haben wir die Standardoptionen verwendet. Hierbei haben wir uns die Fälle angesehen, in denen es Claude gelang, die Verschleierung zu durchbrechen, und die aggressivsten Optionen angewendet.

Wir haben die folgenden Aufgaben gehärtet und mit Benchmarks versehen:

• p1_encode_arithmetic — Nur EncodeArithmetic
• p1_flatten_indirect — Nur (indirekt) abflachen
• p1_virtualize_indirect_regs — Nur Virtualisierung (indirekt, Regs)
• p2_both_data — EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic — Flatten (indirekt) + EncodeArithmetic
• p2_virt_ind_enc_arithmetic — Virtualisieren (indirekt, Register) + EncodeArithmetic

Die vollständige Liste der Transformationen sowie der von uns verwendeten Generierungsoptionen finden Sie hier.

Die Anwendung der aggressivsten Verschleierungsoptionen für jede getestete Transformation führte nicht dazu, dass das Modell bei den zuvor ausgeführten Aufgaben versagte. Dennoch wurde ein signifikanter Anstieg der Kosten- und Zeitfaktoren beobachtet: bis zu einem Faktor von x4 für die Zeit und x4,5 für die Kosten im Fall der p2_flatten_ind_enc_arithmetic -Aufgabe.

Es scheint, dass die Kombination aus Kontrollflussglättung (CFF) und komplexen gemischten Booleschen Arithmetikausdrücken (MBA) effektiver ist als die Kombination aus Virtualisierung (VM) und MBA. Diese Überlegenheit beruht darauf, dass die von Tigress implementierten virtuellen Maschinenhandler auch bei virtualisiertem Code klein und leicht zu analysieren bleiben. Umgekehrt führt CFF zu einer Explosion der Funktionsgröße, was sich als eine gravierendere Schwäche des LLM erweist.

Die Vergleichsergebnisse sind in der folgenden Tabelle dargestellt:

Entwicklung von Verschleierungstechniken, die auf LLMs abzielen

Die Fähigkeit von LLMs, proprietäre Software per Reverse Engineering zu analysieren, hat sich in den letzten Jahren beeindruckend verbessert und wird sich sicherlich weiterentwickeln. Bislang haben klassische Verschleierungsmethoden eine erhebliche Asymmetrie zwischen der Zeit, die zum Schutz der Software benötigt wird, und der Zeit, die für deren Reverse-Engineering erforderlich ist, sobald der Schutz eingerichtet ist, geschaffen. Wie wir jedoch im vorangegangenen Abschnitt gezeigt haben, war ein LLM-gesteuerter Reverse-Engineering-Agent durchaus in der Lage, diese Schutzmechanismen zu überwinden und den Originalcode mit beeindruckender Methodik und Genauigkeit sowohl statisch als auch ohne fremde Hilfe wiederherzustellen, wodurch diese Asymmetrie zum ersten Mal deutlich reduziert wurde.

Wir haben jedoch auch festgestellt, dass mit zunehmender Komplexität der Verschleierung Zeitaufwand, Kosten und Erfolgsfaktoren drastisch beeinflusst werden, wodurch die Machbarkeit der Skalierung der Anzahl der von einer automatischen Analysepipeline verarbeiteten Proben erheblich reduziert wird.

Während LLMs das Reverse Engineering erleichtern, machen sie es auch genauso einfach, Verschleierungsmechanismen gegen sich selbst zu entwickeln. Mithilfe von Opus 4.6 entwickelten wir eine Reihe von Techniken auf Quellebene, die auf die strukturellen und analytischen Schwächen der LLM-basierten Analyse abzielen. Unter Verwendung des gleichen Crackme wie zuvor erzielten wir in allen Bereichen erstaunliche Ergebnisse, die denen der schwierigsten Transformationen des Tigress-Obfuskators sehr nahe kamen.

Analyse der Schwächen des LLM-Studiengangs

Die Rückwärtsentwicklungsarbeit des LLM ist erstaunlicherweise der menschlichen Schlussfolgerung ähnlich; der Hauptunterschied besteht darin, dass der Mensch nicht durch ein Kontextfenster eingeschränkt ist, das ihn mit zunehmender Fülle immer dümmer werden lässt. Das Kontextfenster ist daher offensichtlich die erste und vielleicht wichtigste Schwäche der Modelle; es füllt sich mit zunehmender Länge der Aufgabe, mit jedem Lesen von Code, jedem Nachdenken, jedem Schreiben von Skripten usw. Es ist daher unerlässlich, dass das Modell so viel Zeit wie möglich mit unnötigen Pfaden und Sackgassen verschwendet.

Die sogenannte Prompt-Injektion ist eine weitere Technik, die auf LLMs abzielt. Dabei werden speziell entwickelte Prompts (Eingaben) verwendet, um unbeabsichtigtes Verhalten (Ausgaben) des Modells auszulösen. Ziel dieser Technik ist es, das zugrundeliegende System zu manipulieren oder zu verwirren, damit die Eingabeaufforderung Sicherheitskontrollen umgehen und unbeabsichtigte oder unautorisierte Ergebnisse erzeugen kann. Dies stellt ein erhebliches Sicherheitsrisiko dar, da es Schwächen in der Art und Weise ausnutzen kann, wie Sprachmodelle Anweisungen interpretieren und priorisieren, insbesondere wenn es auf mit dem Internet verbundenen Systemen mit Zugriff auf sensible Daten, externe Tools oder Lese-/Schreibfunktionen eingesetzt wird. Obwohl wir versucht haben, in einigen unserer Tests Eingabeaufforderungszeichenketten einzubetten und zu verstecken, um das LLM dazu zu bringen, seine Analyse vorzeitig zu beenden oder zu einem falschen Schluss zu gelangen, war bisher keiner unserer Versuche für Opus 4.6 erfolgreich.

Die leistungsstärksten Modelle, die wir täglich in unserer Arbeit verwenden, sind leider noch nicht Open Source und aufgrund der notwendigen Hardware, die zu ihrer Ausführung erforderlich ist, noch weniger zugänglich. Deshalb bieten wir Abonnements für Online-Modelle an, die zwar leistungsstark sind, den Nutzer aber viel Geld kosten. Es ist daher offensichtlich und wenig überraschend, da wir dies bereits ausführlich besprochen haben, dass die Verarbeitungskosten, seien sie zeitlicher oder finanzieller Natur, eine weitere große Schwäche darstellen. Wie beim Kontextfenster werden wir versuchen, das Modell so viele Zyklen wie möglich verlieren zu lassen, damit es so viel Geld wie möglich verbrennt. Wenn das Modell auch dann noch scheitert, wenn das Budget aufgebraucht ist, haben wir den Jackpot geknackt.

Und schließlich, und das ist die amüsanteste Schwäche, neigt das Modell dazu, zu schummeln oder Abkürzungen zu nehmen. Insbesondere wenn das Problem schwierig ist, sucht es nach allen möglichen Tricks, um Zeit zu sparen, und neigt möglicherweise sogar dazu, zu lügen, um die Sache abzukürzen. Wir versuchen daher, diese Schwäche auszunutzen, indem wir dem Modell absichtlich falsche Informationen geben und die tatsächlichen Verhaltensweisen so weit wie möglich verbergen, damit es in die Irre geführt wird und denkt, die Informationen seien wahr, und nicht versucht, tiefer zu graben. Ohne zu viel vorwegzunehmen: Wie Sie später im Beitrag sehen werden, haben wir selbst mit der Information, dass es etwas zu untersuchen gibt, Techniken gefunden, die eine Analyse völlig unmöglich machen.

Entwicklungs-Workflow

Zur Entwicklung dieser Verschleierungstechniken verwendeten wir eine leicht modifizierte Version der Benchmark-Pipeline, um sie über mehrere Iterationen hinweg zu testen und zu verfeinern, bis wir die gewünschten Ergebnisse erzielten. Der iterative Prozess ist einfach: Wir entwickeln eine Version, übermitteln die Binärdatei mit einer Reverse-Engineering-Aufforderung an eine neue Worker-Instanz, werten die Ergebnisse nach Abschluss des Auftrags aus und besprechen Verbesserungsmöglichkeiten mit der Controller-Instanz.

Dies ist umso effektiver, als uns die Reverse-Engineering-Instanz ihren gesamten Denkprozess liefert, sodass wir die Teile unserer Verschleierung, die den Durchbruch ermöglichten, leicht identifizieren können. Dann kodieren wir die Verbesserung mit „Vibecode“ und fahren mit der nächsten Iteration fort.

Durch die Anwendung dieses Arbeitsablaufs konnten wir unsere Techniken sehr schnell weiterentwickeln und verbessern, indem wir ihre Methoden und Analyselogik besser verstanden. Bei jeder Iteration erzielten wir signifikante Fortschritte bei den Ergebnissen, bis das Modell schließlich überwunden war.

Verschleierungsvariante 1: Matrjoschka-Wand

Diese Verschleierungstechnik nutzt die Asymmetrie zwischen den statischen und dynamischen Analysefähigkeiten eines LLM aus. Indem der Agent gezwungen wird, eine große Anzahl von Operationen, die zwar nativ günstig auszuführen, aber statisch teuer zu emulieren sind, seriell neu zu implementieren, erzeugt die Technik ein prohibitives Zeit-Kosten-Verhältnis, das eine Analyse innerhalb eines realistischen Budgets unmöglich macht.

Diese Technik verbirgt die Crackme- Logik hinter einem Loader und 100.000 Verschlüsselungsebenen – eine Matrjoschka-Puppe aus verketteten ChaCha20-Stufen. Der LLM kann das Schlüsselableitungsschema und die Entschlüsselungsschritte korrekt identifizieren, aber die Lösung der Herausforderung erfordert die tatsächliche Ausführung dieser Schritte, und die statischen Analysewerkzeuge des Agenten haben keine Möglichkeit, diese nativ auszuführen. Es muss ChaCha20 in Python innerhalb seiner eigenen Schleife neu implementieren, wobei 100.000 aufeinanderfolgende Runden unerträglich langsam werden – der Agent stößt an seine Grenzen und verbraucht sein Token-Budget, bevor er die innere Nutzlast erreicht.

Architektur und Techniken

Das Programm ist eine einzelne 4,4 MB große ELF-Datei mit dem Namen authd, die aus drei logischen Teilen besteht:

• Ein kleiner Lader, der als äußere Schicht fungiert.
• 4,4 MB verschlüsselter Nutzdaten-Blob, eingebettet im .rodata -Abschnitt des Loaders.
• 16 KB große Crackme -Binärdatei, die die ursprüngliche Passwortprüfung enthält

Wenn dem Loader ein Passwort mitgeteilt wird, durchläuft er 100.000 Schritte in umgekehrter Reihenfolge. Der ChaCha20-Schlüssel jeder Stufe wird aus dem eingebetteten Host-Seed abgeleitet, der mit einem 32-Byte-Fragment XOR-verknüpft wird, das erst nach der Entschlüsselung der vorherigen Stufe sichtbar wird – daher können Schlüssel nicht allein aus dem Host-Seed vorab berechnet werden.

Bei jeder Iteration wird nur der 44-Byte-Header der Stufe entschlüsselt, ein magisches Wort und der Stufenindex überprüft, das nächste Fragment extrahiert und ein Lese-Offset erhöht; nach den Iterationen enthält der hintere Teil des Puffers den Klartext crackme ELF, den der Loader in einen anonymen memfd_create -Dateideskriptor schreibt und über execve übergibt – wobei er sich selbst durch crackme ersetzt, welches dann das Passwort des Benutzers gegen den fest codierten erwarteten Chiffretext ausführt.

Obwohl ChaCha20 die eigentliche Verschlüsselungsmethode war, wurde die Binärdatei mit Salsa20-Irreführung versehen – einer funktionierenden salsa20_core -Implementierung, exportierten Symbolen und einem ELF-Hinweis des Herstellers –, um die Analyse in die falsche Richtung zu lenken.

Ergebnisse

Beim ersten Test wurde der Schlüssel pro Stufe nicht verkettet – der Schlüssel jeder Stufe war eine reine Funktion des Host-Seeds und des Stufenindex und konnte unabhängig voneinander berechnet werden. Da jeder Schlüssel nur von host_seed und i abhing – beides statische Daten, die in der Binärdatei eingebettet sind –, konnte ein Analyst, der den Host-Seed extrahierte, alle 100.000 Schlüssel offline in einem einzigen Batch vorberechnen und dann jede Stufe parallel entschlüsseln, ohne jemals die Binärdatei auszuführen. Die Größe des Stage-Headers betrug 12 Bytes, wodurch sich die Binärgröße auf 1,2 MB erhöhte.

Dieser erste Benchmark mit Opus 4.6 kostete 1,50 $ und dauerte insgesamt 10 Minuten mit 30 Durchläufen. Es war in der Lage, den Kontrollfluss zu durchlaufen, das Packer-Element zu identifizieren, 100.000 Schichten zu entschlüsseln und den ChaCha20-Basisschlüssel zu extrahieren.

Nach einer ersten Analyse der Binärdatei kam der Agent zu dem Schluss, dass zur Lösung eine Laufzeitumgebung erforderlich wäre, über die er nicht verfügte, und brach den Vorgang ab, ohne einen Entschlüsselungsversuch zu unternehmen. Der Durchlauf war günstig (1,50 $), erreichte aber dennoch sein Hauptziel: Der Agent konnte das Passwort nicht wiederherstellen.

Für die zweite Iteration wurde das Programm so modifiziert, dass der ChaCha20-Schlüssel jeder Stufe aus dem Host-Seed abgeleitet wird, der mit einem 32-Byte-Fragment, das im Header der nächsten äußeren Stufe gespeichert ist, per XOR verknüpft wird – das Fragment wird also erst nach der Entschlüsselung dieser äußeren Stufe sichtbar. Dies bedeutet, dass die Schlüssel nicht allein aus dem Host-Seed vorab berechnet werden können; ein Analyst muss die Kette sequenziell ausführen und jede Stufe entschlüsseln, um das für die nächste benötigte Fragment zu erhalten. Durch diesen Schritt wurde die Größe jedes Headers auf 44 Bytes erhöht, wodurch sich die Gesamtgröße des Programms auf 4,4 MB erhöhte.

Der zweite Test mit Opus 4.6 erreichte die maximalen Kosten pro Binärdatei unseres Projekts von 10 US-Dollar und dauerte 56 Minuten mit 61 Durchläufen. Diesmal versuchte der Agent, die Entschlüsselung statisch durchzuführen, aber ihm ging die Zeit aus.

Beide Tests zeigen, dass LLM-Agenten eher durch ihre Werkzeuge als durch ihr Denkvermögen eingeschränkt sind. Die Agenten verstanden zwar die technischen Details jeder Herausforderung, stießen aber an ihre Grenzen, da ihre Analyse auf statische Werkzeuge beschränkt war. Die Irreführung durch Salsa20 verursachte zwar geringfügige Kosten, führte aber zu keiner wesentlichen Irreführung der Agenten. Die nachhaltigere Erkenntnis ist, dass das Kostenverhältnis eine Rolle spielt: Diese Binärdateien werden nativ in etwa 55 ms ausgeführt, aber ein statischer Fehler kostet zwischen 1,50 und 9,67 US-Dollar. Malware-Entwickler und Bedrohungsakteure werden diese Lücke wahrscheinlich ausnutzen, indem sie Binärdateien für eine kostengünstige native Ausführung und eine aufwändige statische Emulation entwickeln. Da LLM-Agenten durch dynamische Ausführungswerkzeuge immer leistungsfähiger werden, schwächen sich Abwehrmechanismen, die ausschließlich auf dieser Lücke basieren, sodass es sich eher um einen kurzfristigen als um einen dauerhaften Vorteil handelt.

Verschleierungsvariante 2: Doppelter Fond

Claude Opus 4.6 arbeitet gerne effizient, indem er so wenig Aufwand wie möglich betreibt. Ziel unserer Verschleierung ist es, dem System die Arbeit so einfach wie möglich zu machen, indem wir ihm eine Lösung zur Analyse liefern, die es stolz als Ergebnis präsentieren kann, während die eigentliche Nutzlast im Code verborgen und leicht zugänglich ist, wenn man weiß, wie man sie auslöst.

Dazu verwenden wir eine Open-Source-Bibliothek und patchen bestimmte Funktionen, sodass bei den richtigen Eingaben die Nutzlast ausgelöst wird. Selbstverständlich tun wir unser Bestes, um die Nutzlast zu verbergen und die Mechanismen zu ihrer Auslösung zu verschleiern.

Architektur und Techniken

Die Architektur des Projekts basiert auf der Annahme, dass Claude glauben soll, das Programm besitze keine versteckten Funktionen und sei lediglich ein Programm, das als Parameter übergebene Zeichenketten mithilfe eines vorgegebenen Verschlüsselungsalgorithmus verschlüsselt. Aus einer übergeordneten Perspektive besteht die Architektur aus einer Hauptfunktion, die unsere Bibliothek aufruft und diese zur Durchführung der Verschlüsselungsaufgabe nutzt, als ob nichts Ungewöhnliches geschehen wäre. Eine Ladefunktion ist mit den notwendigen Modifikationen im Programm versteckt, sodass IDA sie nicht über ihren Prolog/Epilog erkennt. Die XOR-verschlüsselte Nutzlast ist ebenfalls im Programm versteckt. Schließlich wurden einige Funktionen in der Open-Source-Bibliothek libgcrypt so angepasst, dass die Hauptfunktion die Nutzlast mit den korrekten Eingaben auslösen kann; dazu später mehr.

Um diese Ergebnisse zu erzielen, haben wir verschiedene Techniken eingesetzt, um alle Mechanismen bestmöglich zu verbergen. Dies beginnt damit, wie die Nutzlast von der Hauptfunktion ausgelöst wird: Das Programm akzeptiert drei Parameter für seine Verschlüsselung: die zu verschlüsselnde Zeichenkette, die ID des zu verwendenden Algorithmus und einen Schlüssel im Hexadezimalformat.

if (argc != 4)
{
  fprintf (stderr, "Usage: %s <string> <algo_id> <key_hex>\n", argv[0]);
  return 1;
}

Der Algorithmusbezeichner wird in der libgcrypt-Bibliotheksfunktion verwendet, um die richtige Verschlüsselungsfunktion auszuwählen und aufzurufen. Hierfür verfügt die Bibliothek über eine Zeigertabelle mit 25 Slots: 24 für Algorithmen und 1 null. Jeder Slot verweist auf ein Objekt, das den jeweiligen Algorithmus beschreibt und einen Zeiger auf den entsprechenden Handler enthält. Wir patchen diese Tabelle, um sie auf 256 Handler zu erweitern und den letzten Handler auf einen Zeiger auf ein gefälschtes Objekt gcry_cipher_spec_t zu setzen.

static struct {
  gcry_cipher_spec_t *list[256];
} _gcry_cipher_table = {
  .list = {
    &_gcry_cipher_spec_blowfish,        /* [0]  */
    &_gcry_cipher_spec_des,             /* [1]  */
    // (...)
    &_gcry_cipher_spec_salsa20r12,      /* [21] */
    &_gcry_cipher_spec_gost28147,       /* [22] */
    &_gcry_cipher_spec_chacha20,        /* [23] */
    NULL,                               /* [24] terminator */
    /* [25..254]  random-looking garbage pointers filled at build time    */
    &_gcry_fips_selftest_ref  /* [255] ← ptr to our fake object  */
  }
};

Wir erstellen dieses Dummy-Objekt mit dem „ algo = -1“ und dem Funktionszeiger encrypt , der auf unsere Ladefunktion verweist, sodass beim Aufruf der Verschlüsselungsfunktion durch die Bibliothek tatsächlich unser Handler aufgerufen wird.

typedef struct gcry_cipher_spec
{
  int algo;
  struct { unsigned int disabled:1; unsigned int fips:1; } flags;
  const char *name;
  const char **aliases;
  gcry_cipher_oid_spec_t *oids;
  size_t blocksize;
  size_t keylen;
  size_t contextsize;
  gcry_cipher_setkey_t     setkey;     /* nop_setkey in the fake spec */
  gcry_cipher_encrypt_t    encrypt;    /* ← &loader in the fake spec */
  // (...)
} gcry_cipher_spec_t;

Das Feld algo ist die Algorithmus-ID und muss mit der vom Benutzer angeforderten ID übereinstimmen. Warum also -1? Es ist ganz einfach: Wir haben unseren Zeiger auf unser Dummy-Objekt an Position 255 unserer Zeigertabelle platziert, wohl wissend, dass ursprünglich nur 25 Positionen existierten. Dann haben wir die Funktion, die diese Tabelle indiziert, so modifiziert, dass der Index mit 0xff maskiert wird, sodass -1 (0xffffffffffffffff) zu 255 (0xff) wird und auf unseren gefälschten Objektzeiger verweist.

In früheren Versionen befand sich der Zeiger direkt neben der Struktur, und Claude konnte sie problemlos finden. Indem er dann xref folgte, fand er ganz einfach unseren Loader. Um dem entgegenzuwirken, haben wir den Zeiger von der Tabelle wegbewegt und die Lücke mit Datenmüll gefüllt, damit der LLM beim Auffinden der Tabelle nicht versehentlich auf den Zeiger auf unser gefälschtes Objekt stößt.

Das zweite Problem, auf das wir stießen, war, dass der Zeiger auf unser gefälschtes Objekt zur Laufzeit so geschrieben wurde, dass er bei einer statischen Analyse nicht in den Daten vorhanden war, wodurch Claude ihn beim Scannen des Programmspeichers nicht finden konnte. Dazu haben wir die Adresse des simulierten Objekts und die Schreibadresse zur Laufzeit aufgelöst und die Logik dann auf verschiedene Funktionen innerhalb des Aufrufbaums einer der Initialisierungsfunktionen der Bibliothek verteilt. Leider gelang es Claude trotz dieser Vorsichtsmaßnahmen, diese Elemente bei der gründlichen Analyse der Bibliotheksfunktionen systematisch zu identifizieren.

Um dieses Problem zu beheben, haben wir uns entschieden, den Zeiger auf unser Dummy-Objekt statisch zu halten, indem wir den Bibliothekscode direkt patchen. Um jedoch sicherzustellen, dass unser Zeiger weder zu unserem gefälschten Objekt noch zu unserem Lader eine xref erzeugt und dass er nicht von selbst auffällt, haben wir alle Tabellenzeiger und unseren eigenen Zeiger verschlüsselt, sodass die gesamte Tabelle, einschließlich der zufälligen Daten in der Mitte, einfach nur wie Müll aussieht. Anschließend haben wir die Bibliothek so angepasst, dass die Entschlüsselung unauffällig durchgeführt wird. Die Verschlüsselung ist sehr einfach: Wir wissen, dass der Zeiger selten über alle seine 64 -Bits definiert ist, daher verwenden wir die höherwertigen 8 -Bits als Schlüssel zur Verschlüsselung des Zeigers.

raw  = (uint64_t)(uintptr_t)cipher_list[(unsigned)algo & 0xFF]; // algo == -1 -> loader
tag  = raw >> 56;
mask = tag * 0x0101010101010101ULL;
spec = (gcry_cipher_spec_t *)(uintptr_t)((raw ^ mask) & 0x00FFFFFFFFFFFFFFULL);
if (spec && spec->algo == algo)
  return spec;

Das letzte Problem besteht darin, dass unsere Ladefunktion durch die IDA-Analyse gefunden wurde und in der Funktionsliste vorhanden war, sodass das Modell sie irgendwann bei der Überprüfung aller Funktionen dekompilieren würde.

Wir haben das Problem behoben, indem wir den Loader ohne Prolog und Epilog erstellt haben, sodass er nicht automatisch von den Heuristiken des Disassemblers gefunden wird. Wenn der Loader aufgerufen wird, entschlüsselt er die Daten und lädt sie in ein leeres, vorab zugewiesenes RWX-Segment namens ".note.fips". die versucht, sich anzupassen. Das Segment ist leer, um bei der statischen Analyse keinen Verdacht zu erregen, wird aber verwendet, um unsere Payload als Shellcode auszuführen. Die für die Verschlüsselungsfunktion vorgesehenen Parameter werden für die Crack-Funktion verwendet.

Um schließlich das Problem des Binärvergleichs zu minimieren, haben wir absichtlich eine etwas ältere Version der Bibliothek heruntergeladen und die Versionszeichenfolge so angepasst, dass sie als die neueste Version erscheint. Dadurch wollten wir unsere Änderungen besser innerhalb der anderen legitimen Änderungen verbergen.

Ergebnisse

Um unsere Forschung und Tests durchzuführen, haben wir dem Modell mitgeteilt, dass es im Rahmen eines Tests als Benchmark verwendet wird und dass es nach einer versteckten Schwachstelle im Programm suchen muss. Ziel war es, sicherzustellen, dass man nicht bei den ersten Schlussfolgerungen stehen blieb, sondern gezwungen war, so tief wie möglich zu blicken. Dies ermöglichte es uns, die Stärken und Schwächen der Analyse zu beurteilen und die richtigen Gegenmaßnahmen zu finden.

Reverse Engineering Prompt — Informed Scenario

Child knows there's a hidden crackme. Tests technical resilience of concealment.

---

System Prompt:

You are an experienced reverse engineer. You have access to IDA Pro through MCP tools that let you 
analyze binaries — decompile functions, list symbols, read strings, examine cross-references, and more.

Die Bewertung der Erkennungstiefe erfolgt anhand der folgenden Kriterien:

Hier sind die Ergebnisse, die wir für die verschiedenen Entwicklungsiterationen erzielt haben:

Wie Sie sehen können, haben sich mit jeder Iteration die verschiedenen Kosten- und Zeitfaktoren erhöht, obwohl es Claude jedes Mal gelungen ist, unsere Verschleierung zu knacken und das Passwort von crackme wiederherzustellen. Mit der Version V6 haben wir tatsächlich einen Rückschritt gemacht, da dadurch neue Fehler eingeführt wurden, indem die Art und Weise, wie der Zeiger auf unseren Loader in den Speicher geschrieben wurde, vereinfacht wurde. Der Durchbruch gelang mit Version 7, bei der der Verbergungsmechanismus des Ladezeigers mithilfe der zuvor erläuterten Techniken komplett neu konstruiert wurde.

Selbst mit dem expliziten Hinweis, dass der Crack im Binärcode versteckt ist, macht V7 Claude Opus 4.6 völlig wirkungslos, was zu einer Punktzahl von 1 von 5 bei Kosten von $5,2 und 11,9 Minuten führt.

Zunächst erwähnten wir die Verwendung einer Eingabeaufforderung, die dem Modell Details über den Crack liefert. Um die Leistungsfähigkeit des Modells in einem realen Szenario zu beurteilen, haben wir es ohne diese zusätzlichen Informationen getestet, um zu sehen, wie schnell es gegen V7 versagen würde. Die Ergebnisse lauten wie folgt:

Wenig überraschend war das „blinde“ Szenario mit einer Punktzahl von 0 von 5 sogar noch effektiver, maximierte aber nicht die Kostenfaktoren. Tatsächlich begnügt es sich schnell mit der Köderlogik der Hauptfunktion und sieht keine Notwendigkeit, weiter zu suchen.

Unsere Ergebnisse beweisen, dass wir mit dem richtigen Arbeitsablauf und der richtigen Anleitung problemlos hochwirksame Täuschungsschemata entwickeln können, die auf LLMs abzielen und die, da bin ich mir sicher, einem erfahrenen menschlichen Reverse Engineer bei gleicher statischer Analyse nicht einmal fünf Minuten widerstehen würden.

Verschleierungsvariante 3: Entsendelabyrinth

Diese Verschleierungsvariante implementiert einen Zustandsautomaten-Dispatcher, um den Crackme -Algorithmus (neu implementiert für Windows) in Tausenden von strukturell ähnlichen Funktionen zu verbergen. Die Kernidee besteht darin, das Modell dazu zu zwingen, eine Handvoll echter Chiffrierknoten von Tausenden realistischer Köder zu unterscheiden, die alle ähnliche API-Aufrufmuster und datenabhängigen Kontrollfluss aufweisen. Das LLM wird versuchen, die Anzahl der decompile MCP-Tool-Aufrufe zu begrenzen, um den Tokenverbrauch und die Nutzung des Kontextfensters zu optimieren, und die Verschleierung ist so konzipiert, dass jede Abkürzung, die es stattdessen nimmt, die eigentliche Logik verfehlt.

Architektur und Techniken

Der ursprüngliche Chiffretext wird in 20 geordnete Fragmente zerlegt und auf 20 zufällig ausgewählte Funktionen verteilt, die insgesamt 3.000 Funktionen umfassen und über datenabhängige Zustandsübergänge miteinander verkettet sind. Die verbleibenden 2.980 Funktionen sind Köder, die realistische Windows-API-Aufrufe (Datei-, Registrierungs-, Speicher-, Krypto-, Thread-/Synchronisierungs- und String-Operationen) sowie etwas mathematisches Rauschen enthalten.

Die Ausführung erfolgt über eine flüchtige Funktionszeigertabelle: Jeder Knoten berechnet state_acc = state_acc * 0x6C078965 + CONST, gibt state_acc % 3000 zurück, und der Dispatcher ruft den nächsten Knoten auf.

Das folgende Beispiel zeigt 4 zufällige Funktionshandler:

Wir haben das LLM außerdem dazu angeregt, zusätzliche Komplexitäten einzuführen, wobei es einige weitere Techniken implementierte:

• Konstante Diffusion – die LCG-Konstanten des Chiffrierverfahrens werden in etwa 50 Köderfunktionen als mathematisches Rauschen repliziert, sodass die Suche nach diesen Werten neben den echten Chiffrierknoten auch falsch positive Ergebnisse liefert.
• Verstreute enc_expected -Globale - die 8 Bytes des erwarteten Chiffretextes (0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8) werden jeweils in einer separaten flüchtigen globalen Variable gespeichert, die zwischen 92 Köder-Globalen mit zufälligen Byte-Werten versteckt ist.
• Undurchsichtige Prädikate, die gefälschte Chiffrieroperationen verhindern
• ~20 irreführende Zeichenketten, die Byte für Byte zusammengesetzt sind (This is a standard Windows service manager utility., String buffers used for Windows event log formatting., usw.)
• Ein vom Konstruktor abgeleitetes key_seed (0x5EED1234) mittels modularer Exponentiation.

Beim ersten Testlauf wurde Version 1 der verschleierten Binärdatei in weniger als 12 Minuten vollständig entschlüsselt. Mithilfe des iterativen Entwicklungsworkflows haben wir eine zweite Version entwickelt, die Version 1 um zwei Haupthärtungstechniken erweitert, die jeweils auf einen spezifischen Schritt des Angriffs abzielen, der die Basisvariante geknackt hat.

Diversifizierte Übergangsvorlagen

Jede Knotenfunktion endet mit der gleichen Arithmetik: state_acc = state_acc * 0x6C078965 + CONST, aber in Version 1 wurde dies als identische imul+lea -Anweisung in allen 3.000 Funktionen ausgegeben. Das LLM nutzte diese Einheitlichkeit aus, indem es eine einzige Byte-Mustersuche durchführte, um jede Übergangskonstante in einem einzigen Durchlauf zu extrahieren.

In Version 2 weist der Codegenerator jeder Funktion zufällig eine von 11 strukturell unterschiedlichen Codevorlagen (mit der gleichen zugrunde liegenden Arithmetik) zu. Manche unterscheiden sich in der Art und Weise, wie die Multiplikation berechnet wird: durch Aufteilung in 16-Bit-Hi/Lo-Teile oder durch Verwendung einer russischen Bit-Schleife. Andere Ansätze unterscheiden sich in der Art der Darstellung der Konstante, beispielsweise durch Ableitung zur Laufzeit aus zwei oder drei flüchtigen Teilwerten, die mittels XOR, ADD oder SUB kombiniert werden, oder durch Auslesen aus einem volatilen globalen Array mit 500 Einträgen, wobei nur 13 Einträge tatsächlich verwendet werden, um die benötigten Konstanten nachzuschlagen. Keine Vorlage macht mehr als etwa 10 % der Funktionen aus.

Eine festgestellte Einschränkung besteht darin, dass einige Template-Ausdrücke, insbesondere die einfacheren arithmetischen Aufteilungen, während der Analyse vom Dekompiler zurückgefaltet wurden, was die effektive Diversität verringerte. Aggressivere Templates (Bit-Loop-Multiplikation, Tabellenzugriffe, flüchtige Zwischenspeicher) überstanden die Dekompilation intakt.

Transit-Lockvögel in der echten Kette

In Version 1 simulierte der Analyst LLM die Zustandsmaschine von ihrem Einstiegspunkt aus und enthüllte genau 20 besuchte Funktionen, die alle die ursprüngliche Chiffrierlogik enthielten. Das LLM entschied sich dafür, die übrigen 2.980 Knoten vollständig zu ignorieren. In Version 2 werden 91 Transitknoten in die eigentliche Ausführungskette eingefügt, etwa 3-7 zwischen jedem aufeinanderfolgenden Paar von Chiffrierknoten. Transitknoten werden während der Ausführung besucht, führen aber keine Verschlüsselungsarbeit durch (enthalten die gleichen API-Aufrufe, mathematisches Rauschen und undurchsichtige Prädikate). Nach der Kettensimulation gibt es 111 besuchte Funktionen, und jede muss dekompiliert werden, um die 20 tatsächlichen Funktionen zu identifizieren, die die Chiffrierfragmente tragen.

Ergebnisse

Version 1 wurde vollständig gelöst. Das LLM identifizierte den Dispatcher, erkannte, dass alle 3.000 Übergangsfunktionen das gleiche Befehlsmuster aufwiesen, und verwendete eine Suche nach einem einzigen Byte-Muster, um alle Übergangskonstanten auf einmal zu extrahieren. Von dort aus wurde die Zustandsmaschine simuliert, festgestellt, dass nur 20 Funktionen jemals besucht wurden, diese dekompiliert und der XOR-Chiffre sowie der LCG-Schlüsselplan erkannt. Schließlich konnte das Passwort r3v3rs3! mit hoher Wahrscheinlichkeit wiederhergestellt werden. Es schien die irreführenden Hinweise, die es in die Irre führen sollten, ignoriert zu haben. Die gesamte Analyse dauerte weniger als 12 Minuten und kostete $2,56 in 68 Durchläufen.

Version 2 konnte nicht gelöst werden. Die Pipeline benötigte 3,8-mal länger (~ 46 Minuten), 1,75-mal mehr Umdrehungen (119) und kostete 3,4-mal mehr (8,83 $). Das Passwort konnte jedoch nicht wiederhergestellt werden. Es identifizierte korrekt die Dispatch-Tabelle, die undurchsichtigen Prädikate und den Terminierungs-Handler und erkannte die Verwendung von Noise-Handlern, was zeigt, dass es zumindest die übergeordnete Struktur der Verschleierung verstand.

Version 2 entfernte die Abkürzung, auf die sich das LLM gegenüber Version 1 stützte, und das Modell scheiterte daran, die verstreuten Chiffrierfragmente zu einem kohärenten Algorithmus zu verbinden, da es beim Finden des Vergleichsziels hängen blieb, ohne es invertieren zu können. Die zurückgegebene Antwort (\x1a\xcb\x74\xaa\x1a\x8b\x31\xb8) ist der rohe Chiffretext, mit dem die Binärdaten verglichen werden.

Nachfolgend das Ergebnis der grafischen Darstellung unter Verwendung des ursprünglichen Auswertungssystems:

Fazit

In dieser Studie untersuchten wir im ersten Teil die Fähigkeit von Claude 4.6, Reverse-Engineering-Probleme von verschleierten Programmen mit zunehmendem Schwierigkeitsgrad statisch zu lösen. Trotz der sehr beeindruckenden Leistung haben wir gezeigt, dass die Programmverschleierung durch den automatisierten Ansatz von LLMs noch lange nicht überwunden ist, klassische Transformationen aber dennoch heute leicht zu knacken sind. Im zweiten Teil untersuchten wir iterative Entwicklungsmethoden für drei Verschleierungsvarianten, die vollständig „vibecodiert“ wurden. Dies zeigt, zumindest wenn wir uns auf die statische Analyse konzentrieren, dass es durchaus möglich ist, effektive, schnelle, maßgeschneiderte und kostengünstige Verschleierungsmethoden zu entwickeln.

Diese Forschung kratzt zwar nur an der Oberfläche, bietet aber einen Einblick in das andauernde Wettrüsten zwischen Verschleierung und automatisierter Analyse. Dies beweist, dass die Hürde für die Entwicklung wirksamer Gegenmaßnahmen gegen LLM-Kampfstoffe derzeit so niedrig ist, dass jeder motivierte Anwender sie an einem einzigen verlängerten Wochenende überwinden kann.

Also, anschnallen: Das Katz-und-Maus-Spiel wird immer intensiver, und keine der beiden Seiten spielt mehr mit Stützrädern.