Dieser Artikel betrifft die Nintendo Wii

Trucha Bug: Unterschied zwischen den Versionen

Aus WiiDatabase Wiki
Zur Navigation springenZur Suche springen
(Die Seite wurde neu angelegt: „Der '''Trucha Bug''' (auch als '''Signing Bug''' oder '''strncmp Bug''' bekannt) war ein Fehler in früheren IOS auf der Nintendo Wii, welcher es erlaubte,…“)
 
(Absatz "IOS16" korrigiert)
 
(19 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 1: Zeile 1:
Der '''Trucha Bug''' (auch als '''Signing Bug''' oder '''strncmp Bug''' bekannt) war ein Fehler in früheren IOS 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 Februar 2008 mit dem [[Wii-Systemmenü 3.2]] im neuen [[IOS37]] behoben und dann im [[23. Oktober Update]] in allen IOS.
Der '''Trucha Bug''' (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 Februar 2008 mit dem [[Wii-Systemmenü 3.2]] im neuen [[IOS37]] behoben und dann im [[23. Oktober Update]] in allen IOS.


== Erklärung ==
== Erklärung ==
Zuerst entschlüsselt IOS bei der Installation eines Titels die Signatur und vergleicht die SHA1 des Payloads - der erste Fehler hierbei ist, dass der Payload-Hash ein binärer SHA1-Hash ist und kein ASCII-String und deshalb ein NULL-Byte ("\0") enthalten kann. Der weitaus größere Fehler ist, dass zum Vergleichen der Hashes die C-Funktion ''[http://www.cplusplus.com/reference/cstring/strncmp/ strncmp]'' benutzt wird, welche Strings vergleicht und beim ersten NULL-Byte stoppt:
Zuerst entschlüsselt IOS bei der Installation eines Titels die Signatur und vergleicht die SHA1 des Payloads mit dem SHA1-Hash in der Signatur - das erste Problem hierbei ist, dass der Payload-Hash ein binärer SHA1-Hash ist und kein ASCII-String und deshalb ein NULL-Byte (<code>\0</code>) enthalten kann. Das weitaus größere Problem ist jedoch, dass zum Vergleichen der Hashes die C-Funktion ''[http://www.cplusplus.com/reference/cstring/strncmp/ strncmp]'', statt ''[http://www.cplusplus.com/reference/cstring/memcmp/ memcmp]'' benutzt wird, welche Strings vergleicht und beim ersten NULL-Byte stoppt:


{{Zitat|Text=This function starts comparing the first character of each string. If they are equal to each other, it continues with the following pairs until the characters differ, '''until a terminating null-character is reached''', or until num characters match in both strings, whichever happens first.}}
{{Zitat|Text=This function starts comparing the first character of each string. If they are equal to each other, it continues with the following pairs until the characters differ, '''until a terminating null-character is reached''', or until num characters match in both strings, whichever happens first.}}


=== Fakesigning ===
=== 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'''. Hier kann einfach auf Bruteforcing zurückgegriffen werden: Einige Bytes der Daten werden geändert, bis der SHA-1-Hash mit 00 anfängt - die strncmp-Funktion bricht ab und die Signatur ist valide.
Das heißt, wenn strncmp auf ein NULL-Byte trifft, vergleicht es nicht mehr weiter, '''selbst wenn mehr Daten hinter dem NULL-Byte existieren'''. Hier kann einfach auf Bruteforcing zurückgegriffen werden: Einige Bytes der Daten werden geändert, bis der SHA-1-Hash mit <code>00</code> anfängt. Auch muss die Signatur genullt werden, da diese dann entschlüsselt null ergibt (da <code>0 hoch Public-Key-Exponent modulo Public-Key-Modulo</code> gleich <code>0</code> ergibt, eine Eigenschaft von RSA). Die strncmp-Funktion schließt das Vergleichen vorzeitig ab und die Signatur ist valide. Wenn dieser Fehler in boot1 ausgenutzt wird, lässt sich der boot2 modifizieren - der HackMii Installer nutzt dies, um [[BootMii]] dort zu installieren. Fakesigning erlaubt es letztendlich, unsignierte IOS und Systemmenüs zu installieren, sowieso unsignierte Spiele zu starten.


== IOS16 ==
== 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.
 
=== IOS16 ===
{{Hauptartikel|IOS16}}
{{Hauptartikel|IOS16}}
Das '''IOS16''' ('''0000000100000010''') war ursprünglich auf der [[Wii Backup Disc]] vorhanden und wurde von jemanden, in dessen Wii eine solche Disc vergessen 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.
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 [[Stub-IOS|gestubbt]] und somit der Trucha Bug endgültig in allen IOS behoben.
 
== Weblinks ==
* [https://wiibrew.org/wiki/Signing_bug Signing bug] auf WiiBrew
* [https://www.youtube.com/watch?v=ktc1XHvrN18&t=50s 25C3: Console Hacking 2008: Wii Fail - Part 4] von 0:50 bis 3:15


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, um Raubkopien abzuspielen.
{{Navbox IOS}}
{{Top Icon Wii}}


{{WiiTopicon}}
[[Kategorie:IOS]]
[[Kategorie:IOS]]
[[Kategorie:Nintendo Wii]]

Aktuelle Version vom 4. Mai 2021, 23:16 Uhr

Der Trucha Bug (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 Februar 2008 mit dem Wii-Systemmenü 3.2 im neuen IOS37 behoben und dann im 23. Oktober Update in allen IOS.

Erklärung

Zuerst entschlüsselt IOS bei der Installation eines Titels die Signatur und vergleicht die SHA1 des Payloads mit dem SHA1-Hash in der Signatur - das erste Problem hierbei ist, dass der Payload-Hash ein binärer SHA1-Hash ist und kein ASCII-String und deshalb ein NULL-Byte (\0) enthalten kann. Das weitaus größere Problem ist jedoch, dass zum Vergleichen der Hashes die C-Funktion strncmp, statt memcmp benutzt wird, welche Strings vergleicht und beim ersten NULL-Byte stoppt:

„This function starts comparing the first character of each string. If they are equal to each other, it continues with the following pairs until the characters differ, until a terminating null-character is reached, or until num characters match in both strings, whichever happens first.“

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. Hier kann einfach auf Bruteforcing zurückgegriffen werden: Einige Bytes der Daten werden geändert, bis der SHA-1-Hash mit 00 anfängt. Auch muss die Signatur genullt werden, da diese dann entschlüsselt null ergibt (da 0 hoch Public-Key-Exponent modulo Public-Key-Modulo gleich 0 ergibt, eine Eigenschaft von RSA). Die strncmp-Funktion schließt das Vergleichen vorzeitig ab und die Signatur ist valide. Wenn dieser Fehler in boot1 ausgenutzt wird, lässt sich der boot2 modifizieren - der HackMii Installer nutzt dies, um BootMii dort zu installieren. Fakesigning erlaubt es letztendlich, unsignierte IOS und Systemmenüs zu installieren, sowieso unsignierte Spiele zu starten.

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.

IOS16

→ Hauptartikel: 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.

Weblinks

Abgerufen von „https://wiki.wiidatabase.de/index.php?title=Trucha_Bug&oldid=9443“