Trucha Bug
Der Trucha Bug (Aussprache: /ˈtɾut͡ʃa/ bzw. „Trutscha“, auch als Signing Bug oder strncmp Bug bekannt) war ein Fehler in früheren IOS, boot1 und boot2 auf der Nintendo Wii, welcher es erlaubte, die digitale Signatur von Software so zu fälschen, dass es so aussieht, als käme diese offiziell direkt von Nintendo. Der Bug wurde zum ersten Mal im März 2008 mit dem Wii-Systemmenü 3.2 rev3 im neuen IOS37 behoben und dann im 23. Oktober Update in allen IOS.
Entdeckung
Der Bug wurde vermutlich gleich drei Mal unabhängig entdeckt:
- Die ersten Entdecker waren Team Twiizers, welche ihren Fund jedoch bewusst nicht publizierten. Sie verwendeten ihn zunächst ausschließlich intern, um tieferen Systemzugang für weitere Forschung an der Wii zu erhalten. Später verwendeten sie den Bug auch, um die Installation der frühesten öffentlichen Versionen des Homebrew-Kanals zu ermöglichen. Spätestens am 28. Dezember 2007 hatten sie eine funktionierende Implementierung, welche sie auf dem 24c3 ohne nähere Erläuterungen zur Umsetzung oder Details zur Sicherheitslücke präsentierten[1].
- Ein weiterer Entdecker war xt5. Er verwendete die Entdeckung, um den Trucha Signer zu ermöglichen[2]. Dieses am 26. Februar 2008 veröffentlichte Tool erlaubte das Fakesignen modifizierter Wii-Spiele, sodass diese – Modchip vorausgesetzt – in Form einer gebrannten DVD gestartet werden konnten (bis zu diesem Zeitpunkt war mittels Modchip lediglich das Starten inhaltlich unveränderter Kopien offizieller Spiele möglich). Von diesem Tool leitet sich auch die Bezeichnung "Trucha-Bug" ab (im Original-Post wird diese Fake-Signatur als "Trucha-Signatur" bezeichnet).
- Zuletzt zu nennen ist noch das Unternehmen Datel, welches am 28. Februar 2008 den Freeloader veröffentlichte. Dabei handelt es sich um eine kommerzielle, ohne Modchip startfähige DVD, welche ein Tool enthält, das die softwareseitige Regionskontrolle der Wii-Konsole umgeht. Die physischen Schutzmaßnahmen der Wii hatte Datel bereits zuvor bei dem Datel SD Media Launcher für den GameCube ausgehebelt, weshalb kein Modchip nötig ist. Die kommerzielle Veröffentlichung eines auf dem Bug basierenden Tools erwies sich in der Homebrewszene als unpopulär, da die Befürchtung aufkam, dass Nintendo dadurch zu einem schnelleren Fix des Bugs angeregt würde[3]. Im Gegenzug ging eine Spende über 1000 US-Dollar von Datel bei WiiBrew ein. Tatsächlich erschien schon am 21. März 2008 mit IOS37 das erste IOS, in welchem der Bug behoben wurde.
Erklärung
Bei der Installation eines Titels prüft IOS die RSA-Signatur von TMD und Ticket. Dazu wird der Signaturblock mit dem öffentlichen Schlüssel entschlüsselt und der darin enthaltene SHA-1-Hash mit dem tatsächlich berechneten SHA-1-Hash der Daten verglichen. Genau in dieser Prüfung stecken zwei Fehler.
Eine korrekte RSA-Signaturprüfung nach PKCS#1 v1.5 müsste den entschlüsselten Block auf seine vorgeschriebene Struktur prüfen (00 01 FF FF ... FF 00, gefolgt von der DigestInfo mit dem Hash). IOS überspringt dies komplett und liest einfach die letzten 20 Byte des Blocks als Hash aus. Dadurch kommt auch bspw. ein komplett genullter Block bis zum eigentlichen Hash-Vergleich durch.
Der weitaus größere Fehler ist, dass zum Vergleichen die C-Funktion strncmp statt memcmp verwendet wird. strncmp ist für nullterminierte Strings gedacht und stoppt beim ersten NULL-Byte (\0), da dieses in einem String das Ende markiert:
„Characters following the null character are not compared.“
Ein SHA-1-Hash ist aber kein String, sondern 20 Byte Binärdaten und darf an jeder beliebigen Stelle ein NULL-Byte enthalten. Trifft strncmp also gleich am ersten Byte auf 00, gibt die Funktion 0 (= "identisch") zurück, ohne die restlichen 19 Byte überhaupt anzusehen.
Fakesigning
Das heißt, wenn strncmp auf ein NULL-Byte trifft, vergleicht es nicht mehr weiter, selbst wenn mehr Daten hinter dem NULL-Byte existieren. Hieraus ergibt sich ein simpler Angriff:
Zuerst wird der komplette Signaturblock mit 00 gefüllt. Da 0 hoch Public-Key-Exponent modulo Public-Key-Modulus wieder 0 ergibt (eine Eigenschaft von RSA), ist auch der entschlüsselte Block komplett null und damit der "erwartete" Hash ebenfalls 00 00 00 .... Anschließend wird ein ungenutztes Padding- bzw. Reserved-Feld in TMD oder Ticket so lange abgeändert, bis der SHA-1-Hash der Struktur mit 00 beginnt.
Da nun beide Hashes mit einem NULL-Byte beginnen, bricht strncmp sofort ab und meldet Gleichheit => Die Signatur gilt als valide.
Dies erlaubt es letztendlich, unsignierte IOS und Systemmenüs zu installieren, sowie unsignierte Spiele zu starten. Da auch frühe boot1-Versionen diesen Fehler enthalten, lässt sich auf betroffenen Konsolen der boot2 modifizieren - der HackMii Installer nutzt dies, um BootMii dort zu installieren.
Fix
Zum ersten Mal wurde der Bug im IOS37 behoben, welches mit dem Wii-Systemmenü 3.2 veröffentlicht wurde. Später wurde der Trucha Bug in allen IOS im 23. Oktober 2008 Update behoben - außer im IOS16. Ein aktualisierter boot1 wurde mit neueren Wiis ab Ende 2008 veröffentlicht.
Der "Gigaleak" vom Mai 2020 zeigt, dass der Trucha Bug ("RSA signature verification bug"/"RSA padding exploit") zuerst am 16. Januar 2008 im Source-Code behoben wurde.[4] Die vollständige Überprüfung der Signatur nach PKCS#1 v1.5 erfolgte am 14. Februar 2008. Im Juni 2008 wurden beide Fixes auf die Release-Branches gemerged.
IOS16
Das IOS16 (0000000100000010) wurde ursprünglich von der Wii Backup Disc installiert und benutzt. Es wurde von jemandem, auf dessen Wii eine solche Disc benutzt wurde, unerlaubt veröffentlicht. Als Nintendo den Trucha Bug in jedem IOS gefixt hat, haben sie nicht daran gedacht, den Trucha Bug auch im IOS16 zu beheben, da dieses ja nie veröffentlicht werden sollte.
Nach diesem Update war das IOS16 das letzte IOS mit dem Trucha Bug und wurde unerlaubt genutzt, um andere IOS und das Systemmenü auf eine Version ohne den gefixten Trucha Bug zu downgraden, hauptsächlich um Raubkopien abzuspielen. Mit dem Wii-Systemmenü 4.0 wurde das IOS16 gestubbt und somit der Trucha Bug endgültig in allen IOS behoben.
Trivia
- Der Gigaleak von 2020 zeigt, dass der Trucha Bug fast nicht existiert hätte: Im Februar 2005 wurde die Prüfung korrekt mit memcmp durchgeführt, bis sie der gleiche Mitarbeiter einen Monat später fälschlicherweise durch strncmp ersetzte. Hierbei wurde die memcmp-Zeile lediglich auskommentiert und das falsche strncmp darunter gesetzt. Das auskommentierte memcmp wurde später gelöscht, als der Code in eine andere Datei überführt wurde.
- BroadOn hat intern selbst ein Tool zum Testen geschrieben, das eine TMD fakesignen kann. Dabei haben sie aber einige Anläufe benötigt, bis der Ansatz mit der der Homebrew-Szene übereinstimmte.
Weblinks
- Signing bug auf WiiBrew
Einzelnachweise
- ↑ Why Silicon-Based Security is still that hard: Deconstructing Xbox 360 Security (Console Hacking 2007 auf dem CCC)
- ↑ Trucha Signer released auf Ingenieria Inversa vom 26. Februar 2008 (Original nicht mehr verfügbar)
- ↑ Thank you, Datel., veröffentlicht am 24. März 2008
- ↑ Leak bei BroadOn: Source-Code für IOS, Datasheets, interne Dokumente und mehr veröffentlicht, veröffentlicht am 04. Mai 2020