¿Se puede hacer un ataque "en frio" a la PS3?

Colección · por **SwapNewbie** 18 May 2008 16:07

Yo el BD lo veo bastante inutil. Es lento leyendo... y teniendo en cuenta que el GTAIV ocupa 6 con algo gigas en la 360... no creo que sea nada supernecesario.

Seguro que algun dia algun juego si que necesita realmente un BD, pero NO me creo que sea el caso de MGS4. Decir que no lo pueden doblar por falta de tamaño es patético.

[bye]

por **f5inet** 18 May 2008 23:49

perdon por la intromision, pero... ¿todos los hilos de Scene y linux de PS3 son asi? o sea... ¿se empieza hablando de un vector de ataque totalmente valido al metodo de cifrado de la PS3 y nos ponemos a comentar que las tecturas de MGS4, que aun no han salido, son de 738MB y que a kojima se le ha quedado el BR pequeño?

por **lacion** 19 May 2008 08:26

f5inet escribió:perdon por la intromision, pero... ¿todos los hilos de Scene y linux de PS3 son asi? o sea... ¿se empieza hablando de un vector de ataque totalmente valido al metodo de cifrado de la PS3 y nos ponemos a comentar que las tecturas de MGS4, que aun no han salido, son de 738MB y que a kojima se le ha quedado el BR pequeño?

get used to it!!!.

sep aqui a la peña que no tiene ni idea solo habla de eso (con todo el perdon del mundo al que se sienta insultado, pero yo dudo mucho que ni si quiera la mitad de los que comentan esas cosas tengan ninguna experiencia haciendo contenido digital(vease texturas, modelos etc. de forma profecional), ni programando en tiempo real), de todas formas. de valido nada de nada, lee lo que he puesto yo antes sobre los SPE en modo "isolated" que es donde se hacen el trabajo de encriptacion.

yo sigo creyendo que ese SPE al que la ps3 no tiene acceso solo se encarga de esas cosas.

por **f5inet** 19 May 2008 17:07

ok, ese SPE en modo isolated debe ser cargado con codigo+datos en algun momento durante el boot, asi que en algun momento durante el boot, esos datos deben estar en memoria.
vamos, mas o menos debe ser asi:
- check de CPU + RAM + BUSES
- inicializacion del PPU
- carga del bootstrap de la flash. comprobacion de la firma de la flash
- inicializacion y chequeo de los SPE y puesta en marcha del cifrado de RAM y SPE en insolated
- inicializacion del resto del hardware
- carga del SO cifrado desde el disco duro

el problema es que segun este arranque, el SPE seria borrado en el chequeo. la clave de descifrado estaria en RAM durante la carga inicial de la flash y la verificacion de la firma.
si la carga del contenido de la flash se realiza en una direccion absoluta, podemos intentar reinicar con otheros, y usando la extension badram del kernel linux, evitar que 'esa parte abosulta de ram' sea usada (sobreescrita) por el kernel al cargar. con un poco de suerte, el SPE y/o hipervisor no habra bloqueado esa zona de RAM.

¿es posible?

por **doragasu** 19 May 2008 20:16

Todo el código que entra y sale de un SPE en modo isolated, va cifrado, incluso durante el boot. Además, según tengo entendido, en el CELL, a diferencia de lo que ocurría en por ejemplo la XBox, la clave no sale en ningún momento hacia fuera.

por **f5inet** 20 May 2008 10:55

vamos a ver, no puedes poner directamente un SPE en modo isolated. debes cargarlo con codigo+datos, y LUEGO ponerlo en isolated y opcionalmente meterle cifrado a las comunicaciones.

yo digo atacar el SPE ANTES de que se encuentre en isolated y DESPUES de que haya sido cargado con codigo+datos.

en la X360 va todo a traves de una cadena de confianza:
- la CPU tiene 'serigrafiado' una CPU KEY.
- Con dicha CPUKEY, se comprueba la firma del 1BL (primer bootloader) (o sea, se inicia la CPU, los buses y la ram, se lee de la flash el famoso kernel 1888, se comprueba la firma con la CPUKEY para verificar que no haya sido atacado (la CPUKEY es la clave publica de comprobacion del firmado del 1bl))
- si el 1bl tiene firma correcta, se procede a cargar el segundo bootloader (2bl, el kernel mas actualizado de la consola) y se comprueba la firma del 2bl
- si la firma del 2bl es correcta (recordad, la cadena de confianza llega al 1bl actualmente, lo que diga el 1bl es confiable), se procede a activar el hipervisor, se prepara la ejecucion del 2bl y finalmente se ejecuta el 2bl
- la consola carga el 2bl (o sea, internamente hace un soft-reboot para cargar un nuevo kernel) que, ahora si, inicializa la tarjeta de video, el sonido, la aceleracion 3D, los mandos, el DVD, el disco duro... ahora la cadena de confianza llega al hipervisor, que verificara constantemente que los accesos a memoria sean siempre dentro de las reglas que ha configurado el 2bl.

¿en la PS3 no es similar? tenemos un hipervisor corriendo en un SPE corriendo en modo isolated, pero antes de eso ese SPE o la misma PPE ha tenido que correr codigo 'no isolated' para cargar dicho codigo, y ese codigo ha tenido que ser copiado desde la RAM. puesto que las arquitecturas tienen la mala costumbre de no inicializar la memoria en un softreboot (por ejemplo, en la 360 este dato es crucial, puesto que si la memoria se limpia en un softreboot el 2bl se perderia y jamas entraria en ejecucion). por supuesto, el vector de ataque requiere de muchas casualidades: que no se limpie la RAM al ejecutar otheros, saber en que parte de RAM se carga el codigo+datos que se cargaran en el SPE isolated, que el hipervisor no bloquee el acceso a dicha RAM cuando se ejecute otheros y preparar un kernel linux con el parche badram que no sobreescriba/use dicha parte de RAM para poder leerla posteriormente con herramientas de volcado de RAM.

pero oye, es una posibilidad...

por **lacion** 20 May 2008 11:46

f5inet escribió:vamos a ver, no puedes poner directamente un SPE en modo isolated. debes cargarlo con codigo+datos, y LUEGO ponerlo en isolated y opcionalmente meterle cifrado a las comunicaciones.

yo digo atacar el SPE ANTES de que se encuentre en isolated y DESPUES de que haya sido cargado con codigo+datos.

en la X360 va todo a traves de una cadena de confianza:
- la CPU tiene 'serigrafiado' una CPU KEY.
- Con dicha CPUKEY, se comprueba la firma del 1BL (primer bootloader) (o sea, se inicia la CPU, los buses y la ram, se lee de la flash el famoso kernel 1888, se comprueba la firma con la CPUKEY para verificar que no haya sido atacado (la CPUKEY es la clave publica de comprobacion del firmado del 1bl))
- si el 1bl tiene firma correcta, se procede a cargar el segundo bootloader (2bl, el kernel mas actualizado de la consola) y se comprueba la firma del 2bl
- si la firma del 2bl es correcta (recordad, la cadena de confianza llega al 1bl actualmente, lo que diga el 1bl es confiable), se procede a activar el hipervisor, se prepara la ejecucion del 2bl y finalmente se ejecuta el 2bl
- la consola carga el 2bl (o sea, internamente hace un soft-reboot para cargar un nuevo kernel) que, ahora si, inicializa la tarjeta de video, el sonido, la aceleracion 3D, los mandos, el DVD, el disco duro... ahora la cadena de confianza llega al hipervisor, que verificara constantemente que los accesos a memoria sean siempre dentro de las reglas que ha configurado el 2bl.

¿en la PS3 no es similar? tenemos un hipervisor corriendo en un SPE corriendo en modo isolated, pero antes de eso ese SPE o la misma PPE ha tenido que correr codigo 'no isolated' para cargar dicho codigo, y ese codigo ha tenido que ser copiado desde la RAM. puesto que las arquitecturas tienen la mala costumbre de no inicializar la memoria en un softreboot (por ejemplo, en la 360 este dato es crucial, puesto que si la memoria se limpia en un softreboot el 2bl se perderia y jamas entraria en ejecucion). por supuesto, el vector de ataque requiere de muchas casualidades: que no se limpie la RAM al ejecutar otheros, saber en que parte de RAM se carga el codigo+datos que se cargaran en el SPE isolated, que el hipervisor no bloquee el acceso a dicha RAM cuando se ejecute otheros y preparar un kernel linux con el parche badram que no sobreescriba/use dicha parte de RAM para poder leerla posteriormente con herramientas de volcado de RAM.

pero oye, es una posibilidad...

No es nada similar. Para empezar el cell comprueba todo lo que entra en memoria y puede entrar cifrado. no hace falta desencriptar nada para ejecutarlo. Perfectamente puede llegar código cifrado al SPE entrar en modo isolated y una ves así ejecutar el Decryp (que te recuerdo es por hardware asi que es una llamada que hace la misma cpu, no hace falta decirle nada.). Después te encuentras con el detalle que en el momento que una aplicación externa intenta acceder a la memoria que no es de su propio dominio el Cell mata el proceso y lo vuelve a lanzar. Dentro del cell no puedes tocar la memoria de otro proceso (dominio) sin que el procesador te detenga la ejecución.

Te recuerdo que las firmas están dentro de la memoria de los propios SPE, no en la ram de la maquina. (así funcionan los cell de los blade center, no tiene porque ser diferente en la ps3)

Colección · por **Pablinho666** 23 May 2008 18:46

Como vas a realizar un ataque en frio si primero congelas con nitrogeno y luego calientas el chip para desoldar, lo normal es que se descongele y entonces la memoria se borre.
No se, digo yo, corregidme si me equivoco.

por **jose manuel rod** 28 May 2008 23:36

fidillo escribió:
Ojobenito escribió:Foto del día 14 de Mayo de 2008 distribuida por Konami.

Las foto que has puesto salio a la luz antes del 14 de Mayo, solo has de ir a IGN y comprobarlo, y porcierto, decir que son de PS1 eso demuestra que no es que no sepas, esque Trolleas.

Salu2[/quote. siento meterme en donde no me dan vela,no es por hacer de abogado del diablo pero creo que una imagen vale mas que mil.......... ale a comprar el mgs

Patrocinadores

Estadísticas

Patrocinadores

Índice de foros › PlayStation 3 › Scene y Linux

¿Se puede hacer un ataque "en frio" a la PS3?

Re:

Re:

No es por nada

Re: Re:

¿Quién está conectado?