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:
Damit haben wird die folgende Schlüsselhierarchie:
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.
... 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:
- Ü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.
- Ü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.
- Das TICKET wird auf die gleiche Art überprüft. Dazu wird das Zertifikat mit der Kennung XS00000003 (RSA-2048, kurz XS) verwendet.
- 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.
- 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:
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.
Wiimms Mario Kart Fun 2023-09
Mittwochs & Donnerstags
ab 19:30 Uhr CEST (17:30 UTC)
mit Team-Speak (freiwillig)
FC: Wiimm=0432-5226-7951, Leseratte=2880-9868-0945
Mittwochs & Donnerstags
ab 19:30 Uhr CEST (17:30 UTC)
mit Team-Speak (freiwillig)
FC: Wiimm=0432-5226-7951, Leseratte=2880-9868-0945
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