Herzlich willkommen zum Ultimate Homebrew Guide (UHG) von Wii-Homebrew.com. Hier lernt ihr die Funktionsweise der Wii kennen, eignet euch Wissen über vielerlei interessante Dinge an, und werdet am Ende dieses Guides eine vor Schäden geschützte, voll modifizierte Wii euer Eigen nennen können. Dazu empfehlen wir euch, jeden Satz mindestens zweimal zu lesen, um etwaigen trivialen Fragen vorzubeugen. Falls Schwierigkeiten auftauchen, ihr Verbesserungsvorschläge habt, Kritik ausüben, oder einfach irgendwas fragen wollt, fühlt euch frei im entsprechenden Support-Bereich des Forums zu fragen.

Während dieses Tutorials werden euch an bestimmten Stellen immer mal wieder sogenannte "Spoiler" begegnen. Diese Spoiler haben den Zweck einen Text zu "verstecken". Ihr könnt den enthaltenen Text lesen, indem ihr einfach mit der Maus auf einen solchen Spoiler klickt.

Die Nintendo Wii ist seit Dezember 2006 auf dem Markt und ist verkaufszahlentechnisch die erfolgreichste "Next-Gen"-Konsole. Sie bietet neben einer innovativen -auf Bewegung beruhenden- Steuerung viele unterschiedliche Spiele für Jung und Alt. Daneben lässt die integrierte "Virtual Console" pures Retrofeeling aufkommen. So lassen sich gegen kleines Entgelt viele Videospielklassiker verschiedenster Konsolen und Heimcomputer herunterladen und spielen. Dabei erwirbt man eine Lizenz des jeweiligen Spiels, was bedeutet, dass man ein Leben lang freie Verfügbarkeit des jeweiligen Spiels erhält.

Während die Wii spieltechnisch überzeugen kann, so enttäuscht sie außerhalb dieses Bereiches. Multimediatechnisch hat Nintendos Große nicht viel zu melden. Leider kann man auch nichts dagegen tun, denn eine Konsole ist, anders als ein PC, ein geschlossenes System. Die Wii ist sozusagen in Nintendos Hand und wir müssen uns mit dem zufrieden geben, was uns unser Lieblingspublisher auf den Teller serviert.

2. Das zwielichtige Team und der Elfenjunge

Es war einmal eine Gruppe von erfahrenen Programmierern -Team Twiizers-, die sich für die Funktionsweise der Wii interessiert haben. Dazu haben sie die Wii auseinander gebaut und ihre Bestandteile analysiert. Einer aus der Gruppe, genannt "bushing", war ein Meister in Sachen "Reverse Engineering". Dadurch hatte er sich einiges, grundlegendes Wissen über die Wii angeeignet. Irgendwann hat das Team ihren ersten Exploit entwickelt, der es ermöglichte, die privaten, verschlüsselten "Keys" der Wii zu erhalten. Dadurch war es möglich das System der Wii besser zu erkunden und eigenen Code im Gamecube-Modus auszuführen. Dieser Exploit wird als Tweezer Attacke bezeichnet. In diesem Zuge, wurde auch der sogenannte Trucha Bug entdeckt. (Dazu später mehr) Aber damit wollte man sich nicht zufrieden geben. Ziel sollte sein, eigenen Code auch im Wii-Modus ausführen zu können, was letztendlich auch gelungen ist. Es gelang dem Team einen Exploit zu entwickeln, der eine Schwachstelle im Spiel "Star Wars - The Complete Saga" ausnutzt. Damit wurde der Grundstein für alle folgenden "Savegame-Exploits" gelegt. Diese beiden Exploits hatte bushing in der "24c3 Hacker-Konferenz" vorgestellt. Ein Video dazu sehen Sie links. Die Homepage von bushing/Team Twizzer finden Sie hier mit vielen technischen Informationen über die Wii. Jetzt fragt ihr euch sicherlich, was denn ein Exploit ist? Nun, dazu müsst ihr euch die Wii wie eine Mauer um eine Burg herum vorstellen. Die Mauer ist ziemlich stabil, weshalb selbst Kanonenkugeln einfach abprallen. Jedoch hat jede Mauer irgendwo schwache Stellen, auf die man gezielt feuern muss um einen Riss zu erzeugen. Die Wii hat ebenfalls solche Schwachstellen, wobei deren Aufspüren sehr schwierig ist. Diese Schwachstellen werden als "Exploits" bezeichnet. Ein "Hack" ist eine Software, die die Schwachstelle/Sicherheitslücke ausnutzt, um sich in der Wii einzunisten und "Unheil" in Form von nicht von Nintendo legitimierten Modifikationen vorzunehmen. Oft wird der Hack selbst als Exploit bezeichnet.

Wie schon gesagt, genügte die Tweezer Attacke nicht um eigenen Code im Wii-Modus auszuführen. Jedoch sollte genau dies später ein Elfenjunge namens Link, aus der berühmten Zelda-Reihe, schaffen. Team Twiizer entdeckten mit Hilfe ihrer Tweezer-Attacke eine Sicherheitslücke/Schwachstelle im Spiel "The Legend of Zelda: Twilight Princess", und haben daraufhin einen geeigneten Hack entwickelt, der sich in einem modifizierten Savegame/Speicherstand vom besagten Spiel befand und der einen ausführbaren Code enthielt. Dieser Hack wurde, dem Namen des Spiels entsprechend, in "Twilight Hack" getauft. Der Exploit enthielt im Savegame den Namen von Links Pferd "Epona", was lang genug war um einen "Buffer Overflow" zu erzeugen (zu Deutsch: Pufferüberlauf), welcher zu der Speicheradresse führte, in welcher sich der ausführbare Code befand. Detailliertere Informationen zu dem Begriff "Buffer Overflow" sind hier nachzulesen.

Den "Twilight Hack" konnte man nun verwenden um selbst geschriebene Programme auf der Wii auszuführen. Diesen gibt es in zwei verschiedenen Versionen. Version 01beta1 für Firmware 3.3 und kleiner, und Version 01.beta2 für Firmware 3.4. Wie der Hack in Aktion ausschaut, erfahrt ihr im rechten Video.

Der Nachteil des Twilight Hacks war der, das man immer auf "Zelda Twilight Princess" zurückgreifen musste wenn man eine Applikation starten wollte. Dem Problem waren sich Team Twiizer bewusst und entwickelten einen "Homebrew Loader", der in der Lage war, ohne Zelda Twilight Princess beliebige Applikationen zu starten. Dieser Loader wurde zum Homebrew Channel (HBC) getauft. Er wurde nachträglich zum Twilight Hack hinzugefügt, so dass er sich in das Menü der Wii als eigener Channel/Kanal installiert hat. Das bedeutete, dass man nun nicht mehr auf den "Twilight Hack + Zelda Twilight Princess" angewiesen war. (Was nicht heißt, dass der Twilight Hack an sich überflüssig wurde. Man benötigt ihn nach wie vor um den HBC auf einer Wii mit FW < 3.0 zu installieren. Ohne den HBC musste man aber JEDES MAL den Hack ausführen um eine Homebrew Applikation starten zu können.) Dies war der Beginn des Aufblühens von Homebrew für die Wii. Seht unten links eine Demonstration des Homebrew Channels in Videoform.

Sobald der Homebrew-Channel einmal installiert war, konnte man also jede beliebige Homebrewapp starten. Um den HBC zu installieren, benötigte man aber dennoch immer das Spiel Twilight Princess. Nun trat der Coder Comex auf den Plan. Er entwickelte mit Hilfe einiger anderer bekannter Coder den sogenannten Bannerbomb-Exploit. Dieser ermöglicht es, durch einen modifizierten Wii-Channel eigenen Code einzuschleusen, und ist entgegen des Savegame-Exploits nicht spiele abhängig. Das heißt, man kann gleich loslegen ohne vorher das Spiel Zelda - Twilight Princess zu kaufen oder zu leihen. Auch Bannerbomb gibt es in zwei Versionen. Bannerbomb v1 funktioniert bei den Firmwares 3.0-4.1. Bannerbomb v2 nur für Firmware 4.2. Dieser Exploit war das Maß der Dinge. Allerdings hatte seine Funktion mit dem Erscheinen der Firmware 4.3 ein jähes Ende gefunden. Aber auch der Twilight Hack funktioniert bei FW 4.3 nicht mehr.

Nun dauerte es einige Zeit, aber auch für dieses Problem sollte eine Lösung gefunden werden. Man konzentrierte sich wiederum auf den sogenannten Savegame Exploit. Der erste dieser Art war "Indiana PWNS", welcher mit dem Spiel "LEGO Indiana Jones - Die legendären Abenteuer" funktionierte. Von nun an war auch das Hacken einer Wii mit Firmware 4.3 kein Problem mehr. Leider hatte das natürlich zur Folge, dass die Preise für dieses Spiel im Handel explodierten. Es wurden teilweise bis zu 160,- EUR aufgerufen. Gott sei Dank wurden im Laufe der Zeit immer mehr Spiele gefunden, die ähnliche Schwachstellen enthielten. Bis heute gibt es insgesamt 6 Savegame-Exploits, mit denen man eine Wii mit FW 4.3 hacken kann. Dadurch hatten sich die Preise normalisiert.

Die Savegame-Exploits für FW 4.3 funktionieren alle nach dem gleichen Prinzip, man braucht eben nur das jeweilige Spiel und den dazugehörigen, modifizierten Speicherstand. Im Normalfall benötigt ihr dazu das originale Spiel. Wenn ihr einen Modchip verbaut habt, genügt auch eine Sicherungskopie. Die Savegame-Exploits funktionieren allerdings auch auf kleineren FW's. Solltet ihr also eines der oben genannten Spiele besitzen und mit Bannerbomb nicht zurechtkommen, so könnt ihr ohne weiteres auch einen dieser Savegame-Exploits bei FW's kleiner 4.3 anwenden.

Die oben genannten Punkte in Bezug auf die Firmware 4.3 waren lange Zeit gültig. Es war ohne eines der Spiele nicht möglich eine Wii mit FW 4.3 zu hacken. Das sollte sich dann am 09.08.2011 ändern. Denn an diesem Tag veröffentlichte Team Twizzer einen neuen Exploit für die Firmware 4.3. In Anlehnung an Bannerbomb, bekam der Exploit den schönen Namen LetterBomb. Dieser nutzt eine Sicherheitslücke im Nachrichtensystem (Messageboard) der Wii. Von nun an kann also auch bei einer Wii mit Firmware 4.3 der Softmod ohne ein Exploit-Game ausgeführt werden. LetterBomb funktioniert allerdings NUR auf Firmware 4.3.

Doch die Räder der Coder standen nicht still. Ende April 2012 gelang es dem Coder giantpune einen weiteren Exploit zu entwickeln. Er wurde Wilbrand getauft. (Joseph Wilbrand = Erfinder des TNT). Dieser basiert -ähnlich dem LetterBomb-Exploit- auf einer Schwachstelle in der Wii-Pinnwand. Dieser Exploit hat 2 ganz entscheidende Vorteile gegenüber LetterBomb.

Da man mit dem Homebrew Channel und dem Twilight Hack unautorisiert in das System der Wii eingreift, wird dies oft als illegal und "böse" verstanden. Dem ist aber nicht so. Team Twiizer, die für den Homebrew Channel und den Twilight Hack verantwortlich waren, haben nie urheberrechtlich geschützten Code in ihren Projekten benutzt. Der Homebrew Channel sowie alle weiteren Projekte von diesem Team sind zu 100% selbst geschrieben. Demnach haben sie das Recht damit zu tun was sie wollen. Jedoch ist Piraterie in Form von "Spiele aus dem Netz laden" illegal und wird durch das Team Twiizer -und auch von uns- nicht geduldet. In der Regel sind alle Homebrewprogramme völlig legal. Es sei denn, sie beinhalten urheberrechtlich geschützten Code. Dies ist jedoch nur selten der Fall, und bei uns nicht zu haben. Desweiteren ist noch zu sagen, dass ihr jegliche Garantie mit sofortiger Wirkung verliert, wenn ihr unautorisierte Software wie den Homebrew Channel auf eurer Wii installiert, denn sollte Nintendo merken, dass eure Wii unautorisiert modifiziert wurde, bekommt ihr im Falle eines Bricks womöglich einen Kostenvoranschlag von derzeit 210 Euro als Reparatur- und "Bußgeld" serviert.

3. Das System der Wii

Damit ihr später verstehen könnt, warum und weshalb etwas funktioniert, bzw. nicht funktioniert, ist es an dieser Stelle erforderlich, das System der Wii näher zu erläutern. Die Wii ist, wie jede andere Konsole, ein geschlossenes System mit einem eigenen Funktionsschema.

Die Wii besteht wie ein PC aus einer CPU und einer GPU. Die GPU spielt in diesem Guide keinerlei Rolle und kann getrost ignoriert werden. Daneben hat die Wii, wie jeder PC, eine "Festplatte" bzw. Flashspeicher. Dieser ist etwa 512 MB groß und wird auch NAND genannt. Wir werden zukünftig die Begriffe Flashspeicher und Festplatte nicht mehr benutzen, sondern ausschließlich den Begriff NAND.

Beim Einschalten der Wii wird die CPU aktiv und führt als allererstes einen Code aus, welcher direkt in die CPU "eingebrannt" wurde. Dieser Code wird als boot0 bezeichnet und kann nicht modifiziert werden. Die geringste Änderung an dem boot0 hat einen unwiderruflichen Totalausfall der Konsole zur Folge. boot0 initialisiert die Wii und bootet den nächsten Code, der als boot1 bezeichnet wird. boot1 befindet sich nicht in der CPU, sondern im NAND. Genau wie boot0 hat die geringste Modifizierung von boot1 einen unwiderruflichen Totalausfall der Konsole zur Folge, weil es von einer digitalen Signatur im boot0 überprüft wird. Sprich wenn boot0 eine Modifizierung von boot1 feststellt, streikt es und lässt die Wii nicht starten.

boot1 bootet anschließend das sich ebenfalls im NAND befindliche boot2. boot2 wird später im Zusammenhang mit Brickschutz eine wichtige Rolle spielen. boot2 bootet/lädt anschließend das Systemmenü-IOS, welches wiederum das Systemmenü lädt. Das Systemmenü ist das Menü, in dem sich alle Kanäle befinden, man Einstellungen vornehmen kann, etc.

Die Wii kann jedoch alleine mit boot0 bis boot2 und dem Systemmenü nicht funktionieren. Es fehlen noch "Kontrollprogramme/Kontrollstationen", die die Wii überwachen und für verschiedenste Funktionen verantwortlich sind und diese lenken. Diese Programme nennt man IOS (Input-Output-System). Die IOS selbst bilden zusammen das Betriebssystem der Wii. Nachfolgend das Bootschema der Wii zusammengefasst.

[boot0 ---->boot1---->boot2---->Systemmenü-IOS---->Systemmenü]

3.1 Was sind IOS und wie viele gibt es von denen?

Wie gesagt sind IOS kleine Programme, die die Wii bzw. deren Funktionen/Inhalte steuern/kontrollieren und das Betriebssystem der Wii bilden. Sie befinden sich alle im NAND. Die Wii hat insgesamt 255 Slots für IOS zur Verfügung. Bisher sind noch viele Slots unbelegt. Für fast jedes IOS steht eine bestimmte Funktion zur Verfügung, beispielsweise ist ein IOS für das Aufblinken der LED an der Wii zuständig, ein anderes für USB-Tastatur Support oder für die Funktionalität eines Kanals, wie z.B. den Wetter- und den Shop-Kanal. Programme machen sich die Funktionen in den IOS zu Nutze, um diese und jene Sachen auszuführen, ähnlich wie Linux-Kernel. Man könnte sagen, was für Linux Kernel sind, sind IOS für die Wii. Deshalb sind Aussagen, die Wii basiere auf Linux, nicht ganz aus der Luft gegriffen.

Fehlen IOS, so fallen deren entsprechenden Funktionen aus. IOS30 beispielsweise ist zuständig für die Erkennung von USB-Tastaturen. Fehlt es, wird keine USB-Tastatur mehr von der Wii erkannt. IOS31 ist zuständig für den Wetter-, News-, und Fotokanal. Fehlt es, so würden besagte Kanäle nicht mehr funktionieren. Manche IOS sind einfach nur Platzhalter mit keinerlei Funktionen. Es kann immer nur ein IOS zur gleichen Zeit laufen. Beispiel: Wenn das Systemmenü gerade zu sehen ist, dann läuft ausschließlich jenes IOS, welches für das Systemmenü verantwortlich ist. Für das Systemmenü 4.2 beispielsweise, ist das IOS70 verantwortlich. Startet man ein Spiel, schaltet sich das IOS70 ab und das IOS, welches für das Starten des Spiels verantwortlich ist, wird aktiv. Insgesamt gibt es nur 2 Zustände, in denen kein IOS läuft, nämlich im Gamecube-Modus und im BootMii/Boot2-Menü. Im Gamecube-Modus läuft stattdessen ein MIOS und im BootMii/Boot2-Menü das MINI, einem IOS-ähnlichen Bestandteil der Wii. Beide Modi werden wir später näher erläutern.

Eine wichtige Funktion von IOS ist das Installieren von Dateien, z.B. Kanäle für das Wii-Menü. Dazu sind 2 Sicherheitsschlüssel erforderlich. Der erste Schlüssel nennt sich common-key und ist für jede Wii identisch. Der common-key ist in jeder Wii in einem ROM in der Nähe des Coprozessors Starlet versteckt. Team Twiizers haben ihn durch ihre Tweezer-Attacke ausfindig machen können. Wenn der common-key gerade in Gebrauch ist, dann befindet er sich im 24MB großen RAM der Wii. Wir erinnern uns, durch die Tweezer Attacke war es möglich den RAM der Wii zu untersuchen.

Der zweite Schlüssel nennt sich private key und befindet sich auf Nintendos Server. Bis heute hat man es nicht geschafft, ihn zu erhalten. Jetzt fragt ihr euch vielleicht, warum es dennoch möglich ist Kanäle zu installieren, obwohl der private key nicht geborgen werden konnte. Nun, Team Twiizers entdeckte in jedem IOS einen Sicherheitsfehler, der als Trucha Bug bezeichnet wird. Jetzt wird es etwas kompliziert (unbekannte Fachausdrücke bitte googeln): Um die Anwesenheit des private keys zu kontrollieren, benutzt das IOS die Funktion strncmp(). strncmp() ist eine Funktion der Programmiersprache C. Diese überprüft, ob es zwei exakt identische Schleifen gibt. Wenn ein 0 byte erkannt wurde, wird angenommen, dass die Schleifen gleich sind und die Funktion wird beendet bzw. die Sicherheitskontrolle wird abgebrochen. Um also etwas installieren zu können, müssen wir den common-key und ein 0 byte in die Installationsfunktion des IOS übertragen. Die Methode etwas mit 0 byte anstatt des private keys zu installieren, bezeichnet man als Fakesigning. Der Sicherheitsfehler eines IOS strncmp() zu benutzen ( und ein 0 byte zu erkennen), wird als Trucha Bug bezeichnet.

Wir fassen also zusammen: Um etwas zu installieren, brauchen wir ein IOS mit dem Trucha Bug. Mit dem Systemmenü 3.3 hat Nintendo es erstmals geschafft alle IOS mit Trucha Bug zu fixen indem man die Funktion strncmp() mit memcmp() ersetzt hat, einer Funktion, die nicht abbricht wenn sie 0 byte gefunden hat.

Irgendwann entwickelte Team Twiizers einen Code, genannt PatchMii, mit dem es möglich war IOS zu downloaden, zu installieren und mit dem Trucha Bug zu patchen. Solche IOS werden cIOS genannt. Jedoch werden solche IOS von vielen Menschen fälschlicherweise als normale IOS bezeichnet oder einfach nur IOS mit Trucha Bug.

Der Programmierer Tona war der erste, der eine Applikation released hat, die das IOS36 runtergeladen, mit dem Trucha Bug gepatcht und im IOS-Slot 249 installiert hat. Damit war das cIOS249 geboren. Dieses cIOS konnte jedoch nicht für Pirateriezwecke missbraucht werden, sprich mit diesem cIOS konnte man keine gebrannten Spiele spielen.

Irgendwann haben die Entwickler Waninkoko und Wiigator die Applikation von Tona kopiert und modifiziert, so dass das IOS36 nicht nur mit dem Trucha Bug, sondern auch mit anderen Funktionen gepatcht wurde, mit denen man dann in der Lage war gebrannte Spiele zu spielen. Das sogenannte "Warez-IOS", oder in den meisten Augen das "echte" IOS249, war geboren.

Unter den IOS unterscheidet man grob zwischen essentiellen und nicht essentiellen IOS. Fehlen nicht essentielle IOS, so werden der Wii einige Funktionen geraubt, aber die Wii selbst funktioniert dann noch. Werden allerdings essentielle IOS entfernt, so startet die Wii nicht mehr. Die IOS, die für die Funktionalität des Systemmenüs verantwortlich sind, sind essentiell. Wenn man sie entfernt, kann logischerweise das Systemmenü nicht mehr gebootet werden, sprich: Die Wii ist hinüber.

Man unterscheidet zwischen natürlichen und unnatürlichen IOS. Alle von Nintendo selbst stammenden IOS sind natürliche IOS. Unnatürliche bzw. künstliche IOS sind von Codern selbst erstellte IOS, die der Wii weitere, von Nintendo nicht zugelassene Funktionen spendieren sollen. Fast alle künstlichen IOS verleihen der Wii die Fähigkeit, selbstgebrannte Spiele zu spielen. Somit ist deren Existenz nicht ganz unumstritten. Künstliche IOS kürzt man standardmäßig mit cIOS ab (custom IOS, siehe weiter oben!). Anfänglich gab es offiziell 6 dieser cIOS. Im Laufe der Zeit wurde die Entwicklung aber immer weiter voran getrieben. Der Coder Waninkoko hatte sich lange Zeit aus der Szene zurück gezogen. Also widmeten sich andere fleißige Coder der Aufgabe neue Versionen der cIOS zu entwickeln. Da der Source-Code von Waninkoko's cIOS und dessen Installer nicht open-Source war, musste eine völlig neue Art von cIOS geschaffen werden. Diese wurden dann "d2x" getauft. Die beteiligten Coder waren davebol und xabby666. Der Coder XFlak entwickelte dann einen Mod für sein Tool ModMii, um die d2x cIOS zu erstellen. Mittlerweile ist der Coder Waninkoko wieder in das Projekt eingestiegen. Seit dem kann man die d2x cIOS auch wieder mit einem Installer direkt an der Wii installieren. Man kann diese cIOS auf verschiedene Arten und in verschiedene IOS-Slots installieren. Das IOS249 hat von allen cIOS als erstes das Licht der Welt erblickt. Deshalb meint man, wenn man allgemein von cIOS spricht, falls man nicht anderes angibt, das IOS249. Der spanische Hacker Waninkoko ist zusammen mit Wiigator verantwortlich für die ursprünglichen IOS249 und IOS250, sowie Hermes für das IOS202, IOS222, IOS223 und IOS224. Das IOS202 ist das einzige IOS, dessen Ziel nichts mit Piraterie zu tun hat. Es spendiert der Wii eine USB2.0-Funktion, Zugriff auf normale DVDs und verbessert wahrscheinlich auch noch die Funktionalität von einigen Homebrews. Diese Funktionen werden nun aber auch weitestgehend von den d2x cIOS übernommen. In diesem Tutorial werden wir insgesamt 12 dieser cIOS installieren. Sowohl die von Hermes, als auch die d2x cIOS. Diese sind: IOS202, IOS222, IOS223, IOS224, IOS236, IOS245, IOS246, IOS247, IOS248, IOS249, IOS250 und IOS251.

Von fast jedem IOS gibt es mehrere Versionen. IOS unterschiedlicher Version können sich von ihrer Funktionalität her stark unterscheiden. So kann ein IOS2 v5 beispielsweise ganz andere Eigenschaften haben, als ein IOS2 v4. Falls in der Wii bereits ein IOS mit demselben Namen installiert ist, so wird jedes gleiche IOS unterschiedlicher Version nur installiert, wenn es eine höhere Version als das bereits installierte IOS aufweist. Dabei wird das zuvor installierte IOS, das eine niedrige Version trug von dem neueren IOS überschrieben. Es kann nie ein IOS gleicher Art installiert werden, wenn bereits ein IOS mit einer höheren Version installiert ist.

Um dieses Prinzip besser nachvollziehen zu können, erinnert euch bitte an Nintendos Systemmenü-Update 4.2. Ein Update hatte bzw. hat unter anderem zur Folge, dass keine gebrannten Spiele mehr funktionieren. Nintendo hat dazu einen einfachen, wie bushing sagte, eher einfallslosen "Trick" angewandt. Alle IOS, die für Sicherheitskopien verantwortlich waren, wurden mit dem Update auf 4.2 mit gleichen IOS höherer Version überschrieben. Der Unterschied zu den IOS vor dem Update, ist die Funktionslosigkeit der neueren IOS. Diese waren völlig ohne Funktion, sie waren stumpf, zu Englisch: Stub. Deshalb werden solche IOS, die keinerlei Funktionen haben, als Stub IOS bezeichnet. Da diese Stub IOS höhere Versionen als ihre gleichen IOS mit Funktionen haben, ist es nicht möglich die alten IOS, die nicht stumpf sind, zu installieren solange es IOS gleicher Art mit höherer Version installiert sind. Die einzige Lösung wäre alle Stub IOS manuell zu löschen und anschließend die alten IOS wieder zu installieren.

3.2 NUS - Nintendos legale IOS-Datenbank

Der NUS (Nintendo Update Server) beinhaltet eine fast vollständige Datenbank aller bisher veröffentlichen IOS. Manche gibt es nicht mehr, andere jedoch schon. Wenn die Wii einen Updatevorgang durchführt, dann nimmt sie Verbindung zum NUS auf, überspielt alle erforderlichen IOS, Kanäle und das Systemmenü und installiert diese dann. Ein erfahrender Coder hat ein Tool für den PC programmiert, welches erlaubt, eine direkte Verbindung zum NUS aufzunehmen und jede dort zur Verfügung stehende Datei völlig legal runterzuladen. Dieses Tool wird als NUSD bezeichnet (Nintendo Update Server Downloader). Dieses wurde von WB3000 programmiert. Es gibt noch weitere Kopien vom NUSD, wie z.B. der NISD (Nintendo IOS System Downloader). Falls ihr im Forum aufgefordert werdet eine bestimmte IOS-Datei zu besorgen, so könnt ihr dies bequem und legal per NUSD machen. Ebenfalls könnt ihr eine bestimmte Systemmenü-Datei herunterladen.

3.3 IOS-Liste

Nachfolgend eine Liste mit allen veröffentlichten IOS inkl. deren Funktionen:

3.5 Trucha Bug, Fakesigning Bug, ES_Identify

Da die obige Erklärung des Trucha Bugs so schön war, sind wir so frei und posten den Text einfach nochmal, doppelt lesen kann nicht schaden:

Eine wichtige Funktion von IOS ist das Installieren von Dateien, z.B. Kanäle für das Wii-Menü. Dazu sind 2 Sicherheitsschlüssel erforderlich. Der erste Schlüssel nennt sich common-key und ist für jede Wii identisch. Der common-key ist in jeder Wii in einem ROM in der Nähe des Coprozessors Starlet versteckt. Team Twiizers haben ihn durch ihre Tweezer-Attacke ausfindig machen können. Wenn der common-key gerade in Gebrauch ist, dann befindet er sich im 24MB großen RAM der Wii. Wir erinnern uns, durch die Tweezer Attacke war es möglich den RAM der Wii zu untersuchen.

Der zweite Schlüssel nennt sich private key und befindet sich auf Nintendos Server. Bis heute hat man es nicht geschafft, ihn zu erhalten. Jetzt fragt ihr euch vielleicht, warum es dennoch möglich ist Kanäle zu installieren, obwohl der private key nicht geborgen werden konnte. Nun, Team Twiizers entdeckte in jedem IOS einen Sicherheitsfehler, der als Trucha Bug bezeichnet wird. Jetzt wird es etwas kompliziert (unbekannte Fachausdrücke bitte googeln): Um die Anwesenheit des private keys zu kontrollieren, gebraucht das IOS die Funktion strncmp(). strncmp() ist eine Funktion der Programmiersprache C. Diese überprüft, ob es zwei exakt identische Schleifen gibt. Wenn ein 0 byte erkannt wurde, wird angenommen, dass die Schleifen gleich sind und die Funktion wird beendet bzw. die Sicherheitskontrolle wird abgebrochen. Um also etwas installieren zu können, müssen wir den common-key und ein 0 byte in die Installationsfunktion des IOS übertragen. Die Methode, etwas mit 0 byte anstatt des private keys zu installieren, bezeichnet man als Fakesigning. Der Sicherheitsfehler eines IOS strncmp() zu benutzen ( und ein 0 byte zu erkennen), wird als Trucha Bug bezeichnet.

Wir fassen also zusammen: Um etwas zu installieren, brauchen wir ein IOS mit dem Trucha Bug. Mit dem Systemmenu 3.3 hat Nintendo es erstmals geschafft, alle IOS mit Trucha Bug zu fixen, indem man die Funktion strncmp() mit memcmp() ersetzt hat, einer Funktion, die nicht abbricht, wenn sie 0 byte gefunden hat.

Manche Sachen funktionieren trotz Trucha Bug nicht. Die Lösung hierfür ist das Patchen der IOS mit ES_Identify (auch ES_Div genannt), einem Code, der dafür sorgt dass das entsprechende IOS getäuscht wird. Grob erklärt: A funktioniert, B funktioniert nicht. Wenn man nun B mit dem IOS initialisiert, dann wird es geblockt. Wenn das IOS jedoch mit ES_Identify versehen ist, denkt es, dass B, A ist und führt es aus. Der AnyTitleDeleter beispielsweise braucht ein IOS mit ES_Identify. Es gibt verschiedene Möglichkeiten solche IOS zu patchen. Z.B. den Simple IOS Patcher oder DopMii. Alternativ kann man diese IOS auch direkt gepatcht herunterladen, z.B. über das PC-Programm ModMii.
Zu den IOS/cIOS welche über ES_Identify verfügen, zählen im Normalfall IOS36, IOS236 und IOS250. Bei den cIOS kommt es nicht auf den verwendeten Slot an, sondern auf das Base-IOS, welches zur Erstellung des cIOS gewählt wird.

3.6 HW_AHBPROT - Eine kleine Revolution in Sachen Homebrew

Was ist HW_AHBPROT (Hardware Advanced High Performance Bus Protection), woher stammt es und was macht es überhaupt:
Auf der Suche nach einer Lösung für ein Problem innerhalb von BootMii, machte der Coder "bushing" eine entscheidende Entdeckung. Er war in der Lage einen Code im PPC (dort wird der Großteil aller Codes auf der Wii ausgeführt) auszuführen, der ihm vollen Zugriff auf die Gesamte Hardware der Wii ermöglicht hat. Er vermutete, dass sich Nintendo dieser Schnittstelle bedient, um Diagnosen an der Wii durchzuführen. Zunächst diente es ihm nur als Lösung seines Problems bei BootMii, weshalb es in den aktuellen HackMii Installer v1.0, und folglich auch in den HBC 1.1.0 eingebunden wurde. Diese Funktionen sind fest im HBC verankert und (entgegen weitläufiger Vermutungen) nicht an ein bestimmtes IOS gebunden. Egal auf welchem IOS der HBC ausgeführt wird, HW_AHBPROT steht immer zur Verfügung. Die Möglichkeiten, welche sich daraus ergaben, wurden erst nach und nach klar. Was haben wir als User aber nun davon? Ganz einfach: Es ist seitdem möglich jedes beliebige IOS "on the fly" temporär mit ES_Div zu patchen. Dieses IOS bleibt so lange gepatcht, bis ein anderes IOS geladen wird, oder man einen Reset an der Konsole durchführt.
Im Klartext heißt das nun, dass ein Programm, welches HW_AHBPROT nutzt, kein gepatchtes IOS mehr benötigt um Daten in den NAND zu schreiben, da der Code des Programms das benötigte IOS für die Dauer der Nutzung temporär patchen kann.

Leider sorgte ein Fehler im HBC dafür, dass HW_AHBPROT in Verruf geriet, da Programme welche dieses nutzten sehr häufig abgestürzt sind. Passierte so etwas zum Beispiel während der Priiloader Installation, war die Wii ein hübscher Ziegelstein. Es dauerte einige Zeit, bis man herausfand woran das lag. Um es einfach zu halten werde ich nur grob anschneiden worum es dabei ging. Der Fehler wurde durch eine fehlerhafte (oder nicht vorhandene) Internetverbindung hervorgerufen. Der HBC initialisiert diese automatisch beim Start. IOS58, auf welchem der HBC normalerweise läuft, brauchte dann in der Regel zu lange um zu "antworten". Wenn das Homebrewprogramm schon gestartet wurde, bevor der Initialisierungsvorgang abgeschlossen werden konnte, stürzte das Programm ab.
Das hatte zur Folge, dass viele Coder die HW_AHBPROT Unterstützung wieder aus Ihren Programmen entfernt haben. Nun sollte es aber nicht allzu lange dauern, bis der Coder "davebol" auch hierfür eine Lösung fand. Es handelt sich dabei im Prinzip um einen ganz einfachen Trick. Im Code des jeweiligen Programms müssen lediglich ein paar zusätzliche Zeilen eingefügt werden. Diese bewirken vereinfacht gesagt ein erneutes Laden des IOS58, unabhängig davon, ob die Initialisierung der Internetverbindung abgeschlossen ist oder nicht. Daraus ergaben sich nun ganz neue Möglichkeiten. Der neue Patch, der aus diesen Schlussfolgerungen entstanden ist, heißt "ES_SET_AHBPROT".

Dieser Patch kann zum Beispiel mit dem neuen Simple IOS Patcher 1.14 auf IOS36/236 angewendet werden. Dadurch wird ermöglicht, dass von nun an nahezu jedes IOS HW_AHBPROT nutzen kann.
Zur Erinnerung: HW_AHBPROT ist normalerweise an den HBC gebunden. Der HackMii Installer benutzt zur Installation offensichtlich einen Exploit, der nicht freigegeben ist. Daher ist nicht bekannt, wie HW_AHBPROT auch auf einer Virgin-Wii zur Verfügung steht. Ist im TMD eines IOS der HW_AHBPROT Flag gesetzt, steht es auch hier zur Verfügung. Aber auch nur dann. Sobald aber ein IOS mit "ES_SET_AHBPROT" gepatcht wurde, steht HW_AHBPROT immer zur Verfügung. Egal ob der Flag in der TMD gesetzt ist oder nicht. Aber es geht noch weiter. Wenn nun ein Programm beim Start ein IOS lädt, welches mit diesem Patch versehen ist, so besitzt jedes weitere geladene IOS ebenfalls HW_AHBPROT. Und das Ganze vollkommen unabhängig vom HBC oder sonstigen Loadern. Durch diesen neuen Patch werden die Karten völlig neu gemischt. Es ist nun vollkommen egal, ob eine Internetverbindung besteht, oder diese womöglich fehlerhaft eingerichtet ist. Die Programme, welche HW_AHBPROT nutzen, arbeiten auf jeden Fall einwandfrei.

3.7 Title, Title ID

Überall ist die Rede von Titles, doch was ist das? Nun, als Title bezeichnet man allgemein Software. Der Homebrew Channel ist ein Title, das IOS30 ist ein Title, Super Mario Bros ist ein Title, World of Goo ist ein Title, das Systemmenü 3.4 ist ein Title usw.

Da es so viele Titles gibt, muss es auch irgendwas geben, anhand dessen man sie unterscheiden kann. Deshalb ist jeder Title mit einer eigenen, spezifischen ID versehen. Der [[Homebrew Channel]] v1.0.8 beispielsweise, hatte die ID namens "HAXX", der [[HBC]] v1.1.0 trägt die ID "JODI" und der neue [[Homebrew Channel]] v1.1.2 trägt die ID "LULZ". Mehr Infos über Title_IDs könnt ihr euch im folgenden Artikel durchlesen: Klick

4.0 Brick und Brickschutz

Das Schlimmste, was einem Wii-Besitzer passieren kann, ist das Bricken einer Wii. Bei uns im Forum haben wir einen eigenen Bereich rund um Bricks und Brickschutzmaßnahmen. Für Fragen dazu, oder für Hilfeanfragen für den Fall, dass eure Wii gebrickt ist, steht es euch frei das Forum zu benutzen. .

Man unterscheidet im allgemeinen zwischen 4 Brickformen:

Fullbrick - Eine Wii mit einem Fullbrick bleibt beim Einschalten der Konsole schwarz, oder zeigt eine Fehlermeldung des Opera-Kanals an. Das Systemmenü wird gar nicht gebootet, ebenfalls nicht das DVD-Laufwerk. Manche Fullbricks sind außerhalb BootMii/Boot2 unbehebbar, andere können mit einem Autoboot-Modchip und SaveMiiFrii wiederhergestellt werden. Fullbricks entstehen in der Regel durch falschen Gebrauch von gefährlichen Homebrews, hervorgerufen durch mangelndes Wissen darüber, was man der Wii antut. Deshalb ist es wichtig, sich gut zu informieren, bevor man voreilig ein Update des Systemmenüs durchführt oder irgendein IOS löscht.

Semi-Brick - Eine Wii mit einem Semi-Brick funktioniert zwar noch, aber man gelangt nicht mehr in die Systemeinstellungen. Stattdessen erhält man einen Warnhinweis bezüglich des Opera-Kanal. Semi-Bricks erhält man, wenn man ein Systemmenü einer falschen Region installiert. Sie lassen sich leicht beheben wenn man nachträglich ein Diskupdate der richtigen Region durchführt, vorausgesetzt man hat eines zur Hand und ein niedrigeres Systemmenü installiert als das, was auf der Disk enthalten ist.

Bannerbrick - Bannerbricks entstehen beim Installieren einer fehlerhaften Wad mit einem falschen Banner (falsche Größe des Banners). Nach der Gesundheitswarnung wird die Wii freezen. Es könnte auch sein, dass die Meldung auftaucht, die Systemdateien seien fehlerhaft. Um Bannerbricks zu beheben gibt es bei uns im Forum ein Tutorial mit mehr Informationen (Danke an liQuii).

Error 003 Brick - Dieser Brick tritt am seltensten auf und das nur bei regionveränderten, koreanischen Wii's. Wenn man diesen ein normales Systemmenü-Update verpasst, bleibt das Bild beim nächsten Einschalten mit der Meldung Error 003 schwarz. Da das Rescue-Menü aber noch funktioniert, kann man versuchen die Wii mittels Modchip, SaveMiiFrii und AutobootDVD zu retten.

4.1 SaveMii, SaveMiiFrii, Rescue-Menü

Die Wii besitzt ein eigenes Rettungsmenü, das als Rescue-Menü bezeichnet wird. Ist die Wii nicht zu sehr beschädigt, lässt sich dieses Menü durch einen Trick aufrufen. In diesem Menü steht in der unteren rechten Ecke das Systemmenü der Wii. Mit einer Trucha-gepatchten AutobootDVD und einem autobootfähigen Modchip lässt sich die Wii durch Aufspielen eines neuen Systemmenüs retten. Das Rescue-Menü lässt sich auf 2 Arten aufrufen: Indem man einen Gamecube-Controller im vierten Port der Wii steckt und beim Einschalten der Konsole alle Richtungstasten des digitalen Steuerkreuzes drückt, gelangt man zum besagten Menü. Bei einem Original Gamecube-Controller ist das gleichzeitige Drücken der Richtungstasten nicht ohne weiteres möglich. Deshalb ist es notwendig, solche Controller vorher aufzuschrauben. Drittherstellercontroller funktionieren in der Regel ohne dass man sie aufschrauben muss. Diese Methode mit dem Gamecube-Controller wird als SaveMiiFrii bezeichnet.

Wer unbedingt Geld loswerden will, der kauft sich ein kleines Gerät, das man in einen Gamecube Memorycard-Slot steckt. Beim Booten der Wii übernimmt dieses Gerät die Rolle eines Gamecube-Controllers und ruft somit das Rescue-Menü auf. Das kostenpflichtige Gerät wird als SaveMii bezeichnet. In vielen Augen ist SaveMii jedoch Abzocke, da es im Endeffekt keine wirklichen Vorteile gegenüber einem Gamecube-Controller hat. Die offizielle Website von SaveMii findet ihr >>hier<<.


4.2 Priiloader, der "Rettungsring" für diverse Bricks.




4.3 BootMii - der ultimative Brickschutz...oder doch nicht?



6.0 NAND-Emulation

Die Wii-Szene ist bereits so weit fortgeschritten, dass man sogar den NAND, auf einer gewöhnlichen SD-Karte oder einem USB-Speichermedium emulieren kann. Dies funktioniert mit dem Programm SNEEK (SD NAND/ES Emulation Kit), oder UNEEK (USB NAND/ES Emulation Kit). Ein Tutorial mit weiteren interessanten Infos gibt es hier. Den Diskussionsthread zu SNEEK findet ihr hier.

7.0 Zusätzliche Informationen

Schwarze/Rote Wii's und auch neuere weiße Wii's enthalten das D3-2-Laufwerk. Dieses Laufwerk kann ausschließlich originale Wii- und Gamecube-Disks lesen und abspielen. Ein Abspielen von Film-/Daten-DVDs oder gebrannten CDs/DVDs ist nicht möglich.

Es gibt kein 100%ig sicheres Merkmal für eine Wii mit einem D3-2-Laufwerk, lediglich Indizien. So ist es gut möglich, dass Wii's mit einer Seriennummer LEH/LEF250+ jenes Laufwerk enthalten. Eine nützliche Seite die weitere Indizien gibt ist diese hier. Dort einfach die komplette Seriennummer eingeben und das Ergebnis ansehen.

Bitte nicht falsch verstehen, diejenigen die BootMii nur als IOS installieren können, haben KEINEN wirklichen Brickschutz und werden auch nie einen bekommen. Ein NAND-Backup sollte man dennoch zwingend anlegen. BootMii/IOS ist nützlich, wenn man als Ahnungsloser ein Banner- oder Semibrick verursacht hat, und nicht genau weiß wie man das beheben soll. In diesem Fall steht die radikale Möglichkeit zur Verfügung, das NAND-Backup einfach in den NAND zu flashen und somit alles darin zu überschreiben. BootMii/IOS-Besitzer werden allerdings von BootMii gewarnt, dass dieser Einspielprozess sehr gefährlich ist, da die Wii bei einer kleinen Störung bricken könnte. Um den Einspielprozess zu beginnen, müssen mit einem Gamecube-Controller alle auf dem Bildschirm gezeigten Tasten gleichzeitig gedrückt werden. Dazu könnte man schon einige Anläufe brauchen.

Hinweis: NAND-Backups bitte nur in Ausnahmefällen einspielen, da keine Software perfekt ist und jederzeit die Wii bricken kann!