3.60 KEYS

Most escribió:

Highwind escribió:Actualmente tengo una crisis muy existencial en mi cabeza, estoy por explotar y PFF, liarla, subir todo lo que tengo en mi PC y que salga todo por donde tenga que salir, que me acribillen o me cuelguen, que me aladen o me señalen, a punto de estallar ya con toda esta mierda... Dios, me va a dar una puta crisis de ansiedad

estate quieto anda xD

Perooooo...... pero para que vais a soltar todo lo que supuestamente teneis, o acaso servirá para hacer funcionar el Gran Turismo 5? Responded, funcionará el GT5 con esto? funcionará? habra un CFW gran turismo 5 espechial?

Si es así, sacad YA todo lo que tengais malandrines, no nos hagais sufrí, que la espera es insoportable, no podemos viví sin el GT5, no lo entendeis.

Y para colmo, mi niño va y le tira un camión a la pantalla de mi led de 47" y el mamon va y se lo carga , coño ahora que han sacao un fix para el skyrim.
Muchachos, dejaos de murgas y lamentaciones, que lo mio si que es un problema.

Yo disiento de poner las keys... tampoco tengo tiempo como para sacarle partido... juegos de 2ª mano y tirando...

Highwind ha borrado todos sus menajes anteriores (aunque todavía se leen en los cuotes ). Para mi que lo han asesinado y borrado toda la evidencia

Gonzakpo escribió:Highwind ha borrado todos sus menajes anteriores (aunque todavía se leen en los cuotes ). Para mi que lo han asesinado y borrado toda la evidencia

Alomejor ha querido borrar toda evidencia para liberar las cosas de manera anónima sin que se le relacione.

A fin de cuentas;


Actualmente; ¿es posible sacar algún provecho a ps3 que originalmente tuvieran 3.61 o superior? (entiéndase, jugar juegos con Fix, hacer Backups o cargar juegos de PS2).

-Salieron los Keys 3.60; en la practica, ¿significa alguna diferencia, podemos hacer algo con nuestras ps3 que no pudiéramos hacer antes? (por ahí hasta leí que solo servían de llavero...).

Según el usuario filex (que también pertenece a este foro) en el foro chilehardware; actualmente se puede jugar a algunos juegos en ps3 que vienen de fabrica con 3.60 o superior, sin la necesidad de las Keys 3.60. Después de leer varios hilos en este foro, no me queda tan claro.


Gracias por sus respuestas.

A fin de cuentas todo sigue igual y seguira asi, la gente dice que tiene mucho y luego no tienen nada, solo son cortinas de humos. Si tuvieran algo ya lo habrian sacado de forma anonima.

DARUPER escribió:A fin de cuentas todo sigue igual y seguira asi, la gente dice que tiene mucho y luego no tienen nada, solo son cortinas de humos. Si tuvieran algo ya lo habrian sacado de forma anonima.

Creo amigo, que estos si que tienen, de hecho ya han sacado mucho.

Pues entonces ya que dicen que tienen algo con lo que se puede liar parda pues que lo saquen que hay mucha gente que no pueden hacer nada con sus ps3 porque las compraron con 3.60 de fabrica

Dorigon escribió:

Krassh escribió:sois mu raros .... priomero os quejabais d e que no habia keys y ahora que ya las tenemos os quejais xq las tenemos ..... FUCK LOGIC espero que con esto se pueda hacer algo para los q estamos en 4.11

PDT una pregunta en caso de que estas keys no sirvan para nada en 4.11 haciendo un rastreo de donde estan localizadas las KEYS de 3.60 no se podria encontrar la de firmwares mas adelantados???

Si se saco en 3.60 se sabra sacar para 4.11 pero olvidate de un cfw instalable ahi al menos a dia de hoy. PAra firmar un cfw valido y aceptado por la ps3 necesitas las privadas y esas ya no se pueden calcular.

entonces si lo e entendido bien todo lo que pudiese salir seria mediante HARD no? -.- pues q chasko antes de comprarme un hard me sale mas a cuenta comprarme otra ps3... lo malo que si tardaran otro año y medio (como an tardado de 3.55 a 3.60 en sacar algo par ami version no se si sale a cuenta esperar tanto ....

Una pregunta, antes que nada decir que no tengo conocimientos sobre la arquitectura de la ps3 (si me preguntan sobre el wii se bastante del funcionamiento, arranque, comprobaciones, etc... xD)
Existe algun archivo donde se guarde a key?Lv0, Lv1...? O eso no se sabe a ciencia cierta!???
Creo que me pondre a informarme sobre el procedimiento de arranque, comprobaciones etc, a ver si encuentro algo...
Saludos!!

antes en metldr estaban las llaves de todos los loaders, de alli se saca la de appldr que es el que nos interesa ya que guarda la llave para cada llavero que usan los juegos.
geohot uso un exploit que habia descubierto un tal seger y publicó el contenido del metldr y dijo que sony no lo podría tapar, ya que metldr no se puede actualizar ya que esta en cada consola y si lo cambian esas consolas no servirian mas.
y que hizo sony? metió todos los loaders dentro del lv0 que si se puede actualizar y supuestamente nadie tiene la llave para ver su contenido.
Se habló muchas veces de formas de sacar las keys nuevas pero hasta ahora no se habia publicado nada... hay que ver si el que tiene las llaves algun dia dice como las consiguió (estaría bueno que lo diga una vez que a sony no le interese mas la ps3 asi mientras tanto sigue sacando las llaves nuevas)

ironhide666 escribió:antes en metldr estaban las llaves de todos los loaders, de alli se saca la de appldr que es el que nos interesa ya que guarda la llave para cada llavero que usan los juegos.
geohot uso un exploit que habia descubierto un tal seger y publicó el contenido del metldr y dijo que sony no lo podría tapar, ya que metldr no se puede actualizar ya que esta en cada consola y si lo cambian esas consolas no servirian mas.
y que hizo sony? metió todos los loaders dentro del lv0 que si se puede actualizar y supuestamente nadie tiene la llave para ver su contenido.
Se habló muchas veces de formas de sacar las keys nuevas pero hasta ahora no se habia publicado nada... hay que ver si el que tiene las llaves algun dia dice como las consiguió (estaría bueno que lo diga una vez que a sony no le interese mas la ps3 asi mientras tanto sigue sacando las llaves nuevas)

Pero hay algo que a mi no me termina de quedar claro. Corrijanme si me equivoco en algo:

1) El que descifra el metadata del lv0 es el bootloader con una llave AES256 contenida en el mismo.

2) Luego supongo que verifica que la firma sea correcta mediante una clave pública ECDSA (¿esto es correcto?).

3) Como el bootldr no es actualizable, la llave que descifra el metadata y la clave pública ECDSA no se pueden cambiar con actualizaciones de software.

4) Si Sony cometió el mismo error explicado por fail0verflow en la llave del lv0 podemos obtener la privada del mismo.

5) Si tenemos la privada del lv0 y la llave AES256 del metadata podríamos firmar CUALQUIER lv0 modificado a gusto en cualquier consola. ¿Correcto?

6) Cómo Sony no puede actualizar el bootloader. Con cada nuevo OFW solo bastaría descifrar el lv0 (en una PC puesto que ya tendríamos las claves!!) para poder modificar el nuevo firmware a gusto y volverlo a firmar con las llaves privadas que tenemos.

En definitiva, el premio mayor sería la clave AES256 que contiene el bootloader para descifrar el lv0. ¿No es cierto?

Y mi última pregunta. ¿Es Sony capaz de actualizar esta clave AES256 que menciono? Pregunto porque si lanza un nuevo OFW utilizando otra clave para cifrar el matadata del lv0, entonces las consolas vendidas hasta la fecha no podrían instalarlo. ¿Correcto? La única solución para Sony sería cambiar la clave de los bootldr en fábrica y sacar dos archivos diferentes de actualización. ¿Verdad?

En fin. Estas son las cosas que no termino de comprender. Creo que todos mencionan al lv0 como "el máximo objetivo" pero me parece que es mucho más importante tener la clave del bootloader. A fin de cuentas esta es la primera clave de la cadena y si se tiene esa se tienen todas las demás. ¿Correcto?

Me gustaría recibir algo de feedback de estas cosas. Si me equivoco en algo me gustaría saberlo por favor. Estoy seguro que aquí hay mucha gente que sabe mucho del tema.

ironhide666 escribió:geohot uso un exploit que habia descubierto un tal seger

Un tal Segher LoL, Segher es uno de los hackers mas prominentes que hay en consolas (como algunos lo describen: "un huracan"),si no recuerdo mal siempre está muy junto con tmbinc (ambos alemánes) y fue el que platicó además del fallo en la encriptación de PS3, el bug strncmp() en wii.

Scorpius666 escribió:

basslover escribió:No, si se pueden conseguir las privadas. Mira de esta pagina y las siguientes:
hilo_metldr-dump-entra-y-sirvete_1700840_s1290

Creo que no entiendes cómo funcionan los loaders del PS3 y para qué sirve cada uno...

Lo que indica esas páginas es que podría calcularse la key privada de lv0. Eso puede ser cierto asumiendo que las claves de lv0 (públicas y privadas) en su momento fueron generadas con la implementación que tiene el fallo que descubrió el fail0verflow. La probabilidad de que las claves privadas de lv0 puedan ser calculadas con un exploit en el bootldr es definitivamente mayor del 95%. Es decir, lo más seguro es que si consigues un exploit del bootldr consigues la clave privada de lv0.

Pero que tengas la clave privada de lv0 no significa que puedas obtener las claves privadas del appldr por encima de la 3.56. No te confundas. Con eso firmas lv0 y nada más que lv0. No hay una clave lv0 3.55 y otra lv0 3.60, la clave de lv0 es una sola y punto, igual para el metldr: una única clave. Así que al hablar de "claves privadas 3.60" ya inmediatamente tu intuición debería decirte que no tiene nada que ver con lv0.

Supongamos que lograste calcular la clave privada de lv0 y firmaste tu propio lv0. Ajá ¿y? ¿Con eso puedes firmar TODO un CFW en 3.60? Pues no. No puedes ni siquiera firmar lo que va DENTRO de lv0 (los loaders están dentro de lv0 desde la 3.60), es decir, no puedes firmar el appldr, ni el isoldr ni nada, puedes firmar un lv0 pero vacío sin nada adentro.

Lo que sí puedes hacer es firmar un CFW con unas claves generadas por ti y meter todos tus loaders firmados por ti dentro de lv0 y tendrás que desensamblar muy bien toda la rutina de instalación de un nuevo firmware para que logres entender cómo Sony introduce claves nuevas cada vez que saca un OFW nuevo y tú intentar imitarlo. Esto nadie lo ha logrado nunca, pero no es imposible, simplemente hay falta de interés porque es más fácil firmar 3.55 y ya que hacer ese trabajo que es súper duro.

Las claves privadas que realmente te interesan son: appldr, isoldr, spp_verifier, rvklist, etc... Todas las que en esta página tengan versión: http://www.ps3devwiki.com/wiki/Keys#Modules

Es más si ves el primer post de este thread verás que cuando dicen "claves" son muchísimas. ¿Cuántas claves tiene el paste de fuckyoudh? bueno esa misma cantidad de claves privadas es la que necesitas para tu soñado CFW (5 en total creo). Con la de lv0 no te basta.

Y te aseguro que las claves privadas de lv1, lv2, app, iso, etc no las volverás a ver más nunca en tu vida

Como nota final: dejen de "enfrascarse" en decir que necesitan las claves privadas. No las necesitan para nada. Hay muchas otras maneras de hacer las cosas.

Como segunda nota final: Mucho menos del 25% de lo que ha dicho Mathieulh ha resultado ser verdad. En este caso específico de poder calcular la clave privada de lv0 tiene razón, pero es una clave totalmente inútil si no se tienen las otras, que jamás se tendrán.

pues yo entendía que si se tenía acceso a los loaders cifrados se podrían volver a calcular las privadas,acabo de mirar otras fuentes y sí parece que estaba equivocado

Gonzakpo escribió:Pero hay algo que a mi no me termina de quedar claro. Corrijanme si me equivoco en algo:

1) El que descifra el metadata del lv0 es el bootloader con una llave AES256 contenida en el mismo.

2) Luego supongo que verifica que la firma sea correcta mediante una clave pública ECDSA (¿esto es correcto?).

3) Como el bootldr no es actualizable, la llave que descifra el metadata y la clave pública ECDSA no se pueden cambiar con actualizaciones de software.

4) Si Sony cometió el mismo error explicado por fail0verflow en la llave del lv0 podemos obtener la privada del mismo.

5) Si tenemos la privada del lv0 y la llave AES256 del metadata podríamos firmar CUALQUIER lv0 modificado a gusto en cualquier consola. ¿Correcto?

6) Cómo Sony no puede actualizar el bootloader. Con cada nuevo OFW solo bastaría descifrar el lv0 (en una PC puesto que ya tendríamos las claves!!) para poder modificar el nuevo firmware a gusto y volverlo a firmar con las llaves privadas que tenemos.

En definitiva, el premio mayor sería la clave AES256 que contiene el bootloader para descifrar el lv0. ¿No es cierto?

Y mi última pregunta. ¿Es Sony capaz de actualizar esta clave AES256 que menciono? Pregunto porque si lanza un nuevo OFW utilizando otra clave para cifrar el matadata del lv0, entonces las consolas vendidas hasta la fecha no podrían instalarlo. ¿Correcto? La única solución para Sony sería cambiar la clave de los bootldr en fábrica y sacar dos archivos diferentes de actualización. ¿Verdad?

En fin. Estas son las cosas que no termino de comprender. Creo que todos mencionan al lv0 como "el máximo objetivo" pero me parece que es mucho más importante tener la clave del bootloader. A fin de cuentas esta es la primera clave de la cadena y si se tiene esa se tienen todas las demás. ¿Correcto?

Me gustaría recibir algo de feedback de estas cosas. Si me equivoco en algo me gustaría saberlo por favor. Estoy seguro que aquí hay mucha gente que sabe mucho del tema.

Pues creo que en todo lo que comentas estás en lo correcto de todos modos a ver si se pasa algún sabio a confirmarlo

El mayor problema de esto parece ser que el lv0 no es tan bonito como parece según comento DarkVolt(que creo que es amigo de fuckyoudh )

DarkVolt escribió:no , dentro de lv0 no te encontrarás los elf's precisamente en eso ando liado , al descifrar el lv0 nuevo te llevas una gran sorpresa te lo aseguro , no puedo sacar appldr ni isoldr ni lv1ldr ni lv2ldr no ay ningun elf que se identifique como loader , pero tiene una sección de 419kb's exactos que no puedo ni mirar ..

La única solución para Sony sería cambiar la clave de los bootldr en fábrica y sacar dos archivos diferentes de actualización. ¿Verdad?

Lo que me extraña es que Sony no hiciese eso desde un principio aunque es probable que en el mismo pup incluya ya los archivos para modelos antiguos y nuevos aunque lo dudo.

Hola amigos con la noticia de hace unos dias de las keys publicas del fw 3.6+,les vamos a mostrar la manera de hacer un cfw y lo que nos haria falta para su desarrollo:

1. Las claves privadas NO se pueden calcular para ningun firmware >= 3.56, y NO estan en ningun sitio, que para algo son PRIVADAS (solo las tiene Sony, y si las pudimos sacar fue gracias a un error de ellos los cuales aplicaron mal el algoritmo de cifrado de modo que con unos pocos datos y operaciones matematicas podiamos calcular las claves privadas).

2. SI se puede crear un CFW 3.61, el unico obstaculo es sacar las claves publicas, las cuales SI se pueden sacar, con mayor o menor dificultad pero se pueden.

Cada loader se cifra con una clave privada y se descifra con la clave publica correspondiente.

Pero el loader de nivel mas bajo en un FW se cifra y se descifra con la root key, la cual es INVARIABLE porque la root key publica utilizada para descifrar dicho loader se encuentra en el metldr (obviamente, el metldr tendra que poseer la clave publica para descifrar el loader) y el metldr NO se puede actualizar de ninguna forma, de modo que la root key no se puede cambiar de una version a otra de un firmware porque se fastidiaria todo.

Entonces, si queremos crear un CFW de la version 3.61, modificando el LV2 para añadir nuevas funcionalidades, tenemos que ir hackeando toda la cadena de loaders hasta llegar a el.

Ejemplo:

METLDR -> LV0LDR -> LV0 -> LV1LDR -> LV1 -> LV2LDR -> LV2

Mas o menos esta es la cadena de loaders (desconozco si hay alguna pequeña variacion en el FW 3.61).

METLDR, como he dicho, NO se puede actualizar.

METLDR descifra LV0LDR con la root key (LV0LDR es el loader de nivel mas bajo, si no contamos a METLDR) y lo ejecuta.

LV0LDR descifra LV0 con la lv0-key (esta clave si puede cambiar entre versiones de firmware ya que LV0LDR SI es actualizable y por tanto LV0 podemos cifrarlo con una clave privada y actualizar LV0LDR para que lo descifre con la nueva clave publica correspondiente) y lo ejecuta.

LV0 descifra LV1LDR....blablabla


LV2LDR descifra LV2 con la lv2-key y lo ejecuta.

Por tanto, si queremos un CFW, necesitamos descifrar LV0LDR (con la root key, la cual publico geohot y nunca va a cambiar), modificar LV0LDR cambiar la clave de descifrado de LV0 (la cambiamos por una clave la cual sea capaz de descifrar un LV0 cifrado con una clave privada que nosotros SI conozcamos... ¿que clave privada? cualquiera, como si es una clave que generamos nosotros), ciframos LV0LDR con la root key, y ya podemos modificar LV0 a nuestro gusto ya que ahora LV0 se descifrara con una clave publica diferente, de la cual conocemos la clave privada.

Y asi modificamos toda la cadena hasta llegar a LV2, modificarlo y recifrarlo con las nuevas claves que hemos elegido.

Y bueno, esa es la forma contada a grandes rasgos (cuando digo cifrar/descifrar, no me refiero a los contenidos de los loaders, porque eso funciona con AES y es cifrado simetrico y no tiene sentido hablar de clave publica/privada, sino que me refiero realmente a la cabecera de dichos loaders, a la firma, la cual utiliza RSA y es donde intervienen las claves publicas/privadas, con el UNICO objetivo de comprobar que dichos loaders NO han sido modificados).

En el caso del FW 3.61 el tema es un poco mas complejo ya que hay claves publicas RSA y claves AES que no son faciles de obtener, pero bueno, que hay metodos para obtenerlas, hay gente que las tiene, y por tanto no es imposible.

Ahora, hay que tener en cuenta que un CFW solo se puede instalar si la consola se encuentra en un FW 3.55 o inferior, porque en las versiones superiores se hace uso de un nuevo actualizador, el cual verifica el paquete de actualizacion (los datos internos del PUP, para que me entendais) chequeando unas nuevas firmas (que antes no existian y ahora son obligatorias) de las cuales no tenemos ni la clave publica ni la privada (la publica se puede sacar, pero la privada nos podemos ir olvidando y aqui no hay ninguna cadena de nada de modo que podamos evitar esto... el actualizador es una aplicacion aparte del FW y ya no tiene que ver con lo anterior explicado).

Dicho esto ultimo, algunos pensareis que si al actualizar a un CFW 3.56/3.60/3.61 ya no podreis volver a instalar ningun otro CFW (es decir, os quedais para siempre en ese CFW o actualizais a un FW oficial).

La respuesta es SI, pero bueno, es evitable ya que, al crear dicho CFW, podemos modificar el VSH (o lo que corresponda) para hacer uso del actualizador viejo (el cual no chequea las firmas nuevas y por tanto no tenemos ningun obstaculo para instalar nuevos CFW), o modificar el APPLDR para que nos permita cargar el nuevo actualizador pero modificado para que no compruebe las firmas (el nuevo actualizador se puede modificar, claro, pero necesitamos modificar tambien el APPLDR de nuestro FW actualmente instalado para poder recifrar dicho actualizador con una clave privada conocida y que luego el APPLDR sea capaz de descifrarlo y ejecutarlo).

Y eso es todo ya sacaz vuestras conclusiones de nuestro amigo Waninkoko .............................

zrandi escribió:Hola amigos con la noticia de hace unos dias de las keys publicas del fw 3.6+,les vamos a mostrar la manera de hacer un cfw y lo que nos haria falta para su desarrollo:

COPIADO DE UN MENSAJE DE WANINKOKO

Y eso es todo ya sacaz vuestras conclusiones de nuestro amigo Waninkoko .............................

Esta bien que compartas info relacionado al tema, pero 2 cosas:
Esto ya lo habían posteado tal cual unas páginas atras en este hilo.
Y por que pones la info así ambiguamente aparentado que lo has escrito tu o al menos no dejando del todo claro que es de Wanin?

Tmv_Josue escribió:

zrandi escribió:Hola amigos con la noticia de hace unos dias de las keys publicas del fw 3.6+,les vamos a mostrar la manera de hacer un cfw y lo que nos haria falta para su desarrollo:

COPIADO DE UN MENSAJE DE WANINKOKO

Y eso es todo ya sacaz vuestras conclusiones de nuestro amigo Waninkoko .............................

Esta bien que compartas info relacionado al tema, pero 2 cosas:
Esto ya lo habían posteado tal cual unas páginas atras en este hilo.
Y por que pones la info así ambiguamente aparentado que lo has escrito tu o al menos no dejando del todo claro que es de Wanin?

De todos modos eso no es cierto, el mensaje de Waninkoko digo, ya fue desmentido por dospiedras en su dia:


hilo_explicacion-de-waninkoko_1627745_s30

Y raíz de eso escribio esto:


hilo_por-que-no-tenemos-cfw-3-60-y-que-falta-para-tenerlo-actualizado_1628073

Tmv_Josue escribió:

zrandi escribió:Hola amigos con la noticia de hace unos dias de las keys publicas del fw 3.6+,les vamos a mostrar la manera de hacer un cfw y lo que nos haria falta para su desarrollo:

COPIADO DE UN MENSAJE DE WANINKOKO

Y eso es todo ya sacaz vuestras conclusiones de nuestro amigo Waninkoko .............................

Esta bien que compartas info relacionado al tema, pero 2 cosas:
Esto ya lo habían posteado tal cual unas páginas atras en este hilo.
Y por que pones la info así ambiguamente aparentado que lo has escrito tu o al menos no dejando del todo claro que es de Wanin?

Y eso es todo ya sacaz vuestras conclusiones de nuestro amigo Waninkoko .............................

zrandi escribió:

Tmv_Josue escribió:

zrandi escribió:Hola amigos con la noticia de hace unos dias de las keys publicas del fw 3.6+,les vamos a mostrar la manera de hacer un cfw y lo que nos haria falta para su desarrollo:

COPIADO DE UN MENSAJE DE WANINKOKO

Y eso es todo ya sacaz vuestras conclusiones de nuestro amigo Waninkoko .............................

Esta bien que compartas info relacionado al tema, pero 2 cosas:
Esto ya lo habían posteado tal cual unas páginas atras en este hilo.
Y por que pones la info así ambiguamente aparentado que lo has escrito tu o al menos no dejando del todo claro que es de Wanin?

Y eso es todo ya sacaz vuestras conclusiones de nuestro amigo Waninkoko .............................

La conclusión como ya dije, es que los que estén en 3.55, bien, pueden tener el CFW que quieran, pues podrían usar el actualizador que se salta las comprobaciones, pero las placas con más de 3.60 de fábrica, seguimos en las mismas.

En conclusión (según lo que han dicho) las dichosas llaves 3.60 sirven de poco y nada...en términos prácticos no cambiara la situación y aquellos con ps3 con CF superior a 3.60 seguirán sin poder hacer ninguna cosa en sus maquinas, de las que si se pueden hacer en aquellas con CF 3.55 o inferior.

Hay un ligero error en la explicación de zrandi pero el 95% de la información es correcta.

La cadena es:


Entonces al obtener un exploit en bootldr (cosa que no se ha conseguido nunca) y obtener la clave pública del lv0 entonces el resto del chain of trust queda accesible.

El bootldr está también encriptado y es una clave por cónsola y la clave no fue generada al azar, sino se deriva del root key llamada per_console_key_0.

Antes del 3.56 era el metldr quien desencriptaba y cargaba todos los demás loaders. Como el metldr fue comprometido por nuestro amigo geohot, se hizo un cambio que fuera lv0 quien desencripta los loaders y se los pasa a metldr para la carga del resto de los módulos, ya que lv0 aún no ha sido comprometido.

Más información en: http://www.ps3devwiki.com/wiki/Boot_Order

Lo demás que dice zrandi es correcto.

Scorpius666 escribió:Entonces al obtener un exploit en bootldr (cosa que no se ha conseguido nunca) y obtener la clave pública del lv0 entonces el resto del chain of trust queda accesible.

Algunos dicen que sí se consiguio, aunque si realmente es cierto ya se verá...

Scorpius666 escribió:Lo demás que dice zrandi es correcto

No lo dice zandri, lo dijo Waninkoko hace cosa de un año aproximadamente

Scorpius666 escribió:El bootldr está también encriptado y es una clave por cónsola y la clave no fue generada al azar, sino se deriva del root key llamada per_console_key_0.

Y yo pregunto, ¿se sabe algo acerca de cómo obtener la per_console_key_0? Porque se estuvo hablando mucho de la per_console_key_1 y es sencillo conseguirla. Pero no se dice nada de la per_console_key_0. Además, si el metldr se descifra con esta key al igual que el bootldr. ¿Por qué se puede conseguir el metldr pero no el bootldr?

Creo que aquí hay muchas cosas que no sabemos y que no se están diciendo públicamente.

Gonzakpo escribió:

Scorpius666 escribió:El bootldr está también encriptado y es una clave por cónsola y la clave no fue generada al azar, sino se deriva del root key llamada per_console_key_0.

Y yo pregunto, ¿se sabe algo acerca de cómo obtener la per_console_key_0? Porque se estuvo hablando mucho de la per_console_key_1 y es sencillo conseguirla. Pero no se dice nada de la per_console_key_0. Además, si el metldr se descifra con esta key al igual que el bootldr. ¿Por qué se puede conseguir el metldr pero no el bootldr?

Creo que aquí hay muchas cosas que no sabemos y que no se están diciendo públicamente.

Todo eso sí se dijo públicamente. El metldr no fue que se desencriptó , se "explotó" y se "dumpeó", nunca fue desencriptado con un key. Es decir se consiguió un exploit. El exploit no fue revelado hasta muchos años después, e inclusive se dice que el exploit de geohot del metldr no es igual al que se reveló luego (que la gente cree que es de Mathieulh, pero no es de él, sino que estaba en su posesión y alguien hizo leak), pero yo creo que el método revelado fue el que usó geohot.

Una vez que hicieron el exploit hicieron un dump del metldr. Cuando digo hicieron realmente es hizo porque lo hizo geohot él solito sin ayuda de absolutamente nadie. Durante el exploit los root keys del 1 al no sé dónde son copiados en una dirección específica de memoria y cuando se hace el dump se obtienen. En ese momento no se sabían para que servían y geohot los ignoró por completo. Gracias a ese dump del metldr y esos root keys se puede hacer CEX -> DEX hoy en día.

En esa época (3.55) el metldr cargaba los demás loaders, al tener el dump del metldr obtener los publics keys del resto era exageradamente sencillo.

Luego que geohot obtuvo todas las claves públicas desde el metldr pasando por lv1, lv2 y llegando al appldr, fail0verflow publica cómo calcular los private keys. geohot observa como se le alínean las estrellas de la mejor manera posible y calcula todas las private keys que pudo y es capaz de firmar el primer CFW para PS3 que existió.

No se sabe nada del per_root_key_0, pero el bootldr es desencriptado con esa clave o con una derivación de ella.

Scorpius666 escribió:

Gonzakpo escribió:

Scorpius666 escribió:El bootldr está también encriptado y es una clave por cónsola y la clave no fue generada al azar, sino se deriva del root key llamada per_console_key_0.

Y yo pregunto, ¿se sabe algo acerca de cómo obtener la per_console_key_0? Porque se estuvo hablando mucho de la per_console_key_1 y es sencillo conseguirla. Pero no se dice nada de la per_console_key_0. Además, si el metldr se descifra con esta key al igual que el bootldr. ¿Por qué se puede conseguir el metldr pero no el bootldr?

Creo que aquí hay muchas cosas que no sabemos y que no se están diciendo públicamente.

Todo eso sí se dijo públicamente. El metldr no fue que se desencriptó , se "explotó" y se "dumpeó", nunca fue desencriptado con un key. Es decir se consiguió un exploit. El exploit no fue revelado hasta muchos años después, e inclusive se dice que el exploit de geohot del metldr no es igual al que se reveló luego (que la gente cree que es de Mathieulh, pero no es de él, sino que estaba en su posesión y alguien hizo leak), pero yo creo que el método revelado fue el que usó geohot.

Una vez que hicieron el exploit hicieron un dump del metldr. Cuando digo hicieron realmente es hizo porque lo hizo geohot él solito sin ayuda de absolutamente nadie. Durante el exploit los root keys del 1 al no sé dónde son copiados en una dirección específica de memoria y cuando se hace el dump se obtienen. En ese momento no se sabían para que servían y geohot los ignoró por completo. Gracias a ese dump del metldr y esos root keys se puede hacer CEX -> DEX hoy en día.

En esa época (3.55) el metldr cargaba los demás loaders, al tener el dump del metldr obtener los publics keys del resto era exageradamente sencillo.

Luego que geohot obtuvo todas las claves públicas desde el metldr pasando por lv1, lv2 y llegando al appldr, fail0verflow publica cómo calcular los private keys. geohot observa como se le alínean las estrellas de la mejor manera posible y calcula todas las private keys que pudo y es capaz de firmar el primer CFW para PS3 que existió.

No se sabe nada del per_root_key_0, pero el bootldr es desencriptado con esa clave o con una derivación de ella.

Ok gracias! Esperemos que alguien libere un metodo para dumpear el bootldr. Según Marcan es sencillo (lo dijo por twitter hace muy poco) pero no dijo como hacerlo ni tampoco contesta si le preguntas :S

http://twitter.com/marcan42/status/223885743435681794

Aquí se hablo del tema en su día:
hilo_metldr-dump-entra-y-sirvete_1700840_s1290

Según parece para dumpear el bootldr descifrado habría que modificar el exploit del metldr filtrado de Mathieulh para que en lugar del metldr dumpease el bootldr. Y con dos bootldr descifrados se podría calcular las keys privadas del lv0.
O al menos eso es lo que yo he entendido

A ver que piensan de esto. Si miran la sección dedicada a las per_console_root_keys de la wiki: http://www.ps3devwiki.com/wiki/Per_Console_Keys

Pueden ver que mencionan que todas las per_console_root_keys se derivan una a partir de la otra. Y también menciona que la per_console_root_key_1 se puede obtener a partir de la per_console_root_key_2 (supongo que haciendo el proceso inverso que se hace para derivarla, que teóricamente se encuentra en el isoldr al cual tenemos acceso en 3.55--). ¿No podría ser que lo mismo se puede hacer con la per_console_root_key_0 a partir de la per_console_root_key_1 y así poder descifrar el bootldr (que supongo que es el mismo para todas las PS3)?

Antes de que alguien se ilusione quiero aclarar que todo esto son simples ideas. Yo no estoy capacitado ni tengo una PS3 con CFW para probar estas cosas. Así que por mi lado no van a encontrar nada. Solo pregunto porque quizás, haciendo esta especie de brainstorming, se pueda llegar a algo interesante. Quizás alguno de los que tienen la info en EOL y no la comparten al menos nos pueden confirmar estas cosas.

basslover escribió:Según parece para dumpear el bootldr descifrado habría que modificar el exploit del metldr filtrado de Mathieulh para que en lugar del metldr dumpease el bootldr. Y con dos bootldr descifrados se podría calcular las keys privadas del lv0.
O al menos eso es lo que yo he entendido

Sí pero no es fácil. El bootldr nada más se puede ejecutar una vez, mientras el metldr se puede ejecutar muchas veces. Entonces la gente booteaba en Linux, cargaba el metldr en un SPU, lo ejecutaba y lo explotaba. Eso no sirve en el bootldr.

Luego que el bootldr se ejecuta hace algo para marcar que ya se ejecutó y no se puede volver a ejecutar de nuevo.

Entonces hay dos alternativas:

1.- Desensamblar el metldr y leerlo línea por línea hasta buscar una pista para determinar qué hace el bootldr para marcarse como ejecutado y cambiar eso de forma que se pueda volver a ejecutar el bootldr, cargarlo en un SPU y "explotarlo".

2.- Hacer un CFW especial donde el bootldr cargue un lv0 que va a explotar y obtener un dump del bootldr desencriptado, soldar un NOR dumper para poder sacarlo de ahí y sacrificar una cónsola la cual una vez que se le instale este PUP especial y se bootee y explote va a la basura sin absolutamente ninguna manera de repararla.

Nadie quiere hacer ninguna de las dos sin que les paguen una buena cantidad de dinero.

Sobre lo de las keys: Los algoritmos de derivación de una key a la otra están basadas en funciones que no son biyectivas por ende no tienen inversa. ¿Recuerdan eso de la secundaria? MD5 es una función sin inversa (en general todas las funciones de hashing no tienen inversa). Por ende a partir de la per_console_key_1 no puedes obtener la anterior. La gracia de las cadenas de confianza es que si se compromete una sección nunca se comprometa nada antes de ella.

Scorpius666 escribió:

basslover escribió:Según parece para dumpear el bootldr descifrado habría que modificar el exploit del metldr filtrado de Mathieulh para que en lugar del metldr dumpease el bootldr. Y con dos bootldr descifrados se podría calcular las keys privadas del lv0.
O al menos eso es lo que yo he entendido

Sí pero no es fácil. El bootldr nada más se puede ejecutar una vez, mientras el metldr se puede ejecutar muchas veces. Entonces la gente booteaba en Linux, cargaba el metldr en un SPU, lo ejecutaba y lo explotaba. Eso no sirve en el bootldr.

Luego que el bootldr se ejecuta hace algo para marcar que ya se ejecutó y no se puede volver a ejecutar de nuevo.

Según DarkVolt:

el bootldr no tiene ningún flag que evite que se evite su reload

La diferencia con el metldr es que al bootldr hay que "engañarlo" de alguna forma para que pueda volver a ejecutarse,posible es, lo que no se es exactamente como lo hace(DarkVolt), quizás sea como la primera opción que señalas, tiene lógica, aunque puede que exista alguna alternativa.

Y no se podria crear un xell(linux) ke muestre la key?tan dificil es desde mi ignorancia?con el xploit de geohot(el de los pulsos) si no recuerdo mal se comprometia el bootloader

yo cuando llegue de vacaciones a finales de mes tengo 1 ps3 para sacrificar y si convenzo a alguien 2... una tiene luz amarilla, y la otra esta en 3.60 pero mi colega le dio un golpe y no lee los discos xDD cualquier cosa o pruebas estaré encantado de aportar sin obtener nada a cambio.

Scorpius666 escribió:Sobre lo de las keys: Los algoritmos de derivación de una key a la otra están basadas en funciones que no son biyectivas por ende no tienen inversa. ¿Recuerdan eso de la secundaria? MD5 es una función sin inversa (en general todas las funciones de hashing no tienen inversa). Por ende a partir de la per_console_key_1 no puedes obtener la anterior. La gracia de las cadenas de confianza es que si se compromete una sección nunca se comprometa nada antes de ella.

Bueno pero una cosa es la teoría y otra cosa es la implementación de Sony de la misma jaja. Cometieron un fallo gravísimo con las llaves ECDSA por lo que no me extrañaría si la función que deriva las keys termina siendo biyectiva. Además, la ps3devwiki dice explicitamente: "can be obtained with a derivation of this key going backwards" para el caso de la per_console_root_key_1. Por lo que la función que deriva la per_console_root_key_2 es biyectiva (de hecho es simplemente un cifrado AES que si no fuera reversible no serviría como algoritmo de cifrado!!). Por lo que, en mi opinión, es altamente probable que la per_console_root_key_1 haya sido derivada de la del bootloader (per_console_root_key_0) de forma similar. Si cometieron el error una vez, seguramente lo hayan cometido dos veces.

Por lo que lo único que sería necesario para obtener la clave del bootloader sería encontrar la función que deriva la clave per_console_root_key_1 y aplicarla a la inversa.

una cosa ¿es cierto lo que dicen, que este mismo usuario soltara en menos de 1 mes las Keys del fw 3.70?

Hibiki-naruto escribió:una cosa ¿es cierto lo que dicen, que este mismo usuario soltara en menos de 1 mes las Keys del fw 3.70?

El mes que viene estarán 3.7x y 4.xx para todo el mundo.