Creo que la cantidad de características que ofrecía esta consola la hacía muy atractiva para la piratería, ya que descifrar el sistema de seguridad permitiría a los desarrolladores caseros tener en sus manos las capacidades de la consola sin tener que pasar por las verificaciones de Nintendo. Sea como fuere, la Wii acabó teniendo una fantástica biblioteca Homebrew.
Protección de copia
Empecemos con la víctima común: la unidad de disco.
Los discos de Wii incluyen la mencionada zona de "burst cutting", inaccesible para los lectores convencionales. Por lo tanto, en ausencia de esto, el lector siempre se negará a leer el contenido.
La unidad de disco no permitirá que nadie pase esta pantalla hasta que se inserte un disco válido.
Los desarrolladores de modchip descubrieron que la unidad contenía una interfaz de depuración llamada "Serial Writer" , aunque este puerto está bloqueado hasta que se introduce una clave secreta. Aun así, era cuestión de tiempo que se descubriera la clave. Una vez ocurrido esto, los modders pudieron desactivar la protección anti-copia y posteriormente desarrollaron un modchip que automatizaba este proceso.
Matsushita lanzó nuevas revisiones de esta unidad ofuscando la interfaz de depuración, sin embargo, se descubrieron otros fallos en el lector que volvieron a habilitarlo.
Cabe mencionar que el principal beneficio de los modchips era la piratería pura y dura, ya que el contenido del disco sigue estando cifrado, por lo que se necesitaban más investigaciones y herramientas para ejecutar código personalizado.
El homebrew de la GameCube, por su parte, ya era posible de ejecutar siguiendo exploits previos descubiertos en la predecesora.
Cifrado del sistema
Esta es probablemente la sección más compleja de esta consola, pero su incesante investigación abrió la puerta a montones de desarrolladores con talento y programas asombrosos.
La Wii diseñó su seguridad interna en torno a un par de cifrados criptográficos (AES, RSA, ECC, SHA-1 y HMAC). Para facilitar las explicaciones, veamos cada grupo por separado:
Cifrado compartido
La comunicación entre muchos componentes (NAND, disco de juego y tarjeta SD) está encriptada para evitar su manipulación. Nintendo eligió un sistema de clave simétrica para protegerla , lo que significa que la Wii utiliza la misma clave para cifrar y descifrar sus datos.
El Starlet tiene tres claves AES de 128 bits almacenadas en su memoria OTP , estas se escriben una vez durante la fabricación:
- Clave común: clave global generada por Nintendo que se encuentra en todas las Wii, se utiliza para descifrar la primera capa de cifrado utilizada en los canales y juegos basados en disco (a partir de ahora nos referiremos a ellos como títulos).
- Clave SD: Se utiliza para cifrar/descifrar los datos transferidos a la tarjeta SD, y sólo el menú del sistema puede realizar estas transferencias.
- Nintendo almacenó una copia de esta clave dentro del IOS sin ninguna razón clara.
- Clave NAND: Esta clave se genera aleatoriamente durante el proceso de fabricación (lo que significa que es única para cada Wii) y se utiliza para proteger el chip NAND.
Con esto, podemos ver que el Starlet se encarga del cifrado/descifrado de contenido sensible, es por esto que esta CPU es la única que tiene acceso a datos confidenciales.
Cadena de confianza
Los títulos contienen otra capa de seguridad, RSA-2048. Se trata de un cifrado asimétrico, lo que significa que necesitamos una clave para cifrar el contenido y otra para descifrarlo. En pocas palabras, esto permite a Nintendo cifrar los títulos utilizando una clave no revelada (llamada "clave privada"), mientras que la Wii los descifra utilizando una "clave pública", que se almacena en la consola. Si los piratas informáticos obtuvieran la clave pública, no sería suficiente para descifrar el sistema de seguridad, ya que se espera que los datos sigan cifrándose con la clave privada, que sólo Nintendo conoce.
Además, RSA no sólo se utiliza para cifrar contenidos, sino también para comprobar la integridad de dicho cifrado. Verás, Nintendo utiliza múltiples claves que se usan para firmar (cifrar) datos ya cifrados, formando una cadena de cifrado con el único propósito de asegurarse de lo siguiente:
- Todas y cada una de las claves utilizadas han sido autorizadas por Nintendo.
- Los datos no se han alterado y se han vuelto a cifrar sin autorización.
Permítanme darles un ejemplo de cómo funciona esto:
- Nintendo crea una clave llamada
x. - Nintendo programa el Starlet para que sólo confíe en los contenidos firmados con la clave
x. - Si el Starlet tiene que descifrar un título con la clave
y, solo procederá siyha sido firmado con la clavex.
Esto se denomina cadena de confianza. Fuera de la Wii, esta técnica se utiliza habitualmente para proteger la mayoría de nuestras comunicaciones en todo el mundo (por ejemplo, los navegadores web que utilizan HTTPS se basan en "certificados raíz" para validar la autenticidad de certificados desconocidos).
Cadena del Starlet
La OTP del Starlet almacena claves públicas (lo que significa que, para nuestros propósitos, sólo puede descifrar y verificar la firma del contenido). Su cadena de confianza está formada por las siguientes claves :
- Clave Raíz: firma la clave CA.
- El Starlet sólo necesita almacenar esta clave (pública), el resto puede ser descifrado (y posteriormente confiado) si ha sido firmado por esta clave.
- La Clave de Autoridad de Certificación (CA): firma las claves XS y CP.
- La Clave XS: esta clave firma "Tickets", un tipo de datos que contiene una lista de claves AES necesarias para descifrar títulos (llamadas claves de título).
- La Clave CP: una vez descifrado el título mediante la respectiva clave de título, la clave CP se utiliza para firmar los metadatos de un título (denominados TMD).
- Aunque no firma el contenido en sí, los metadatos incluyen un hash SHA-1 que el Starlet utiliza para verificar la integridad de esos datos.
Como ves, todo esto permite a Nintendo ser el único distribuidor de contenido, lo que puede ser positivo para los estudios de juegos preocupados por la piratería.
Más claves
Este sistema también contiene un par de claves privadas y públicas de la ECC. La criptografía de curva elíptica (ECC) es otro algoritmo similar al RSA. En este caso, sólo se utiliza para firmar el contenido transferido a través de la tarjeta SD. Esto es lo que impide que los contenidos copiados de una Wii se utilicen en otra.
La clave ECC está firmada por otra clave pública RSA llamada MS, que permitirá al Starlet confiar en la clave ECC.
La última clave utilizada por esta consola es la clave HMAC, que utiliza otro algoritmo que combina hashes SHA-1 y HMAC. Durante el proceso de arranque, el Starlet comprueba que la NAND no haya sido alterada por hardware de terceros. Para ello, calcula el hash SHA-1 de NAND y lo compara con un hash fijo para comprobar si coinciden. Además, el hash guardado se firma con la clave HMAC para garantizar su autenticidad.
Como nota final, la clave HMAC se almacena en SEEPROM (fuera del Starlet), no en OTP.
Observaciones
Después de todo esto, cabe mencionar que cuando el sistema ejecuta juegos de GameCube, no se utiliza ninguno de los métodos de cifrado mencionados. En su lugar, el Starlet sólo comprobará que el juego sólo accede a sus posiciones de memoria designadas. Esto se debe a que 1/4 de la RAM GDDR3 está asignada para simular la antigua ARAM.
La caída del cifrado
Empecemos con las claves AES, el algoritmo puede ser difícil de descifrar, pero si las claves se extraen de alguna manera (especialmente la clave común), esa capa de seguridad quedaría anulada al instante. Por lo tanto, el principal reto es cómo extraerlas.
Diagrama de seguridad del Starlet.
Pues bien, un grupo de hackers llamado Team Twiizers descubrió que la falta de firmas en el modo GameCube puede ser una prometedora zona de ataque . No solo descubrieron que 3/4 de esa RAM GDDR3 no se inicializaban tras ejecutar un programa GC, sino también que puenteando algunos puntos de dirección de la placa base (usando, eso sí, unas pinzas) podían intercambiar los bancos seleccionados de RAM GDDR3, permitiendo el acceso a zonas restringidas. Y he aquí, se descubrieron las claves AES residían allí.
No olvidemos que esto sólo permite descifrar la "primera capa" de seguridad, pero para poder ejecutar programas sin firmar (Homebrew), también hay que crackear RSA. Por desgracia, esto puede ser computacionalmente imposible... A menos que haya fallos en su aplicación. Pues bien, Team Twizzers no se detuvo ahí, así que empezó a invertir la forma en que se codificaba IOS, centrándose en sus funciones de verificación de firmas.
La verificación de firmas RSA, sin entrar en demasiados detalles, funciona comparando el hash de la operación RSA calculada con la firma descifrada. Después de algunas manipulaciones, el grupo descubrió algo gracioso: Nintendo implementó esta función usando strncmp (la comparación de "cadenas" de C).
Para la gente no familiarizada con C, strncmp es una rutina utilizada para comprobar si dos cadenas son iguales. Este método recibe tres parámetros: dos cadenas y un número entero, este último indica el número de caracteres que hay que comparar. Después, strncmp comienza a comparar cada carácter hasta que se alcanza el final de cualquier cadena (o el contador de caracteres). Las cadenas en C son solo una cadena de caracteres terminada en un carácter \0, esto significa que strncmp deja de compararse una vez que cualquier cadena llega a \0. Por lo tanto, al componer un título de Wii de forma que su hash contenga \0 al principio, los cálculos RSA del Starlet se encontrarán comparando hashes muy cortos (o incluso vacíos) con sustanciales posibilidades de colisión (datos diferentes que producen el mismo valor hash). En última instancia, utilizando una cantidad factible de fuerza bruta, esto permitió que la comparación arrojara igual... ¡El título está firmado!
Por si fuera poco, este fallo se descubrió en múltiples versiones de IOS, ¡e incluso en rutinas encontradas en el boot1 y el boot2!
Los albores del Homebrew
Después de esto, sólo quedaba una cosa: hacer que el exploit fuera permanente e implementar una herramienta "fácil de usar", para que pudiera ejecutar programas personalizados sin problemas.
La ejecución de aplicaciones de terceros se realizaba inicialmente mediante una partida guardada falsificada.
Hasta ahora, estos exploits requerían el uso de hardware adicional, por lo que no todos los usuarios podían aprovecharlos... Hasta que Team Twizzers descubrió otro exploit: un desbordamiento del búfer del juego.
Me refiero al famoso The Legend of Zelda: Twilight Princess (un juego de Nintendo, por cierto). TT descubrió que el archivo de guardado del juego podía modificarse para desbordar el número de caracteres utilizados para dar nombre al caballo del jugador. Así, cuando el jugador intenta leer el nombre desbordado, se desencadenaría una reacción en cadena que terminaría en la ejecución de código arbitrario. Esto podría usarse para ejecutar, digamos, un cargador de programas.
Como ahora se podían falsificar las firmas, este archivo guardado manipulado se distribuía fácilmente por la red para que otras personas lo utilizaran. Como resultado, la comunidad homebrew ahora podía ejecutar su software personalizado.
Un estado permanente
Al seguir revirtiendo IOS, se descubrió que las firmas sólo se comprueban durante la instalación de los títulos, no durante su ejecución.
El Canal Homebrew no oficial (2008).Probablemente el hack más fácil de usar de todos los tiempos.
Por lo tanto, TT lo hizo de nuevo. Forjaron cuidadosamente un canal instalable que podía cargar programas arbitrarios desde la tarjeta SD. Si este canal se instalara antes de que Nintendo hubiera tomado medidas para mitigar los problemas de seguridad, la Wii disfrutaría de homebrew de forma permanente (independientemente de que Nintendo parcheara los fallos de su firma en el futuro, como así hizo).
El Canal Homebrew fue el resultado de esto, este título permitía a cualquier usuario poner en marcha programas homebrew que se beneficiaban del control total de este sistema (con todas las implicaciones que esto significa).
La respuesta de Nintendo
Por razones obvias, Nintendo emitió varias actualizaciones de sistema que corregían los exploits de firma en múltiples versiones de IOS, también se ocuparon de sus etapas de arranque defectuosas enviando nuevas revisiones de hardware.
Muchas de estas están llegando.
Sin embargo, todavía se descubrieron fallos fundamentales en este sistema:
- El Broadway puede reiniciar al Starlet a cualquier versión de IOS sin permisos adicionales, permitiendo usar exploits de versiones no parcheadas.
- Las API ocultas de IOS pueden seguir utilizándose sin privilegios especiales, lo que permite un control aún más desautorizado del hardware.
- La unidad de disco puede recibir comandos para leer DVD convencionales y algunos IOS contenían llamadas ocultas para enviar esos comandos. Esto era especialmente preocupante por motivos de piratería.
Por lo tanto, para resolver esto, lo único que quedaba era sólo el juego del gato y el ratón. Durante los meses siguientes, se descubrieron diferentes exploits y Nintendo intentó parchearlos uno tras otro. Este "juego" continuó hasta que la consola llegó al final de su vida útil y no se publicaron más actualizaciones. Podemos asumir que el ratón ganó esta vez.
En el momento de escribir estas líneas, los exploits mencionados en este artículo ya han sido parcheados, pero también sustituidos por otros que funcionan actualmente.
Supongo que no se puede discutir acerca del impacto que tuvo la hacking scene en este sistema, y quién puede olvidar la enorme cantidad de homebrew que se puso a disposición (había incluso una "tienda" de homebrew, que era más rápida y libre que el "Canal Tienda Wii" oficial).