Auf der 33C3 2016 haben derrek, naehrwert und nedwill ihre Fortschritte beim Exploiten der Wii U gezeigt. Besonderer Fokus wurde dort auf den boot1 gelegt, dem Bootloader der Wii U. Ein potenzieller Fehler wurde gefunden, allerdings wurde er nie in der Praxis ausgenutzt – der berüchtigte Satz "After all, it’s just the Wii U" fiel und das Team beschäftigte sich später mit der Switch.

Nun hat Hexkyz Details von derrek erhalten und mit diesen ist ihm die Code-Ausführung im boot1 gelungen. Allerdings ist das Ganze nicht so nützlich, wie man sich anfangs erhofft hatte.

Der Fehler selbst ist relativ simpel: Vereinfacht gesagt wird eine PRSH-/PRST-Struktur von IOS-MCP (einem IOSU-Prozess) erstellt, welche Speicherregionen (darunter eine "boot_info"-Sektion) beschreibt. Vor einem Neustart der Konsole wird diese Struktur mit dem Ancast-Key verschlüsselt und der RAM nicht geleert – boot1 parst dann diese Struktur, um den Pointer zur boot_info-Sektion zu finden. Dieser Pointer wird nicht validiert, was heißt, dass er geändert werden kann.

Der Prozess läuft also folgendermaßen ab:

1. PRSH-/PRST-Struktur (welche von IOS-MCP im RAM erstellt (Kaltstart) bzw. verschlüsselt (Warmstart) wird und Speicherregionen beschreibt) wird vom boot1 entschlüsselt
2. boot1 sucht die "boot_info"-Sektion darin
   1. Wenn diese nicht vorhanden ist, wird eine neue Sektion erstellt und in die Struktur eingefügt, aber der Pointer wird auf eine sichere Adresse hardcodiert
   2. Wenn diese existiert, dann wird der Pointer aus der Struktur genommen und von der übergeben Adresse gelesen – es wird nicht geprüft, ob der Pointer zu einer sicheren Adresse zeigt, die auch wirklich die boot_infos beherbergt!

Die Attacke sieht also wie folgt aus:

1. Die PRSH-/PRST-Struktur im Speicher mit einem geänderten boot_info-Pointer erstellen/modifizieren
2. Diese Struktur mit dem Ancast-Key und dem boot_info-Initialisierungsvektor, der sich an der Adresse 0x050677C0 im IOS-MCP befindet, verschlüsseln
3. Konsole neu starten

Durch geschicktes Ausnutzen dieses Bugs ist Hexkyz die Code-Ausführung im boot1 gelungen. Da das Ganze so früh passiert, lassen sich auch zwei mysteriöse OTP-Blöcke dumpen, die allerdings nicht benutzt werden. Eine Option zum Dumpen des boot1 hat er in seine HexFW CFW integriert, was allerdings nur für Entwickler interessant ist.

Doch wo ist der Haken? Wie oben schon geschrieben, funktioniert das Ganze nur bei einem Neustart, also einem sogenannten Warmboot. Wir sind aber an einem ersten Start, also an einem Coldboot interessiert – das ist mit dieser Attacke allein leider nicht möglich, was ein enormer Nachteil gegenüber bspw. Coldboot Haxchi ist.

Hexkyz spekuliert aber, ob es möglich wäre, eine quasi-permanente CFW laufen zu lassen, indem mithilfe von contenthax (das, was haxchi nutzt) der vWii-Loader modifiziert wird, was dann einen Payload laufen lassen würde, der den obigen Bug ausnutzt, die Konsole in eine CFW neu startet und den vWii-Loader wiederherstellt. Demzufolge also:

1. Konsole anschalten
2. "B" gedrückt halten, um den Wii-Modus aufzurufen
3. Dieser lädt jetzt einen Payload, der eine modifizierte PRSH-/PRST-Struktur erstellt, verschlüsselt und die Konsole neu startet
4. Voilà! CFW!

Doch wie ihr schon sehen könnt, würde sich der Bootprozess dadurch verzögern, da die Wii U bekanntermaßen nicht die schnellste ist und eben ein Reboot durchgeführt werden muss. Möglicherweise dauert dies sogar länger, als bei Coldboot Haxchi.

Hexkyz will sich aber später noch einmal mit der ganzen Sache beschäftigen und durch die neuen Infos kann er hoffentlich auch weitere Entwickler anziehen. Das Ganze wurde so lange geheimgehalten, da Nintendo es sehr leicht patchen kann – da die Wii U aber End-of-Life ist, ist jetzt der perfekte Zeitpunkt für die Veröffentlichung gewesen.

Das hier war nur ein kurzer Überblick, soweit ich es zusammenfassen und erklären konnte. Wer sich für die ganzen technischen Details interessiert, sollte am besten selbst einen Blick in Hexkyz' Blog werfen.