Un gran problema con el desarrollo para Wiis (sobre todo el que modifica cualquier parte del sistema) es que la estabilidad de la Wii recae única y exclusivamente en el testeo en la fábrica. Hay mil y una formas de terminar con una Wii brickeada por cualquier motivo, y Nintendo evita eso simplemente probando bien todo el software oficial. Por lo tanto, un primer paso importante sería el desarrollo de algún software que nos permita restaurar la Wii después de un brickeo.
El proceso de arranque de la Wii es más o menos así:
- Boot0 es un bootstrap que está en una memoria ROM dentro del Hollywood, y es el encargado de cargar boot1. Sólo puede cargar desde NAND Flash (no hay ninguna opción alternativa como en la PSP, que tiene el arranque desde Memory Stick con la batería de pandora). Para que boot0 se ejecute correctamente, hace falta que boot1 esté presente e incorrupto en la NAND. Si no lo está, tenemos un brick que solo se puede recuperar flasheando la NAND por hardware.
- Boot1 es el encargado de cargar boot2 desde una zona reservada de la NAND y verificarlo. Boot1 existe principalmente por dos motivos: porque es bastante grande y se ahorra dinero poniéndolo en NAND, y porque de esta forma se puede actualizar. Sin embargo, una vez que la Wii se fabrica, boot1 queda fijo ya que se comprueba contra un hash guardado en una memoria que se escribe permanéntemente en la fábrica, y que boot0 utiliza para verificar que boot1 está intacto. Esto le da a Nintendo ha posibilidad de cambiar boot1 sin modificar ningún chip (que es carísimo), símplemente actualizando el software a la hora de programarlo en la fábrica, pero una vez que la Wii sale, boot1 no se puede tocar. Los devkits tienen el hash de boot1 sin programar, con lo que boot0 no lo verifica: los devkits sí que pueden usar un boot1 cualquiera y sin firma alguna. Además, boot1 es el primer software en la Wii que realiza una comprobación de firma digital RSA, y tiene el mismo bug de trucha que todos los demás. Conclusión interesante: toda Wii fabricada hasta el momento puede usar un boot2 trucheado, y Nintendo no puede arreglar este problema - flasheando la NAND por hardware siempre será posible modificar boot2 en las Wiis actuales. Para que boot1 se ejecute correctamente, debe existir un boot2 que no esté corrupto (hay dos copias por si acaso) y que pase los chequeos de la firma (aunque se puede truchear). De lo contrario, la consola no arrancará y será necesario acceder a la NAND por hardware.
- Boot2 es un mini-IOS. Realmente, su función es tener los suficientes drivers (NAND, FS, ES) como para encontrar un IOS que se encuentra en un archivo de la NAND, cargarlo, y ejecutarlo. También tiene el bug de las firmas, y aunque es actualizable, Nintendo todavía no lo ha hecho. Como no se instala como un título normal (aunque sí se parece mucho a uno), no se instala con las rutinas normales de instalación. Por lo que he visto del código de actualización por internet, creo que Nintendo no puede actualizar boot2 por internet, al menos no directamente (podrían meter una actualización que a su vez actualice boot2). Sin embargo, sí que se puede actualizar con juegos que lo traigan en la partición de update. Boot2 es el primer código ejecutable en Starlet que podemos modificar a nuestro antojo, gracias al fallo de boot1. Se conjetura que boot2 originalmente iba a ser el único IOS, y que lo de tener varias versiones de IOS se pensó más tarde como medida de compatibilidad de juegos. Para que boot2 arranque, hace falta un sistema de archivos válido en la NAND, encriptado con la clave específica de cada Wii, y que contenga los archivos correspondientes al menú del sistema y su IOS, además de algunos archivos del sistema. Si esto falla, con el boot2 de Nintendo, tendremos un brick que de nuevo necesitará de acceso por hardware.
- IOS es el sistema operativo completo de Starlet que realiza las funciones de los drivers de casi todos los dispositivos de la Wii que no existian en la Gamecube. También es el encargado de arrancar el Broadway y pasarle su primer código. IOS es capaz de ejecutar cualquier título/canal de NAND (según diga un flag situado en un archivo en la NAND), pero la primera ejecución de IOS al arrancar, con el flag que deja boot2, hace que se ejecute el menú del sistema. IOS puede fallar por los mismos motivos que boot2, además de por un fallo en algún dispositivo que se intente ejecutar, etc. Igualmente, si tenemos problemas en la NAND y IOS falla, con los IOS de Nintendo, tendremos que echar mano de un programador de NAND.
- El menú del sistema ya lo conocéis de sobra. Hay varias cosas que pueden causar cuelgues, como por ejemplo banners mal formados. Si el fallo se produce después o justo al cerrarse la pantalla de aviso, se puede corregir utilizando un lector con modchip y un disco autoarrancable. Si el fallo se produce antes, de nuevo, tenemos un brick.
Un sistema de recuperación debería ser capaz de, por lo menos, hacer un backup de la NAND, restaurarlo, y ejecutar código para futuras ampliaciones. El lugar evidente para los backups es la tarjeta SD. Por lo tanto, nos encontramos con el primer problema: ya que estamos antes de boot2, donde no hay ningún driver, hay que hacer un driver para la SD (y para la NAND, pero eso es algo más fácil).
Es casi imposible desarrollar nada sin tener indicaciones de como progresa el código. Starlet no tiene acceso al chipset gráfico, con lo que estamos ciegos. Curiosamente, parece que hay indicaciones de que pueda tener acceso al sistema de audio, pero eso no es que sea muy intuitivo de usar. Bueno, entonces ¿cómo vemos lo que estamos haciendo? Resulta que Nintendo nos ha dejado una ayudita. Hollywood tiene varios registros de GPIO (entradas/salidas de propósito general) para cosas como controlar los LEDs y los botones, etc. En uno de estos registros, hay 8 bits que van directamente conectados a unos puntos de prueba en la placa, y se pueden usar para lo que queramos. De hecho, boot0 los usa para indicar su progreso (en forma de códigos que indican el sector de la NAND que se está leyendo actualmente, y de parpadeos que indican un error). El pinout es el siguiente:
- Código: Seleccionar todo
GP2 TP223-O O-TP220 GP7
GP3 TP224-O O-TP221 GP0
GP1 TP222-O O-TP226 GP5
GP4 TP225-O O-TP219 GP6
Yo he decidido conectarlo a algo un poco mas legible, y el resultado es este:
No es más que un LCD HD44780 de los de toda la vida. Un poquito de código que se ejecuta en el Starlet es el encargado de enviarle los comandos correctos para mostrar texto.
Vale, tenemos una consolita cutre para hacer pruebas. Pero esto no le sirve a ningún usuario que quiera usar y controlar el sistema de recuperación en sí. ¿Qué hacemos? Pues, como buenos hackers, matar tres pájaros de un tiro: el sistema de recuperación será modificable (incluso con el resto de la Wii brickeada), tendrá acceso a los gráficos, y de paso usará tecnología que ya hemos reversado y que todos sabemos usar sin problemas. Vamos a escribir el menú de recuperación para el Broadway (PPC), igual que cualquier otro software de Wii. Nuestro código de Starlet lo cargará desde SD, y despertará al PPC para que empiece a ejecutarlo. Mientras se ejecuta, actuará como proxy para permitirle al PPC acceder al hardware de Starlet - como si fuera un IOS (muy simple), pero a más bajo nivel y sin ningún tipo de restricciones, permitiendo que el PPC tenga acceso total al sistema.
Para terminar, ¿cómo pinchamos esto en boot2? La idea es cojer nuestro código y empaquetarlo delante de boot2. Si no está pulsado RESET al arrancar, lanzaremos boot2 directamente. Si pulsamos RESET, se ejecutará nuestro código. Y como no podemos distribuir boot2 al ser código con copyright de Nintendo, el instalador de todo esto tendrá que extraer el boot2 de la consola, añadirle nuestro código como cabecera, volver a encriptarlo y prepararlo, y finalmente verificar todo e instalarlo.
Espero que esto despeje un poco las dudas sobre el proceso de arranque de la Wii y a donde queremos llegar de momento
