Le mystère des Wii LUA64

[Newserator]

Suite à l'article concernant l'histoire du hardware Wii, Bushing continue sur sa lancée en revenant sur le problème des fameuses Wii dites LUA64 qui empêchent le lancement de code homebrew.

Note : si vous ne l'avez pas encore fait, il est conseillé de lire les articles suivants qui ont été rédigés pour préparer cet article:

- L'histoire du hardware Wii

- L'histoire de l'IOS Wii

Il y a quelques mois maintenant, sont apparus des retours d'utilisateurs à propos de Wii impossibles à modifier de manière logicielle (Wii unsoftmoddable), connues également sous le code "LUA64+". Normalement cela n'aurait pas dû nous intéresser (La Team Twiizers), mais nous avons découvert que notre HackMii Installer ne fonctionnait pas sur ces Wii. Nous avons pensé en 1er lieu que cela provenait d'une modification matérielle inoffensive, coïncident avec le déploiement du boot2v4, mais cela n'a jamais été expliqué. Voici les explications.

"LUA64+" est un nom pour le moins idiot afin de décrire ces Wii. Il se réfère aux 4 premiers caractères du N° de série des premières Wii dites unsoftmoddables. Cependant, on ne peut pas blâmer les gens car il s'agit du seul moyen visuel permettant d'identifier ces consoles une fois fabriquées.

Retour en arrière au début de 2009. Les éléments suivants concernent toutes les Wii fraichement achetées :

1) Toutes les versions de l'IOS sont désormais corrigées au niveau du bug strncmp(), de l'accès au /dev/flash blocked, et “ES_Identify” ne fonctionne plus.

2) Boot1 voit le bug strncmp() corrigé

3) Des données "poubelles" sont installées dans le slots des IOS3, IOS4 et IOS254

Début mars, un groupe assez bien défini de symptômes lors de lancement de code homebrew ont été observés sur ces nouvelles wii :

1) Les anciennes (mais valides) versions d'IOS ne se lançaient plus, celles-ci bloquaient lors des essais, empêchant ainsi tout downgrade. Cela ne s'appliquait pas à l'IOS16 qui avait été leaké.

2) Les essais de reload d'IOS via libogc provoquaient également de temps à autre des blocages selon le programme. Cela ressemblait à un freeze ou simplement un blocage des appels de l'IOS.

Il ne semble exister de différences au niveau software entre une des ces Wii comparé à ce que vous obtiendriez en effectuant une mise à jour via le System Menu.

Des personnes proposent des théories telles que "Nintendo a ajouté un code spécial dans le boot1/boot2 permettant la détection de hack, mais ils ont installé une "back door" pour l'IOS16". Comme cela a déjà été expliqué dans le passé, l'exécution de boot1 et boot2 est terminée bien longtemps avant que vous ne voyez quelque chose à l'écran, et n'affectent rien après cela. Bien que boot2 soit responsable du chargement de l'IOS et l'IOS est responsable du chargement du code PowerPC pour le System Menu ou les jeux. Si vous insérez un disque de jeu qui utilise une version différente de l'IOS, l'IOS en cours d'exécution s'occupe de charger et lancer le nouvel IOS, qui lui même lance le code PPC, et peut être éventuellement un autre IOS pour retourner au System Menu, etc... (L'ordre exact de ces étapes devient important pour la suite).

Il s'agissait d'une curiosité généralement ignorée puisqu'elle n'affectait pas nos programmes, jusqu'au lancement du HackMii Installer.

La raison qui nous a poussé à créer un installer commun pour BootMii, la Chaine Homebrew et DVDx fût qu'il devenait compliqué d'installer des logiciels sur les Wii. Différentes approches ont été nécessaires, selon la configuration des Wii, et on ne pouvait que constater qu'il devenait idiot de multiplier les installers. Cela s'est terminé par la mise en place de codes qui examinent l'état de la Wii sur lequel ceux-ci sont lancés et d'appliquer une stratégie appropriée puis d'installer automatiquement le logiciel souhaité.

Il existe plusieurs moyens pour utiliser l'Installer. si cela est possible il utilisera simplement un ancien IOS dont la fonction de comparaison du hash n'est pas patchée et permet un accès illimité à /dev/flash (effectuant un reload vers cet IOS autant que nécessaire). Si ce n'est pas possible, l'Installer choisira un des IOS dans une liste contenant les IOS permettant un exploit selon les versions de l'IOS installé (chaque exploit nécessite d'être personnalisé selon les versions des IOS) et de l'utiliser pour lancer MINI en mémoire et l'exécuter. De là, nous pouvons accéder directement à la NAND flash et détecter la version installée de boot1 et boot2. Au final, cela permet de décider si BootMii peut être installé en tant que boot2, puis retourner à un IOS normal qui permet l'accès à la Wiimote. Bien entendu, le fait de retourner à l'IOS ne se fait pas en un claquement de doigt. MINI contient une fonction qui lance un title spécifique de la NAND via la lecture de boot2 au début de la NAND, puis il patch l'appel de ES_LaunchTitle(1-2) vers le title ID souhaité, et enfin exécute le boot2 patché.

Tout ceci s'effectue automatiquement et de manière transparente, mais cela nécessite quelques secondes. A cause d'escrocs qui ont cherché à revendre nos homebrews, nous avons installé un écran d'avertissement anti-escrocs avant de permettre l'installation. Le délai mis en place pour l'installation de l'exploit IOS fait que celui-ci s'exécute durant l'apparition de ce fameux écran d'avertissement.

Cela n'a pas fonctionné comme nous le souhaitions sur certaines Wii, étrangement un reboot s'opère au milieu du délai d'affichage de l'écran d'avertissement sur ces fameuses Wii non softmoddables. Soudainement cet état de fait est devenu un problème intéressant.

Malheureusement, nous avons tous d'anciennes Wii. Nous étions dans l'incapacité à reproduire le problème nous même. Le seul moyen était d'avoir à la fois une nouvelle Wii et un USBGecko afin d'obtenir des logs de debug. Fort heureusement nous avons fini par mettre la main sur une de ces Wii et de lancer une version debug de notre Installer sur celle-ci. L'Installer a planté lors de la tentative de retour à l'IOS via le boot2. Il s'est avéré que ces nouvelles Wii contenaient une nouvelle version du boot2, boot2v4, et notre routine "patch boot2 pour retourner à l'IOS au lieu du System Menu" ne parvenait pas à trouver le code à patcher. Au lieu d'afficher un message d'erreur, le nouveau boot2 non modifié était exécuté et qui relancer le System Menu en lieu et place de lancer l'Installer. Oops.

Cela devait certainement être assez simple à régler. Un patch pour le boot2v4 a été installé et l'Installer semblait réussir à relancer l'IOS, seul un blocage de __IOS_InitializeSubsystems() dans libogc (précisément, ios_open(”/dev/es”)) persistait. Cela commençait à correspondre aux problèmes rapportés au niveau des programmes libogc au moment du IOS_Reload().

svpe a indiqué qu'il avait dû faire face à des problème de délai en travaillant sur le boot avant et après entre les IOS et MINI et a suggéré d'essayer d'ajouter un délai. Lors de l'ajout d'un délai de 5sec dans le code entre le moment ou il est demandé à MINI de recharger l'IOS, et lors de la réinitialisation de ligogc, tout à correctement fonctionné. La situation paraissait étrange puisque le code fonctionnait bien avec boot2v3, puis avec boot2v4 si le System Menu était rechargé (c'est ce qui arrivait aux personnes lorsque le patch boot2 ne fonctionnait pas).

Après un ou deux nuits supplémentaires sans dormir, il est devenu clair que boot2v4 prenait plus de temps à charger quelque chose que boot2v3. Si nous vérifions le numéro de version IOS juste avant d'appeler __IOS_InitializeSubsystem(), l'information retournée indiquait la bonne version de l'IOS sur le boot2v3, mais 0 avec le boot2v4. Cela indiquait que le boot2 était toujours actif, boot2 paramètre le numéro de version à 0 lorsqu'il se lance.

La réponse à ce problème semblait assez simple, il suffisait d'ajouter une portion de code qui fonctionnerait de la manière suivante :

1) Envoyer IPC à MINI en lui demandant de booter dans l'IOS

2) Retarder le déroulement jusqu'à ce que le numéro de version IOS indique 0 (signifiant que boot2 est entièrement chargé et est en cours d'exécution).

3) Retarder le déroulement jusqu'à ce que la version IOS correspond à la version IOS attendue

4) Lancer l'initialisation de l'IOS

Encore une fois, effectuer cette opération provoque une légère différence, mais pas une bonne. Désormais il n'y avait plus de blocage lors de la requête __IOS_InitializeSubsystems(), mais tous nos appels IOS ne fonctionnaient plus dès que nous bootions sur l'Installer, et cela échouait avec des codes erreurs plutôt étranges comme “-900074497?. svpe a alors précisé que le processus de chargement de l'IOS s'effectuait de la manière suivante :

1) lancement de boot2

2) boot2 paramètre le numéro de version de l'IOS à 0

3) boot2 exécute es_main()

4) es_main appelle ES_LaunchTitle(1-2) (ou dans notre cas, IOSxx puisque ce paramètre a été patché)

5) ES_LaunchTitle reconnait que nous tentons de charger un IOS, puis paramètre le numéro de version IOS en mémoire afin que le nouvel IOS chargé sache de quelle version il s'agit.

6) ES_LaunchTitle transfert le contrôle au nouvel IOS

7) IOS se lance et paramètre les registres IPC afin de dialoguer avec le PPC

La course fut lancée entre le moment ou ES_LaunchTitle change le numéro de version IOS et quand IPC se lance. si nous tentions de lancer les appels IPC à Starlet avant le changement de numéro de version, c'est comme si nous demandions à IPC d'appeler boot2 alors qu'il était au milieu du reboot. De ce fait nous n'aurions jamais obtenu de réponse et libogc aurait planté. Si nous attendions jusqu'à ce que le numéro de version soit paramétré, libogc tenterait de dialoguer avec le nouvel IOS avant qu'IPc soit initialisé. Dans le cadre de cette initialisation, IOS aurait renvoyé un message "ack" buggé laissant croire à libogc que l'appel ios_open(”/dev/es”) avait échoué et cela n'aurait jamais correctement initialisé ES et tous les appels suivants auraient échoué. Si nous attendions dans notre propre code ce message "ack" (comme suggéré par isobel), alors tout devrait fonctionner.

Armés de ces informations, il était devenu possible d'ajouter un bout de code pour ajouter un délai à l'Installer et obtenir les chiffres suivants :

Sur le matériel ancien :

Temps de chargement boot2v3: 958 ms

Temps d'exécution entre boot2v3 et le lancement de l'IOS:

Temps d'initialisation IPC:

Sur le matériel nouveau:

TTemps de chargement: 134 ms

Temps d'exécution entre boot2v3 et le lancement de l'IOS: 178 ms

Temps d'initialisation IPC: 499 ms

Ainsi, nous avions plus ou moins notre solution au problème de boot2v4 et du HackMii Installer, il suffit d'ajouter un certain délai. Alors pourquoi le délai est-il autant différent sur les nouvelles Wii, et pourquoi cela n'affecte pas les opérations habituelles sur la console ?

Résumons les faits :

* Les Wii récentes sont produites avant un nouveau boot2v4, qui est basé sur le même code présent dans le lot d'IOS publiés en octobre dernier.

* Le fait de recharger l'IOS échoue régulièrement sur les nouvelles Wii, spécialement lors d'une tentative de reload d'une ancienne version d'IOS (avant octobre, pris sur une ancienne Wii).

* Le lancement de titles PPC fonctionne correctement sur les nouvelles Wii, même si cela nécessite de recharger une version différente de l'IOS (comme cela arrive lors du lancement de la Chaine Homebrew).

* Les même versions d'IOS fonctionnent différemment sur les anciennes Wii, et n'ont aucun des problème cités précédemment. La seule différence au niveau logiciels chargés sur ces Wii se trouve dans boot1 et boot2.

* La version leakée de l'IOS16 semble exempte de ces problèmes.

D'après les recherches précédentes, il est possible d'ajouter les détails suivants à nos connaissances :

* boot1 et bc ont chacun 4 révisions, de celles-ci, une était pour corriger le bug strncmp et 3 pour modifier les routines bas-niveau d'initialisation du matériel.

* La correction du bug strncmp est apparue en 1er dans l'IOS37 en Mars 2008. IOS, bc et boot1 ont apparemment été corrigés en internet par Nintendo / BroadOn en Février/Mars 2008 mais n'ont pas été publiés avant plusieurs mois après cette correction.

* bc (et probablement boot1) a été revu avec quelques modifications mineures au niveau de l'initialisation matérielle.

* Les nouvelles versions de boot2 et de tous les IOS ont été réalisées le 11 juillet 2008

* Les nouvelles versions IOS ont été placées sur les serveurs de mise à jour Nintendo en Octobre

* Les Wii ont commencé à être vendues avec les nouveaux IOS (mais avec boot2v4) fin 2008

* Deux révisions du PCB ont été réalisées à la fin 2008, début 2009, toutes ces Wii ont été vendues avec les nouveaux IOS et boot2v4, et ne semblent pas fonctionner très bien avec les anciennes versions d'IOS.

* L'unique modification remarquée sur le PCB se situe au niveau du circuit d'alimentation. Hollywood (où l'IOS est exécuté) n'a pas été modifié (toujours en version "Hollywood AA") et quelques modifications mineures et sans conséquences ont été faites sur le Broadway.

Un scénario commence à émerger :

1) Nintendo développe un nouveau design des PCB pour réduire les coûts en simplifiant le circuit d'alimentation mi-2008. Le nouveau PCB contient moins de composants mais demande quelques millisecondes supplémentaires pour stabiliser le voltage de l'alimentation.

2) Le nouveau matériel nécessite un kernel IOS plus tolérant, de ce fait BroadOn revoit boot2 et IOS afin que Nintendo les utilise sur le nouveau PCB. Ces version IOS restent toutefois compatibles avec la révision C/RVL-CPU-01.

3) Nintendo publie les nouveau IOS via une mise à jour fin 2008, pour annihiler le bug strncmp() (ainsi que l'accès /dev/flash et ES_Identify()

4) Nintendo lance la production du PCB C/RVL-CPU-01 avec les nouveaux IOS sur celui-ci (boot2 n'est pas mis à jour, Nintendo n'ayant aucun intérêt à le faire).

5) Nintendo lance éventuellement une production massive de PCB C/RVL-CPU-20 qui nécessitent un boot2(v4) mis à jour afin de fonctionner, ainsi que de nouvelles versions IOS qui ont déjà été correctement testés à ce moment là.

6) Les clients reçoivent ces nouvelles Wii basées sur le C/RVL-CPU-20. Certains tentent d'installer d'anciennes versions IOS et de lancer du code libogc utilisant ces IOS.

7) libogc ne sachant pas qu'il est désormais nécessaire d'attendre un peu plus longtemps pour recharger IOS, et selon le délai, provoque un blocage ou empêche l'initialisation de l'IOS.

Il est fort probable que Nintendo n'a jamais imaginé que cela pouvait être un problème. Voici comment le système boot normalement :

1) Mise sous tension du système

2) boot / boot1 / boot2 se lancent sur le Starlet

3) boot2 charge le TMD pour le System Menu, regarde la version IOS nécessaire, puis lie le chargement à cette version de l'IOS

4) La nouvelle version chargée de l'IOS charge le System Menu depuis la NAND vers la mémoire, puis active le PPC et l'exécute.

5) L'utilisateur sélectionne une chaine ou un disque, IOS charge TMD, et se relance dans le nouvel IOS

6) IOs lance le jeu depuis la NAND ou le disque vers la RAM, puis bootstraps PPC

Voici ce qui arrive lorsque quelqu'un lance un USB loader depuis la Chaine Homebrew :

1) L'utilisateur sélectionne HBC depuis le System Menu, le menu appelle ES_LaunchTitle(00010000-HAXX)

2) IOS regarde le TMD HBC depuis la NAND, observe que l'IOS61 est nécessaire (ou autre) et se recharge avec celui-ci.

3) IOS61 initialise le hardware, puis charge le contenu HBC dans la RAM et boostraps PPC

4) L'utilisateur sélectionne son USB Loader depuis la SD Card

5) HBC lance le ELF depuis la SD Card dans le PPC et va vers ce dernier directement

6) L'ELF appelle (par exemple) IOS_Reload(249) pour charger une version patchée de l'IOS

7) Libogc effectue un appel IPC vers l'IOS pour recharger l'IOS, mais n'attends pas assez longtemps pour que le processus se termine et tout se confond.

Dans le scénario normal de Nintendo, IOS est toujours celui se rechargeant lui-même puis la nouvelle version de l'IOS charge le PPC et lance le code. Il n'y a jamais aucun code PPC s'exécutant durant ce processus , et le code PPC est impossible à lancer tant que l'ARM n'est pas prêt. A contrario, le processus utilisé par libogc se réalise "en coulisses", avec le PPC rechargeant le code ARM, un code de synchronisation insuffisante est utilisé pour éviter cette course car les anciennes Wii se rechargent tellement vite que ce fait n'a jamais été un problème.

Voici ce qui arrive lorsque quelqu'un lance (par exemple) un forwarder de chaine depuis le System Menu, une bannière avec un TMD leurre qui charge une ancienne version (probablement patchée) d'IOS puis lance autre chose :

1) L'utilisateur sélectionne "forwarder channel" depuis le System Menu, le menu appelle ES_LaunchTitle() sur le title

2) IOS regarde le TMD de la chaine depuis la NAND, observe qu'il nécessite IOS36 (ou autre) et se recharge avec celui-ci.

3) IOS36 ne parvient pas à initialiser correctement le hardware et le système se bloque.

Ce n'est pas une explication absolue. Pour le moment on ne peut expliquer :

* Pourquoi l'IOS16 continue de fonctionner

* Quelles fonctions spécifiques sont nécessaires dans un IOS pour qu'il fonctionne sur les nouvelles Wii. Le processus de boot d'un IOS est multithreadé et difficile à suivre.

* Pourquoi, précisément, le nouveau code est nécessaire

* Pourquoi la dernière version du HackMii Installer ne fonctionne pas sur toutes les Wii avec boot2v4, même si le code de synchronisation est en place

Quoi qu'il en soit, il s'agit surement des meilleures explications possibles plutôt qu'un "Nintendo a mis en place un truc magique pour faire des Wii non softmoddables". Ne vous méprenez pas, il est certain que des sourires sont surement apparus chez Nintendo lorsqu'ils ont vu que ce hack ne fonctionnait plus. Mais habituellement les efforts de Nintendo contre les hackers sont moins subtils, par exemple, en bloquant le /dev/flash et corrigeant l'exploit IOS utilisé auparavant dans l'installer HBC.

Si vous, lecteur, souhaitez vous amuser avec cela, voici un petit programme de test dont vous pouvez télécharger les sources et le binaire. Il s'agit principalement d'une version du code libogc IOS_Reload, mais affichant des informations de debug sur l'écran de votre TV et quelque code de délai. Ce n'est pas exactement le même dont il fût question plus haut dans cet article, boot2 n'est pas invoqué dans ce processus, mais ceux d'entre vous qui ont accès à ces nouvelles Wii avec un boot2v4 (et pour ceux dont l'installer HackMii ne fonctionne pas) peuvent participer à trouver ce qui ne va pas. Vous pouvez librement changer les 2 version d'IOS ("from" (depuis) et "to" (vers).

Lorsque ce code est lancé sur une Wii Coréenne, les chiffres suivants sont affichés :

stats: id=0x06bcc32d boot2v3 IOS46->IOS22 IOSticks=32 IPCticks=475

stats: id=0x06bcc32d boot2v3 IOS46->IOS20 IOSticks=32 IPCticks=1041

Sur une ancienne Wii NTSC (qui était distribué à l'origine avec un boot2v2) :

stats: id=0x0408cafa boot2v3 IOS35->IOS22 IOSticks=32 IPCticks=497

stats: id=0x0408cafa boot2v3 IOS35->IOS20 IOSticks=32 IPCticks=1052

Il peut être intéressant de voir si des différences substantielles apparaissent selon le type de matériel.

  Site officiel : HackMii

Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2414

[Shakin]

Salut,

Merci pour le gros boulot de traduction.

C'est vraiment tres intéressant et enrichissant comme article.

@+