Angepinnt Signaturen und Zertifikate der Wii ... und mögliche Angriffspunkte

      Signaturen und Zertifikate der Wii ... und mögliche Angriffspunkte

      Signaturen und Zertifikate der Wii
      ... und mögliche Angriffspunkte


      Einleitung

      Mit diesem Artikel erkläre ich, wie sich die Wii vor unerwünschten Programmen schützt und welche Schwachpunkte dieser Schutz hat. Ausgangspunkt meiner Überlegungen ist die jüngste Erweiterung meines WIT-Tools, dass die Wii-typischen Zertifikate erkennen, analysieren und verwalten kann.

      Wie ist die Wii abgesichert?

      Alle Discs (Spiele) und alle WAD-Dateien verwenden im Prinzip denselben Schutzmechanismus: Es werden SHA1-Prüfsummern gebildet, die dann mit Hilfe von asymmetrischen RSA-Schlüsseln signiert werden. Dieses geschieht im mehreren Ebenen. Im Detail:

      1. Über den Inhalt von Disc-Partitionen und WAD-Dateien werden SHA1-Prüfsummen gebildet. Dabei ist es unerheblich, dass bei einer Disc ein 5 stufiges Verfahren (H0 bis H4) verwendet wird. Diese SHA1-Prüfsummen werden dann im Datenbereich der TMD abgelegt.

      2. Über den Datenbereich der TMD wird eine neues SHA1-Prüfsumme gebildet. Nintendo hat sich das RSA-Zertifikat CP00000004 (RSA-2048, im folgenden nur noch kurz CP genannt) erzeugt und mit dem privaten Schlüssel aus der TMD-SHA1 eine Signatur berechnet. Diese berechnete Signatur ist dann im Signatur-Bereich der TMD gespeichert.

        Beim Überprüfen durch die Wii wird die Signatur mittels des öffentlichen Schlüssel (public key), der im übergeordneten Zertifikat liegt, entschlüsselt und das Ergebnis mit der SHA1-Prüfsumme des Datenbereiches verglichen. Sind sie unterschiedlich, dann ist das Programm nicht zulässig.

      3. Das TICKET wird auf die gleiche Art überprüft. Dazu wird das Zertifikat mit der Kennung XS00000003 (RSA-2048, kurz XS) verwendet.

      4. Und nun beginnt die Verkettung: Die Gültigkeit der beiden Zertifikate CP00000004 und XS00000003 wird durch ein weiteres Zertifikat, CA00000001 (RSA-2048, kurz CA), gesichert.

      5. Diese letzte Zertifikat (CA00000001) wird dann durch den öffentlichen Schlüssel 'Root' (RSA-4096) abgesichert. Dieser Root-Schlüssel ist fest in den IOS verdrahtet.


      Damit haben wird die folgende Schlüsselhierarchie:

      Quellcode

      1. __________Root__________ (public key)
      2. _______CA00000001_______ (certificate)
      3. CP00000004 XS00000003 (certificate)
      4. ___TMD____ __TICKET__ (signature)
      5. _Disc/WAD_ (data -> sha1)


      Durch die Veränderung auch nur eines einzigen Bytes wird die Gültgkeit dieser Ketten durchbrochen. Ungültige Programm werden nicht ausgeführt.


      Was ist Trucha Sign (auch Fake Sign genannt)?

      Nintendo hatte anfangs einen gravierenden Programmierfehler in allen IOS: Anstatt mittels memcmp(sha1,decrypt,20) alle 20 Bytes auf Identität zu prüfen, hat Nintendo die Funktion strncmp(sha1,decrypt,20) verwendent. Diese Zeichenkettenfunktion überprüft auch die ersten 20 Bytes, bricht aber bereits mit Erfolg ab, wenn das Ende beider Zeichenketten erreicht ist. Und Zeichenketten enden auf den Wert 0.

      Füllt man nun das Signaturfeld mit lauter Nullen, dann erhält man nach dem Entschlüsseln als Kontrollwert 20 Null Bytes. Mit memcmp() müsste man nun eine SHA1-Prüfsumme haben, die ebenfalls 20 Nullen enthält. Durch die Verwendung von strncmp() reicht es aber, wenn die SHA1-Prüfsumme im ersten Byte den Wert Null hat. Dieses kann man durch einfaches Probieren mit verschiedenen Werten (Erwartungsgemäß 128 Versuche) im nicht benutzen Füllbereich der Daten schnell schaffen. Und genau dieses ist fake signing. Damit hat man dann die Wii überlistet.

      Nintendo hat diesen Fehler bereits korrigiert, jedoch werden im Homebrew-Bereich die IOS gepatched, so dass sie den Trucha-Bug wieder drin haben. Und alle Homebrew-Erweiterungen werden dann fake signed.


      Schwachstellen und Angriffspunkte

      Ich habe erst gestern in einem Versuch TICKET, TMD und alle beteidigten Zertifikate modifiziert und fake signed: Die Wii akzeptiert es. Das bedeutet, dass man wirklich alle Stufen als potentielles Angriffsziel sehen kann. Um einen dauerhafte erfolgreiche Aushebwlung dieses Mechanismuses zu erreichen, sehe ich 2 Angriffsmöglichkeiten.

      Ziel eines Angriffesn kann entweder das Zertifikat CA00000001 oder aber die beiden Zertifikate CP00000004 und XS00000003 sein. Im ersten Fall braucht man nur ein Zertifikat knacken und muss dann die anderen beiden durch eigene ersetzen. Mit den eigenen Zertifikaten kann man dann alles drunterliegende problemlos signieren und sich selbst auch neue Zertifikate ausstellen, weil man ja die privaten Schlüssel hält.

      1.) RSA-Angriff
      Durch einen vereinten Brute-Force Angriff versuchen wir, den private Schlüssel eines der Zertifikates zu errechnen. Dieses ist ein erhbelicher Aufwand, den ich als Verschlüsselungslaie nicht richtig abschätzen kann. RSA gilt aber shcon seit Jahren als relativ unsicher.

      2.) SHA-Angriff
      Wir generieren uns ein eigenes RSA-Schlüssel-Paar (privater + öffentlicher Schlüssel). Aus den Schlüssel-Daten erzeugen wir ein neues Zertifikat. Danach muss man in der Art von Fake-Sign durch Verändern nicht benötigter Datenbereiche versuchen, dass die SHA1-Prüfsumme dann der gewünschten entspricht. Im Prinzip gibt e 2^160 Möglichkeiten, der Angriff soll gemäß Literatur jedoch mit einem Aufwand von 2^69 machbar sein.


      Schlussfolgerungen

      Diese Zertifikatkette zeigt sich als Schwachpunkt, weil man nur ein Mittelglied austauschen muss, um dauerhaft in die Wii einzubrechen. Ich sage nicht, dass der Brute-Force-Angriff einfach oder schnell ist, aber mit vereinten Kräften und Rechenleistung ist es bestimmt möglich. Nicht umsonst gelten RSA und SHA1 als veraltet.

      Mir persönlich fehlen die Erfahrungen im Umgang mit Schlüsseln und Zertifikaten. Und dennoch wollte ich meine neues Wissen hier aufzeigen und zum Weiterdenken und Weiterentwickeln anregen.

      WIT: Wiimms ISO Tools
      Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

      SZS: Wiimms SZS Tools
      Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.



      PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Wiimm () aus folgendem Grund: Kleine Korrekturen ohne Sinnentstellung

      RSA gilt keineswegs als unsicher. Als unsicher gelten nur früher auf Debian-Systemen erzeugte Schlüssel, da dort der Schlüsselgenerator einen Bug hatte, und zu kurze Schlüssel. Als berechenbar gilt aktuell ein 768bit-Schlüssel. Bis 2048-bit lange Schlüssel geknackt werden, werden noch mindestens 10, vermutlich aber deutlich mehr Jahre vergehen - bis dahin dürfte Nintendo eh kein kommerzielles Interesse mehr an der Wii haben. Der Aufwand für Brute Force ist dabei vermutlich sogar höher als zum Berechnen des Schlüsseln, denn ver- und entschlüsseln ist mit RSA ziemlich komplex, weshalb man es überhaupt erst mit SHA kombiniert.

      Die Idee, den öffentlichen RSA-Schlüssel zu ersetzen, scheint erstmal gut, hat aber einen gravierenden Nachteil. Man könnte keine Original-Disks oder Shop-Downloads mehr spielen, und jedes Update würde die Wii unweigerlich bricken. Das wäre daher höchstens eine Lösung, wenn man einen kompletten Ersatz fürs Systemmenü hätte, so dass mit Ausnahme von boot1/boot2 überhaupt keine Prüfung mehr stattfindet.

      etox schrieb:


      Die Idee, den öffentlichen RSA-Schlüssel zu ersetzen, scheint erstmal gut, hat aber einen gravierenden Nachteil. Man könnte keine Original-Disks oder Shop-Downloads mehr spielen, und jedes Update würde die Wii unweigerlich bricken. Das wäre daher höchstens eine Lösung, wenn man einen kompletten Ersatz fürs Systemmenü hätte, so dass mit Ausnahme von boot1/boot2 überhaupt keine Prüfung mehr stattfindet.
      Warum? Jede WAD und jedes Spiel bringt doch seine eigene Zertifikatkette mit. Und wenn ich einmal ein Mittelzertifikat gefunden habe, welches sich gegen Root ausweisen kann, dann kann ich jedes eigene Tool ordnungsgemäß signieren, egal ob WAD oder Disc. Daher wird eine Wii auch nicht bricken, wenn man was andere läd. Und eine zertifizierte WAD-Datei ist dann der Dosenöffner.

      Das mit RSA mag stimmen, ich habe nur das hier gelesen: de.wikipedia.org/wiki/RSA-Kryp…odifizierte_RSA-Verfahren

      WIT: Wiimms ISO Tools
      Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

      SZS: Wiimms SZS Tools
      Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.



      PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.
      Verstehe ich es richtig?

      Du willst beim sha1 Angriff ein eigenes Schlüsselpaar generieren und den public key in CA00000001 einbinden. Danach erfolgt ein SHA1 mit vereinter Rechenleistung. Hat das geklappt, dann können wir die beiden anderen Zertifikate ersetzen und damit jedes ticket und jede tmd gültig signieren. Und dann kann man signierte Spiele und Wads erzeugen, um dann alles mögliche ausführen zu können?

      Noch ne Frage: Die Wii selbst kennt nur den Root-Schlüssel, alles andere bringen die Programme selbst mit? Dann frage ich mich, welche Vorteile die Zertifikat-Kette bringen soll, außer das die Angriffsfläche vergrößert wird.

      P.S.:
      Sobald es ein Tool gibt lasse ich gerne meine PC oder auch die Wii durchlaufen.
      Ein Mensch, der gerne spielt.

      Wii Freund schrieb:

      Verstehe ich es richtig?

      Du willst beim sha1 Angriff ein eigenes Schlüsselpaar generieren und den public key in CA00000001 einbinden. Danach erfolgt ein SHA1 mit vereinter Rechenleistung. Hat das geklappt, dann können wir die beiden anderen Zertifikate ersetzen und damit jedes ticket und jede tmd gültig signieren. Und dann kann man signierte Spiele und Wads erzeugen, um dann alles mögliche ausführen zu können?
      So ähnlich habe ich es mir vorgestellt. Das schöne ist, dass es nicht in andere bestehende WADs und Discs eingreift, da diese ihre eigenen Zertifikatkette mitbringen.

      Wii Freund schrieb:

      Noch ne Frage: Die Wii selbst kennt nur den Root-Schlüssel, alles andere bringen die Programme selbst mit? Dann frage ich mich, welche Vorteile die Zertifikat-Kette bringen soll, außer das die Angriffsfläche vergrößert wird.
      Nur der Root-Schlüssel ist fest in den IOS verdrahtet, alles andere kommt von den zu verwendeten Programmen (WADs und Discs).

      Wii Freund schrieb:

      Sobald es ein Tool gibt lasse ich gerne meine PC oder auch die Wii durchlaufen.
      Warten wir mal ab, ob sich was ergibt.

      WIT: Wiimms ISO Tools
      Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

      SZS: Wiimms SZS Tools
      Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.



      PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.
      Eine kleine Synology DiskStation, hat zwar nicht viel Leistung, kann dafür aber 24/7 laufen. Wenn ich damit helfen kann stelle ich gerne ein bisschen Rechenzeit zur Verfügung ;)
      nice..
      Wäre es nicht so besser:
      Einfach ein neues Zerfikat erstellen, dass wie das alte "aussieht" und die Wii akzeptiert?

      Edit: Hab grad gefunden, dass es eine Datei Root Certificate.cer gibt, was ist das jetzt für eine Datei in deiner Liste? PS: Ja die Datei ist von der WII^^

      Xiider schrieb:

      nice..
      Wäre es nicht so besser:
      Einfach ein neues Zerfikat erstellen, dass wie das alte "aussieht" und die Wii akzeptiert?
      Genau das meine ich ja. Und damit sie so aussieht, muss die SHA1 Prüfsumme stimmen. Und dafür wäre ein SHA1-Brute-Force notwendig.

      WIT: Wiimms ISO Tools
      Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

      SZS: Wiimms SZS Tools
      Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.



      PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.
      Ich hoffe das, dass jetzt nicht böse kommt, wenn ich hier reinschreibe, aber dieser Thread ist unglaublich interressant für mich. Nicht das ich wieder wegen Totenruhestörung was auf en deckel bekomme. :P

      Ich habe mich jetzt auch ziemlich mit dem Thema befasst da es mir auf den Keks geht das ich kein Bootmii@boot2 installieren kann. Was an dem selben Problem liegt, da im NAND Boot1 und Boot2 vereint sind und eben es nur durch einen Bug möglich war den Block des Boot2 mit der Bootmii WAD zu überschreiben.

      Bitte Wiimm korrigiere mich wenn ich was falsch verstanden haben sollte.

      Wir haben bei der Kryptography Engine der Wii insgesammt 2 Keys einen Private und einen Public Key. Der Public müsste soweit ich das verstanden habe seitens Twiizer Attack bekannt sein. Die Keys bestehen aus Primzahlen deren Summe einer Berechnung die ja auch auf Wiki vorliegt einen Signatur Schlüssel ergeben der dann eben den Content zertifizert. Der Public Key liegt im Boot1 vor und kann wenn ich es richtig verstanden habe bereits ausgelesen werden, dennoch kann Content mit falscher Signatur ohne den Private Key nicht ausgeführt werden, da ja nur beide Keys erst die endgültige Zertifizierung ergeben. Was ja dann auch das Fake Signing erklären würde.

      Wenn ich das jetzt auf Wiki richtig verstanden habe ist es nur möglich anhand von korrekt zertifiziertem Content und dem Public Key den Private Key zu errechnen. Auslesen wird nicht gehen, soweit ich das richtig verstanden habe liegt der embedded im inneren der Hollywood GPU als Starlet Coprocessor vor und wird von der Konsole immer akzeptiert und auch nicht überprüft da dieser unmöglich ist zu ändern da hier ein ROM verfahren vorliegt und ich denke auch das niemand ein kompletten Befehlsplan des Chips zur Hand hat.

      Bruteforcen wird nicht gehen, ich kann dir da aus Erfahrung sagen das, dass unter Umständen mehrere Jahrezehnte dauern kann selbst wenn du 100+ Leute zusammen bekommst die da mithelfen, wird auch der Grund sein warum sich Nintendo für diesen Mechanismus entschieden hat.

      Wenn meine Theorie die ich eben schon oben angesprochen habe stimmt, fällt die Methode der SHA-1 Attacke schon mal komplett weg. Desweiteren ist der Private Key im Boot0 als IPL geschaltet. Heißt der wird schon direkt beim starten benutzt wodurch hier noch nicht einmal ein Bypassing möglich wäre. Da sich die Konsole hier noch in einem Initilisierungsprozess befindet.


      Ich will mich der Sache gerne annehmen, aber meine Zeit ist ein wenig eingeschränkt und brauche daher noch ein paar Helle Köpfe, weil mehr Gehirne haben mehr Windungen.
      Das wesentliche: Durch die Verkettung reduziert sich der Angriff auf einen SHA-1 Angriff, der wesentlich unaufwendiger als ein RSA-Angriff ist.

      Beispiel:
      1. Man ersetzt das Zertifikat CA00000001 durch ein eigene. So habe man den privaten und öffentlichen Schlüssel.
      2. Dieses Zertifikat modifiziert man im Füllbereich solange, bis man die notwendige SHA-1 Prüfsumme hat. Und genau dieser Teil ist der Angriffspunkt, den man einmalig ausführt.
      3. Hat man vorheriges geschafft, dann kann man alles drunterliegende mit dem eigenen privaten Schlüssel signieren.

      Leider habe ich fast keine Ahnung von RSA und Co.

      WIT: Wiimms ISO Tools
      Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

      SZS: Wiimms SZS Tools
      Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.



      PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Wiimm ()