KRAKEN, Teil 1: Erst die Sandbox, dann die KI

Ich bin auf ein Projekt auf GitHub gestoßen: KRAKEN. Ein Werkzeug zum Reverse Engineering, also zum Zerlegen fertiger Programme, wenn man den Quellcode nicht hat. Unter der Haube steckt der Decompiler von Ghidra, dem bekannten Werkzeug der NSA. KI-Agenten wie Claude Code können mitarbeiten. Das Ziel des Projekts: ein Programm Funktion für Funktion in Rust neu schreiben und jede Funktion gegen das Original prüfen.

Das wollte ich ausprobieren. Teil 1 handelt davon, wie man so etwas sicher zum Laufen bringt. Die KI kommt in Teil 2.

Warum ein Käfig

Wer Programme zerlegt, hat Dateien auf dem Rechner, denen er nicht traut. Dazu kommt ein Werkzeug, das acht Tage alt ist, zwei Sterne auf GitHub hat und sich selbst „Pre-Alpha“ nennt. Und eine KI, die Code schreibt und ausführt.

Bevor ich irgendetwas installiert habe, habe ich das Repository gelesen: keine Aufgaben, die beim Öffnen im Editor automatisch starten, keine Build-Skripte, die heimlich etwas herunterladen, keine versteckten Anweisungen an KI-Agenten in den Projektnotizen. Das Sicherheitskonzept ist durchdacht. Trotzdem gilt: Lesen ersetzt keine Abschottung.

Eine Kleinigkeit fiel dabei auf. Die Anleitung verspricht, dass Downloads per Signatur geprüft werden. Im Installationsskript steht aber, dass der Signaturschlüssel noch gar nicht erzeugt wurde. Geprüft wird nur eine Prüfsumme, die vom selben Server kommt wie der Download. Das schützt vor kaputten Dateien, nicht vor manipulierten.

Eine Maschine, die nichts darf

KRAKEN läuft bei mir in einer eigenen Linux-Maschine, einer virtuellen Maschine auf dem Mac mini. Die Software dafür heißt OrbStack. Sie bietet einen „isolierten“ Modus: kein Zugriff auf die Dateien des Macs, keine Mac-Befehle, kein Zugriff auf andere Maschinen.

Ich habe nachgemessen. Mac-Dateien: nicht sichtbar. Dienste auf dem Mac: nicht erreichbar. Mein privates VPN: erreichbar. Die isolierte Maschine kam über den Mac an Geräte in meinem VPN heran. Ein Dienst hat sie abgewiesen, weil er prüft, wer anfragt. Andere Dienste im VPN vertrauen jedem, der drin ist.

Deshalb kam eine eigene Firewall in die Maschine: nur Internet, keine privaten Netze, kein VPN. Danach habe ich dem Benutzer in der Maschine die Admin-Rechte genommen. Was dort läuft, kann die Firewall nicht abschalten. Ändern kann ich sie nur vom Mac aus.

Die Lehre: „Isoliert“ heißt bei jedem Werkzeug etwas anderes. Nachmessen, nicht glauben.

Der Apple-Chip und die Sandbox

Fertige Pakete von KRAKEN gibt es nur für Linux auf Intel- und AMD-Prozessoren. Der Mac mini hat einen Apple-Chip. Kein Problem, dachte ich: OrbStack kann Intel-Linux über Rosetta übersetzen.

Installiert, gestartet, abgebrochen. KRAKEN verlangt Landlock, eine Sandbox-Funktion des Linux-Kernels, die einem Programm verbietet, Dateien außerhalb eines Ordners anzufassen oder ins Netz zu gehen. Der Kernel hatte Landlock. Aber unter Rosetta kommt der Aufruf nicht an, der Kernel antwortet „gibt es nicht“.

Für die reine Analyse hätte ich die Sandbox abschalten können. Für das eigentlich Spannende nicht: Den Rust-Code, den eine KI schreibt, baut und startet KRAKEN nur in dieser Sandbox. Einen Schalter dafür gibt es bewusst nicht. Das finde ich richtig.

Also eine zweite Maschine, diesmal für den Apple-Chip, und KRAKEN aus dem Quellcode bauen. Dort meldet der Kernel Landlock in Version 10.

Drei Stolpersteine beim Bauen

Der stille Platzhalter. Der erste Build war nach 98 Sekunden fertig, ohne Fehler. Verdächtig schnell. Ohne die Quellen des Ghidra-Decompilers baut KRAKEN still einen Platzhalter, der nichts dekompiliert. Der Einrichtungsbefehl lädt nur einen Teil der Dateien, die Decompiler-Quellen braucht einen zweiten Befehl.

Die fehlende Bibliothek. Mit den echten Quellen brach der Build ab: Funktionen zum Entpacken fehlten beim Zusammenfügen des Programms. KRAKEN bringt die Bibliothek dafür mit, auf dem Apple-Chip landet sie aber in der falschen Reihenfolge. Getestet wird das Projekt bisher nur auf Intel und AMD. Ein zusätzlicher Verweis auf die System-Bibliothek löste es.

Der Emulator. Für Programme, die gemeinsame Bibliotheken des Systems nutzen, braucht KRAKEN eine Kopie dieser Bibliotheken für den Emulator. Programme, die alles selbst mitbringen, liefen sofort.

Der erste Blick

Mein Testfall: ein kleiner Taschenrechner aus den Übungsprogrammen des Projekts, optimiert kompiliert und ohne Funktionsnamen. So sieht ein Programm aus, von dem man nichts weiß.

KRAKEN fand 14 Funktionen. Die meisten heißen nur FUN_00101280 und ähnlich. Der Decompiler macht daraus lesbaren C-Code. Bei einer Funktion sieht man nach ein paar Zeilen, was sie tut: Leerzeichen überspringen, auf Klammern und Minus prüfen, Ziffern zu einer Zahl zusammensetzen. Das ist der Teil des Rechners, der Zahlen einliest. Ein zweites Übungsprogramm lief im Emulator und lieferte dieselbe Ausgabe wie im echten Betrieb.

Bis hierhin hat keine KI etwas getan. Das ist Teil 2: Kann ein Modell diese Funktionen richtig benennen und in Rust neu schreiben, so dass am Ende dasselbe herauskommt? Ich nehme dafür ein Open-Source-Programm, dessen Quellcode ich kenne. Dann lässt sich prüfen, wie nah die KI rankommt.

Zerlegt werden bei mir nur Programme, die ich analysieren darf. KRAKEN schreibt das selbst in die Anleitung, und das gilt nicht nur dort.