28 August 2011 | Publicado por Dekuwa en Videojuegos
Tras 18 meses de trabajo, gligli ha publicado The Reset Glitch Hack, un nuevo exploit para Xbox 360. Requiere la instalación de un chip y es compatible con la mayoría de modelos, todos los Slim y los Zephyr y Jasper de las FAT. Las Falcon tendrán que esperar un poco más.





[Tienes que estar registrado y conectado para ver esa imagen]



El funcionamiento, explicado de forma simple, consiste en el envio de pequeños pulsos al procesador desde el chip con el fin de desestabilizar la consola y hacerle creer que un CB modificado está correctamente firmado. Es algo que no funciona siempre, por lo que hay que repetir el proceso hasta que salga. Una vez que el CB modificado ha sido validado por la consola ya es posible ejecutar código sin firmar en ella, en el ejemplo del video el XeLL.









[Tienes que estar registrado y conectado para ver esa imagen]


* La Xbox 360 falla restablecer hackear *


Introducción / algunos datos importantes

tmbinc mismo lo dijo, los enfoques basados ​​en software de ejecutar código sin firmar en el 360 en su mayoría no funcionan, fue diseñado para ser seguro desde el punto de vista del software.

El procesador comienza a ejecutar el código de la ROM (1BL), que luego empieza a cargar una firma RSA y encriptado RC4 parte del código de la NAND (CB).

CB entonces inicializa el motor de procesador de seguridad, su tarea será hacer encriptación en tiempo real y comprobar hash de la memoria DRAM física. Por lo que hemos encontrado, es el uso de cifrado AES128 y fuerte hashing (Toeplitz?). La criptografía es diferente cada vez que arranque, ya que se siembra por lo menos de:
- Un hash de la fuseset todo.
- El valor del contador de base de tiempo.
- Un valor realmente aleatorio que viene desde el generador de números aleatorios de hardware del procesador incorpora. en grasas, que podrían ser RNG electrónicamente desactivado, pero no hay un cheque de "aleatoriedad aparente" (sólo una cuenta de 1 bits) en el CB, que sólo espera a que un número aparentemente aleatorio apropiado.

CB continuación, puede ejecutar algún tipo de motor de software simple bytecode basado en cuya tarea será principalmente para inicializar DRAM, CB se puede cargar el gestor de arranque siguiente (CD) de la NAND en él, y ejecutarlo.

Básicamente, el CD se carga un kernel base de NAND, el parche y ejecutarlo.

Que el núcleo contiene una pequeña porción privilegiada de código (hipervisor), cuando la consola se ejecuta, este es el único código que tiene los derechos suficientes para ejecutar código sin firmar.
En 4532/4548 versiones del núcleo, una falla crítica en lo que parecía, y todos los conocidos 360 hacks necesarios para ejecutar uno de los núcleos y explotación de esa falla para ejecutar código no firmado.
En 360 válidos, el CD contiene un valor hash de los dos núcleos y se detendrá el proceso de arranque si intenta cargarlas.
El hipervisor es una pieza relativamente pequeña de código para comprobar los defectos y, aparentemente, no los más nuevos tiene alguna falla que podría permitir ejecutar código sin firmar.

Por otro lado, tmbinc dijo que el 360 no fue diseñado para resistir los ataques de ciertos equipos como el ataque del tiempo y "glitching".

Glitching aquí es básicamente el proceso de la activación de los fallos de procesadores de medios electrónicos.

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



El fallo restablece en pocas palabras



Hemos encontrado que mediante el envío de un pulso de reset pequeño al procesador, mientras que es más lento no se restablece sino que cambia la forma en que el código se ejecuta, parece que es muy eficiente en la toma de gestores de arranque funciones memcmp siempre vuelven "no hay diferencias". memcmp a menudo se utiliza para comprobar el hash SHA gestor de arranque que viene contra uno que se almacena, lo que permite que se ejecute si son los mismos. Por lo tanto, se puede poner un gestor de arranque que no Verificación del hash en NAND, falla el anterior gestor de arranque y que se ejecute, lo que permite casi cualquier código se ejecute.




Detalles para el hack de la FAT



Las grasas, el gestor de arranque que falla es el banco central, por lo que se puede ejecutar el CD que queremos.

cjak encontró que al afirmar la señal CPU_PLL_BYPASS, el reloj de la CPU se ralentiza mucho, hay un punto de prueba en la placa base que es una fracción de la velocidad de la CPU, que es 200Mhz cuando el guión funciona, 66.6Mhz cuando se inicia la consola, y 520Khz al que la señal se afirma.

Por lo tanto, va así:
- Afirmamos CPU_PLL_BYPASS alrededor de códigos POST 36 (hex).
- Los esperamos para POST 39 inicio (POST 39 es la memcmp entre hash almacenado y el hash de la imagen), y comienza un contador.
- Al contrario que ha llegado a un valor exacto (a menudo alrededor del 62% de la POST toda la longitud 39), se envía un pulso de 100 ns en CPU_RESET.
- Esperamos un tiempo y luego nos deassert CPU_PLL_BYPASS.
- La velocidad de la CPU vuelve a la normalidad, y con un poco de suerte, en vez de AD error de la POST, el proceso de arranque continúa y CB funciona nuestro CD personalizado.

La NAND contiene un cero pares CB, nuestra capacidad de carga de un CD personalizado, y una imagen modificada SMC.
Una falla poco confiable por su naturaleza, se utiliza una versión modificada de la imagen que se reinicia infinitamente SMC (es decir, imágenes de archivo reiniciar 5 veces y luego RROD) hasta que la consola ha arrancado correctamente.
En la mayoría de los casos, el fallo tiene éxito en menos de 30 segundos desde el encendido de esa manera.



Los detalles de la SLIM




El gestor de arranque que falla es CB_A, por lo que se puede ejecutar el CB_B que queremos.

En adelgaza, no fueron capaces de encontrar una pista de la placa base para CPU_PLL_BYPASS.
Nuestra primera idea era quitar el cristal de 27Mhz maestro 360 y generar nuestro propio reloj lugar, pero fue una modificación difícil, y no dió buenos resultados.
Luego buscamos otras maneras de disminuir el reloj de la CPU hacia abajo y se encontró que el chip HANA había configurable registros PLL para el reloj de 100Mhz que se alimenta de la CPU y la GPU pares diferenciales.
Al parecer, los registros son escritos por el SMC a través de un bus I2C.
Bus I2C puede ser visitado libremente, es aún disponibles en la cabecera (J2C3).
Así que el chip HANA ahora se convertirá en nuestra arma de elección para disminuir la CPU hacia abajo (tmbinc sentimos, no siempre se puede estar en lo cierto, no es aburrido y que se sienta en un autobús interesante;)

Por lo tanto, va así:
- Nosotros enviaremos un comando i2c a la HANA para frenar la CPU en el código POST D8.
- Los esperamos para POST DA inicio (POST DA es el memcmp entre hash almacenado y el hash de la imagen), y comienza un contador.
- Al contrario que ha llegado a un valor preciso, enviamos un pulso de 20ns en CPU_RESET.
- Esperamos un tiempo y luego enviar un comando i2c a la HANA para restaurar el reloj de la CPU regular.
- La velocidad de la CPU vuelve a la normalidad, y con un poco de suerte, en vez de error de la POST F2, el proceso de arranque continúa y CB_A corre nuestra CB_B personalizado.


Cuando se inicia CB_B, DRAM no es inicializado por lo que decidimos sólo se aplican unos parches para lo que se puede ejecutar cualquier CD, los parches son:
- Siempre activar el modo de cero pares, de modo que se puede utilizar una imagen modificada SMC.
- No descifrar CD, en lugar de esperar que un CD de texto en NAND.
- No se detenga el proceso de arranque si hash de CD no es bueno.


CB_B es encriptado RC4, la clave viene de la llave de la CPU, así que ¿cómo parche CB_B sin conocer la clave de la CPU?
RC4 es básicamente:
encriptado = xor texto pseudo-aleatorios keystream
Por lo que si sabemos y texto encriptado, se puede obtener el flujo de clave, y con el flujo de clave, podemos cifrar nuestro propio código. Se va así:
adivinado-pseudo-aleatorios keystream = encriptado xor texto
nuevo-encriptado = adivinado-pseudo-aleatorio-xor keystream texto-patch
Usted podría pensar que hay un problema de la gallina y el huevo, ¿cómo hemos llegado texto en el primer lugar?
Fácil: teníamos texto CBS de las consolas de grasa, y pensamos que los primeros bytes del código sería el mismo que el CB_B nuevo, así que podríamos cifrar una pequeña pieza de código para descargar la clave de la CPU y CB_B descifrar!

La NAND contiene CB_A, un CB_B parcheado, nuestra capacidad de carga de una costumbre CD texto y una imagen modificada SMC.
La imagen de SMC se ha modificado para que reinicie infinito, y para evitar que periódicamente el envío de comandos I2C, mientras que nuestro envío.

Ahora, tal vez no se han dado cuenta todavía, pero CB_A no contiene el control de fusibles de la revocación, por lo que es un hack unpatchable!




Advertencias



Nada es perfecto, así que hay algunas advertencias de que el hack:
- Incluso en la falla que encontramos es bastante fiable (25% tasa de éxito por intento de media), puede tomar hasta unos pocos minutos para que arranque con código sin firmar.
- Que la tasa de éxito parece depender de algo así como el hash de la versión modificada del bootloader que queremos ejecutar (CD para las grasas y CB_B para adelgaza).
- Se requiere un hardware preciso y rápido para poder enviar el pulso de reset.




Nuestra implementación actual




Se utilizó un Xilinx CoolRunner CPLD II (xc2c64a) junta, porque es rápido, preciso, actualizable, barata y puede trabajar con dos niveles de tensión diferentes al mismo tiempo.
Usamos el reloj 48Mhz de espera desde el 360 para el contador de saltos. Para el corte delgado, incluso el contador funciona a 96MHz (incrementado en los bordes de subida y bajada del reloj)
El código CPLD está escrito en VHDL.
Lo necesitamos para ser conscientes de los códigos POST del corriente, nuestras implementaciones utilizó por primera vez el conjunto de 8 puertos DESPUÉS bits para esto, pero ahora estamos en condiciones de detectar los cambios de poco POST sólo uno, lo que hace más fácil el cableado.


Conclusión

Tratamos de no incluir ningún código de derechos de autor de MS en las herramientas de corte en libertad.
El objetivo de este truco es ejecutar Xell y otros programas libres, I (gligli) no lo hizo para promover la piratería o cualquier cosa relacionada, yo sólo quiero ser capaz de hacer lo que quiera con el hardware que he comprado, incluyendo la ejecución de mi propio código nativo en él.




[Tienes que estar registrado y conectado para ver esa imagen]



Xbox 360 falla restablecer hackear v1.00


1 - Lista de carpetas y para qué sirven:

\ Common: Archivos comunes entre 360 ​​y 360 delgada de grasa.
\ Common \ lptjtag_programmer: Esquema para un programador de CPLD sencilla con PC puerto paralelo LPT. Que necesita para poder tanto el programador y el CPLD con 3,3 voltios.
\ Common \ imgbuild: script Python para construir una imagen de memoria flash NAND.
\ Common \ cdxell: CD de reemplazo que se ejecuta Xell, CDjasper es de jaspes y CD es para otra cosa.
\ Common \ Xell: Xell la imagen, la versión de restablecer hackear fallo.
\ FAT: los archivos de 360 ​​FAT.
\ FAT \ glitch48nofullpost: código CPLD, uno por cada revisión de hardware.
\ FAT \ cableado: esquemas y fotografías.
\ SLIM: los archivos de 360 ​​SLIM.
\ SLIM \ glitchslimnodp: código CPLD.
\ Cableado SLIM \: esquemas y fotografías.

2 - Procedimiento básico para la FAT 360 (Zephyr, jaspe)

2.1 Programa de la CPLD Xilinx con impacto, un programador de CPLD de su elección y el archivo JED para su revisión de hardware 360.

2.2-Wire de su 360 con los esquemas y las imágenes en / FAT / cableado

- Si está utilizando una tabla de CMOD, no se olvide de quitar R2 y R3 corto sobre el mismo.
- Cable de tierra con alambre más grueso.

2.3 Construir la imagen NAND, por ejemplo, para una piedra de jaspe el comando debería ser algo así como:

python comunes \ imgbuild \ build.py original_nand.ecc comunes \ cdxell \ CDjasper comunes \ Xell \ Xell-gggggg.bin

(Es necesario hacer un volcado de NAND antes de eso)
(Si usted no tiene una piedra de jaspe, usted necesitará una copia de un archivo de texto plano jaspe SMC (v2.3))

2.4-Flash la salida resultante \ image_00000000.ecc utilizando el comando w + nandpro.

3 - Procedimiento básico para la 360 slim (Trinidad)

3.1-Programa de la CPLD Xilinx con impacto, un programador de CPLD de su elección y el archivo JED para su revisión de hardware 360.

3.2-Wire de su 360 con los esquemas y las imágenes en / delgado / cableado.

- Si está utilizando una tabla de CMOD, no se olvide de quitar R2 conectar almohadilla superior de R2 para bajar pad de R1 en el CMOD.
- Cable de tierra con alambre más grueso.

3.3 Construir la imagen NAND, por ejemplo, el comando debería ser algo así como:

python comunes \ imgbuild \ build.py original_nand.ecc comunes \ cdxell \ CD comunes \ Xell \ Xell-gggggg.bin

(Es necesario hacer un volcado de NAND antes de eso)

3.4-Flash la salida resultante \ image_00000000.ecc utilizando el comando w + nandpro.

4 - Disfruta de tu hackeado = 360)




[Tienes que estar registrado y conectado para ver esa imagen]






[Tienes que estar registrado y conectado para ver este vínculo]

una cosilla oscar creo que te has equivocado de apartado.
:S

Si, llevas razon, ya esta en el sitio correspondiente, gracias tio

de nada

Buenas me llamo juan tengo problemas con placa jasper 256mb, echo todo lo del tutorial para reset glich hack, pero tarda mucho en arrancar xell y ggbuild. tengo chip cpld.

Las dudas van en el apartado de dudas & preguntas. en este caso en el apartaco de XBOX del foro.