Hacking The 3ds IV: Ataques Hardware
Introducción
En este post vamos a introducirnos de lleno en el mundo de los ataques a nivel de hardware, especificamente orientados a la 3ds pero totalmente aplicables a otros dispositivos. He descrito todo con el máximo nivel de detalle posible, intentando explicar conceptos previos. Espero que sea de utilidad, y además, que sirva para preservar del olvido algunos increibles ataques que la pequeña consola de Nintendo ha visto.
Ataques Hardware
Hace unos años, cuando escribí mi primer artículo sobre hacking de la 3ds, pensaba que los ataques en el hardware pertenecían a ese tipo de habilidades mágicas que son imposibles de aprender si no has nacido con ellas. Sin embargo, haciendo retrospectiva, estoy muy contento con lo conseguido hasta ahora, y a medida que aprendo más y más no todo parece tan oscuro y misterioso. En parte, algunos conocimientos que me han ayudado los he aprendido en la universidad, pero no temas querido lector, puedes encontrar toda esta información en internet, y yo hoy aquí voy a intentar explicar lo máximo posible.
Volcado de memoria NAND
Para preservar algunos de los ataques que ha vivido la scene de esta consola, empezaré hablando sobre los volcados de la memoria NAND. Este tipo de modificaciones en el hardware han sido recurrentes tanto en la 3ds como en prácticamente todas las consolas de Nintendo.
¿Qué es una memoria NAND?
Una memoria NAND no es más que uno de los muchos tipos de memorias flash basedas en puertas lógicas NAND. Como vimos en el primer post, la 3ds utiliza una memoria NAND interna de 1GB fabricada por Samsung.
Sin embargo, otros ejemplos de memorias NAND son algunas tarjetas SD. Estas simplemente son extraíbles, mientras que la memoria interna de la 3ds está soldada.
Para conocer más en detalle como funcionan las tarjetas SD, recomiendo este documento Pero en resumen,las tarjetas SD pueden funcionar en un modo de alta velocidad, o en un modo de baja velocidad basado en el protocolo SPI.
No es mi objetivo explicar hasta el último detalle de como estan construidas estas memorias. Así que, por el momento, veamos como funcionan, al menos en modo rápido.
Normalmente para utilizar este modo solo necesitamos utilizar los siguientes pines de la tarjeta:
- CMD I/O , que es una línea para enviar comandos
- Un pin de datos, por ejemplo DAT0 (para leer los contenidos que especifiquemos a través de CMD I/O)
- CLK que corresponde a la señal de reloj que marca la velocidad.
- VDD y GND para suministrar electricidad a la memoria.
En la 3ds, debido al diseño del circuito de la PCB (la “placa base”), estos pines están comunicados con algunos componentes y pines de la placa. Es decir, no hace falta desoldar el chip para leerlo. Sencillamente con soldar unos cables en esos contactos nuestra información y comandos llegarán directos hasta el chip.
Estos son dichos contactos en la consola Old3DS:
Pines necesarios + un pin alternativo para el clock (CLK) en otra parte de la placa.
El lector ávido habrá notado que no hay pin VDD ;) esto se debe a que no es necesario. No necesitamos alimentar el chip manualmente. Al estar la consola encendida este se encenderá.
Como ejemplo bonus aquí están los pines para acceder a la memoria nand de la Nintendo DSi:
El último detalle que hay que solucionar es cómo hacer llegar esos contenidos a un ordenador. Podríamos invertir en implementar los comandos para hablar con la memoria en un Arduino, Raspberry Pi, o FPGA, pero existe un truco mejor. ¿Cuál es este truco? Realmente se trata de la parte más sencilla de todo el ataque. Vamos a crear un adaptador casero con componentes súper baratos y vamos a dejar que el sistema operativo de nuestro PC se encargue del trabajo duro, la comunicación.
El concepto es sencillo. Os había dicho que una tarjeta SD y la memoria NAND compartían el mismo protocolo, ¿verdad?. ¿Por qué no hacer creer al ordenador que la memoria es una tarjeta SD para que la lea?
Un ejemplo más “común”. Los adaptadores de microSD a SD hacen lo mismo. Simplemente conectan los pines de la microSD, que son pequeños, a unos más grandes del tamaño de una tarjeta SD, para que el lector de SD de un PC pueda leer la tarjeta. Entonces… ¿y si fabricamos un adaptador de NAND a SD?¿Funcionaría? La respuesta es SI. Como puedes ver en la imagen de arriba, es precisamente en lo que consiste esta técnica. La parte inferior de los cables va soldada a la placa de la consola, y la superior la soldamos a un adaptador de microSD a SD que vale menos de un euro. Y eso es todo. Conectamos este adaptador a un ordenador y listo, hablará con la memoria como si una tarjeta SD fuese. Un detalle importante, es que aparecerá sin formato. Podemos volcar su contenido con un software que permita hacer imágenes de discos raw, como dd (en linux) o win32diskimager (en windows).
RAM Sniffing, RAM tracing y RAM injection
La lectura y escritura de la NAND ha sido un concepto simple, para entrar en calor. Veamos ahora un ataque más complejo. La idea es la siguiente: Interceptar las líneas (normalmente llamadas buses) que conectan la memoria RAM con la placa, y registrar las operaciones de escritura y lectura que hace el procesador en la memoria RAM, para asi generar una imagen o volcado de la memoria en un momento específico. Esto puede hacerse con una FPGA.
Este ataque se conoce como RAM Tracing y la única implementación pública y conocida en consolas fue realizada por @scanlime hace algunos años. Lo hizo con la RAM de la Nintendo DSi. Puedes encontrar más información
Alternativamente, podemos extender el ataque, hasta el punto en el que también permita inyección o emulación de los contenidos de la memoria RAM.
Aunque utilizamos el mismo hardware, una FPGA ,debo decir que se necesitan unas habilidades de soldadura (y de-soldadura) extremas. Para este ataque, lo que haremos será interceptar las lineas de datos de la memoria como en el ataque anterior. Pero además, tal y como hizo @scanlime, hay que interceptar la línea CS (Chip Select) de la memoria, para que, cuando detectemos que la CPU está intentanto leer algunos datos de la RAM,nuestra FPGA redireccione esos contenidos a su propia memoria, de forma que proveeremos a la consola con datos “falsos” o modificados.El trabajo de @scanlime es impresivo ya que es, de lejos, la única implementación libre y documentada.Puede verse en los links de arriba.
Modificación/inyección de cadenas de texto en la RAM
Sin embargo, también es remarcable el trabajo de neimod, quien presuntamente fue la primera persona en hackear la 3ds. Gracias a las siguientes imágenes de su trabajo (que han estado desaparecidas de internet durante mucho tiempo) puedo deciros que utilizó una placa personalizada con una FPGA para hacer un ataque muy muy similar, en la 3ds:
Desafortunadamente se cree que neimod vendió todo su trabajo e información. Más tarde todas las fotos fueron borradas pero en este post puedes apreciar semejante trabajo de soldadura e ingeniería.
No puedo asegurar la veracidad de la foto que dice “#Opening JTAG…”. Puede que sea falsa y la persona que la posteó intentó crear un engaño diciendo que se había conectado a la 3ds utilizando JTAG(lo cual es, en teoría, imposible) o alguien fue capaz de restaurar el depurador JTAG del procesador y no había sido elimidado después de todo. O tal vez sea el output del programador de la FPGA.. nunca lo sabremos.
Emulación de EEPROM + Exploit en partida guardada
Vamos a ver ahora un ataque algo diferente. Es muy interesante ya que es algo bastante nuevo e innovador. Y sí, también requiere una FPGA. Sin embargo, hay que soldar mucho menos, y las soldaduras son muy simples.
La primera implementación que descubrí de este ataque fue el trabajo de Micah Elizabeth Scott (scanlime) y podéis encontrarlo aquí:
17/11/2019 EDIT: Al parecer, el Team Twiizers consiguió incluso antes hacer un ataque de emulación utilizando.. Arduino! Échale un vistazo en la Parte 5 de esta serie.
Con este hardware es posible emular la EEPROM donde guarda las partidas guardadas el cartucho y “alimentar” en tiempo real al juego con una partida modificada. Lo interesante es que el juego utiliza estos datos, asi que es un buen lugar para buscar exploits, como veremos en el próximo post.
Hardware de scanlime ejecutando un exploit de modo DS
Volviendo al presente, hace poco tiempo que mi amigo Gericom desarrolló una interfaz similar para la DS, con la sutil diferencia de que su hardware emula la memoira ROM, siendo capaz de cargar juegos de DS y DSi desde su FPGA. Fue un paso más allá y hasta diseño y fabricó su propia PCB en lugar de manipular un cartucho existente.
Las FPGAs son dispositivos que pueden actuar como practicamente cualquier componente electrónico digital. Los proyectos mostrados nos dan el poder para emular memorias ROM o EEPROM e interactuar con la consola. Esto es muy curioso, ya que los cartuchos de 3Ds son practicamente similares, salvo que estos incluyen memorias de mayor capacidad, en conclusión, podemos reproducir estos mismos ataques. Cambiando los datos de la partida guardada podemos atacar el código del juego y encontrar vulnerabilidades.
Me encuentro trabajando en un proyecto de hardware similar, donde usaré una FPGA para crear mi propia interfaz ;)
Glitch attacks / fault injection (inyección de glitches)
Este tipo de ataques es, en mi humilde opinión, el más sencillo de entender y aun asi el más caro y complejo de implementar en el mundo real. La idea es introducir glitches (pequeños fallos lógicos) en el procesador (que es en resumidas cuentas, una máquina de estados) de forma que sea posible saltar instrucciones o modificar las ya existentes, entre otros trucos de magia.
Y sorpresa. Ha habido ataques de inyección de glitches exitosos contra el bootloader de la 3DS en los últimos años.
Ejemplo práctico de un ataque del tipo fault injection.
Es interesante resaltar que existe hardware específico para realizar estos ataques, como el Chipwhisperer aunque tiene un precio elevado.
Conclusiones
¡Y hasta aquí hemos llegado! En el próximo post mostraré un exploit totalmente funcional en el modo sandbox, como atacar código nativo desde nuestro exploit y también algunos de mis hardwares terminados!! Nos acercamos a pwnear la 3Ds por completo.
Quiero agradecer en especial a @Nitehack (que salvó todo el trabajo de neimod hace años y gracias al cual no ha desaparecido) a @Gericom (un tipo increible y con una “sabiduría” técnica enorme) y a @ChampionLeake