Hacking The 3ds II: Encontrando el Patrón

Bienvenidos de nuevo! Estamos de vuelta en esta parte 2 “Encontrando el Patrón” si aun no has leido la parte 1… ¡échale un vistazo ahora!

Resumen Rápido

Anteriormente, había analizado que posibles puntos de entrada podría utilizar para conocer más sobre la Nintendo 3DS. La conclusión fue que, al parecer, los contenidos de la memoria RAM no estaban encriptados. Podéis verlo aquí:


Ejemplo de cadena de texto UNICODE que se encuentra en los volcados de memoria RAM


Como se puede observar, si buscamos por cadenas de texto (en encoding UNICODE y no ASCII, ya que la 3DS trae soporte para idiomas extensos, como japonés o español) podemos encontrarlas en texto plano. He buscado lineas de texto que sabía que podrían estar en la memoria, como mi nombre de Perfil de usuario o el nombre de carpetas que tenía en el menú de la consola.

Los volcados de memoria

Podemos encontrar cadenas de texto, pero de por si mismo no es algo interesante. ¿O sí?. Antes de adentrarnos en el oscuro mundo del análisis forense de volcados de memoria, quiero repasar algunos conceptos:

  1. Memoria Virtual: Cualquier computador medianamente moderno, desde ordenadores hasta teléfonos móviles, tiene un procesador capaz de ejecutar varias aplicaciones de forma simultanea. Esto implica que las diferentes aplicaciones comparten los mismos recursos. Si no existiese ningún tipo de separación, esto sería un absoluto desastre. Cualquier aplicación podría leer y modificar los datos de otra. Dado que no se puede “separar” fisicamente los chips de RAM en pequeños trozos.. se inventó la memoria virtual. En resumidas cuentas, cuando se le ordena al procesador ejecutar un nuevo proceso, este lo lanzará haciéndole creer que se está ejecutando como si TODO el sistema estuviese vacío y libre para él. Puede acceder a cualquier dirección de memoria (dentro de la cantidad de RAM que tenga el sistema) que le permitamos que acceda. Y de hecho, esas direcciones, que se llaman virtuales, se corresponden con direcciones de memoria de los chips de RAM instalados en el sistema. La aplicación cree que se está ejecutando sola, aunque en verdad comparte espacio con otras, pero está aislada.

  2. Localización de las páginas de memoria: Sin embargo, los ordenadores modernos son aún más.. complejos y eficients. En un PC, esas direcciones de memoria virtual puede que no correspondan a los chips de memoria RAM: ¡es posible que correspondan al disco duro! (o a otros medios de almacenamiento). Si nuestro programa utiliza mucha memoria, es posible que una parte se encuentre en la RAM, otra parte en el disco duro, etc. El procesador divide esta memoria en unidades que denominamos páginas de memoria.

  3. Tipos de páginas de memoria: Por supuesto, no todas las páginas son iguales. Pueden ser de distinto tamaño, desde unos pocos kilobytes hasta un megabyte. Pero también tienen distintas propiedades. Existen páginas en las cuales puedes excribir datos (w-write) y leer datos (r-read), pero no puedes tratar de ejecutar esos datos como si fueran código (x-execute). De igual manera existen páginas en las cuales puedes tratar los datos que contiene como si fueran código y ejecutarlo, pero no puedes (sobre)escribir ese código por el tuyo propio. En concreto, acabo de describir una protección de seguridad llamada DEP (Data Execution Prevention) o también llamada NX bit (No eXecute bit), que trata de prevenir vulnerabilidades del tipo stack overflow.

Encontrando el Patrón

Conocemos ligeramente cómo puede funcionar nuestra consola internamente. Y tenemos volcados de memoria. Podemos intentar varias cosas: ¿Y si pudieramos distinguir y diferenciar los diferentes tipos de páginas de memoria que había en la RAM? Las páginas que solo puedan ejecutarse, deben contener código. Y las páginas donde se podía escribir y leer, tal vez contengan datos.

El truco se encuentra en la entropía. ¿Eso qué es? En resumen y sin entrar en aburridas definiciones físicas, es la forma de medir la aleatoriedad. ¿¡Chulo verdad!? Pero.. ¿de qué nos ayuda a nosotros? Todo se resume a la forma en la que pensamos las personas y en la forma en la que funcionan los procesadores modernos. Es común que los diseñadores de procesadores intenten hacer las instrucciones del procesador lo más compactas y eficientes posibles, mientras que los programadores… rara vez intentamos almacenar datos de forma eficiente.

Es predecible que las páginas marcadas como ejecutables, las que contengan código, tendran una alta entropía (o aleatoriedad). Mientras que, por el contrario, las páginas que contienen datos, tendrán una entropía baja.

Intentemos comprobarlo. Desafortunadamente no puedo compartir mis propios volcados, ya que estos contienen código propietario con copyright, pero en los próximos posts enseñaré como obtenerlos de nuestras consolas.

Vamos a utilizar una herramienta web llamada binvis para analizar de forma visual la entropía. Se ejecuta en el navegador, así que no hay riesgo de que nadie nos robe nuestros preciados archivos.

Binvis1 Primer vistazo a los volcados de memoria.

Existe un montón de memoria vacía (byte 0x00) ya que realizé los volcados con pocas aplicaciones ejecutándose. Activemos la opción de visualización de entropía:

Binvis2 Ajá!.. esto promete..

Si analizamos con más cuidado las secciones de color rosa (entropía alta) no podemos encontrar ninguna cadena de texto, lo cual tiene sentido. De hecho, parece código!

Binvis3 Posible código identificado.

Intentemos hacer zoom (botón +) y movernos al principio del volcado. Podemos observar lo siguiente:

Binvis4 Hmmm.. ¿algún tipo de identificador de secciones?

Esto puede ser lo que estabamos buscando.

Un dato curioso, es que el código máquina de un procesador no es lo único con entropía alta. Bloques de datos encriptados e imágenes comprimidas, también tienen un alto grado de aleatoriedad.

Podemos repetir el proceso e ir examinando los distintos bloques rosas, a la vez que tomamos nota de las direcciones, relativas al archivo, en los que se encuentran. Más adelante extraeremos estos bloques y tal vez los analicemos con más cuidado.

Cuando un programa se ejecuta, no todo el contenido del archivo se carga en memoria, solo partes importantes, como el código o algunos datos, así que es de esperar que sea fácil identificar el código ni extraerlo de forma precisa.

Conclusiones

En este breve post hemos comprobado que nuestra teoría inicial era correcta, y seguramente seamos capaces de extraer código y otros datos interesantes. En la siguiente entrada veremos cómo analizar más en profundidad esta información, así como otras técnicas y herramientas.

Quiero agradecerle a las siguientes personas por su ayuda o por ideas interesantes:
-@nicowaisman: Me dio algunas ideas sobre cómo analizar la memoria.
-@ws: La idea de analizar la entropía fue suya, así como me ayudó bastante con otras dudas.
-@cortesi: Creador de binvis
-@GovanifY: ehhh, me respondiste a todos los emails xD

comments powered by Disqus