Proceso Arranque Xbox 360

De ElOtroLado

la fuente de este articulo es una entrevista realizada por la pagina web XLIFE.NL a el conocido hacker que posibilito el hack de firmware DVD, TheSpecialist.

Fuente: http://www.xlife.nl/article.php?id=21676

La entrevista ha sido limpiada, modificada y traducida, para detallar en este Wiki, todo lo relativo a la seguridad en el arranque de la consola Xbox360.

Todos los ejecutables de Xbox360 tienen una firma digital. Esta firma es revisada por el hipervisor. Si se pudiera modificar el hipervisor, podemos ejecutar Homebrew.

Sin embargo, el hipervisor tambien esta firmado.

el proceso de arranque es el siguiente:

• La primera cosa que sucede cuando enciendes la consola Xbox360, es la carga del primer BootLoader (tambien conocido, y abreviado, como '1bl'). Este BootLoader, que se puede pensar en el como un archivo, es muy pequeño, puesto que resulta extremadamente caro colocar archivos grandes en la CPU. El 1bl esta embebido en la CPU, y teoricamente, es imposible cambiarlo, puesto que viene 'serigrafiado' en el mismo chip.
• Puesto que el 1bl es un archivo muy pequeño, apenas hace poca cosa mas que comprobar minimamente el hardware critico (testeo somero de RAM y CPU) y procede a cargar el segundo BootLoader (abreviado como '2bl'). Este 2bl esta localizado en la memoria FLASH de la consola Xbox360 (la cual se puede actualmente dumpear y desencriptar con herramientas ya disponibles).
• Por supuesto, el 2bl esta firmado, y dicha firma es comprobada por el 1bl antes de permitirle ejecutarse. Si la firma es conforme, el 1bl le da permisos de ejecucion al 2bl que ya esta cargado en memoria y comienza su ejecucion.
• El 2bl comienza una secuencia para 'sincronizar' el kernel con el hipervisor. Es importante remarcar que es el 2bl quien inicializa el hipervisor, puesto que antes no estaba activo. Una vez que tanto el kernel como el hipervisor estan preparados, arranca ambos.
• El kernel termina de inicializar el resto de dispositivos, como la GPU, los subsistemas de disco, los puertos USB y demas. Mientras esta inicializando el resto de dispositivos, y tras inicializar la GPU, muestra la animacion de inicio. Una vez ha terminado el arranque, muestra el dashboard.

De esta forma, si quieres correr codigo sin firmar, se debe encontrar una forma de alterar el 1bl. De esa forma, se puede instalar un BootLoader propio que no chequee la firma del 2bl, y entonces parchear el 2bl de tal forma que no chequee la firma del kernel ni del hipervisor de tal forma que sea capaz de lanzar ejecutables sin comprobar las firmas. Basicamente, es una cadena de chequeos de firma: el 1bl comprueba la firma del 2bl, el 2bl chequea la firma del kernel y del hipervisor, y el hipervisor chequea la firma de los ejecutables. Asi que, si puedes romper el principio de la cadena, puedes cambiar el resto como quieras.

Pero alterar el 1bl no es nada sencillo, puesto que esta en el interior de la CPU... Pero nada es imposible

UPDATE: se ha descubierto un metodo de ataque, conocido como TimingAttack que permite meter un 2bl con firma personalizada, permitiendo el arranque de cualquier kernel, vulnerables o no.

NUEVO:

The cpu begins running the 1BL. All cores go from real mode into translated mode (instruction only). All cores but one are catched into a loop. The other one does the whole boot process. The encrypted CB section is decrypted and read into mem/cache. Its (RSA!) signature is checked and its HMAC pairing data aswell. If all is ok it jumps to the CB section.

At the beginning of the CB section the second part of the CB section is loaded into a different part of memory. Also the code the other cores will later on jump to (containing a jump into the hv) is loaded into mem. Then it jumps to the second part of CB. After doing some setup it decrypts and loads the CD section into memory. It checks the SHA1 hash (contained in the RSA signed part of CB) and if correct jumps to CD (mtlr/blr jump, not rfid).

In the CD section translation for data access is turned on (no real mode addressing data anymore). It then decrypts and reads the CE section into memory and checks another SHA1 hash. If correct it decompresses the CE into the memory location the hv starts. Keep in mind this is done in data-translated mode (so starting at effective address 00000000). Basicly kernel/hv 1888 is now loaded into memory. It then loads and decrypts one of the CF sections. Checks the RSA signture and paring data (HMAC) and if all is ok runs the CF section.

The CF section checks if its corresponding CG section (which contains patch data) is correct by another SHA hash. If correct CF decompresses the CG patches into the kernel/hv. It then returns to CD. In the CD section there is a rfid-jump to the entry point of the hv (also changing into real addressing mode again).

In the hv (hypervisor real mode) lots of mmu stuff is being set and after that there is a jump to the kernel (again translated mode, lots of 800xxxxx adresses in there). In the kernel systems calls are used to get in and out of the hypervisor. One of the first things it does is re-awake the other cores who will also jump into the hv first. And of course the whole xbox is configured during the rest of the kernel bootup.

Thats pretty much how the xbox booting process looks like.

sacado de: http://www.xboxhacker.net/index.php?topic=8668.msg55011