[TUTORIAL AVANZADO] J-Tag (Xploit) + INFO + PROMP XELL

Bueno, como mencione en el titulo del post esta es una descripcion tecnica, para todos aquellos que deseen entender como funciona el hack, para todos aquellos que prefieran un conocimiento mascado, por favor esperad, saldran muchos tutoriales, y descripciones menos tecnicas, en cuanto haya una forma mas sencilla tendras mi tutorial...

-----------ADVERTENCIAS Y RECOMENDACIONES ------------------
Ni EOL ni yo nos hacemos responsables por danos a tu consola, este es un documento/tutorial para usuarios del Nivel Avanzado o Experto.. CON UN ALTO RIEGO DE BRICK

Este hack puede usarse para reiniciar en un kernel de Microsoft, para permitir usar juegos en modo local, el hack permite ejecutar software y TU decides que software se ejecutara, puede ser linux, tu emulador favorito, o un rebooter.

Nosotros No damos Soporte a modificar el Kernel de Microsoft bajo ninguna circunstancia, Igualmelte, Jugar en LIVE no sera posible sin ser baneado, nunca, actualmente existen rutinas destinadas a detectar cualquier modificacion no autorizada, Te Recomendamos no usar este Hack para PIRATERIA.

--------FIN DE RECOMENDACIONES Y ADVERTENCIAS-------------

Objetivo:

Este es un nuevo hack/Xploti que permite ejecutar homebrew(Codigo Casero) en menos de 5 segundos, ve al final del documento para leer la descripcion de como funciona el mismo, por ahora todo lo que deben saber es que esta es una nueva forma de aprovechar el exploit descubierto en el kernel 4532(King Kong), de tal manera que funcione en macquinas actualizadas, a menos que se hayan actualizado el 11 de Agosto, Funciona en todos los modelos de placa.

En Terminos Funcionales, El resultado es el mismo que con el exploit de King Kong, Solo que mucho mas rapido, Funciona en mas Hardaware (anteriormente solo en Xenon), asi que reemplaza al hack de King Kong.

Tutorial

Lo Primordial es determinar la version del Kernel de tu consola. El Hack se ha probado en todas las versiones de kernel que sean menores a 849x, no funciona en superiores, es decir la actualizacion de Agosto 09 y sus Betas.

Posteriormente debes determinar tu placa, Xenon, Zephyr, Falcon/Opus o Jasper

Necesitas tambien algunos archivos que no se incluyen en el paquete, Actualmente se trabaja en una forma legal de obtener dichos archivos, por ejemplo un Backup de tu NAND

Son:

- un pack funcional "CB/CD". Esto es Parte del BootLoader y es especifica para la version de tu consola:

Xenon: 1921
Zephyr: 4558
Falcon: 5770
Jasper: 6712

- El Codigo Hackeado del SMC, *Igualmente para tu placa*.
- Un Microcontrolador haciendo el trabajo del JTag, o un SMC Hackeado con el Codigo del JTag
- Desempaquetar La Actualizacion 4532 (xboxupd.bin)
- Un compilador cruzado que permita asignar la Arquitectura PPC64

- La Posibilidad de reprogramar tu NAND, puedes usar un programador externo, un SPI, o si posees un Cygnos360 v2, escribir el hack en dicha NAND.
Creando la Imagen
-------------------------


Para poder crear una imagen funcional necesitamos

- un firmware SMC parchado, el cual inicie el comando 07 "READ SECTOR(S) DMA" en el momento adecuado por asi decirlo, Nesesitas el correspondiente para tu placa, pues todos son diferentes y el USAR EL ERRONEO PUEDE GENERAR BRICK dificil de recuperar.
- un microcontrolador que haga las funciones de J-Tag implementado como un parche para el SMC.
- una combinacion de 2BL/4BL (BootLoaders) funcional para tu tipo de placa, y que sean de una version igual o mayor a 1920.
- El 5BL (kernel 1888), es el mismo para todos.
- la Actualizacion 4532 (o 4548), extraida de la misma.
- Un bloque de configuracion SMC, Almacena algunos datos.
- El Xploit, el cual sera inyectado mediante DMA en el Kernel/Hypervisor
- El Codigo que desees ejecutar(XeLL, por ejemplo)

El Archivo build_image.py (python) puede generar la imagen valida si tienes los elementos adecuados
items.

ejemplo:

python build_image.py image_backup.bin input/C{B,D}.1920 input/4532_upd.bin \
input/xell-backup.bin input/xell-1c.bin input/smc_hacked.bin

donde:
- image_backup.bin Es un Backup de tu NAND,
- C{B,D}.1920 es la combinacion 2BL/4BL, en su forma desencriptada
- 4532_upd.bin o 4548_upd.bin es el archivo xboxupd.bin de la actualizacion 4532 o 4548,
- xell-1c.bin y xell-backup.bin son XeLLs asocioados a 0x01c00000
- smc_hacked.bin es el SMC con la intruccion leer rtc hackeada (y tambien el J-Tag)

El el directorio de compilacion se generaran varias partes las cuales deberas flashear en las pociciones adecuadas.

Flashea estas imagenes en la Nand de la 360, HAS BACKUP PRIMERO, tambien queta la resistencia R6T3, pues ahy codigo que puede quemar e-fuses y generaria alto riesgo de brick.

Pon las 3 resistencias si quieres usar el J-Tag basado en SMC.

Conecta los cables y si recibes una pantalla azul (NO, NO LAS DE WINDOWS), felicitaciones, diviertete...


SMC GPIOs
---------

Necesitamos algun hardware que use JTag para establecer el objetivo del DMA tan pronto inicie la secuencia de arranque, inicialmente usabamos un controlador externo, pero ya teniamos un controlador en la board el SMC, esisten algunos puertos GPIO que no son usados, que son -al menos en las Xenon, accesibles en la derecha, Estos puertos Operan a 3.3v, asi que necesitamos algunas resistencias para manejar los 1.8v que usa la parte logica de la GPU.

Zephyr en adelante no tiene tantos puertos GPIO ¬¬, pero no te preocupes, tanmbien existe solucion aca.

en caso de que estes usando el SMC Hackeado con los GPIO, usa resistencias de 330 Ohm.
J1F1.3 --- [330R] --- J2D2.1
J1F1.4 --- [330R] --- J2D2.2
J1F1.5 --- [330R] --- J2D2.4

PROMP XELL ("LINEA DE COMANDOS")

El primer condigo en se ejecutado es un lanzador, cargador, como querais llamarlo que opera de la siguiente forma:

- si ahy un caracter en el puerto seria, este se leera'
- si el caracter es "a", se entra en el modo de carga (carga de software) por puerto serial
- si el caracter es"@", se entra en el cargador de Backups de BL
- si no se carga desde el puerto serial:
- POST 0x10
- lee el BL desde la flash (backup o normal)
- POST 0x11
- ejecuta

- If a character is present on the serial port, it will be read.
- if that character is '@', we will enter serial upload mode.
- if that character is ' ', we will use the backup bootloader
- if not serial upload mode:
- POST 0x10
- read bootloader from flash (either backup or normal)
- POST 0x11
- run
- via cargador del puerto seria;
- imprime ">"
- recive caracteres
- despues de 10 "X", detiene la carga
- imprime "!"
- ejecuta

Esto nos permite realizar cierto tipo de recuperacion por si quieres actualizar el BL de la flash'

Se usan las siguientes direcciones:

FLASH_BASE es la locatlizacion el la flhas del backup del BL,
FLASH_BASE + 0x40000 es la localizacion del BL principal,
CODE_BASE es la direccion del memoria del BL en ejecucion.

por defecto se usa el siguiente mapa de la memoria:

00000000..00100000: SMC, KV, CB, CD, CE, CF, CG, backup BL
00100000..00140000: BL principal
00140000..00f7c000: Vacio
00f7c000 : bloque de configuracion del SMC
00ffc000 : Bufer del Xploit

pero esto puede alterarse

SOLUCION DE PROBLEMAS
---------------

Q: "La fuente de poder cambia a rojo cuando se inicia la consolo"
A: , uniste un pin de corriente, problablemente V33_SB, el que va conectado a la NAND, revisa si existen residuos de soldadura, usa mucho flux y sldador para retirarlo.

Q: "La fuente esta en amarillo y al prender la consola no pasa nasa."
A: El Codigo del SMC es invalido, puede ser una memoria flash mal conectada, una imagen corrupta, un mal flasheo o simplemente un codigo corrupto en la SMC.
Verifica
- primero las coneciones electrica.
- Flasheaste las configuraciones ECC correctas? Las imagenes flash casi siempre contienen informacion ECC raw( son 512+16 bytes por sector, asegurate de que tu programador no las sobreescriba
- Usaste la Imagen SMC Correcta?

Q: "Los Ventiladores/Disipadores se Disparan al maxino"
A: Es casi siempre una mala configuracion del SMC, Flasheaste todas las partes que genera el programa es su pociccion adecuada?, fijate en que lo offset, sin contar los bytes ECC, son mostrados como Payload Offsets, usualmente esto concuerda con lo que tu programador de NAND te muestra, pero en caso de que tu hayas unido todas las umagenes en una sola, ten cuidado de convertir los offsets adecuadamente.

Q: "E79"
A: Felicitaciones, tu consola esta tratando de arrancar el kernel, pero no puede hacerlo ( tu nand no tiene el sistema de archivos), ya casi lo logras, pero por alguna razon el ataque DMA no arranca, puede dberse a que no usaste un SMC Parchado, o ke la direccion de destino no se inserto adecuadamente


Q: "La consola enciende pero se obtiene una pantalla en negro."
A: Bueno, existen varias rasones para esto. Primero, Espera un tiempo (~1
minuto), Y mira si obtienes luces rojas. Si es Asi, el codigo del VM fallo en la sincronizacion con el SMC( codigo de error XXXX), lo que usalmente significa que se congelo, y el SMC Espero hasta que expiro.
Usaste la Conbinacion adecuada de 2BL/4BL? Usate una version reciente de SMC? Desde que el codigo VM toma mas y mas tiempo (medio segundo en 1888 y varios segundoes en 1920), el codigo del SMC fue modificado para esperar mas, asegurate de que usas una version adecuada del SMC, Si no obtienes luces rojas, Revisa el codigo POST, puedes hacerlo via J-Tag, o Con los * POST Pins.

Post code 6C:
El Xploit fallo de alguna manera.

Post code 10:
El Codigo corre! Genial!, pero fallo al copiar el Xell-payloas, Intenta cargar el alterno, mira en la seccion(xpliot loader), o vuelve a flashear.

Post code 11:
El Xploit corre y arranca Xell. pero XeLL se congelo. intenta el alterno, o usa recuperacion seral, si jodiste el 1BL y 2BL

Post codes >= 0x80:
Son errores del Bootloader, revisa la desambiguacion de los cargadores para saber ke falla exactamente, no deberia pasar a menos que tengas un flasheo erroneo.

Post code 0xA0:
Tu 2BL se reusa a arrancar por la revocacion de permisos 2BL de los efuses, usa una version mas reciente de la combinacion 2BL/4BL, si tienes la mencionada, no tienes suertem tu xbox fu actualizada, asi que restaura la resistencia R6T3, el Backup de la Nand y sige jugando.

Actualmente algunos componentes de hardware no son inicializados adecuadamente, debido al poco tiempo que lleva el xploit, esto afecta a:

CPU:

- La CPU se ejecuta en modo de bajo consumo, y a un cuarto de su potencia total, activarla completamente es posible pero actualmente se trabaja en ello.

GPU:
- Se requiere una instalacion a pantalla completa, incluida la programacion de ANA, actualmente solo soporta 640x480.
- EDRAM debe "entrenarse". esto es lo que falla cuando se muestra E74, el codigo es bastante completo y se ha realizado ingeneria invera, pero todavia no corre adecuadamente, sin embargo funciona, y debe trabajarse mas.

SATA:
- SATA nesecita algo similar a un reset, funciona adecualamente bajo linux, pero no bajo Xelll


----------------ACA TERMINA EL TUTORIAL Y EMPIEZA LA EXPLICACION TECNICA, SI NO TE INTERESA PUEDES SALTARLA----------

Para etender este nuevo hack, vamos a mirar primero a lo que hace posible el Xploit de King kong: Un Bug fatal en el manejo de llamadas al sistema del Hypervisor introducido en la actualizacion 4532, para mas detalles mira aca(Ingles):
http://www.securityfocus.com/archive/1/ ... 0/threaded donde explican el problema en detalle.

El exploit KK Explota el bug del kernel modificando un shader sin firmar para que haga una serie de llamadas al sistema, una operacion donde la GOU puede escribir los resultados de un pixel o un vertex shader en la memoria. El shader fue programafo para sobreexcribir en contexto de hilos en espera, para hacer al kernel saltar a cierta posicion en memoria, con algunos registros bajo nuestro control.

Para obtener el control de todos los registros, un segundo paso es nesesario, esta vez saltando hacia el restaurador. Esto finalmente permite a todos los registros de proposito general de la CPU ser llenados con determinados valores. El contador del programa puede ser restaurado con una llamada al sistema en el kernel, con los valores de los registros previamente modificados, lo ke lanza el Xploit.

El Xploit basicamente permite saltar hacia cualquier direccion de 32-bit en el espacio destinado al hypervisor.
Para salta hacia una pocision arbitraria, nosotros solo usamos un par de registros "mtctr, bctr" en el hypervisor, lo que conyeva a una redireccion hacia cualquier direccion de 64-bit, Esto es importante, pues necesitamos limpiar los primeros 32-bit (asignar el MSB para Desactivar el HRMO), pues el codigo que queremos enviar, esta en memoria sin encriptar.

Este codigo usualmente carga un cargador de segunda fase, por ejemplo Xell, en la memoria y lo ejecuta, Xell intentara tomar control sobre todos los hilos de la Cpu( pues solo el hilo principal es afectado por nuestro Xploit) y carga el codigo del usuario, por ejemplo desde un DVD

Asi pues, Las siguientes areas de memoria estan implicadas:

- Contexto de hilos en espera, en 00130360 de la Memoria Fisica

Almacena el puntero de la pila ( y otros elementos) cuando el hilo en espera es suspendido, para cambiar el puntero, y esperar a que el kernel cambie al hilo en espera, podemos adquirir permisos sobre el puntero de la pila. Parte del contexto de cambio de puntero es tambien contexto de restauracion, basado en el nuevo puntero de la pila.

- Contexto de restauracion, parte 1, localizacion arbitraria, Xploit KK usa la 80130AF0

El Hilo del contexto de restauracion, no restaura todos los registros, pero nos permite controlar el NPI (Puntero de la Sigiente intruccion en ingles, nosotros configuramos el NPI para interrumpir dicho contexto, lo que realiza una carga relativa del SP (Puntero de la Pila) de la mayoria de los registros.

- Contexto de restauracion, parte 2, Misma localizacion que la anterior

Simplemente reutilizamos el mismo puntero de la pila, pues las areas donde el contecto de interrucion y restauracion leen , no se regeneran. Este segundo contexto de restauracion nos permite pre-determinar todos los registros con valores arbitrarios de 64 bits.

- Offset del Hypervisor en 00002080 para la llamada 0x46 en el kernel 4532T

Debido al bug en el hypervisor, podemos escribir este offset en memoria desencriptada, dandonos la posibilidad de saltar a cualquier ubicacion en el espacio del hypervisor ( con cierto prefijo de encryptacion), usualmente escribimos 00000350 aca, donde apuntamos a las intrucciones "mtctr %r4; bctr", lo que nos permite saltar a %r4.

- Nuestro Cargador, en ubicacion arbitraria

Este codigo sera ejecutado desde el hypervisor,es nuestro primer codigo que sera ejecutado, %r4 en la llamada al sistema apunta a este codigo.

Solamente el contexto de hilo en espero y el Offset del hypervisor tienen direcciones modificadas.

Afortunadamente, El controlador de la NAND soporta lectura DMA, cuando el payload esta separado de los datos "ECC", cada pagina tiene 512 bytes de payload, y 16-bytes de datos ECC, una simple lectura DMA, puede usarse para cargar todas las direcciones de memoria requeridas, elegimos el payload para leer el contexto de hilo en espera, el contexto de restauracion y el codigo del cargado, los datos ECC llevaran el offset del hypervisor.


Para realizar una lectura DMA, los siguientes registros de la NAND deben sobreescribirse:

Direccion ea00c01c para el Payload
Direccion ea00c020 para ECC
Direccion ea00c00c dentro de la NAND NAND
comando ea00c008 : lectura DMA (07)

El Controlador de Administracion del Sistema (SMC en ingles) es un nucleo 8051 embedido en el Southbridge, Administra la secuencia de corriente, y siempre esta activo cuando la Xbox tiene corriente (completa (verde) o en espera (amarillo)), controla los botones frontales, tiene un reloj en tiempo real, decodifica el infrarojo, controla los ventiladores y la lectora, se comunica con el panel frontal y establecer los LEDs. Cuando el sistema esta en ejecucion, el kernel puede comunicarse con el SMC, por ejemplo para actualizar el reloj, abrir la bandeja, sucede en sentido bidireccional FIFO ( en ea001080 / ea001090). ve el codigo SMC de Xell para mas detalles.

El SMC puede leer la NAND, pues requiere acceso a una pagina especial de la NAND la cual contiene un bloque para la configuracion del SMC, este bloque contiene informacion de calibracion para los diodos terales y sus objetivos, el nucleo 8051 tiene acceso a los registros de la NAND, que estan mapeados en los SFRs 8051. usa el mismo protocolo que el kernel, y escribe en una dirreccion, hace un comando le lectura y lee los datos de los registros.

Tambien puede hacer un comando de lectura (DMA), asi que hackeando el SMC, podemos hacer a la xbox ejecutar el Xpliot sin ningun shader-pues el SMC puede accesar la NAND en cualquier momento, incluso si el kernel esta en ejecucion (piensa en ke hace una interferencia), asi pues, solo disparamos la lectura DMA cuando el kernel a sido cargado y todo esta bien

Entendido?

Bueno, eso seria muy facil, mientra la mayoria de los registros de la NAND estan mapeados, los registros de direcciones DMA(1c, 20) no lo estan. Podemos hacer un DMA, pero solo a las direcciones por defecto (o donde el kernel haya hecho la ultima DMA) FALLO.

La GPU, (H)ANA (el "reescalador"-que en realidad no reescala nada, es solo un set de DAC, y, desde Zephyr, un codificador DVI/HDMI), el southbrigde y la CPU tienen sus puertos JTAG expuestos el la board, son terminales sn terminales, pero las senales esta ahy, el JTAG de la CPU es una historia (compleja) diferente, el del SouthBrigde no ofrece mucha funcionalidad, el de ANA no se ubica en ningun bus de datos interesante, lo que nos deja el de la GPU.

Ae aplico ingenieria inversa al JTAG del GPU hasta el punto donde escrituras PCI arbitrarias son posibles, hasta cierto punto, lo que nos permite comunicarnos con con cualquier dispositivo PCI del sistema, incluido el controlador de la NAND, asi que simplemente podemos usa eso en vez del SMC para iniciar el DMA?

Entendido?

Bueno, no exactamente, el problema es que el "Codigo VM", el codigo que inicializa gran parte del sistema como la memoria (ese codigo tambien es responsable de generar los errores 01xx de las luces rojas), asigan cierto bit en algun registro de la GPU que desabilita la interface JTAG, El Codigo VM es ejecutado antes que el kernel, asi que tambien es un FALLO.

Pero la combinacion funciona, al programar la direccion objetivo del DMA via JTAG, y ejecutar el ataque via SMC, el ataque puede ejecutarse tan pronto como el kernel este corriendo, esto permite interactuar al SMC con el RTC, nos aprovechamos de esto para iniciar el ataque, lo que es un punto perfecto para nosotros.

Pero como ejecutamos un kernel con el Xploit?, Muchas maquinas ya estan actualizada, Dejenme recordarles como funciona el proceso de arranque

1BL (Bootrom)

Embedido dentro de la CPU, este codigo ROM de menos de 32k es responsable de leer el 2BL de la NAND y desencriptar la misma en la SRAM de la CPU, Verifica el HASH de la imagen desencriptada con un bloque firmado al inicio del 2BL, y detiene la ejecucion si el codigo n corresponde, este codigo tambien contiene un numero de funciones de prueba, las cuales puede activarse desde los 5 POST IN pins, los cuales se encuentran el la parte posterior del PCB, Ninguno de los test es particularmente interesante ( desde el punto de vista de la explotacion), pues la mayoria son relativos al FSB ( Comunicacion etre CPU y GPU) todos los sistemas usan el mismo codigo.

2BL ("CB")

Este codigo generalmente esta localizado en la NAND en la Posision 0x8000, es desencriptado por el 1BL y se ejecuta desde la SRAM interna.

Realiza una inicializacion basica del harwarem y contiene el codigo de verificacion de efuses el cual verifica la version del mismo. Los efuses almacenan la version esperada, y el 2BL almacena una Version, y una "AllowedMask" (=bitfield), y usualmente se almacena en las direcciones 0x3B1 / 0x3B2 ... 0x3B3.

Xenon Zephyr Falcon Jasper
2 0003 1888, 1901, 1902
4 1920 "codigo zeropair nuevo"
5 0010 1921 4558 5760,5761,5770 6712 TA-fixed

Entonces verifica la informacion de paridad almacenada en la cabezera del 2BL, parte de la misma es un checksum del area de la NAND la cual fue usada para cargar el codigo del SMC.

Tambien contiene una maquina virtual, y cierto codigo que corren en esta maquina, este codigo es bastanque complicado y hace lo siguiente:

- Inicializacion del PCI-Bridge
- Desactiva el puerto GPU PCIE JTAG
- inicializa el puerto serial
- se comunica con el SMC para limpiar el bit de sincronizacion
- inicializa la memoria
- genera luces rojas si falla la inicializacion de la memoria

Despues de eso, la memoria externa (512MB) sera inicializada y usable. el 2BL desencripta el 4BL en esta memoria, la encriptacion de la memora ya esta activada, el codigo no ejecutable siempre se escribe encryptadamente.

4BL ("CD")

Este codigo es responsable del verificar y descomprimir el 5BL, y tambien de aplicar parches de actualizaciones, Primero, los efuses son leiods para determinar la secuencia de actualizacion, un numero que basicamente cuenta el numero de actualizaciones actualizadas, esto permite configurar la consola de manera que no se use una actualizacion antigua, asi pues, cada ranura de la actualizacion almacena el maximo valor de efuses quemados, el kernel base, tambien tiene un valor asignado, usualmente 0, pero puede ser ccambiado en el bloque de paridad del 2BL. de esto es lo que se aprovecha el timming attack.

5BL ("HV/Kernel")

El hypervisor y el kernel se encuentran en una sola imagen comprimida con un algoritmo propietario (LDIC).

6BL ("CF"), 7BL ("CG")

Esto es parte de una actualizacion del sistema, cada consola tiene una llamada al sistema "kernel base", es cual es el kernel 1888 que estaba disponible en el lanzamiento en 2005, y 2 secciones de actualizacion, areas de 64k c/u (128k en las jasper), que contienen el 6BL 7 BL, 6BL es un codigo que aplica la actualizacion, usando compresion delta clever, y 7BL es la actualizacion actual, en un binario esencial.

Oh, pero las actualizaciones son de mas de 64k, pues solo los primeros 64 son almacenados en las areas de actualizacion, lo demas se almacena en en el sistema de archivos como un fichero especial, Desde que el 6BL no contiene un interprete del fichero de archivos, un blockmap es anadido en el 6BL el cual apunta a los senctores que contienen el resto de la actualizacion.

Zero-Pairing

Ahora, ahy una situacion especial: si el bloque de paridad del 2BL es 0, el bloque de paridad no es comprobado, sin embargo, un bit es asignado de tal forma que el kernel no arranque el binaro del dashboard, pero otro bit llamado "mfgbootlauncher", donde mfg es probablemente una abreviatura de "Manufacturing:, asi que es un residuo del proceso de produccion, donde la imagen de la flash es usada en todo el hardware, probablemente antes de programar una CPU Key.

Usando esta caracteristica, nos permite producir una imagen de la flashe que sea valida para todas las consolas, sin embargos, el 4BL, no mira las ranuras de actualizacion cuando detecta este modo, asi que terminamos en el kernel base 1888, y no podemos ejecutar el dashboard, y es imposible escapar de este modo.

Anteriormente, este era bastanten aburrido, pues el kernel 1888 no contiene el exploit, y de todas maneras es imposible ejecutar king kong.

Sin embargo, iniciando con una version del 2BL 1920, pasa algo interesante:
La clave de encriptacion del $BL es generada con ayuda de la CPU-key, esto significa que son la CPU-key, no es posible desencriptar el 4BL, Notese que el 2BL tiene exactamente una unica imagen valida del 4BL - el 2BL contiene un hash del 4BL altamente codificado, y no usa RSA.

Sin embargo, Los datos sin paridad son detectados, la CPU key NO se usa en este proceso como anteriormente, esto significa que tu ya no puedes solo asignar ceros a los datos sin paridad nunca mas
, el 4BL seria desencriptado con la clave erronea, en cambio necesitas desencriptar el 4BL ( Necesitas el CPU-key), y re-encriptarla con el algoritmo.

Sin embargo, 1920 es suceptible al timming attack y recuperar la CPU-key seria posible en una consola, lo que no asyudaria a desencriptar el 1920 4BL, las ranuras de update no serian ignoradas, encambio, si tienen paridad 0, serian aplicadas.

Este cambio nos permite arrancar en cualquier kernel, sabiendo que tenemos un set 2BL/4BL que corre en la maquina, esto es muy importante, pues podemos generr una imagen que corra en el kernel 4532, independiente de cuantos efuses haya, sin embargo, el proceso de revocacion del 2BL debe saltarse, asi que no somos completamente independientes de los efuses, todavia.
Pero desque que usamos paridad zero, el hash del SMC no importa mas ( existen mas formas de pasar por el problema del hash del SMC, como el timming attack, pero este es gratis), todavia, arrancamos con el MfgBootLauncher,(lo que genera un aro rojo y verde, lo veras, es unico y no luce como luces rojas o algo parecido), pero gracias al SMC/JTAG hack describido anteriormente, esto nos permite lanzar nuestro ataque desde este estado.

La consolas nuevas (que tienen el timming attack corregido) no ejecutan 1920, estas ejecutan por ejemplo 1921, el problema es que no podemos ejecutar codigo de Hypervisor en dichas maquinas asi que no conocemos la CPU-key, sin embargo si comparamos 1921 y 1920 2BL (el cual podemos desencryptar) el unico cambio es el fix para el Timming Attack (reemplazando dos instancias de memcmp, con una funcion memdiff). Tambien, conocemos el valor hash esperado del 4BL desencriptado, basado en un 1920 4BL, y esperamos que hayando cambiado su funcionalidad y el tamano del mismo, seamos capaces de hacer modificaciones, para generar una imagen que pase el chequeo del 2BL. Entiendase que no es una colision de hash, nosotros hicimos derivar en la imagen exacta, aplicando los cambios entre 1920 y 1921 BL obteniendo el ultimo.

el 1921 2BL teoricamente se ejecuta en todas las maquinas, incluyendo aquellas con el Timming Attack corregido, pero falla al ejecutarse en Zephyr, Falcon y Jasper., la razon es el codigo de la maquina vrtual el cual no cobija los 3 tipos de gpu: Xenon 90nm, Zephyr y Falcon 80 nm y jasper 60nm.

Pero el paso de 1921 a 4558 es corto, es solo una version difierente, mas una diferencia en el codigo memcpy, la cual puede ser portada desde el 2BL.

En jasper 67xx la cosa es distinta, pues el codigo anade soporte para la flash mas grande usada en las Jasper-Arcade, Usamos cierta magia para obtener este codigo.

Asi que tenemos TODAS las versiones del 4BL, no es genial, esto significa que TODAS las maquinas pueden ejecutar el kernel 4532, Este kernel soporta consolas falcon y tambien funciona en las consolas Jasper (pues explotamos la vulneravilidad despues de que las diferentes GPU has sido tocadas).

------------------------ACA ACABA LA PARTE TECNICA, GRACIAS POR LEER-------------------------------------

Agradecimientos

recuperacion del CB1920 por robinsod,
Ingenieria inversa inicial del JTAG por tmbinc,
Informacion de los straigh por SeventhSon,
Primera descripcion de como funciona por Martin_sw,
Codigo SMC JTAG, pruebas y debugging por Tiros
Mis cursos de ingles que me premitieron traducir todo d(X_X)b

A LA COMUNIDAD EOL