[Tecnico] Reset Glitch Xploit

Tmbinc escribió:Todas las aproximaciones lógicas que puedas pensar para la ejecución de código sin firmar en la Xbox 360, en la mayoría de casos, simplemente no funcionan, pues la arquitectura de la misma fue diseñada para ser segura desde el punto de vista del software.

Durante la secuencia de inicio de la Xbox 360, el procesador Inicia la carga de un código ROM también conocido como 1BL, el cual se encarga a su vez de cargar cierto código firmado con RSA y cifrado bajo RC4 desde la NANC (el CB).

El CB se encarga, en gran parte, de inicializar las tareas de seguridad den procesador, entre las que se incluye el cifrado y la verificación Hash de la memoria DRAM, en tiempo real, por lo que conocemos se utiliza un cifrado AES128 y una "colchon de seguridad" (Toeplitz?) bastante robusto. La encriptación es diferente en cada booteo, pues depende al menos de:

-Un hash del set de eFuses de la consola
-El reloj interno del CPU
-Un valor completamente aleatorio generado por un generador basado en Hardware, dicho generador puede ser apagado, peroexiste un control de "aleatoreidad" (a cargo de 1 bit, de hecho) en el CB, que espera hasta obtiene lo que parece ser un valor aleatorio correcto.


En el CB funciona un motor logico basado en bytecode, con la simple tarea de iniciarlizar la DRAM, posteriormente el CB procede a cargar el gestor de arranque (CD) desde la NAND, y lo ejecuta.

En pocas palabras, el CD carga un kernel desde NAND, lo parchea y procede a ejecutarlo.

Este kernel contiene un pequeño segmento de código con privilegios (hypervisor), cuando la consola esta encendida, es el único código que tiene los permisos suficientes para ejecutar código sin firmar.

En los Kernel 4532/4548, Aparece una falla crítica en el hypervisor, y es por eso que todos los hacks conocidos requieren utilizar en cierta medida estos kernels y aprovechar esta vulnerabilidad para ejecutar código no firmado.

En las consolas actualizadas, el CD contiene un valor hash de estos dos kernels y detiene el proceso de arranque si intenta cargar alguno de ellos.

El hipervisor es una pieza relativamente pequeña de código, por lo que es muy sencillo localizar una falla, y no parece probable que aparezca una nueva versión que contenga algo que autorice la ejecución de código sin firmar.

Sin embargo, Por otro lado, tmbinc dijo que la XBOX 360 no fue diseñada para soportar ciertos ataques via hardware, tales como el Timming Attack y el "glitching".

En el Glitching La acción es básicamente forzar cierto bugs a nivel de procesador mediante electrónica.

Esa es la forma en que solía ser capaz de ejecutar código sin firmar.

Descubrimos que al enviar pequeños pulsos al procesador mientras estaba inicando, este no se reiniciaba, por el contrario, cambiar la forma en que el código se ejecuta. Parece que esto es muy efectivo con las funciones que comparan dos valores de memoria en los bootloader pues siempre devuelven "no hay diferencia". La función de comparación de la memoria se utilizan entre otras cosas, para comparar el hash SHA del bootloader con los Hash almacenados, y si son idénticos, lo ejecuta.

Podemos introducir un bootloader que no pase la verificación hash de la NAND, sin embargo gracias al Glitch, se le dará por valido y procederá a su ejecución inmediata

En las consolas FAT, el bootloader al que aplicaremos el glitch es el CB con el fin de lanzar el CD que queremos.

Cjak descubrió que enviando la señal CPU_PLL_BYPASS, fuerza a la CPU a ralentizarse bastante y hay un punto de prueba en la placa base que trabaja a una fracción de la velocidad de la CPU, es de 200Mhz cuando el Dashboard está en funcionamiento, 66,6 MHz cuando se inicia la consola y cuando la señal CPU_PLL_BYPASS esta activa es de 520Khz.

Asi que se procede de la siguiente manera:

- Activamos CPU_PLL_BYPASS código POST 36 (hex).
- Esperamos a que se inicie el codigo POST 39 (POST 39 es la comparación de la memoria entre el hash base y el hash almacenado en la imagen), e inicializamos un contador.
- Cuando el contador llegue a un valor específico (a menudo alrededor del 62% del progreso total del POST 39), se envía un pulso de 100 ns de CPU_RESET.
- Esperamos un momento y luego desactivamos CPU_PLL_BYPASS.
- La velocidad de la CPU vuelve a la normalidad, y con un poco de suerte, en lugar de obtener un error POST AD, continúa el proceso de arranque y el CB es el ejecutado con nuestro CD.


La NAND tiene un CB con "paridad a zero" Nuestra carga de un CD modificado requiere de un SMC modificado también.

Una glitch como este, por su naturaleza, es poco confiable, nosotros utilizamos un SMC Modificado, que se reinicie infinitas veces (en comparación con el SMC que lo hace cinco veces y luego reinicia la consola con RROD) hasta que la consola haya iniciado correctamente.
En la mayoría de los casos, la consola se iniciará en menos de 30 segundos después de encenderla.

El bootloader al que aplicamos el glitch es el CB_A, de esta manera se puede iniciar el CB_B que queremos.

En las consolas SLIM, no fuimos capaces de encontrar una pista en la placa madre que activase el CPU_PLL_BYPASS.

Nuestra primera idea fue remover el el reloj interno maestro de 27Mhz , y generar nuestro propio reloj en su lugar, pero fue un cambio complejo, que no dio resultados.

Luego buscamos otras maneras de disminuir la velocidad de la CPU y se descubrió que el chip HANA posee registros PLL configurables de 100MHz que fuerzan la CPU y la GPU.

Al parecer, estos registros son escritos por el SMC a través del bus I2C, El bus I2C es de libre acceso desde el punto (J2C3).
Por lo tanto el chip HANA es nuestra arma para reducir la velocidad de la CPU (tmbinc lo sentimos, no siempre se puede estar en lo cierto, no es aburrido y de hecho es un bus de interés)

Asi que se procede de la siguiente manera:
- Le enviamos un comando por i2c hacia HANA para frenar la CPU u obtener un codigp POST D8.
- Esperamos aparesca un codigo POST DA (POST DA es la comparación de la memoria entre el hash base y el hash almacenado en la imagen), e inicializamos un contador.
- Cuando el contador llegue a un valor específico, se envía un pulso de 20ns de CPU_RESET.
- Esperamos un momento y luego enviamos un comando via i2c hacia HANA para que el reloj de la CPU vuelva a la normalidad.
- La velocidad de la CPU vuelve a la normalidad, y con un poco de suerte, en lugar de obtener un error POST F2, continúa el proceso de arranque y CB_A ejecuta nuestro CB_B modificado.

Cuando CB_B se inicia, la DRAM no se ha inicializado, por lo que debemos aplicar los siguientes parches para permitir la ejecucion de cualquier CD:

- Activación permanente de modo "paridad Zero" con el fin de utilizar un SMC modificado.
- No des-encriptar ningun CD y recibir un CD normal de la NAND.
- No detener el proceso de arranque si el CD no tiene un hash correcto.

El CB_B está cifrado con RC4, la clave viene privada viene de la CPU-KEY, cómo obtener la clave de cifrado sin tener la CPU-KEY?

El Cifrado RC4 es mas o menos:

texto cifrado = texto normal xor flujo de numeros pseudoaleatorios

Así que si conocemos el texto normal y el cifrado, podemos conocer el flujo de numeros pseudoaleatorios, y con el, podemos cifrar nuestro propio código. Trabaja como esto:

flujo numeros pseudoaleatorios = texto normal xor texto cifrado

nueva encriptacion = flujo numeros pseudoaleatorios xor texto normal modificado

Usted puede pensar que esto es un problema muy facil, pero ¿cómo se obtiene el texto normal en el primer lugar?

Fácil: conocemos el texto normal del CB de las consolas de FAT, y que supone que los primeros bytes del código son los mismos que el CB_B nuevo, asi pues hemos sido capaces de cifrar una pequeña pieza de código para desifrar la CPU-KEY y desencriptar el CB_B!

Nuestra NAND ahora contiene el CB_A, un CB_B modificado, un CD sin cifrar y modificado, y un SMC modificado.

El SMC se modifica para permitir un número infinito de reinicio del sistema, y para evitar emitir órdenes sobre el bus I2C, mientras que realizamos nuestros envíos.

puede que aun no se haya dado cuenta pero el CB_A no contiene ningún tipo de verificación sobre la revocación eFuses, este Xploit no es parcheable.

Nada es perfecto, hay algunas advertencias sobre este hack:

- A pesar de la falla se encuentra en lugar adecuado (tasa de éxito del 25% por ensayo en promedio), puede tomar unos minutos para que la consola arranque y ejecute código sin firmar.
- La tasa de éxito está relacionado con el has del bootloader modificado que se desea ejecutar (para FAT CD y para SLIM CB_B).
- Se requiere un material rápido y preciso para enviar el pulso de reset.

Utilizamos un CPLD Xilinx CoolRunner II (xc2c64a), ya que es rápido, preciso, reprogramable, barato y funciona con dos niveles de tensión diferentes al mismo tiempo.

Usamos la un reloj de 48 MHz para el contador del glitch. Para la Slim 96MHz
El Código CPLD está escrito en VHDL.
Tenemos que saber el código POST actual, nuestra primera implementación utilizaba los 8 bits del puerto para este propósito, pero ahora estamos en condiciones de detectar cambios de un solo bit del POST hacer el montaje más fácil .

-No incluimos software de MS en el paquete para realizar el hack.
-El objetivo de este hack es ejecutar Xell y otros programas libres, yo (GliGli) NO promuevo BAJO NINGUNA CIRCUNSTANCIA, la piratería o cualquier cosa que semejante a ella, sólo quiero la oportunidad de hacer lo que quiera y pueda con el equipo que compre, incluida la carga de mi propio codigo en el.