⚕️ 🤮 👆🏽 Protección y piratería de la Xbox 360 (Parte 3) 🎥 🧢 👨‍👨‍👦‍👦

En 2011, 6 años después del lanzamiento de la consola de juegos Xbox 360, los investigadores descubrieron un hecho interesante: si la señal "0" se envía a la salida RESET del procesador central por un tiempo muy corto, el procesador no restablecerá su estado (como debería ser), sino que en su lugar cambia tu comportamiento! Basado en esta "característica", se desarrolló Reset Glitch Hack (RGH) , con la ayuda de la cual fue posible comprometer por completo la protección de la Xbox 360, ejecutar código sin firmar, abriendo así el camino para hackear el sistema y derrotar las unidades DG-16D5S "irrompibles" .

¡Echemos un vistazo más de cerca a cómo funcionaba RGH, cómo los desarrolladores intentaron reparar un agujero y cómo estos parches pudieron moverse!

¿Qué es un ataque de falla?

El procesador es bastante tonto, no importa lo que digan los especialistas en marketing. Todo el código de alto nivel escrito por los programadores se reduce a la ejecución de comandos simples: aritmética con números, datos en movimiento, saltos condicionales e incondicionales. Se supone que el procesador siempre ejecuta estos comandos sin errores, y el resultado coincide con la documentación.

De hecho, compilando el código

i = i + 2;

confía en el hecho de que el valor de la variable i aumentará exactamente 2, sin siquiera darse cuenta de cómo podría ser de otra manera.

Los ataques de Glitch violan esta confianza: su objetivo es garantizar que el procesador tenga "errores" y se comporte mal. Hay varias formas de "fallar" el procesador, por ejemplo:

Reduzca el voltaje de la CPU
Para dar un impulso extra a la frecuencia de referencia de la CPU
"Brillo" en porcentaje de radiación

Existen dispositivos especiales para llevar a cabo tales ataques; por ejemplo, ChipWhisperer ofrece una amplia gama de ataques en frecuencia y potencia:

En el caso de la Xbox 360, se produce un "error técnico" como resultado de la exposición a la línea RESET. El procesador comienza el procedimiento de reinicio, pero debido a la muy corta duración de la señal, no tiene tiempo para completarlo y continúa trabajando como si nada hubiera pasado. ¡Pero solo por este breve momento, mientras la señal RESET está activa, su comportamiento cambia!

Procesador Glitch

La protección de Xbox 360 se basa en los gestores de arranque que se controlan entre sí en una cadena. En última instancia, la verificación en cada etapa se reduce a llamar a la función de comparar la suma de hash con el "patrón". Fue entonces cuando aplicaron el ataque de falla, obligando al procesador a ignorar la falta de coincidencia. Un impulso a la línea RESET inmediatamente después de llamar al procedimiento memcmp obliga al procesador a "ir" a lo largo de otra rama y continuar cargando, incluso si la suma de hash es incorrecta:

El mejor lugar para atacar se encontró en el gestor de arranque de la segunda etapa, "CB". Las etapas posteriores son más difíciles de atacar (y fáciles de arreglar), pero en la primera etapa de carga ("1BL", ROM) el ataque falló debido a una construcción ligeramente diferente del código del programa.

Suena simple, pero de hecho, al intentar llevar a cabo un ataque, se descubrieron muchos matices.

Primero, para llevar a cabo con éxito un ataque de falla, es necesario determinar con mucha precisión el momento en el que se debe aplicar un pulso RESET. Si comete un error al menos por un microsegundo, envíe un impulso demasiado corto o largo, el ataque no funciona.

Afortunadamente, en Xbox 360, cada paso de arranque va acompañado de un cambio de valor en el bus de depuración POST_OUT. Además, la salida de depuración se organiza con tanta frecuencia que se establece un nuevo valor POST inmediatamente antes de comparar la suma de hash:

Por lo tanto, cerrar la ubicación de la salida de depuración del sitio de ataque fue un desencadenante extremadamente conveniente. POST_OUT es un bus paralelo y se emite a 8 sitios de prueba en la placa de circuito impreso, cada uno de los cuales es responsable de uno de los bits del valor. Incluso fue posible simplificar el esquema de conexión utilizando solo un bit y contando el número de cambios en su estado desde que se inició el sistema:

También resultó que debido a la alta frecuencia del procesador, es casi imposible llegar al momento correcto en términos de precisión y duración. El tiempo de exposición debe ser muy corto, en el orden del tiempo de ejecución de una instrucción por parte del procesador. Pero cuanto más lento se ejecuta el procesador, más nos conviene el intervalo de tiempo. ¡Por lo tanto, tomamos y ralentizamos el procesador!

En una PC normal, la frecuencia de la CPU se define como el producto de la frecuencia externa, "referencia" y multiplicador:

Entonces, en la Xbox 360, las líneas externas de la frecuencia de referencia son adecuadas para el procesador, y dentro de esta frecuencia se multiplica por PLL . Y en las antiguas revisiones "gruesas" del decodificador, el mecanismo PLL podría desactivarse, ralentizando el procesador hasta 128 veces:

En las versiones "Slim", el truco PLL no se puede hacer (la línea no está separada en el tablero), y como no podemos influir en el factor "Slim", ¡reduciremos la frecuencia de "referencia"!

Es generado por el chip HANA, y se puede configurar a través del bus I2C:

Desafortunadamente, no fue posible reducir mucho, "a bajas velocidades" la frecuencia final del procesador comenzó a "nadar" fuertemente, lo que redujo las posibilidades de éxito. La opción más estable fue una desaceleración de 3.17 veces. No 128 veces, pero al menos algo.

¿Todas? No, no todo. Está lejos de ser un hecho que el ataque funcionará la primera vez (especialmente en Slim). Y si el inicio falla, el prefijo se reinicia e intenta comenzar de nuevo. Solo se dan 5 intentos para comenzar, después de lo cual el prefijo se detiene y comienza a parpadear el "anillo rojo de la muerte". Por lo tanto, también parcheamos el firmware del puente sur (SMC) para que no sufra basura y reinicia el prefijo hasta que se vuelva azul:

Entonces, obtenemos el algoritmo:

parche SMC
ralentizar el porcentaje (a través de PLL o I2C)
esperando un disparador POST
esperando N microsegundos
enviar impulso a RESET
acelerar el porcentaje de vuelta

Para una mayor precisión de los cálculos, tomamos la frecuencia de la misma HANA (48 MHz):

Y obtenemos dicho diseño basado en el económico CPLD Xilinx XC2C64A:

No olvide chamanizar con la longitud y la ubicación del cableado en el RESET (preste atención a la "bobina" en la parte inferior de la foto) y adelante, espero que el lanzamiento funcione en un minuto.

Pero esto es solo en el lado del hardware. ¿Cómo parcheamos el gestor de arranque y rellenamos nuestro código?

Cargadores de parches

Como mencioné, el cargador de arranque de segundo nivel, "CB", está siendo atacado. Este gestor de arranque está encriptado con una clave fija, la misma para todas las consolas, pero solo "CB" no se puede modificar, solo lo atacamos. Pero el siguiente ya está encriptado con una clave de CPU, única para cada decodificador. Y para modificarlo, necesita saber esta clave ... ¿
O no?

En las antiguas revisiones "gruesas" de la Xbox 360, el cargador llamado CB soportaba el llamado modo "Emparejamiento cero", que se usa en la etapa de producción de la consola. El encabezado de cada gestor de arranque en el desplazamiento 0x10 contiene un conjunto de datos de emparejamiento aleatorio que se utiliza como parte de la clave para el descifrado. Y si este conjunto de datos consistía completamente en ceros ("Emparejamiento cero"), entonces la clave del procesador fue ignorada y en su lugar se usó una clave fija cero.

Con este truco, fue posible ensamblar una imagen con el "CB" original, cifrar el siguiente cargador de arranque, "CD" (con su propio código) con una clave cero y ejecutarlo usando RGH.

En las consolas, "Slim" envolvió este truco, eliminando el modo "Emparejamiento cero" y dividiendo el "CB" en dos partes. Aquí, "CB" se dividió en un "CB_A" muy simple y pequeño y se cifró con la clave del procesador "CB_B":

Pero el cifrado con el algoritmo RC4 (es decir, CB_B está cifrado con este algoritmo) tiene una peculiaridad. En el proceso de encriptación basado en la clave, se genera una secuencia de datos pseudoaleatoria, que es binaria "sumada" (operación 'exclusiva o', 'xor') con los datos de origen. Al descifrar, en consecuencia, sucede lo mismo, agregar con la misma secuencia pseudoaleatoria devuelve los datos a su valor original:

Pero la operación de suma binaria es conmutativa y asociativa, lo que significa que podemos modificar los datos cifrados sin conocer la clave, ¡solo para xor 'y el código cifrado con el parche que necesitamos!

Como resultado, podemos encriptar "CB_A", parchear el "CB_B" encriptado (para que no realice descifrado) y poner en texto plano "CD" con su código.

En resumen, si lo juntas, el lanzamiento se ve así:
(XeLL es el gestor de arranque de homebrew, Linux, y también muestra las claves de la CPU)

Microsoft contraataca

Por supuesto, Microsoft trató de arreglar todo.

En la nueva actualización del sistema, todas las consolas antiguas se transfirieron a un arranque "separado" de "CB_A" y "CB_B", cerrando así finalmente el modo "Emparejado a cero". En Slim, los gestores de arranque también se han actualizado. Los nuevos gestores de arranque se han modificado seriamente para proteger contra RGH, con el mayor énfasis puesto en la protección de CB_A:

Salida de depuración completamente eliminada en POST
La verificación hash se ha vuelto a hacer y se ha duplicado para garantizar la fiabilidad.
En todo el código, sleep () se configuró por un tiempo aleatorio (¡dependiendo de la clave de la CPU!)
Se agregó la comprobación de fusión CBLDV para revocar CB_A

La lista de innovaciones no deja ninguna posibilidad para RGH. Pero prestemos atención al último elemento de la lista: antes de eso, ¡no había verificación de fusión en CB_A! Error fatal. Además, como recordamos, la clave del procesador no está involucrada en la decodificación "CB_A". Esto significa que el cargador CB_A vulnerable a RGH se puede iniciar en cualquier consola, y esto no se puede prohibir.

Pero para comenzar algo con la ayuda de este vulnerable "CB_A", debes esquivar un poco. Si no conocemos la clave de la CPU, todo lo que nos queda es parchear el "CB_B" existente. Pero, ¿qué sucede si, en lugar de modificar secciones individuales, sobrescribimos completamente el gestor de arranque completo? Y debido a esto, "escribir" el viejo gestor de arranque, que ya sabemos cómo parchear, para reemplazar el nuevo. Entonces lo hicieron:

Encriptamos el CB_A vulnerable de la misma manera que en la imagen original
XOR nuestro CB_B con el nuevo, obteniendo la "diferencia"
¡Lo ponemos en el "CB_B" encriptado!

Todo, nuevamente, sin conocer la clave, reemplazamos con éxito el contenido cifrado y también colocamos el cargador de arranque vulnerable. Las consolas piratean, Microsoft está sorprendido.

Los desarrolladores trabajaron duro, y en la próxima actualización del sistema ... cambiaron ligeramente el método de cifrado "CB_B", ahora la clave de cifrado también se ha vuelto dependiente de la versión de "CB_A":

Ahora, al intentar xor 'y empujar los datos al vulnerable "CB_A" de la versión anterior, el gestor de arranque descifró la basura debido a las diferencias en las claves. Y el nuevo gestor de arranque no puede ser pirateado, está bien protegido de los ataques glich. ¡Hasta ahora, victoria para Microsoft!

Corona lanza problemas

Mientras tanto, una nueva revisión de la Xbox 360, Corona, entró en el mercado y trajo problemas de modders:

No hay suficientes fichas en el tablero, ¿puedes encontrarlo? Así es, el chip HANA estaba "oculto" en el puente sur. No hay otro lugar para tomar la frecuencia de 48 MHz para el chip mod, los comandos anteriores de desaceleración de I2C no funcionan. Pero, ¿qué es, el flash NAND de 16 MB, que ha servido como almacenamiento del sistema Xbox 360 durante todos estos años, fue reemplazado por un chip de 4 GB con una interfaz eMMC! (Es cierto, solo en la versión más barata de la consola, pero aún así):

Pero nada, todo fue tratado. Descubrimos cómo leer / escribir memoria flash a través de un lector de tarjetas:

Se encontraron nuevos comandos de desaceleración I2C, un oscilador de cristal externo de 48 MHz reemplazó a HANA:

Se completaron los scripts de compilación, se agregó soporte para NAND de 4 GB ...

Pero Microsoft continuó poniendo palos en las ruedas. Por ejemplo, en las nuevas placas, algunas resistencias desaparecieron, sin las cuales el chip mod dejó de funcionar:

Es cierto que esto se solucionó instalando puentes con un soldador:

Las cosas se pusieron más serias cuando las pistas POST_OUT desaparecieron del tablero:

Pero aquí Microsoft no tuvo suerte, las "bolas" de CPU necesarias para RGH estaban en la fila extrema:

Y, por supuesto, pudieron conectarse con ellos. Primero, los más duros, perforando ligeramente el borde del procesador y soldando directamente a la bola con el cableado:

Y luego, los chinos lanzaron un marco con una aguja cargada por resorte, que descansa exactamente sobre la pelota, y el problema se resolvió para todos los demás:

La última frontera

Después de derrotar a la "corona", hubo un problema: las nuevas versiones del sistema no cedieron a la piratería. Para iniciar RGH, necesita conocer la clave de CPU, y para encontrar la clave de CPU, debe ejecutar RGH al menos una vez. El problema del pollo y los huevos en general.

Y luego surgió un pensamiento, y no solo verifiquemos con la autenticación "glitch", sino que también omitiremos el descifrado. Si funciona, entonces no necesitamos saber la clave, poner "CB_B" en claro, eso es todo. Esta idea formó la base de Double Glitch Hack (DGX):

Este chip "da error" el porcentaje dos veces, el primer pulso omitió la fase de descifrado del gestor de arranque y el segundo pulso omitió la autenticación. Funcionó mucho menos estable, ya que se requería al menos un lanzamiento exitoso; luego obtenemos la clave de la CPU y procedemos como antes.

DGX no fue relevante por mucho tiempo, después de 3 meses, los chinos lanzaron el lanzamiento de "DGX RIP" con imágenes que se ejecutan en cualquier decodificador, funcionan con RGH estándar y, por supuesto, comenzaron mucho más estables:

Estas imágenes contenían una versión especial del cargador de arranque CB_A utilizado en la producción de Xbox 360 y, de hecho, es un análogo completo del antiguo y antiguo modo "Emparejamiento cero". En lugar de la clave del procesador, este "CB_A_mfg" descifró "CB_B" con una clave nula fija:

Y aquí está Microsoft. En esta versión de "servicio" de "CB_A" tampoco hubo verificación de fusión y fue imposible prohibirlo. Fue suficiente para grabar la imagen de acuerdo con la revisión de la Xbox 360, soldar el chip, y todo funcionó.

Winchester!

RGH se arregló completamente solo en la nueva revisión de la consola, con nombre en código Winchester. Por primera vez, los procesadores de CPU y GPU se combinaron en un chip, la placa se simplificó lo más posible:

Las pistas POST_OUT no solo se eliminaron. Incluso si suelda a la plataforma debajo del procesador:

E incluso si suelda el procesador a una versión especial de la placa para desarrolladores, XDK, donde estas pistas todavía están allí:

En POST_OUT, solo se ve un pulso cuando se inicia la consola. Bus bloqueado:

Además, se bloquea solo en la etapa de producción. Si toma un procesador "limpio" de una fábrica donde todavía no ha quemado fusibles, ¡POST_OUT funciona!

Pero RGH ya no funciona. No importa cómo intente dar un pulso de RESET, el procesador realiza correctamente un reset o ignora su señal debido a su corta duración. Aparentemente, se agregó un módulo lógico especial al procesador, filtrando la línea RESET y, por lo tanto, finalmente solucionó el error de hardware.

Post scriptum

Resulta que la última revisión de la Xbox 360 es imposible de hackear?

Si y no. Actualmente, solo hay una forma conocida de ejecutar un sistema modificado en una revisión de Winchester.

El kit de desarrollo de software (XDK) contiene varias claves privadas para firmar código compilado. Y resultó que, entre ellos, la clave de firma "shadowboot", un gestor de arranque de tercer nivel para sistemas XDK, estaba abarrotada. Y con él, puede recopilar una imagen firmada legítima con firmware modificado. Simplemente trabaje en consolas normales de "tienda", no lo hará. Necesitamos un procesador con la versión XDK de la consola, o una CPU "limpia" con fusibles sin fusibles (se puede ver en Aliexpress):

Y solo entonces tendrá la oportunidad de contemplar dicha inscripción en la "información del sistema" del shell personalizado:

¡Y eso es todo! Como de costumbre, estoy listo para responder sus preguntas en los comentarios :)

Protección y piratería de
Xbox 360 , Parte 1 Protección y piratería de Xbox 360 , Parte 2
Protección y piratería de Xbox 360, Parte 3

Protección y piratería de la Xbox 360 (Parte 3)