☝️ 🤵🏾 🛎️ Protección y piratería de la Xbox 360 (Parte 1) 🤤 🧗🏻 👩🏾‍⚖️

Probablemente haya escuchado sobre la consola de juegos Xbox 360, y que está "parpadeando". Por "firmware" se entiende aquí una omisión de los mecanismos de protección incorporados para lanzar copias de juegos y software privativo. ¡Y aquí surgen preguntas! ¿Qué mecanismos, cómo se mueven? ¿Qué hicieron los desarrolladores, cómo lograron sortearlo? De hecho, el tema es muy extenso e interesante, especialmente para Xbox 360: aquí puede encontrar vulnerabilidades de software, fallas de hardware y magia absolutamente mágica. ¿Interesante? ¡Entrar un momento! En la primera parte, se nos presenta el hipervisor, las unidades y el firmware ...

Conoce el tema

La consola de juegos Xbox 360 fue lanzada en 2005 y no ha sufrido cambios en las características del hierro desde entonces. Todo el tiempo que fue lanzado, fueron lo mismo:

CPU PowerPC de 3.2 GHz, / 3 núcleos
GPU de 500 MHz
512 MB de RAM
DVD-ROM SATA
HDD SATA (opcional)

Sí, el diseño cambió con el tiempo, los nanómetros disminuyeron:

Sin embargo, todos los juegos funcionaron igualmente bien en todas las "revisiones" de las consolas; este es exactamente el caso cuando los juegos modernos se pueden ejecutar en equipos de 2005.

En el momento del lanzamiento, se hizo una fuerte declaración de que la consola se había desarrollado de la manera más segura posible: chips personalizados con protección a nivel de hardware y, en general, los piratas informáticos aún no han visto esto:

Habrá niveles de seguridad en este cuadro que la comunidad de hackers nunca ha visto antes

¿Qué inventaron los desarrolladores?

En primer lugar , hicieron todo lo posible para que no se pudiera obtener el código del programa del sistema . Una ROM de 32 KB que contiene un cargador primario (1BL) y una SRAM de 64 KB en la que se ejecutó se integraron en el procesador central. Es muy, muy difícil obtener el contenido de ROM de un chip de CPU:

En segundo lugar , se colocaron fusibles especiales en el mismo procesador : puentes quemados (literalmente, de alto voltaje), una especie de memoria que alguna vez fue programable. Los fusibles incluyen:

Bits de bloqueo de la interfaz JTAG
bits que determinan el propósito del prefijo (retail / devkit / testkit)
clave única de procesador de 128 bits
Contadores de valor de bloqueo (LDV) para deshabilitar la degradación

Sí, la cantidad de fusión es limitada. Si logra actualizar su consola 80 veces seguidas, el contador CFLDV finalizará y ... No sé, no he intentado hacer esto. Probablemente, el prefijo ya no se actualizará.

Tercero , los desarrolladores han implementado una cadena de confianza . Para verificar la autenticidad de los gestores de arranque, se usó una combinación de algoritmos modernos (en ese momento) SHA-1 y RSA-2048, que excluyeron la posibilidad de lanzar su propio código o modificación no autorizada de los gestores de arranque, incluso si de alguna manera obtuvo todas las claves de la consola y pudo reconstruir el sistema .

Cuarto , los desarrolladores decidieron ir más allá en el principio de "no confiar en nadie" y colocar un módulo de hardware especial para proteger la RAM en la misma desafortunada CPU . ¡Con su ayuda, todas las áreas con código de programa se cifraron y se activó la supervisión de integridad para las áreas más importantes (hipervisor)!

Al hacer esto, los desarrolladores se defendieron contra los ataques de DMA cuando, a través de dispositivos externos que tienen acceso a RAM, modifican el código del programa del sistema en RAM.

Finalmente , el hipervisor se ocupó de la diferenciación de derechos en regiones de memoria . Solo él podía hacer que las páginas fueran ejecutables, por supuesto, antes de que verificara la firma digital, por lo que era imposible descargar código sin firmar o ejecutar algo desde el área de datos incluso a través de una vulnerabilidad en algún controlador o juego (el eje y los juegos se lanzaron con derechos de kernel) .

Como resultado, el sistema operativo Xbox 360 estaba bien protegido y, por lo tanto, se eligió DVD-ROM como el primer vector de ataque.

Comenzamos ... ¡copias de seguridad!

En la Xbox 360, se eligió un DVD de doble capa como medio principal para los juegos. Naturalmente, los mecanismos de defensa también estuvieron presentes aquí:

el intercambio de datos con DVD-ROM se cifró con una clave única
al comienzo del disco había "Sectores de seguridad" especiales para confirmar la licencia
los archivos ejecutables en el disco se firmaron digitalmente

Pero se prestó mucha menos atención a la protección de la unidad de DVD que al sistema principal. La consola de juegos mostró demasiada confianza en la unidad de DVD: fue el DVD-ROM el que determinó la licencia del disco. Además, el firmware estaba almacenado en una memoria externa y el programador podía leerlo:

Como resultado, el 14 de mayo de 2006, commodore4eva (c4eva) lanzó el primer firmware modificado para manejar el modelo TS-H943:

README para la versión de firmware

— Xtreme firmware for TS-H943 Xbox 360
— Here it is, the long awaited World first Xbox 360 backup firmware modification to boot all game backups!

Features
— Boots all Xtreme Xbox 360 backups
Boots all Xtreme Xbox 1 backups
Boots all Xbox 360 originals
Boots all Xbox 1 originals on Xbox 360
Xtreme0800 extraction firmware enables drive to function natively under Windows without any hardware conversion/adaptors
Use on Xbox Live at own risk

Technical details
— Reads Xbox 360 security sector from PSN 04FB1F (Layer 0)
Reads Xbox 1 security sector from PSN 605FF (Layer 0)
Security sector must be extrated using Xtreme0800 360 firmware for Xbox360 games and Xbox 1 games
Will not boot Xbox 1 backups made with Xbox1 605b 0800 firmware (maybe in future release)

El firmware leyó sectores de seguridad de áreas fijas en un disco DVD y engañó a la consola, haciéndole pensar que se insertó un disco con licencia.

Al mismo tiempo, se lanzó el firmware 0800, diseñado para crear copias de juegos y leer sectores de seguridad. La unidad Xbox 360, flasheada con dicho firmware, se detectó en la computadora y pudo leer completamente los sectores del disco del juego.

README sobre el uso del firmware 0800

Extracting Security Sector
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following four custom cdb commands:

AD 00 FF 02 FD FF FE 00 08 00 01 C0
AD 00 FF 02 FD FF FE 00 08 00 03 C0
AD 00 FF 02 FD FF FE 00 08 00 05 C0
AD 00 FF 02 FD FF FE 00 08 00 07 C0

Then save hexadecimal display as bin file as SS.bin

Creating a game backup
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Extract Isobuilder.rar
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following custom cdb command to unlock drive: (game data visable)

FF 08 01 01

Run Isobuster
Right click on DVD and select Extract From-To
Click Length and enter number of LBAs as follows:

Xbox 1 Original Number of LBA to read 3431264 decimal
or
Xbox 360 Original Number of LBA to read 3567872 decimal
Select User Data (2048 bytes/block)
Click Start Extraction
Enter filename as game.iso and click Save
Upon read error dialogue box choose fill with blank zeros for sector and select use this selection for all errors
Copy game.iso and ss.bin to the relevent isobuilder directory (Depending on Xbox 360 or Xbox 1 game)
Run build360.bat (Xbox 360 game) or build.bat (xbox 1 game)
Ensure your burner will set the booktype of DVD+R DL to DVDRom
Burn with CloneCd and choose the image.dvd file

Otro juego podría copiarse parcialmente con el siguiente truco:

poner en una computadora DVD-ROM disco ordinario de dos capas
espera hasta que se calme y deje de girar
con un clip de papel, abra la bandeja y cambie la unidad al juego desde la Xbox 360
¡cierra la bandeja y crea una imagen de disco!

(No funcionó en todos los modelos de DVD-ROM)

Lo más importante es que la unidad fue flasheada exclusivamente por software, con comandos especiales de ATA. El kit incluía un programa especial para leer el firmware original y escribir modificado. En el firmware original, se almacenaba la clave atesorada, con la cual la unidad estaba vinculada a la Xbox 360:

La pérdida de la clave significaba que incluso los discos con licencia no podían iniciarse, por lo que algunos escribieron la clave en un cuaderno, la guardaron siempre que fue posible, este era el conocimiento más preciado.

Un tema aparte fue el pánico sobre el juego en línea. Todos temían que Microsoft descubriera que la unidad se había modificado y que deshabilitara remotamente la consola. Algunos incluso hicieron un mod de hardware para cambiar entre el firmware modificado y de fábrica:

Jugaron con el firmware original "en licencia" y, con una conexión a la red, los desconectaron vergonzosamente del cable de Internet modificado. Por cierto, el pánico no fue en vano, pero tales modificaciones fueron completamente en vano, todo se registró sin conectarse a la red.

Exactamente un mes después (15 de junio de 2006) el firmware fue portado a otro modelo de unidad, que estaba instalado en la Xbox 360 en ese momento: Hitachi GDR3120L. También tenía una unidad flash externa que contenía firmware:

Esta unidad estaba mejor protegida:

el firmware se almacenó en ROM en forma cifrada
hubo control de integridad en el firmware
para sobrescribir el firmware, tenía que entrar en un "Modo B" especial

Y si los investigadores lograron los primeros dos puntos ellos mismos, la hazaña de la traducción en "Modo B" sería repetida por todos los ~~jóvenes~~ intermitentes.

Se propuso que esta acción se realizara utilizando un disco de arranque especial con Slax Linux, o acortando los cables al inicio. Era necesario cortocircuitar los contactos 0 y 9 del conector de alimentación del variador. Por ejemplo, con alfileres!

En ambos casos, después de tales abusos, la unidad se definió en Windows como una unidad de DVD normal, donde fue recogida, ~~violada~~ y cosida.

Después del primer lanzamiento, se finalizaron los firmwares personalizados, se mejoró la estabilidad, se agregó soporte para nuevos juegos, en general, todo fue como de costumbre.

Respuesta de Microsoft

Los desarrolladores de las acusaciones de que la consola "irrompible" fue pirateada, respondieron simplemente:

El sistema no fue pirateado, solo aprendimos cómo lanzar copias de juegos, estamos trabajando en ello

respuesta original

The core security system has not been broken. However, it is reported that the authentication protocol between the optical disc drive and the console may be attacked, which if accurate could allow people to play illegally copied games. Our security team is aware of this and we are investigating potential solutions to this issue. The Xbox 360 platform was designed to be updated, and we are prepared to respond appropriately should any unauthorized activity be identified.

Lo que realmente se hizo para corregir la situación:

Samsung TS-H943 comenzó a venir con el firmware ms28, que no entró en el modo de firmware por el conocido comando ATA
Hitachi GDR3120L apareció con el firmware 0078 y 0079, sin parpadear incluso en el Modo B
Aparecen nuevas unidades BenQ-LiteOn VAD6038
Comenzaron las primeras "prohibiciones" de piratas en Xbox Live, a los piratas se les prohibió jugar en línea para siempre

Si todo era inequívoco e irreparable con la prohibición (en ese momento), los investigadores pronto descubrieron las unidades:

Para Hitachi se encontró desbloquear el modo firmware a través de un disco de audio especial
Samsung ms28 y BenQ VAD6038 entraron perfectamente en el modo de firmware a través de controladores SATA VIA 6421 económicos

Dejemos el campo de batalla por el firmware del disco por un tiempo, no hubo un período muy interesante cuando los investigadores intentaron hacer el firmware "Stealth", para no ser excluido de Xbox Live, adaptarse a los nuevos juegos con nuevas "olas" - versiones de actualización del sistema y transferir los resultados a todo Una variedad cada vez mayor de firmware y unidades. De todos modos, todo fue cosido, las "copias de seguridad" se lanzaron con éxito, la Xbox 360 estaba ganando popularidad entre la gente ...

Romper el eje!

Como recordará de la primera parte de la historia, el sistema Xbox 360 tenía un hipervisor que controlaba todo y todo. Entonces aquí. ¡En una versión del sistema, una vulnerabilidad apareció de repente en él! No sé con certeza cómo exactamente los investigadores recibieron las muestras de código del hipervisor. Pero el hecho es que, a fines de 2006, los investigadores lanzaron código sin firmar en la Xbox 360, y a principios de 2007 los desarrolladores corrigieron la vulnerabilidad:

Timeline:
Oct 31, 2006 — release of 4532 kernel, which is the first version containing the bug
Nov 16, 2006 — proof of concept completed; unsigned code running in hypervisor context
Nov 30, 2006 — release of 4548 kernel, bug still not fixed
Dec 15, 2006 — first attempt to contact vendor to report bug
Dec 30, 2006 — public demonstration
Jan 03, 2007 — vendor contact established, full details disclosed
Jan 09, 2007 — vendor releases patch
Feb 28, 2007 — full public release

El hipervisor tenía una característica: a diferencia del resto del código, se ejecutó no en el espacio de direcciones virtuales, sino en el físico (modo real). La transmisión no se utilizó, las llamadas se realizaron directamente (direcciones de la forma 0x00000000'xxxxxx). O esto se hizo por velocidad o por simplicidad ... Y aquí estaba una característica del espacio de direcciones de Xbox 360.

El modo de acceso a la memoria estaba determinado por su dirección física. Es decir, los bits más significativos de la dirección tenían un propósito oficial. Por ejemplo, la dirección 0x00000 0 00'0000201C significaba acceso directo a la dirección 0x201C, y 0x00000 1 00'0000201C significaba que tenía que descifrar y verificar la integridad sobre la marcha al leer la misma dirección física 0x201C.

En consecuencia, para que la ejecución se lleve a cabo con el cifrado y la protección habilitados, debe consultar direcciones como 0x00000 1 00'xxxxxxxx. Solo entonces el módulo de hardware incluía mecanismos de protección. Por lo tanto, a nivel de hardware, el bit deseado se agregó automáticamente (el registro HRMOR especial fue el responsable de esto: registro de desplazamiento del modo real del hipervisor).

Una vez más, tan pronto como el hipervisor accede a una dirección como 0x00000 0 00'xxxxxxxx, la MMU cambia automáticamente esta dirección a 0x00000 1 00'xxxxxxxx, ¡incluyendo cifrado y protección! Entonces, ¿cualquier intento de ejecutar el código "directamente" desde la memoria física, sin protección y cifrado, está condenado al fracaso ... o no?

Veamos el código vulnerable de la versión del hipervisor 4532:

// %r0 – 13D8: cmplwi %r0, 0x61 // ID 13DC: bge illegal_syscall // 0x61, , ... 13F0: rldicr %r1, %r0, 2, 61 // 4 13F4: lwz %r4, syscall_table(%r1) // 13F8: mtlr %r4 // lr ... 1414: blrl //

¿Ves al gopher? ¡Pero el es! La instrucción Cmplwi funciona con valores de 32 bits , pero rldicr, ¡con 64 bits ! Es decir, podemos pasar el valor 0x20000000'0000002A como número de llamada del sistema, pasará la prueba (porque la parte inferior de 32 bits es menor que 0x61), y como resultado, en lugar de la dirección 0x10EC, ¡la dirección del controlador se tomará de 0x80000000'000010EC!

Y luego, como dicen, cuida tus manos. Los bits más significativos de la dirección no son iguales a cero, respectivamente, ¡HRMOR no se agrega ! Y dado que el espacio de direcciones real es de 32 bits, el conjunto de 63 bits establecido por nosotros simplemente se ignora. Redirigimos el hipervisor a una memoria no cifrada e insegura, simplemente enviando un número de llamada incorrecto al sistema.

Pero espere, para que haya dónde saltar, necesitamos poder escribir nuestros datos en la memoria física. ¿Cómo lograr esto?

Aquí es donde entra en juego el segundo factor: la GPU en la Xbox 360 era inteligente, incluso demasiado inteligente. Apoyó una instrucción especial de sombreado, MemExport, para cargar datos de geometría a la memoria física. Es decir, puede compilar el sombreador, ejecutarlo en la GPU y, por lo tanto, grabar cualquier cosa en cualquier lugar. Y lo más importante, los sombreadores no estaban firmados, si modifica el disco del juego de alguna manera, puede reemplazar fácilmente el código del sombreador.

Quedaba una pregunta. ¿Cómo reemplazar el código de sombreador en el disco del juego? Y aquí hackear la unidad de DVD de la consola fue muy útil. ¡Escribimos un sombreador, lo reemplazamos en la imagen del juego, lo grabamos en un disco y lanzamos Linux!

Sí, para ejecutarlo, tenía que iniciar el juego cada vez, esperar a que el exploit funcionara, poner el disco de arranque con Linux, ¡pero eso era al menos algo!

Como ya se mencionó, Microsoft lanzó una actualización del sistema en la que repararon la vulnerabilidad del hipervisor. Pero, ¿y si devuelve un núcleo vulnerable?

¡Degradar!

En general, la arquitectura de la Xbox 360 se estableció mecanismos de protección contra la degradación. En los fusibles de hardware del procesador, cada vez que se quemaba un bit durante la actualización (Valor de bloqueo, LDV aumentado), y si este LDV no coincidía en los fusibles y en el sistema, la consola simplemente no se iniciaba.

Considere la estructura del cargador de arranque Xbox 360, a saber, "Secciones del cargador de arranque":

Se puede ver que hay varios conjuntos de cargadores de arranque en la imagen, cada uno de los cuales corresponde a algunos LDV. En el ejemplo, estos son 1888 para LDV 0, 16767 para LDV 3 y 16756 para LDV 2

Por lo tanto, todas las actualizaciones del sistema en sí se registraron en las secciones 6BL / 7BL y simplemente se "aplicaron" como parches al "núcleo" base 5BL 1888 . ¡Pero qué conjunto de parches para aplicar se seleccionó de acuerdo con el LDV prescrito en los fusibles y los encabezados del cargador de arranque! Y solo en 5BL el encabezado podría modificarse, con un gran PERO: el encabezado se verificó contra la suma de hash HMAC-SHA-1 registrada en él. Y fue verificado por memcmp ordinario .

Si aún no entiende a dónde van las cosas, aquí logró aplicar un ataque de tiempo (Ataque de tiempo). La función memcmp estándar completa la comparación inmediatamente después de la primera discrepancia. Por lo tanto, al cambiar el primer byte del hash y detectar el tiempo de ejecución de memcmp, puede seleccionar el valor deseado (el tiempo de verificación aumentará con él). Continuando más, ¡puedes recoger todos los bytes de la suma de hash!

Para la medición, se utilizó el bus de depuración POST_OUT. Funciona como una PC, en diferentes momentos de carga se muestra un valor de un solo byte, por el cual puede juzgar dónde se está ejecutando actualmente el procesador y qué error ocurrió. De hecho, estos son 8 puntos en la placa base, cada uno de los cuales es responsable de un bit de valor específico:

Después de soldar a estos puntos, puede medir el tiempo de ejecución de cada una de las etapas de descarga y ver si se ha producido un error.

Todo el proceso de selección de hash dura aproximadamente una hora:

Como resultado, obtenemos una imagen en la que se instala el LDV actual para el núcleo del núcleo, por lo que no se aplican parches y se lanza la versión más antigua del sistema 1888. Desde donde ya es posible actualizar a la versión vulnerable 4532:

Por supuesto, Microsoft corrigió esta vulnerabilidad al actualizar el primer gestor de arranque actualizado (2BL, "CB") y quemar el fusible CBLDV, lo que hizo imposible la degradación de nuevo. Ahora, en lugar de memcmp, se utilizó su versión segura, con el mismo tiempo de ejecución independientemente de los valores de entrada.

JTAG Hack!

Pero aquí, los investigadores no se rindieron y encontraron una escapatoria. Sí, de tal manera que los desarrolladores ni siquiera podían imaginarlo.

En el modo normal de funcionamiento de la consola, todos los gestores de arranque están conectados entre sí en una cadena. Como resultado, el descifrado de cada gestor de arranque depende del área de datos en el encabezado del gestor de arranque anterior (Datos de emparejamiento). Además, el cifrado del código depende de la clave de procesador única, por lo que no puede tomar y ensamblar una imagen de trabajo sin conocer CPU_Key. ¿O es posible?

En la etapa de producción de la consola (cuando la clave del procesador aún no se ha quemado en fusibles), se utiliza un modo especial de inicio de Xbox 360 cuando los datos de emparejamiento son cero (emparejamiento cero). Y tal imagen (¡con un núcleo vulnerable!) ¡Se puede ejecutar en cualquier consola sin siquiera saber la clave del procesador!
Desafortunadamente, no habrá un lanzamiento completo, este error será así:

Es decir, el juego de King Kong no se puede iniciar, el exploit a través de los sombreadores no se puede activar ... ¡Pero el núcleo vulnerable ya está comenzando! Tal vez hay otra forma de grabar la RAM? Resultó que hay.

Para empezar, soldamos tres GPIO gratuitos de la consola sur de la consola a los pines JTAG de la GPU:

Luego modificamos el firmware del puente sur (está encriptado, pero no firmado) y recopilamos la imagen con el núcleo vulnerable. Entonces sucede la magia:

Al inicio, el puente sur en la GPU JTAG sube a PCI Express y configura el controlador NAND
Ahora, al leer, el controlador NAND escribirá datos en el área de memoria que necesitamos
El núcleo del sistema se inicia e informa al puente sur que el sistema ha comenzado
¡El puente sur tira del controlador NAND, sobrescribe la RAM en el lugar correcto y explota la vulnerabilidad del hipervisor!
El control se transfiere a nuestro código, hagamos lo que queramos

En resumen, hicieron todo lo mismo que en King Kong Shader Exploit, pero más genial: no hay necesidad de iniciar el juego y cambiar los discos.

Sobre la base de JTAG Hack, se crearon versiones modificadas del sistema: XBReboot, Freeboot, con verificación de firma deshabilitada, donde los piratas ya estaban caminando. Los juegos podrían iniciarse no solo desde unidades y discos USB, sino también a través del protocolo SMB directamente desde una computadora.

Es importante destacar que un hackeo completo del sistema les dio la oportunidad a aquellos que perdieron la clave del DVD y no pudieron reproducir; al tener la clave del procesador, no fue difícil extraer la clave del DVD.

Por supuesto, aquí Microsoft cerró rápidamente la vulnerabilidad, actualizando nuevamente 2BL y aumentando el valor de CBLDV. Sobre esto, la épica del hipervisor vulnerable terminó, la gente corrió a comprar los restos de las consolas "compatibles con JTAG" en las tiendas: todos querían jugar con unidades flash USB sin ningún problema. Se celebraron debates en foros sobre qué paquetes con qué fecha de lanzamiento son adecuados para piratear ...

El tema de las modificaciones al sistema Xbox 360 se detuvo durante casi dos años, pero el tema del firmware continuó desarrollándose. Y justo en el firmware de las unidades LiteOn, estalló la batalla más extensa entre los investigadores y Microsoft. Pero más sobre eso en el próximo artículo :)

Enlaces:

informe GoogleTechTalks
King Kong Hack
Timing Attack
JTAG / SMC Hack

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

PS ¡Cualquier persona interesada en detalles, responderé cualquier pregunta sobre el tema en los comentarios!