Zwei Konsolen, zwei KVM-Boxen und ein Schalter für den Netzknopf
Am 18. Oktober 2026 veröffentlichte der Entwickler pepsipu ns2jb: den ersten reinen Software-Jailbreak für Nintendos aktuelle Switch 2-Firmware 23.0.1. Kein Gehäuseöffnen, kein Löten, keine Modchips – die gesamte Angriffskette vom Bootvorgang bis zur vollständigen Übernahme vollzieht sich ausschließlich auf der Softwareebene. Code, der in der Jailbreak-Umgebung ausgeführt wird, läuft mit Rechten von Systemmodulen: Er kann Homebrew-Anwendungen starten, Spielstände sichern, Games modifizieren und direkt auf die meisten Peripheriegeräte zugreifen.
Was die Sicherheits-Community jedoch wirklich aufhorchen ließ, war die Methode des Angriffs: Der gesamte Reverse-Engineering-Prozess wurde von OpenAIs Codex-Agenten gesteuert. Als physische „Hände“ diente eine automatisierte Schleife aus gewöhnlicher Consumer-Hardware.
Abbildung: Die automatisierte Testschleife – Switch 1 und Switch 2 nebeneinander, zwei JetKVM-Boxen für HDMI-Streaming und Gamepad-Eingaben sowie ein modifizierter Bluetooth-Kippschalter. Quelle: Blog von pepsipu
Beim Absturz drückt der Schalter den Power-Button
Dieser Versuchsaufbau verdient besondere Aufmerksamkeit, weil er bemerkenswert preiswert ist: eine Switch 1, eine Switch 2, zwei JetKVM-Einheiten – kompakte Netzwerkboxen, die HDMI-Videosignale streamen und USB-HID-Eingaben emulieren – und ein bei Amazon gekaufter, mechanisch modifizierter Bluetooth-Schalter.
Die Switch 2 besitzt eine Eigenheit, die Reverse-Engineers das Leben schwer macht: Stürzt das System ab oder gerät der Kernel in Panik, startet die Konsole nicht automatisch neu. Ein menschlicher Nutzer muss physisch den Einschaltknopf drücken. Bislang bedeutete dies, dass Forscher stundenlang neben der Konsole saßen: Test ausführen, Absturz abwarten, Knopf drücken, Neustart abwarten. Der modifizierte Bluetooth-Schalter wandelte diese Fleißarbeit in reine Kinematik um: Ein Hebel senkt sich ab, drückt den Einschaltknopf ein und schnellt durch das Restdrehmoment des Motors wieder in die Ausgangsposition zurück – ein unermüdlicher mechanischer Finger.
Damit schloss sich der Regelkreis: Codex analysierte die Videosignale, setzte Controller-Eingaben ab, testete Schwachstellen und aktivierte bei einem Systemabsturz den Schalter, um die Konsole neu zu starten und die Fuzzing-Tests fortzusetzen. Der Autor betitelte die Anordnung ursprünglich mit: „set a goal to jailbreak the switch 2. make no mistakes“. In den Kommentaren stellte er später klar, dass dies nur eine ironische Bildunterschrift war – in Wirklichkeit dauerte der Jailbreak-Prozess zwei Wochen harter, ununterbrochener Rechenzeit. Die Maschinen arbeiteten Tag und Nacht; der Mensch musste lediglich die Schleife konstruieren.
Die Browser-Route erwies sich als Sackgasse
Codex versuchte es zunächst über den naheliegendsten Angriffsvektor: das Laden einer bekannten WebKit-n-Day-Schwachstelle über ein manipuliertes Wi-Fi-Captive-Portal im integrierten Browser der Switch 2. Den Protokollen des Agenten zufolge gelang tatsächlich ein nativer Control-Flow-Hijack – der Befehlszähler (Program Counter) befand sich vollständig unter Kontrolle des Angreifers.
Allerdings hat Nintendo die Switch 2 mit modernen Sicherheitsmechanismen ausgestattet: XOM (Execute-Only Memory) verhindert das Lesen und Schreiben von Code-Segmenten, PAC (Pointer Authentication Codes) signiert Pointer kryptografisch, und CFI (Control Flow Integrity) schränkt indirekte Sprungziele streng ein. Obwohl der Kontrollfluss gekapert war, ließ sich daraus kein beliebiger Systemaufruf ableiten. Der Agent brach diesen Pfad schließlich ab.
Abbildung: Protokollauszug von Codex zur Übernahme des Kontrollflusses via WebKit n-Day, an dem der Angriff vorerst strandete. Quelle: Blog von pepsipu
Auf einer anderen Hardwarearchitektur hätte das Ergebnis anders aussehen können – doch das ist eine andere Geschichte.
Die Sicherheitslücke steckte in einem BASIC-Interpreter
Der eigentliche Durchbruch gelang über die Switch 1 im Versuchsaufbau. Die Switch 1 besitzt keinen PAC-Schutz, ihr Vertrauensanker (Root of Trust) wurde bereits vor Jahren von der Community geknackt, und Spiel-Binärdateien lassen sich entschlüsseln und offline analysieren. Codex wählte als Ziel SmileBASIC – ein kommerzielles Programm, mit dem Nutzer kleine Spiele in BASIC programmieren können.
Die Schwachstelle lag in der Routine zum Löschen von Array-Elementen: Das Programm prüfte, ob position + count die Array-Länge überschritt. Bei dieser vorzeichenbehafteten 32-Bit-Ganzzahl-Addition trat jedoch ein Integer-Überlauf auf, der in negative Zahlen umschlug und die Grenzprüfung aushebelte. Das anschließende Kopieren von Speicherdaten wurde mit (length - position) * 8 Bytes ausgeführt, was zu einer unzulässigen Out-of-Bounds-Speicherübertragung führte. Ein klassischer Integer-Overflow aus dem Lehrbuch, verborgen in einem seit Jahren verkauften kommerziellen Titel.
Da beide Konsolengenerationen fundamentale Architekturkomponenten teilen, reichte das Fundament auf der Switch 1 aus, um die nötigen Ausführungsrechte auf der Switch 2 freizuschalten.
Mario Kart modifizieren – reiner Spaß an der Freude
Die Demonstration nach dem geglückten Exploit war ausgesprochen unterhaltsam: Codex manipulierte den Switch 2-Exklusivtitel Mario Kart World und schleuste eine wilde Truppe von Community-Charakteren auf die Rennstrecke – Sanrios Cinnamoroll, Reze aus Chainsaw Man, Steve aus Minecraft, Walter White aus Breaking Bad und Hatsune Miku fuhren gemeinsam um den Sieg.
Abbildung: Die Siegerehrung in Mario Kart World nach der Modifikation: Walter White und Hatsune Miku auf derselben Rennstrecke. Quelle: Blog von pepsipu
Der Autor betonte ausdrücklich, dass die Modifikation von Mario Kart reines „Vibecoding“ war – an einem Nachmittag aus reiner Spielfreude zusammengehackt; der Jailbreak-Payload hingegen sei mit kompromissloser Präzision entwickelt worden. In den Diskussionsforen meldeten sich rasch Gleichgesinnte mit ähnlichen Setups: Ein Entwickler nutzte Capture-Karten und smarte Steckdosen, um Claude DOS-Spiele portieren zu lassen; ein anderer setzte zwei ESP-Mikrocontroller mit Servomotoren ein, um den Reset-Knopf von x86-Boards zu drücken. Das einhellige Fazit: Der größte Vorteil solcher Schleifen liegt in ihrer Parallelisierbarkeit und dem unterbrechungsfreien 24/7-Dauerbetrieb.
Der Flaschenhals war nie die Intelligenz
Zurück zu dem Bluetooth-Schalter, der unermüdlich den Netzknopf drückte: Das Hardware-Reverse-Engineering scheiterte in der Vergangenheit selten an der intellektuellen Kapazität, sondern an der zermürbenden Monotonie von „Ausführen, Absturz, Neustart, Wiederholen“. Sobald Kameras, Capture-Karten und Relais diese mechanischen Aufgaben übernehmen, verwandelt sich Reverse Engineering von einem personellen Engpass in ein Durchsatzproblem. Der Mensch konstruiert die Schleife, die Maschine wickelt die Wiederholungen ab – und verdichtet die monatelange Arbeit eines Forschers in zwei Wochen Laufzeit.
Nintendo wird nicht tatenlos zusehen. Der Autor spekuliert in einer Fußnote über die nächsten Schritte: Würde Nintendo entschlüsselten Spielcode ausschließlich im Kernel-Space verwalten, gäbe es im Userland keinerlei beschreibbare, ausführbare Speicherseiten mehr. Selbst der Loader müsste dann höher privilegierte Ringe um Code bitten – mit der Konsequenz, dass Spiele ihren eigenen Code zur Laufzeit nicht mehr lesen könnten. Nintendo baut dynamische Code-Features seit geraumer Zeit konsequent ab; dieser Schritt würde ins Bild passen.
Doch die Spielregeln der Auseinandersetzung haben sich verschoben. Bislang mussten Schutzmaßnahmen lediglich die Ausdauer menschlicher Forscher überdauern; heute wird diese Geduld an mechanische Relais ausgelagert. Wenn die nächste Version 23.0.1 erscheint, wird kein Mensch mehr den Einschaltknopf drücken.
Referenzen:
- Original-Blogbeitrag von pepsipu: ns2jb
- Hacker News Diskussion (item?id=50192536)
