KRAKEN, Teil 2: 100 Prozent Treffer, und genau das ist das Problem

In Teil 1 habe ich einen Käfig für KRAKEN gebaut, ein Werkzeug, mit dem KI fertige Programme zerlegt. Jetzt darf die KI ran. Die Frage: Findet sie in einem Programm ohne jede Beschriftung die richtigen Funktionen, und versteht sie, was sie tun?

Erst die Gratis-Modelle

Bei OpenRouter gibt es Modelle zum Nulltarif. Ich habe fünf ausprobiert. Keines kam zu einem Ergebnis.

Nemotron 3 Ultra hat Zahlen als Text übergeben, also "50" statt 50. KRAKEN hat das jedes Mal abgelehnt, nach elf Aufrufen war das Budget leer. Laguna S hat das Programm sofort richtig erkannt und sich dann beim Blättern durch die Funktionsliste verheddert. Flint hat in neun Aufrufen 243.000 Tokens verbraucht. Inkling gibt OpenRouter nur für bestimmte Apps frei, Gemma war überlastet.

KRAKEN hat sich dabei gut benommen: Es fragt vor jeder KI-Arbeit nach den Kosten, bricht sauber ab, wenn ein Limit erreicht ist, und kann jeden Lauf mit einem Befehl rückgängig machen.

Claude draußen, KRAKEN drinnen

Dann Claude, über mein normales Abo. Claude läuft auf dem Mac, nicht in der Testmaschine. Es bekommt keine Shell und keinen Zugriff auf Dateien, nur die Werkzeuge von KRAKEN: Funktionen auflisten, dekompilieren, Texte suchen, umbenennen, kommentieren. KRAKEN selbst bleibt im Käfig.

Die Aufgabe war für beide Programme gleich: Finde die eigenen Funktionen des Programms, gib ihnen Namen, sag, was sie tun. Welches Programm es ist, habe ich nicht verraten.

Test 1: 2048

Das Spiel 2048 als Open-Source-Version in C, 577 Zeilen. Ich habe es selbst übersetzt, alle Namen entfernt und die C-Bibliothek fest eingebaut, wie bei vielen echten Programmen. KRAKEN fand 1.111 Funktionen, 196 davon ohne Namen. Irgendwo darin stecken 19 Funktionen des Spiels.

Claude brauchte 78 Sekunden. Es fand alle 19. 17 Namen waren exakt die aus dem Quellcode: slideArray, rotateBoard, findPairDown. Einer war nur anders geschrieben, einer anders benannt, aber inhaltlich richtig. Nebenbei bemerkte Claude, dass der Compiler eine Funktion in eine andere hineinkopiert hat.

Test 2: das echte xxd

Dann eine Datei, die ich nicht selbst gebaut habe: xxd, das Hexdump-Werkzeug aus Vim, so wie Ubuntu es ausliefert. 22 Kilobyte, ohne Funktionsnamen. Ich habe die Datei über Ubuntus signierte Paketlisten geprüft, von der Signatur bis zur Prüfsumme. Als Lösung dient das offizielle Debug-Paket mit den echten Namen. Die KI hat es nie gesehen.

Claude brauchte 53 Sekunden. 10 von 10 Funktionen, alle mit exakt dem Originalnamen: xxdline, skip_to_eol, exit_with_usage, fclose_or_die. Dazu alle Optionen und die Exit-Codes. Und es nannte Funktionen, die der Compiler in main eingebaut hat, mit Adressbereich, obwohl diese Namen in der Datei nirgends stehen.

Warum mich das nicht beruhigt

Beide Programme enthalten einen Versionstext. Bei xxd steht der Autor drin. Claude hat ihn gefunden und dann selbst geschrieben: „Die Hilfsfunktionen entsprechen xxd.c.“ Es kennt den Quellcode von Vim. Er steckt in seinen Trainingsdaten, genau wie 2048, ein Projekt mit über 600 Sternen auf GitHub.

Die Namen kommen also zum Teil aus dem Gedächtnis. Die Datei bestätigt nur, was die KI schon weiß.

Ganz so einfach ist es aber auch nicht. Wo genau im Maschinencode welche Funktion liegt, welche Teile der Compiler zusammengeschoben hat, welche Option welchen Exit-Code auslöst: Das steht in keinem Quellcode. Das hat Claude aus der Datei gelesen.

Für Angreifer und Verteidiger heißt das dasselbe. Bekannte Software, und das ist fast alle Software, durchschaut eine KI in Sekunden. Was früher Tage dauerte, ist jetzt eine Minute.

Was das noch nicht beweist

Ob die KI ein Programm versteht, das sie nicht kennen kann, weiß ich noch nicht. Darum geht es in Teil 3: ein Programm, das erst nach dem Wissensstand des Modells entstanden ist. Dann zeigt sich, wie viel von den 100 Prozent Lesen war und wie viel Erinnern.

Zerlegt habe ich nur Open-Source-Programme. Ihre Lizenz erlaubt das, und wir haben den Quellcode zum Vergleich.