En esta ocasión la demora ha sido muy prolongada, hace casi ocho meses desde la última vez que tuvimos oportunidad de conversar.
Y como siempre, hay muchas cosas en el tintero, pero las responsabilidades del mundo real a veces nos complican darnos tiempo para las dosis de debraye.
Sin embargo, para regresar con todas las ganas traigo los resultados de los trasteos de estas últimas semanas.
Nintendo sacó al mercado hace unos pocos años la consola portátil Nintendo 3DS (3DS). Se trata de una evolución del exitoso Nintendo DS (NDs) que incorpora además de doble pantalla, la novedad de desplegar gráficos tridimensionales sin necesidad de gafas.
Sin embargo, al momento de lanzar esta consola su recepción en el mercado no fue del todo satisfactoria. Desde mi opinión, los 'talones de Aquiles' del lanzamiento fueron su precio elevado, la falta de lanzamientos 'vendeconsolas' y la imposibilidad de transmitir la sensación 3D a través de anuncios y reviews. Es decir, para poder experimentar la principal característica de la consola, era necesario tener acceso físico a una y probarla 'con tus propios ojos'.
Con el tiempo la consola bajó de precio (en un movimiento sumamente agresivo por parte de Nintendo), el catálogo mejoró y comenzó a atraer el interés de los videojugadores y desarrolladores. Entre los desarrolladores podemos contar a la 'scene', que se trata de desarrolladores que generan aplicaciones 'hechas en casa' (homebrew). La scene siempre tiene que lidiar con los sistemas de protección de los aparatos que impiden la ejecución de código arbitrario. Para poder sortear ese obstáculo se debe recurrir a brechas de seguridad en el software y/o el hardware de la plataforma objetivo.
Cuando hablamos de código arbitrario nos referimos a cualquier programa, sin algún tipo de restricción.
En el caso del 3DS, el primer frente de entrada de la scene fue a través de las Flashcard. Son dispositivos similares a las tarjetas de juego que emplea la consola, con la ventaja que permiten colocar un programa arbitrario para que sea ejecutado por el sistema. Dicho programa puede ser una aplicación homebrew o la copia de un título lanzado para la consola.
La desventaja de emplear una Flashcard radica en su costo relativamente alto y la relativa dificultad para conseguirlas, debido a que en varios lugares su venta se encuentra restringida (ya que facilitan la piratería).
Después de algún tiempo se fueron encontrando otros puntos de entrada (entrypoints) que permiten ejecutar código arbitrario en la consola, algunos aprovechan errores en algunos juegos (Cube Ninja y The Legend of Zelda Ocarina of Time), otros utilizan errores en los módulos NDS del firmware (MSET), mientras los más difundidos aprovechan vulnerabilidades en el navegador de internet (Spider/Browserhax) o en el propio menú de la consola (Theme/Menuhax).
Cada uno de estos entrypoints funciona en un rango determinado de versiones de firmware, ya que Nintendo trata de cubrir vulnerabilidades con cada nueva versión de sistema. Asímismo cada entrypoint tiene distintos grados de acceso al sistema y taza de éxito. Entre los más estables están el MSET y el Menuhax, mientras que Browserhax es de los menos estables.
Cuando su servidor compró su 3DS el firmware más actual era la versión 9.2, el cual tenía la vulnerabilidad Browserhax que permitía ejecutar las herramientas de la Flashcard Gateway. Gracias a esas herramientas es posible crear una EMUNAND y hacer downgrade (bajar la versión del sistema) a la versión 4.5. En la versión 4.5 se puede emplear el MSET (un entrypoint muy estable) para ejecutar un Custom Firmware (CFW).
Antes de avanzar más en este debraye aclararé algunos términos, ya que una de las peculiaridades de la scene de 3DS con respecto a otras es la cantidad de variantes que hay en cada configuración. En contraste la scene de PSP no tiene muchas variantes, en la actualidad (fin de la vida comercial de la consola) sólo existen dos variantes de CFW (PRO y ME), las cuales difieren en muy pocas funcionalidades.
En el caso de la 3DS los CFW recurren al uso de la llamada EMUNAND. Se trata de una copia de la memoria interna de la consola que se aloja en una tarjeta SD. Esta copia del sistema no realiza las verificaciones de seguridad que se realizan en la memoria del sistema (SYSNAND), por lo que en ella se pueden instalar y ejecutar una amplia gama de aplicaciones. Al ser una copia de la memoria de sistema, no es posible intercambiar EMUNANDs entre distintas consolas (no funciona).
Es decir, en las versiones de sistema 4.5 ~ 9.2 los CFW funcionan de la siguiente forma:
- Se crea una copia de la memoria de sistema en la tarjeta SD.
- Se copian los ejecutables del CFW en la memoria y se establece el entrypoint que se empleará para arrancar del CFW, ya que dependiendo del entrypoint dependerá también el formato de los ejecutables que se empleará.
- Al arrancar el CFW comenzamos a utilizar el sistema almacenado en la EMUNAND, sobre el cual podemos hacer todas las modificaciones pertinentes y ejecutar código arbitrario.
- Al apagar o reiniciar la consola la SYSNAND vuelve a tomar el control, por lo que el CFW no es permanente.
Cuando adquirí mi 3DS realicé los pasos para bajar la versión de sistema a 4.5 y utilizando el MSET (aprovechando que cuento con una Flashcard R4i) arrancar el CFW. Primero utilicé el CFW Palantine, posteriormente el rxTools 2.5.
A pesar de que las cosas funcionaban bien, me parecía engorroso todo el proceso de arranque del CFW, inyección del FBI (aplicación para instalar paquetes en la consola) y la propia instalación de juegos. A mi parecer todo se sentía como un entorno improvisado.
Por un buen tiempo dejé de lado todas las noticias relacionadas a la scene del 3DS, el desarrollo de nuevos exploits, el Homebrew Launcher (HBL) y del lanzamiento de nuevos juegos. Inclusive dejé guardada la consola por un largo periodo de tiempo.
Sin embargo, mi amigo MagmaD un día me preguntó ¿Te aventarías a hacerle el Hardmod a mi 3DS? A lo cuál respondí inmediatamente... ¿Hacerle al 3DS qué?
Entonces me enseñó un video autoría de Yakara Colombia (quien al parecer en realidad es un Link de peluche) donde se explica cómo soldar un conector de tarjeta SD a la tarjeta lógica de un 3DS para poder conectarlo a la computadora, extraer el firmware, aplicarle unos parches y volver a inyectar el firmware en la consola para poder ejecutar un exploit para bajar la versión a la 9.2 (y poder ejecutar CFW). Esta adaptación es llamada Hardmod y permite leer y escribir directamente en la SYSNAND de la consola.
Viendo que el Hardmod es un proceso sencillo (aunque requiere un poco de precisión), me llevé la consola a casa para ponerme manos a la obra ese mismo fin de semana. Realicé todo el proceso de downgrade (versión 10.5 a 9.2 y de 9.2 a 4.5) e incluso preparé la consola para funcionar con el CFW rxTools 2.5 (el que yo usaba) cuando surgió el anuncio más revolucionario de la scene, el Arm9LoaderHax (a9lh).
El a9lh es un exploit que permite ejecutar código arbitrario (payload) en la 3DS cuando apenas arranca, inyectando código en las primeras particiones del sistema, las cuales son accedidas por el contador de programa (PC) del procesador ARM9 de la consola antes de cargar el kernel. Es decir, posibilita ejecutar el payload antes de que siquiera se ejecute el sistema de la consola. Con este exploit se puede ganar control total de los recursos de la consola.
El único detalle que dificulta la aplicación de este exploit (que podríamos llamar el exploit definitivo) es que se requiere obtener la clave "One Time Programmable" (OTP) de nuestra consola. La OTP es una cadena binaria que se escribe en el CPU de la 3DS al momento de fabricar el chip (directo en el silicio, antes de encapsularlo como chip). Dicha cadena es una llave privada de encriptación. Se le llama OTP debido a que ese número se emplea una sola vez, es decir, no hay dos consolas con el mismo OTP. Los sectores de arranque de la NAND de nuestra consola se encuentran encriptados con la llave pública que corresponde a nuestra OTP, es por ello que las NAND no se pueden intercambiar entre consolas, pues la llave de desencriptado no coincidirá y la consola no arrancará.
Debido a que el OTP se encuentra dentro del CPU y no de una memoria externa no volátil, es virtualmente imposible de extraer... A menos que se nos olvide 'cerrar la ventana' y permitir acceso al OTP después de arrancado el sistema. Y precisamente, en las primeras versiones de firmware de 3DS (hasta la versión 3.0) el acceso al OTP no se protegía, lo que nos posibilita leerlo y extraerlo si nuestra consola cuenta con una versión de firmware anterior a 3.0.
Ese es un obstáculo, pero no es el único. Para bajar el 3DS hasta una versión vulnerable (2.1) necesitamos los archivos del firmware correspondientes a la región de nuestra consola, los cuales "misteriosamente" ya no se encuentran disponibles desde los servidores del Nintendo Update Server (NUS). Además en muchos sitios de la scene está vetado enlazar o proporcionar copias de los archivos de firmware debido a una ambigüedad en la interpretación de las leyes de protección de 'copyright'. Ya que bien es cierto que el firmware de las consolas 3DS es propiedad intelectual de Nintendo (es un código escrito por ellos), para llevar a cabo cada una de las guías o tutoriales se requiere del uso de dichos archivos, por lo que dichos sitios cargan con la responsabilidad de incitar a sus lectores a realizar una descarga privada de dichos archivos y por lo tanto infringen los derechos de copyright de forma indirecta (bajo el término jurídico de "provocación"). Dichas políticas de esas páginas de la scene, por lo que podemos ver no los exime de responsabilidad alguna y por otra parte, incluso complican de forma innecesaria un proceso de por sí laborioso.
¿Porqué todo este choro jurisprudencial? Porque para la guía que publicaré a la brevedad, "mi copia personal privada de todos los archivos que empleé en mi consola por un descuido quedará a disposición de internet, ¡Ohh, que descuidado soy! (wink, wink)".
A la brevedad publicaré dicha guía (ya se encuentra escrita y revisada), la cual detallará paso a paso cómo llevar la consola 3DS (en sus versiones originales, no 'New') del firmware 4.5 a la versión 2.1 para poder extraer la OTP y posteriormente llevar la consola a la versión de sistema 9.2 (compatible con varios entrypoints e indispensable para instalar el a9lh) y la versión de EMUNAND a la 10.6 (la más actual al momento de escribir). También se abordará la compilación del a9lh, la instalación en la consola para finalmente terminar con la consola en versión de sistema 10.6 en modo CFW, con lo que el uso de la EMUNAND ya no será necesario. Los archivos que se anexarán corresponden a los utilizados para consolas de región US.
Ahh, y antes de que cualquier otra cosa ocurra, aprovecho para aclarar que el objetivo de la guía y el material que se proporcionará, será para que usted, amable lector aprenda el procedimiento y pueda ponerlo en práctica en un objeto de estudio real (consola). Se le suplica a quienes lleven a cabo este proceso que no lo utilicen con el objetivo de fomentar la piratería (la cual daña de forma importante a la industria), sino que lo lleven a cabo como una actividad de aprendizaje.
El mundo de los videojuegos es muy apasionante no sólo cuando se disfruta de los títulos, sino cuando se estudia y se aprende toda la ingeniería y programación que se emplea para lograr que las plataformas funcionen.
Estamos en contact!
