Il y a un peu plus de deux ans, Derrek, Naehrwert et Nedwill ont montré qu'il était possible de lancer du code dans le boot1, mais cela n'a jamais été exploité par les développeurs.
Mais c'est encore Hexkyz qui nous détaille cette exécution de code dans le Boot1 en nous expliquant pourquoi elle n'est pas si intéressante que cela.
La faille du Boot1 résulte dans l'architecture de démarrage de la console, pour parler clairement avant de démarrer la console, le boot confirme la région de stockage (le boot_info) avec la clé Ancast et la RAM n'est alors pas vidée, pour ensuite aller pointer la section à utiliser. C'est ce pointeur qui n'est pas sécurisé et qui peut être modifié.
En modifiant cette architecture, Hexkyz a réussi à créer une option pour vider le boot1, mais pas un CFW complet, il faudrait avoir accès à l'intégralité du boot pour cela, et ce n'est pas possible avec cette seule faille.
Il n'est pas exclu cependant de spéculer, selon Hexkyz, il serait possible d'éxécuter un CFW en utilisant contenthax (haxchi) pour modifier le loader vWii, afin d'exécuter un payload pour exploiter un bug.
Voilà sa théorie :
- Allumez la console
- Appuyez et maintenez "B" pour entrer en mode Wii
- Cela charge maintenant un payload qui créé l'environnement modifié, le crypte et redémarre la console
- Lancement du CFW
Si vous voulez en savoir plus le long billet est là.
Il diffuse un hexFW pour partager ces informations et espère ainsi faire avancer un CFW, bien entendu la clé boot1 AES n'est pas intégrée dans son hexFW.
Hexkyz explique toute la procédure sur son blog, après s'être approché de Derrek il a obtenu le bug utilisé, la procédure et l'a exécuté pour profiter du boot1. Il reste encore énormément de travail à accomplir, Hexkyz confirme que c'est par manque de temps ou de motivation que la scène Wii U n'évolue plus, il faut dire qu'elle s'est tournée désormais sur la Switch.
