Porqué la placa TA88v3 no ha sido hackeada

sta es una explicación de la seguridad que ha sido añadida en la TA88v3, y que seguramente se repita en la PSP3000.

Cuando la PSP se inicia, el código de arranque (a partir de ahora el pre-ipl o el cargador del ipl) carga el ipl desde ya sea la NAND o la memory stick. El IPL es entonces dividido en partes de 0x1000 bytes.

Los primeros 0xA0 bytes de cada bloque es un encabezamiento para el comando nº1 de hardware de encriptación kirk. Contiene las claves, el tamaño de los datos de cifrado, y dos hashes, uno que es parte de por sí del encabezamiento, y otro para el propio cuerpo. Los 0xF60 bytes restantes son el cuerpo cifrado, que se descifrarán en 0xF60 bytes simples... si los hashes, que sn comprobados por el comando kirk de hardware de por si, son correctos. (Nota: El cuerpo cifrado puede ser menor que 0xF60; en este caso, los demás bytes son ignorados... al menos esto sucedía antes de la TA88v3)

La seguridad de los hashes con kirk fue destruida con un llamado timing attack, y entonces el IPL se desprotegió.
¿Qué ha añadido Sony para arreglar esto?

La respuesta puede encontrarse en los ipl's de PSP Slims con un firmware 4.0+. Disminuyeron el tamaño del cuerpo cifrado hasta 0xF40 para dejar 0x20 bytes al final de cada bloque (salida 0xFE0)
Como hemos comentado anteriormente, esos demás bytes eran ignorados... en pre-ipl's de PSP anteriores a la TA88v3, y de hecho, pueden ser aleatorios, y el ipl seguirá cargando en esas PSP's. En los nuevos pre-ipl's, esos 0x20 bytes tienen un significado.

Los primeros 0x10 bytes es un hash desconocido hasta la fecha, calculado desde el bloque descifrado. Se deduce pues que es calculado desde el bloque descifrado y no del cifrado ya que 4.01 y 4.05 tienen muchos bloques de la propia IPL en común, los cuales, al estar descifrados, son parecidos, pero son totalmente distintos al estar cifrados. En estos dos ipl's, el hash es el mismo, como se puede ver en la imagen:



Esta es una explicación de la seguridad que ha sido añadida en la TA88v3, y que seguramente se repita en la PSP3000.

Cuando la PSP se inicia, el código de arranque (a partir de ahora el pre-ipl o el cargador del ipl) carga el ipl desde ya sea la NAND o la memory stick. El IPL es entonces dividido en partes de 0x1000 bytes.

Los primeros 0xA0 bytes de cada bloque es un encabezamiento para el comando nº1 de hardware de encriptación kirk. Contiene las claves, el tamaño de los datos de cifrado, y dos hashes, uno que es parte de por sí del encabezamiento, y otro para el propio cuerpo. Los 0xF60 bytes restantes son el cuerpo cifrado, que se descifrarán en 0xF60 bytes simples... si los hashes, que sn comprobados por el comando kirk de hardware de por si, son correctos. (Nota: El cuerpo cifrado puede ser menor que 0xF60; en este caso, los demás bytes son ignorados... al menos esto sucedía antes de la TA88v3)

La seguridad de los hashes con kirk fue destruida con un llamado timing attack, y entonces el IPL se desprotegió.
¿Qué ha añadido Sony para arreglar esto?

La respuesta puede encontrarse en los ipl's de PSP Slims con un firmware 4.0+. Disminuyeron el tamaño del cuerpo cifrado hasta 0xF40 para dejar 0x20 bytes al final de cada bloque (salida 0xFE0)
Como hemos comentado anteriormente, esos demás bytes eran ignorados... en pre-ipl's de PSP anteriores a la TA88v3, y de hecho, pueden ser aleatorios, y el ipl seguirá cargando en esas PSP's. En los nuevos pre-ipl's, esos 0x20 bytes tienen un significado.

Los primeros 0x10 bytes es un hash desconocido hasta la fecha, calculado desde el bloque descifrado. Se deduce pues que es calculado desde el bloque descifrado y no del cifrado ya que 4.01 y 4.05 tienen muchos bloques de la propia IPL en común, los cuales, al estar descifrados, son parecidos, pero son totalmente distintos al estar cifrados. En estos dos ipl's, el hash es el mismo, como se puede ver en la imagen:





Los segundos 0x10 bytes parecen ser de igual manera dependientes del cuerpo descifrado (posiblemente dependientes de los anteriores 0x10 bytes de igual manera¿?) En la imagen se puede ver que son diferentes en 4.01 y 4.05, pero pueden ser intercambiados; puedes mover esos 0x10 bytes del mismo bloque del ipl de 4.05 al de 4.01, y seguirá cargando; mas sin embargo, este cambio no puede ser aleatorio.

Esta protección de igual manera destruye cualquier posibilidad de hacer un downgrade por debajo de 4.00, ya que estas nuevas CPU's no serían capaces de cargar previos ipl's con dichos firmwares.

En resumen: Básicamente, toda la seguridad de los nuevos cpu's de psp descansa en el cálculo de esos 0x20 bytes. Si el pre-ipl pudiera ser dumpeado de alguna manera, esa seguridad caería TOTALMENTE.

Resumen gráfico: (en inglés)


Fuente dark-alek.org