Por que no tenemos cfw 3.60 y que falta para tenerlo [Actualizado]

yeahja escribió:whaaaaaaaaaat!!! a cual hilo le hago caso? hay dos... repetidos....

dospiedras y ves posible esto viniendo de ti, o sea que tu lo lleves a cabo o es algo que requiere de mucho tiempo y paciencia? (me imagino)

dospiedras1973 escribió:

yeahja escribió:whaaaaaaaaaat!!! a cual hilo le hago caso? hay dos... repetidos....

dospiedras y ves posible esto viniendo de ti, o sea que tu lo lleves a cabo o es algo que requiere de mucho tiempo y paciencia? (me imagino)

reventé mi 80gb's intentandolo la primera vez

y por una pollada , una bola de estaño a la altura del hdmi , petó algo , fusibles todos ok , ni puñetera idea de que es y ni la luz roja oye , escueta escueta xD

sokii escribió:Nadie puede crear el nuevo cfw que todos deseamos .Y aun sabiendo que alguien puede hacerlo...no lo publicaria.

dospiedras escribió:solución? factory mode , este modo en la consola ( si el del jig ) se salta las comprobaciónes de hash del syscon y nos permite arrancar cualquier coreos instalado , perfecto! , pues solo nos queda modificar nuestra nand 3.55 con un cambio drastico
sustituir lv1 por un pequeño codigo hecho nuestro para que dumpee toda la ram a un lugar predeterminado y obtener los loaders descifrados de 3.61 o 3.60 y de ahí sacar las keys publicas , perfecto...

Waninkoko escribió: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).

Ferdopa escribió:Jur...

Tras recibir un MP del autor, lo muevo y reabro en el foro correspondiente.

Un saludo.

matias1823 escribió:Dospiedras, te hago una pregunta, con esto que aclaras aca, estas demostrando desacuerdo con lo que dijo Waninkoko?

Waninkoko escribió: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).

Es decir, se podria instalar un CFW desde un OFW>=3.56? O todavia no estas seguro? Gracias de antemano.

ing_pereira escribió:

dospiedras escribió:solución? factory mode , este modo en la consola ( si el del jig ) se salta las comprobaciónes de hash del syscon y nos permite arrancar cualquier coreos instalado , perfecto! , pues solo nos queda modificar nuestra nand 3.55 con un cambio drastico
sustituir lv1 por un pequeño codigo hecho nuestro para que dumpee toda la ram a un lugar predeterminado y obtener los loaders descifrados de 3.61 o 3.60 y de ahí sacar las keys publicas , perfecto...

Bien pero aun si uno de nosotros o aun no tiene el codigo para dumpear la RAM o simplemente no le interesa igual le sirve este metodo si desea solo tener la posibilidad de un flamante Dual-FW entre FW (3.15, 3.41, 3.55) (Con el simple Piggybacking ) ya que el service mode se salta la comprobación pero me imagino que es posible volver a un FW menor que el 3.55 y de ese modo volver a bootear tu flamante CFW 3.55 o 3.41 y luego estando ahi volver a deshabilitar el modo servicio y seguir disfrutando de el y luego volver a habilitar el Service mode para ir a un FW (3.41, 3.55, etc obviamente saltando el Hash) pero como mucho si lo quieres hacer con el FW 3.60 solo disfrutarias de una Consola en service mode en el FW 3.60 ya que no es posible salir del modo servicio en los FW desde el 3.56 hasta el 3.61 pero si nos sirve para un muy factible Dual-FW entre cualquier FW hasta el 3.55 siendo posible salir del Modo servicio en estos FW. Dospiedra cualquier cosa respondeme si he obviado algo a hablar sobre esto .

Ya se me habia ocurrido lo de usar el Service mode pero asi como lo indicas todavia hace falta escribir ese codigo que pueda dumpear la RAM conoces la dificultad de moddear el LV1 del FW 3.55 para hacer el dump de la RAM?.

Saludos dospiedra y felicitaciones dejaste claro practicamente todo.

vasolechecongalletas escribió:Entiendo muy poco o nada, pero algo si que creo que me ha quedado claro. Todo aquel que se compre una ps3 hoy o el que la tenga ya en 3.61 esta jodido, no?

pupila1992 escribió:Que grande eres dospiedra, ya sabes todo lo que te aprecio tio!



PD: tranquilo, con cuchillo quemado sale todo

dospiedras1973 escribió:

pupila1992 escribió:Que grande eres dospiedra, ya sabes todo lo que te aprecio tio!



PD: tranquilo, con cuchillo quemado sale todo

jajajajaja , si eso seguro :-D

acabo de revisar la actu 3.65 y veo que nos han devuelto lv1 sin encapsular en lv0 pero el lv0 ahora mide 200 kb mas que antes

igusi2000 escribió:Por lo que comentan en muchos lados todo el mundo sabe como hacerlo y es mas quizas ya muchos lo tengan,el problema quizas esque a nadie le interesa sacarlo a la luz.

igusi2000 escribió:Bueno si pero vamos si lo pasas pasando ente amigos igualmente saldra de un punto inicial n? Y aparte supongo que si creas algo asi y te lo curras lo que quieres es publicidad,sacarlo anonimamente no creo que les interese.

Pero vamos por lo que comento 2piedras y wanin es posible conseguirlo veremos haber que pasa

milano33 escribió:Desde mi punto de vista aparte de parecer estar parada, la Scene está muerta.

bley escribió:Con la cantidad de ingenieros de software que hay en el mundo y nadie sabe sacar esto que para alguien sera una chuminada...

dospiedras1973 escribió:
hola ing_pereira , te cuento , eso no sería posible por una simple razon

con dos nands en 3.55 clonadas -> actualizas una de ellas a 3.61 , ( se pone el nuevo hash del coreOS en el syscon ) , pones factory mode y vuelves a tu 3.55 en factory , al quitar el factory te llevarás un bonito brick , ya que no has reescrito el nuevo hash , podrías volverlo a reescribir con el lv2diag en 3.55 , pero , ¿reinstalar el fw cada vez que cambias de fw? es una locura xD, si es posible , pero un mareo de procedimiento cada vez que cambies de fw .....o eso o prepararte una imagen de 3.55 con el lv1 modificado para que se salte el check de firmas del coreOS , que es posible también

ing_pereira escribió:

dospiedras1973 escribió:
hola ing_pereira , te cuento , eso no sería posible por una simple razon

con dos nands en 3.55 clonadas -> actualizas una de ellas a 3.61 , ( se pone el nuevo hash del coreOS en el syscon ) , pones factory mode y vuelves a tu 3.55 en factory , al quitar el factory te llevarás un bonito brick , ya que no has reescrito el nuevo hash , podrías volverlo a reescribir con el lv2diag en 3.55 , pero , ¿reinstalar el fw cada vez que cambias de fw? es una locura xD, si es posible , pero un mareo de procedimiento cada vez que cambies de fw .....o eso o prepararte una imagen de 3.55 con el lv1 modificado para que se salte el check de firmas del coreOS , que es posible también

Vale entiendo, pero aun asi digamos que yo quiero tener 2 NOR con el CFW 3.41 (Linux, etc) y en la otra NOR escribo el mismo FW copiando el core_os y la dev_flash de la otra NOR y que yo en caso de obtener bricks por modificar muchos archivos en cuestion dentro de la NOR y tenga un bonito brick, ¿No podria utilizar la otra NOR que tenia el otro respaldo del FW 3.41 para volver a escribir el respaldo de la NOR sobre la flash brickeada? supongo que al pasar al Service mode en el FW 3.41 y querer salir de nuevo como tu especificaste tendria otro brick pero podria arreglarlo instalando de nuevo el FW y ya estando en eso habiendo desbrickeado la NOR secundaria con el tema de que no se habia reescrito los hashes podria usar linux (Ya estando despues del Service mode) desde esa misma NOR para escribir de nuevo el respaldo del FW sobre la primera NOR que se habia brickeado al yo ponerme a inventar sobre ella, quizas es una idea loca pero funcionaria al menos como seguro Full Anti-Brick .

Oye dospiedra me puedes confirmar si para usar un FW debug es necesario lo siguiente:

Modificar el EID0 y con ello el IDPS (No es posible aun?)
Volverlo a cifrar (No es posible aun?)
Instalar por completo el contenido del Core_OS con linux (Posible)
Instalar la dev_flash (Posible)

El FW debug checkea algun otro valor ademas del Target ID 0x82?

Sabes que necesitamos para poder modificar el EID0 es decir el IDPS para cambiar los datos de la consola?

ing_pereira escribió:

dospiedras1973 escribió:
hola ing_pereira , te cuento , eso no sería posible por una simple razon

con dos nands en 3.55 clonadas -> actualizas una de ellas a 3.61 , ( se pone el nuevo hash del coreOS en el syscon ) , pones factory mode y vuelves a tu 3.55 en factory , al quitar el factory te llevarás un bonito brick , ya que no has reescrito el nuevo hash , podrías volverlo a reescribir con el lv2diag en 3.55 , pero , ¿reinstalar el fw cada vez que cambias de fw? es una locura xD, si es posible , pero un mareo de procedimiento cada vez que cambies de fw .....o eso o prepararte una imagen de 3.55 con el lv1 modificado para que se salte el check de firmas del coreOS , que es posible también

Vale entiendo, pero aun asi digamos que yo quiero tener 2 NOR con el CFW 3.41 (Linux, etc) y en la otra NOR escribo el mismo FW copiando el core_os y la dev_flash de la otra NOR y que yo en caso de obtener bricks por modificar muchos archivos en cuestion dentro de la NOR y tenga un bonito brick, ¿No podria utilizar la otra NOR que tenia el otro respaldo del FW 3.41 para volver a escribir el respaldo de la NOR sobre la flash brickeada? supongo que al pasar al Service mode en el FW 3.41 y querer salir de nuevo como tu especificaste tendria otro brick pero podria arreglarlo instalando de nuevo el FW y ya estando en eso habiendo desbrickeado la NOR secundaria con el tema de que no se habia reescrito los hashes podria usar linux (Ya estando despues del Service mode) desde esa misma NOR para escribir de nuevo el respaldo del FW sobre la primera NOR que se habia brickeado al yo ponerme a inventar sobre ella, quizas es una idea loca pero funcionaria al menos como seguro Full Anti-Brick .

Oye dospiedra me puedes confirmar si para usar un FW debug es necesario lo siguiente:

Modificar el EID0 y con ello el IDPS (No es posible aun?)
Volverlo a cifrar (No es posible aun?)
Instalar por completo el contenido del Core_OS con linux (Posible)
Instalar la dev_flash (Posible)

El FW debug checkea algun otro valor ademas del Target ID 0x82?

Sabes que necesitamos para poder modificar el EID0 es decir el IDPS para cambiar los datos de la consola?

igusi2000 escribió:Una duda dospiedras1973 solo das la informacion de como hacerlo o tu lo estas intentado mas que nada por saberlo,gracias

dospiedras1973 escribió:A ver , con este hilo intento acabar con los malentendidos para el que se quiera informar y el que quiera colaborar que no se pierda por caminos cerrados y pierda el tiempo por culpa de un post desinformativo a nivel de scene.

Paso 1 , entender el sistema antiguo que conociamos todos con los cfw's 3.41 y 3.55 , su funcionamiento ( no hablo de dongles eso es un mundo a parte )
Mediante un fallo de criptografía se consiguió un algoritmo capaz de generar claves privadas de sony para firmar correctamente archivos según el fw del que se extrajeran las claves ( vulnerables a este bug de criptografía )

este bug lo solucionaron pronto como era de esperar , era un fallo muy tonto estilo al memcmp de xbox 360 ( timming attack )

con ese bug eramos dioses en esas versiones digamos , que eramos sony con esas claves , perfecto ..

ahora que pasó? sony cambió todas sus claves privadas desde 3.56+ para adelante y sus algoritmos y por si fuera esto poco , la manera que teníamos de crear y validar los pup's se fueron al carajo con un nuevo sistema que comprueba los headers y sha256 de todos los archivos a instalar con un sistema llamado "spkg" que es controlado por el nuevo modulo del coreOS llamado spu_pkg_rvk_verifier.self que se encuentra en los updates en el core_os_package.pkg , vale via de los cfw's de la antigua era cerrada ..

paso 2 , explicar proceso de boot de la antigua era y de la nueva

antiguo sistema de boot
bootldr -> lv0
metldr ->lv1ldr,lv1,lv2ldr
lv2->lv2_kernel->vsh

nuevo sistema de boot
bootldr->lv0-< se manda a un spu aislado y dentro se descifra y se envia a ram los archivos lv1ldr lv1 lv2ldr DESCIFRADOS y se cargan unos a otros lv1ldr->lv1->lv2ldr->lv2
lv2->lv2_kernel->vsh
NO SE USA METLDR de ahí a que no se saquen las claves publicas ( las que descifran ) de 3.60

peeero , existe un metodo paso 3 :
como he comentado arriba el nuevo metodo almacena en ram los loaders descifrados , bién , ¿existe manera de sacarla logica? sí

con dual boot :-D es decir instalando 2 nor flashes o tener quadro nand's depende de la versión de consola que tengas con tu flash los dos boot's , y con un selector para elegir entre ellos , vale hasta aqui perfecto..

ahora con el selector en posición 1 cojemos la consola y la actualizamos a 3.61 , nos actualiza bien , perfecto..

apagamos la consola y volvemos a encender con nuestra flash 2 que teniamos en 3.55 , pero op's! sorpresa no arranca...

¿ por que ? , simple ...

en el syscon ay una eeprom que guarda el ultimo y funcional HASH del coreos instalado ( el ultimo fué 3.61 verdad? ) putadón ...

solución? factory mode , este modo en la consola ( si el del jig ) se salta las comprobaciónes de hash del syscon y nos permite arrancar cualquier coreos instalado , perfecto! , pues solo nos queda modificar nuestra nand 3.55 con un cambio drastico
sustituir lv1 por un pequeño codigo hecho nuestro para que dumpee toda la ram a un lugar predeterminado y obtener los loaders descifrados de 3.61 o 3.60 y de ahí sacar las keys publicas , perfecto...

otro problema , al reiniciar nuestra consola de forma normal la ps3 borra la ram , si al cambiar de 3.61 a 3.55 nos borra la ram por mucho lv1 modificado que tengamos no nos va a dumpear una leche , es decir lo hará , pero sin rastro de nada de 3.60 o 3.61 ¿ existe solución para esto ? sí

usar un puerto del procesador de la ps3 que se comunica con el syscon que se llama "cell reset be line"

un ejemplo de que ya se ha hablado : http://www.ps3sos.com/showthread.php?14 ... de-la-3.60

si tenemos nuestra nand en posición 1 y el 3.60 cargado en el menú y le damos un pulso a esa linea de 60ns el procesador se reiniciará pero NO LA MEMORIA RAM rapidamente cambias el switch a posición 2 y voilá tu codigo te dumpeará todos los loaders y el resto de la ram de 3.60 0 3.61 segun tengas correctamente.


link's de referencia de todo lo que digo :
orden de boot http://ps3devwiki.com/index.php?title=Boot_Order

la verificación de los pup's http://ps3devwiki.com/index.php?title=P ... ckage_(PUP)

iré añadiendo segun se me vallan ocurriendo

porfavor si existe algun error o modificación hacedmela saber y rapido rectifico , gracias.

Smacks escribió:

milano33 escribió:Desde mi punto de vista aparte de parecer estar parada, la Scene está muerta.

Campeón la Scene no es solo Custom Firmwares , tu sabes la burrada de emuladores que están saliendo actualmente? El ShowTime es una maravilla de reproductor por ejemplo, y es el mejor ejemplo de aplicaciones homebrew que están saliendo actualmente, así como nuevas formas de acceso a la consola etc...

Jhondistorsion escribió:

dospiedras1973 escribió:A ver , con este hilo intento acabar con los malentendidos para el que se quiera informar y el que quiera colaborar que no se pierda por caminos cerrados y pierda el tiempo por culpa de un post desinformativo a nivel de scene.

Paso 1 , entender el sistema antiguo que conociamos todos con los cfw's 3.41 y 3.55 , su funcionamiento ( no hablo de dongles eso es un mundo a parte )
Mediante un fallo de criptografía se consiguió un algoritmo capaz de generar claves privadas de sony para firmar correctamente archivos según el fw del que se extrajeran las claves ( vulnerables a este bug de criptografía )

este bug lo solucionaron pronto como era de esperar , era un fallo muy tonto estilo al memcmp de xbox 360 ( timming attack )

con ese bug eramos dioses en esas versiones digamos , que eramos sony con esas claves , perfecto ..

ahora que pasó? sony cambió todas sus claves privadas desde 3.56+ para adelante y sus algoritmos y por si fuera esto poco , la manera que teníamos de crear y validar los pup's se fueron al carajo con un nuevo sistema que comprueba los headers y sha256 de todos los archivos a instalar con un sistema llamado "spkg" que es controlado por el nuevo modulo del coreOS llamado spu_pkg_rvk_verifier.self que se encuentra en los updates en el core_os_package.pkg , vale via de los cfw's de la antigua era cerrada ..

paso 2 , explicar proceso de boot de la antigua era y de la nueva

antiguo sistema de boot
bootldr -> lv0
metldr ->lv1ldr,lv1,lv2ldr
lv2->lv2_kernel->vsh

nuevo sistema de boot
bootldr->lv0-< se manda a un spu aislado y dentro se descifra y se envia a ram los archivos lv1ldr lv1 lv2ldr DESCIFRADOS y se cargan unos a otros lv1ldr->lv1->lv2ldr->lv2
lv2->lv2_kernel->vsh
NO SE USA METLDR de ahí a que no se saquen las claves publicas ( las que descifran ) de 3.60

peeero , existe un metodo paso 3 :
como he comentado arriba el nuevo metodo almacena en ram los loaders descifrados , bién , ¿existe manera de sacarla logica? sí

con dual boot :-D es decir instalando 2 nor flashes o tener quadro nand's depende de la versión de consola que tengas con tu flash los dos boot's , y con un selector para elegir entre ellos , vale hasta aqui perfecto..

ahora con el selector en posición 1 cojemos la consola y la actualizamos a 3.61 , nos actualiza bien , perfecto..

apagamos la consola y volvemos a encender con nuestra flash 2 que teniamos en 3.55 , pero op's! sorpresa no arranca...

¿ por que ? , simple ...

en el syscon ay una eeprom que guarda el ultimo y funcional HASH del coreos instalado ( el ultimo fué 3.61 verdad? ) putadón ...

solución? factory mode , este modo en la consola ( si el del jig ) se salta las comprobaciónes de hash del syscon y nos permite arrancar cualquier coreos instalado , perfecto! , pues solo nos queda modificar nuestra nand 3.55 con un cambio drastico
sustituir lv1 por un pequeño codigo hecho nuestro para que dumpee toda la ram a un lugar predeterminado y obtener los loaders descifrados de 3.61 o 3.60 y de ahí sacar las keys publicas , perfecto...

otro problema , al reiniciar nuestra consola de forma normal la ps3 borra la ram , si al cambiar de 3.61 a 3.55 nos borra la ram por mucho lv1 modificado que tengamos no nos va a dumpear una leche , es decir lo hará , pero sin rastro de nada de 3.60 o 3.61 ¿ existe solución para esto ? sí

usar un puerto del procesador de la ps3 que se comunica con el syscon que se llama "cell reset be line"

un ejemplo de que ya se ha hablado : http://www.ps3sos.com/showthread.php?14 ... de-la-3.60

si tenemos nuestra nand en posición 1 y el 3.60 cargado en el menú y le damos un pulso a esa linea de 60ns el procesador se reiniciará pero NO LA MEMORIA RAM rapidamente cambias el switch a posición 2 y voilá tu codigo te dumpeará todos los loaders y el resto de la ram de 3.60 0 3.61 segun tengas correctamente.


link's de referencia de todo lo que digo :
orden de boot http://ps3devwiki.com/index.php?title=Boot_Order

la verificación de los pup's http://ps3devwiki.com/index.php?title=P ... ckage_(PUP)

iré añadiendo segun se me vallan ocurriendo

porfavor si existe algun error o modificación hacedmela saber y rapido rectifico , gracias.

Muy buenas, viendo lo documentado que estas en el tema tengo un problema con el que quizas me puedas ayudar a mi y a mas de 400 personas aunque seguramente ya te suene el tema, se trata del error 8002F2C5 y similares que se produjeron al cambiar el disco duro en versiones 3.56v1 quedandose la consola en un bucle infinito al pedir la instalacion/actualizacion de firmware fuera del XMB, alguna idea para recuperar el XMB? he leido por ahi que hay formas de solucionar Bricks parcheando la NAND con el chip Infectus se podrian aplicar? gracias

NaVaJa90 escribió:la teoria de la dual nand k se saco es buena idea, pero aora la pregunta, es factible? es decir cuando salio el documento salio como una teoria, pero llevarlo a la practica es posible?

dospiedras1973 escribió:

NaVaJa90 escribió:la teoria de la dual nand k se saco es buena idea, pero aora la pregunta, es factible? es decir cuando salio el documento salio como una teoria, pero llevarlo a la practica es posible?

sí , llevarlo a la practica no es muy costoso , el problema es dinero , ganas , materiales , tiempo