DOCUMENTACIÓN

HACKING GAME CUBE.

Por David Senabre. 2005

El objetivo principal de este documento es explicar de forma más o menos clara los principios que han permitido hackear la Gamecube, y de ofrecer información sobre el funcionamiento general de los modchip, de para qué vale cada cable que se suelda a la consola, etc. Así como de tratar diversos temas sobre el hardware de nuestro cubo ;-) Siempre con fines educativos, nunca con intención de promover un uso ilícito ni de la consola ni de esta información. No me responsabilizo por el uso que se le de.

¿Cómo se ha podido hackear la Gamecube?

Lo que ha permitido hackear la Gamecube ha sido el poder sustituir o modificar la BIOS original. Este proceso no era fácil, porque la BIOS está encriptada. El mecanismo de encriptación es un sencillo XOR, pero para desencriptarlo es necesario conocer la clave, a priori desconocida. Y en teoría sería imposible obtenerla. Pero un fallo(?) de Nintendo ha hecho vulnerable su sistema de cifrado. Antes de explicar el bug que ha permitido sustituir la BIOS original, explicaré un poco el panorama.

En primer lugar, nuestro cubo no tiene una ROM paralela como es usual, sino que la BIOS, también llamada IPL, está contenida en una ROM serie en el chip de RTC (reloj de tiempo real), y creo que también contiene una sram. Este chip está conectado al bus EXI. Como el acceso a una ROM serie es mucho más lento y engorroso que hacerlo a una ROM paralela (obvio), la BIOS se debe cargar en la memoria RAM al encender la Gamecube, para poder acceder fácilmente a ella.

El bus EXI es del tipo SPI. Nos interesarán las líneas de CS (chip select), de entrada y salida de datos serie, y el reloj. Se considera que salida se refiere a la transferencia de datos de la CPU al dispositivo, por ejemplo el chip RTC, es decir, del dispositivo maestro al esclavo. La entrada, lógicamente, es al revés, hacia la CPU. El reloj es generado por la CPU, que es el dispositivo maestro.

A modo de ejemplo, una transferencia típica de la CPU a un dispositivo seguiría el siguiente patrón ;

1º Bajar la línea CS para seleccionar el dispositivo, y avisarle que la acción va dirigida a él, o sea que espabile.

2º Poner en la línea de salida el bit que queramos mandar hacia él.

3º Esperar al siguiente pulso de reloj.

4º Leer la línea de entrada el bit enviado a la CPU desde el dispositivo.

Este esquema es sólo orientativo. Podría cambiar si el bus operara en otros modos, pero para lo que voy a explicar es perfecto. Lo más importante es darse cuenta de que la transferencia es en ambas direcciones simultáneamente. En cada pulso de reloj se transmite y se recibe un bit.

Por lo tanto, si somos la CPU y queremos enviar datos al dispositivo, no esperaríamos que el dispositivo nos enviara nada, ya que le toca recibir. Pero en lo cierto, el dispositivo nos enviará el mismo número de bits que le mandemos, y cómo no esperamos nada de él en ese momento, estos bits son ignorados (a estos bits se le llama dummy). Por lo tanto no hay manera de no enviar información. Siempre se envía, pero cuando no es relevante, se mandan dummy bits, que podrían ser todo ceros, o todo unos, y se ignoran.

El bus EXI está conectado al Flipper. Como interface entre ambos se usa un registro de desplazamiento de 32 bits. Por un lado entran los bits del bus EXI, y por el otro salen los bits hacia el bus EXI. Como se ve, es una comunicación serie, bit a bit. Pero la conexión al Flipper es paralela, de 32 en 32 bits, es decir, todo el registro a la vez. Veamos el esquema.

Por lo tanto, si el Flipper quiere acceder a una posición de la ROM, que está en bus EXI, cargará la dirección en el registro, y estos 32 bits irán saliendo uno a uno hacia la entrada EXI, donde la ROM está a la escucha. Entonces, la ROM manda los 32 bits solicitados, uno a uno, hacia la salida EXI, cargando el registro. Cuando los 32 bits están dentro, Flipper los lee de golpe. Fácil ¿no?

De acuerdo, ahora imaginemos que enviamos datos de la IPL a la memoria RAM. Para ello, cargaríamos bit a bit el registro, y si no me equivoco, el Flipper leería los datos y los almacenaría en la RAM (conectada al Flipper por un bus interno). Después de haber leído 32 bits, lo que esperamos es que se trajeran otros 32 bits de la IPL al registro, uno a uno, para que fueran almacenados, y así sucesivamente. ¿Cuál es el problema? Que una vez que el Flipper ha leído el registro, no lo borra, y por lo tanto, conforme se van metiendo nuevos bits por la salida EXI, los bits antiguos que contenía el registro van saliendo por la entrada EXI como bits dummy. Y son dummy porque lo que estamos haciendo ahora es pasar datos del bus EXI al Flipper, no al revés, y los bits que entran al bus EXI son ignorados. Quizá parezca algo tonto porque los bits que salen son los que acaban de entrar, pero no lo es.

El Flipper se encarga de desencriptar la BIOS conforme le va llegando, y de almacenarla en la RAM, pero la metedura de pata está en que estos 32 bits desencriptados se quedan en el registro, por lo que irán saliendo bit a bit cuando se vaya metiendo nueva información a dicho registro.

El efecto es que mientras se están mandando palabras de la IPL al Flipper, por la entrada EXI van saliendo los 32 bits desencriptados que fueron metidos en la anterior transferencia, y por lo tanto perderemos los últimos de 32 bits de cada bloque. Esto es así porque cuando los últimos 32 bits sean desencriptados, si en lugar de seguir trayendo datos del IPL, lo que hacemos es mandarle datos, o una nueva dirección, los 32 bits descifrados son sobrescritos con los datos a enviar al bus EXI. Esto se entiende mejor gráficamente, pero creo que es la mejor explicación que he leído de esto en todo el mundo, así que no esperes algo mucho mejor ;-)

El Gekko es una CPU de tipo PowerPC, que arranca desde la dirección 0xFFF000100. Por lo visto, los PowerPC tienen su vector de reset en la dirección 0x100, pero existe un bit en uno de sus registros que cambia la base de interrupciones a 0xFFF000000, que más 0x100 da 0xFFF000100. Para quién no lo sepa, el vector de reset es la dirección a la que una CPU salta cuando se reseta la maquina.

El espacio de direcciones 0xFFF000000 es accedido a través del Flipper, que se encarga de transformar la dirección en una transferencia del bus EXI, y de desencriptar al vuelo los datos que vienen de él. El Gekko lee datos en bloques de 64 bits, luego eso significa que empezará leyendo 8 bytes de la ROM, y teniendo en cuenta el bug de encriptación, sólo podremos recuperar 4 bytes desencriptados (los primeros 4). De esta manera son leídos los primeros 2 Kbytes, de los cuales conocemos el 50%. Pero una vez hecho esto, la ROM es leída en bloques, no de 8 bytes, sino de 1Kbyte cada vez. Por lo que de los 1024 bytes recuperaremos 1020. Esto ya no está nada mal. Como de estos 1020 conocemos los bytes cifrados, y los bytes desencriptados, podemos hallar la clave de encriptado para cada byte, y así poder encriptar una pequeña BIOS que se encargue de volcar el contenido completo de la IPL original.

Resumen de hardware

No me esmeraré demasiado ya que está información es mucho más fácil de encontrar. si quieres saber más, te recomiendo que leas mis artículos "La Carrera de los Bits y los Megahercios".

En cuanto a rendimiento gráfico real, se estima que la consola es capaz de mover entre 6 y 12 millones de poligonos texturados por segundo. La Gamecube no está diseñada para ser una máquina que alcance altas velocidades pico o teóricas, sino para mantener un buen rendimiento global en tareas reales. En cambio, Sony, con su Playstation 2, hace muchas deducciones teóricas, dando por ejemplo, cifras de hasta 60 millones de polígonos por segundo. Pero esto no se puede alcanzar nunca. Para empezar, los cálculos en los que se basa, supone que son polígonos sin texturas, ni efectos de luces, ni inteligencia alguna. En la práctica, ambas consolas están muy igualadas.

Componentes

Buses

La Gamecube tiene tres buses principales que conectan el Flipper con el resto del sistema., la 1T-SRAM, el Gekko, y la ARAM.

A parte existen otros buses, que también se conectan todos al Flipper :

VOLVER