"Timing Attack" de Xbox 360

El estilo de este artículo debe ser mejorado.

El artículo no sigue completamente las convenciones de estilo.

Este artículo tiene una traducción deficiente.

Hay textos que pueden figurar en castellano y no están traducidos.

• El 'Timing Attack' se usa para permitir el downgrade de máquinas con kernel 4552 o superior. El propósito del 'timing attack' es encontrar el valor requerido de hash para permitir que un kernel base (1888) con la sección CB alterada sea arrancado por la consola. El contador 'lockdown' (contador de efuses quemados) de la seccion CB es cambiado a un valor mas alto para permitir que un kernel base (1888) pueda ser arrancado en una consola con efuses quemados. Esta comprobación es, básicamente, lo que hace imposible reflashear la NAND con un kernel mas antiguo (o vulnerable).
• La comunidad de XboxHacker.net hizo este proyecto posible. Arnezami encontró el vector del 'timing attack' e imagino el concepto básico, y Robinsod construyó el hardware necesario para el downgrade y el software de medición requerido para realizar el ataque.
  
  

Propósito

• Una buena explicación del usuario arnezami [1]:
• ¿Con la CPU Key no podemos refirmar las partes esenciales del hipervisor (de ahora en adelante HV), o cualquier otra cosa, con un bootloader modificado?: Todo el código ejecutable en la Xbox esta (de una u otra forma) firmado con una clave RSA. MicroSoft tiene la clave privada RSA, y esa es la razón por la cual nunca sera posible firmar nuestro propio código. Esto es lo que nos impide ejecutar cualquier cosa diferente de lo que MS ha compilado/firmado (como el Kernel o el bootloader). Esto no tiene nada que ver con la CPUKey, la unica cosa que podemos hacer con la CPUKey es elegir que version del Kernel/bootloader queremos ejecutar, pero no podemos cambiar ni un bit a ninguno de ellos.
• Entonces, ¿porque downgradear?: Porque dos versiones de kernel que MS ha publicado (4532 y 4548) tienen un pequeño fallo. Y si tenemos nuestra CPUKey podemos ejecutar dichas (viejas) versiones de Kernel y 'explotarlas' ejecutando el juego KingKong (de ahora en adelante, KK) parcheado especialmente. Despues de ejecutar el exploit del juego KK, tenemos control total sobre la Xbox (pero no antes). Esto significa que para poder ejecutar software casero o linux, necesitas iniciar el juego, presionar OK, insertar un disco, etc.
• Representacion Visual del proceso a seguir:

Memcmp Flaw

• Una función memcmp es usada para comprobar el valor del CB-auth HMAC-hash. El valor es de 16-bytes de longitud y es realizado byte-por-byte. Cambiando un byte por vez es posible determinar si un byte es el valido (true) analizando el tiempo que tardan en compararse lo valores true y false. Al final obtendremos el hash correcto y el proceso de arranque podrá continuar.
• La diferencia de tiempo entre un valor valido y uno falso es de aproximadamente 2200 microsegundos.
• Posibilidades: 16 bytes * 256 posibilidades diferentes para cada bytes = 4096 intentos. Estadisticamente solo la mitad deben ser intentados, luego 2048 intentos.

Procedure

• La documentación oficial del usuario robinsod para el hardware del downgradeo y su proceso pueden ser descargados desde el hilo Timing Attack en XboxHacker.

Dump NAND

• Usar Infectus o un hardware casero (lector de memorias) para realizar un dump válido de la NAND.

Patch CB

• Conseguir un base del kernel 1888 y parchear el CB lockdown con el LDV (LockDownValue) de la sección CF en el dump de la NAND:

1. Conseguir la base del kernel.
2. Descargar Degraded.exe para automatizar la construcción de la nueva imagen del 1888 con las secciones SMC, Keyvault, CB, CD y CE del dump de la NAND. El LDV (contador fuse) será corregido para CB (que es por lo que debes buscar un nuevo hash) y el valor del hash se pondrá todo a cero.

• An external 1888 base kernel is needed because essential system files for 1888 is overwritten in the 4552 update and later, making it impossible to use the NAND dump to create a new 1888 image.
• In Degraded.exe click 'Settings', set the 1BL Key to 'DD88AD0C9ED669E7B56794FB68563EFA', select the folder where the 1888 file system is located, and set 'File System Start' to '39'.
• Select the NAND dump file under 'Flash Dump' and click 'Build Downgrader Image'.

Flash Image

• Flash the new 1888 base kernel build to the NAND.
• Connect Infectus chip to the Xbox 360 again, erase and flash the new patched 1888 base kernel image.

Attack Hash

• Attack the HMAC-hash value using the timing hardware and DGTool.

1. Build the downgrader hardware and connect a serial port cable and power/ground (3.3v or 5v) from the 360 or an external power supply (USB) to the downgrader hardware.
2. Connect the USB cable to the Infectus chip. The Infectus is required to flash the NAND page for the CB section with a new value for each new guess (every ~2 seconds).
3. Create a folder with the 3 following files; DGTool.exe, Infectus.dll and SiUSBXp.dll. Move the 1888 image to this folder too, e.g. Infectus_5787_downgraded_1888.bin.
4. Open a new command-prompt, by Start -> Run -> 'cmd'. Change directory (cd) to the folder where the DGTool.exe is located.
5. DGTool normally only needs 2 arguments to start; one being the COM- or serial port the downgrader hardware is connected to and the other is the filename of the patched 1888 image.

DGTool.exe 1 Infectus_5787_downgraded_1888.bin

• Enter the command above and press enter. Now power on the Xbox 360 and wait for the 3 red lights to start blinking, aka Red Ring Of Death (RROD). Press enter once more to start the timing process. Let it run for a little over an hour (around 1 hour 10 minutes seems to be normal) and the correct hash value will hopefully be discovered. If successful the last line of text should state 'BOOT!'.

Upgrade Kernel

• Once you can boot the 1888 base kernel, you can apply the vulnerable 4532 or 4548 update to use the King King exploit.
• Download the 4532 HD DVD update, extract the files into a folder, and burn the content on a regular CD-R. Insert the CD-R into the Xbox 360 and you will be prompted that a update is required.

Get CPU Key

• Boot a modified King Kong game disc and launch Gentoo Linux to get the CPU Key.

1. Patch the King Kong game image with the King Kong exploit and burn it to a DVD+R Dual Layer disc.
2. Burn the latest Gentoo Xenon release (as of writing beta2) from free60.org to a CD-R and insert the disc after pressing 'Start' on the modified King Kong disc.
3. Download the dump32 application to dump the fusesets to find the CPU Key of the machine.

wget http://home.x-pec.com/~ivc/sites/ivc/xbox360/files/arnezamidump32.tgz
tar zxvf arnezamidump32.tgz
cd arnezamidump32
sudo ./dump32

• Save the FUSES.TXT file to a USB memorystick, upload it to yousendit.com, mail it to yourself, or use the 'scp' or 'ftp' utility to transfer it over the network to a computer.
• The CPU Key is found by combining line 3 + 5 in the FUSES.TXT file.
• It is now possible to upgrade to latest kernel (as of writing 5787) and then downgrade to a lower version again using the 360 Flash Tool. Insert the correct CPU Key in the 360 Flash Tool and patching the LDV (LockDownValue) in the CB/CE/CF section to that of the latest update.

Speculation

• arnezami: MS cannot fix this problem by simply changing the memcmp function in a future kernel version. Thats not gonna help them. The weakness is that the byte-wise memcmp function is in the 1888 kernel/bootloader (and they cannot change that one anymore of course). [2]
• tmbinc: sure, microsoft can change the 2BL, and burn a fuse (of the fuseline 2) so that an old 2BL doesn't work anymore... [3]
• arnezami: Ah. Right. If they can indeed burn these fuses at row 2 than you wouldn't be able to run any of the lower kernel versions anymore. [4] Been thinking about this. I'm now pretty sure when row 2 of the fuses is burned your xbox won't be able to downgrade or run homebrew anymore (it appears the fuse count number is indeed RSA signed). [5]
• surrido: you could if it makes you happy wire a switch to the R6T3 and keep it on while being in live and turn it of when you receive an update. [6]
• tmbinc: No, a switch at R6T3 doesn't help. It's not the resistor which presence can be detected, but the result to the fuse (burned or not). So his question is completely valid: If you remove the resistor, you could end up with an unbootable box after the next update. But at least you could restore a previous flash. (If you want, you could *then* re-attach the resistor, and update again, of course loosing the possibility to downgrade). [7]

References

• Fuente original