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

1, 2, 3, 4, 511
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?

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 ?

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.

Actualización del proceso : tenemos otro problema nuevo , en 3.60 no se puede poner el service factory mode , es decir necesitamos que antes de actualizar la consola a 3.60 PONERLA EN FACTORY MODE ESTANDO EN 3.55, si nó no ay vuelta atrás.

Supuesto metodo para downgradear 3.60 : he visto que podriamos downgradear 3.60 con infectus con una nand donada copiando los datos cruciales de nuestra nand a la donada Y como en 3.60 no podemos poner service mode necesitariamos que la nand donada tuviera el lv1 parcheado para que no compruebe el hash del coreos , es una manera de poder hacer bypass a ese check en concreto.
kobol6666 está baneado por "saltarse el ban con clon"
Pues nada,ya tienes todo lo necesario para el nuevo CFW dospi,ya que sabes tanto,yo me ofrezco con mi PS3
mva255 está baneado por "utilizar clon para saltarse baneo de subforo"
gracias, justo esto te lo habia preguntado en el lio deñ hilo de wanin.
A mi me suena a una liada considerable:D
Gracias por la explicacion, ahora ya me ha quedado todo claro :)

1 saludo!
Goldmember está baneado por "faltas de respeto"
esto si que es un SCENER :)
Con esto y un bizcocho..... Me sé de dos que como cojan soldador....

Madre mía en 3 días Cfw vuelan...

Si coño, haceros un Team

Dospiedras1973+PsManiaco+Lukin

=

DoBle Ps Luking Good Team!!!

JasJasJas Coñas Aparte! [+risas]
Jur...

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

Un saludo.
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)
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 [+risas]

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
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 [+risas]

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


ni pecs por lo menos lo estas intentando y con eso sobra haber que sucede a la larga ojala y en una de esas logres lo que quieres (queremos) ja, saludos
dospiedras dime estas serca de esto o hay q esperar mucho ¿
Nadie puede crear el nuevo cfw que todos deseamos .Y aun sabiendo que alguien puede hacerlo...no lo publicaria.
sokii escribió:Nadie puede crear el nuevo cfw que todos deseamos .Y aun sabiendo que alguien puede hacerlo...no lo publicaria.


Y en las proximas elecciones volvera a salir Zapatero aun sin presentarse, puestos a ser pesimistas.
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 XD) 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.
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.
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?
hola.
yo no entiendo nada,pero si no me equivoco y entendi bien lo que dejeron fue,que para un cfw la solucion es facil no hay que hacer una doble nand ni nada,simplete compilarla para que funcione,sin las comprobaciones de las versiones posteriores a la 3.61,que han modificados las llaves y la comprobacion de seguiradad,pero no seria imposible ya que las llaves para esa version estan,por que las llaves al tenerla se puede compilar un nuevo cfw,poniendo unas llaves (cualquiera por la pondria quien compile el nuevo pub) para version superior a la 3.56,por la nueva verificacion de seguridad,que fue modificada.
y para las versiones superiores solo hacen falta las llaves,que segun dijo no era imposible,pero abria que saber sacarlas por la nueva encriptacion,y que una clave siempre iva a ser la misma y no se podia cambiar esa esta,lo que faltarian seria la otra.
por lo menos eso creo haber entendido.
Ferdopa escribió:Jur...

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

Un saludo.


Por curiosidad Ferdopa... el "Jur..." es como decir "Hola..." ? Es que es una duda que me come por dentro compañero... sorry por preguntar esa tontería XD XD
lo que tenemos ya es la 3.65 ya pide astualisar
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.


Sí , estoy en desacuerdo , ahi muchas burradas escritas ahí , desconozco el motivo , que puedan aver cfw's 3.56+ lo mas posible es que sí , pero no te lo voy a asegurar ;-)

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 XD) 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.


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 ;-)

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?


no tiene por qué... solo paciencia..
Que grande eres dospiedra, ya sabes todo lo que te aprecio tio!

;)

PD: tranquilo, con cuchillo quemado sale todo XD
pupila1992 escribió:Que grande eres dospiedra, ya sabes todo lo que te aprecio tio!

;)

PD: tranquilo, con cuchillo quemado sale todo XD

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 ¬_¬
Pues ya sabes tio, un par de horitas y es tuyo! XD

Cualquier cosita me das un toque ;)
Haber si yo me he enterado.. dospiedras, sabes como obtener las keys de dichos firmwares no?.. pero piensas investigarlo e intentar algo? o solo lo aportas para que otros sceners colaboren al trabajo?. Espero tu respuesta, gracias.
Esta claro una cosa, que si los hackers hubieran querido tener CFW ya lo tendriamos.
PDNKED está baneado por "usar clon para saltarse baneo"
dospiedras1973 escribió:
pupila1992 escribió:Que grande eres dospiedra, ya sabes todo lo que te aprecio tio!

;)

PD: tranquilo, con cuchillo quemado sale todo XD

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 ¬_¬


Lo de que mida mas me mosquea...

Pero lo de devolver el lv1 tiene su logica, y es que tenian que amortizar el dineral que han gastado en psn. Aunque puede ser tambien que tengan algo nuevo pensado. De una forma o de otra el jailbreak volvera.
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ó: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.


Posiblemente por las represalias, ¿no crees? , esto es lo de Juan Palomo, yo me lo guiso, yo me lo como XD XD .

El procedimiento para sacar un CFW a la luz es: Hazlo tú mismo, pásaselo a un colega con más pelotas que tu, que ese amigo se lo pase a otro, ese a otro con más huev*s que el caballo de Espartero y que sea él quién lo publique desde un cyber.

Sencillo, ¿no? XD XD XD XD XD
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
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


Al contrario, es mejor en estos casos pertenecer al anonimato, aun que te llames Federico Ortensio Oliviera y te hagas llamar "Shu-KdemasterS-ReshuULooOn" (Parida XD XD ) tarde o temprano pueden localizarte, ergo, lo mejor es irte a un cyber alejado de tu ciudad y publicarlo bajo nombre anonimo, con pruebas de que funciona claro está, pero permaneciendo anónimo, vamos yo es lo que haría si fuese scener, lástima que no tenga "ni papa" siquiera de cómo abrir un PUP
Con la cantidad de ingenieros de software que hay en el mundo y nadie sabe sacar esto que para alguien sera una chuminada... [uzi]
Desde mi punto de vista aparte de parecer estar parada, la Scene está muerta.
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... :) :)
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... [uzi]


Es que la mayoría de los ingenieros de software que hay en el mundo se dedican a crear su software para sacar beneficio y beneficiar a usuarios, no se dedican a crackear consolas para gente que en su mayoría actualizaron por el online del COD y juegan solamente a backups...

Ya no se trata solo de que sea o no posible o de represalias, es que ningún hacker con un CFW 3.55 ve la necesidad de poder actualizar su consola a la versión 3.61 (o a la cercana 3.70) porque no aportan nada nuevo ni a la jugabilidad ni a la scene. Y encima que es gente que trabaja gratis arriesgando sus consolas no veo necesario repetir como papagayos siempre las mismas frases sobre los que no quieren o no pueden hacer un CFW 3.61 para jugar al Call of Duty online.
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 XD.

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?
PDNKED está baneado por "usar clon para saltarse baneo"
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 XD.

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?


Tengo entendido que para modificar esos valores es necesaria una autentificación de sony. Y no se tiene.
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 XD.

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?



creo entenderte xD por que me he liado leyendolo 3 veces jaja

a ver , si puedes copiar tu nand en la otra y así tenerla de espejo , mientras no te muevas del 3.41 que instalastes y no te vallas a otra versión ni de cfw ni a otro ofw es decir que el hash que tienes en tu syscon sea el mismo que el de las dos flashes , sí , tendrías un anti brick , o mejor dicho un backup :-D

con lo del eid , a ver , es muy complicado eso , de todas maneras conozco una manera de generarlos ( no lo he probado ) se trata del programa objetivesuites , pero lo hace online directamente

el problema al ejecutar un fw debug es la comprobación del product id sí , y está almacenado en tu idps , exactamente está en 6 byte en adelante ( De tú idps ) , hablo de el descifrado , math sabe como cifrarlos , me lo ha dicho , pero como de costumbre cuando le pides algo , obtienes.............................................................
nada
Una duda dospiedras1973 solo das la informacion de como hacerlo o tu lo estas intentado mas que nada por saberlo,gracias
igusi2000 escribió:Una duda dospiedras1973 solo das la informacion de como hacerlo o tu lo estas intentado mas que nada por saberlo,gracias



las dos cosas.
Buenas ok ojala tengas suerte y lo consigas,como va la cosa pinta bien? O esta la cosa xunga
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?

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 ?

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
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... :) :)


No lo expresé bien pero con Scene me he referido en ese caso a la carga de backups y sobre todo los CFW para 3.60/61
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?

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 ?

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


prueba esto , quita el tornillo del disco duro de tu ps3 con la ps3 apagada ,

enciendela y cuando inicie el proceso de instalación ( no dejes que empiece), o por lo menos salga el fondo azul extrae de inmediato el hdd en caliente sin apagar la ps3
y espera a sucesos , lo normal es que te diga que la instalación esta dañada y que tienes que esperar 60 segundos bla bla bla y te pida de nuevo el pup nuevo al reiniciarse ;-) si es satisfactorio le pones el hdd de nuevo .
este tema esta muy bien, pero alguien podria ya publicar como desencriptar eboot de las actualizaciones de una vez porque los juegos van a venir 3.60 y nos vendria bien algo asin para desencriptar esos eboot y no esperar que alguien que lo tiene tan escondido te lo pase y lo publique

es una opinion pero esque tengo el pkg DukeNukemForever y no puedo jugarlo en 3.41, hasta que alguien lo saque

un saludo
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?
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
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


cuanto puede suponer en dinero? xk yo kreo k de dinero no es xk no kreo k sea caro, si no es de conocimientos normales-avanzados sobre soldadura
otra cosa, esto de la nand representa que sirve para los que actualmente tienen cfw no? xk instalas un infectus para dumpear la nand y dsp esa misma puedes actualizarla a la version que quieras y la nueva nand soldada le instalas el dump que as exo con el infectus, no es asi?
A estas alturas no creo que sea muy importante un cfw 3.60, cuando ya es oficial la 3.65...

es mejor trabajar sobre la ultima...

un saludo...
kobol6666 está baneado por "saltarse el ban con clon"
graf_chokolo acaba de publicar que en esta semana sacara su cfw 3.60 con dual boot,de este hombre me fio [plas] [plas] [plas]
521 respuestas
1, 2, 3, 4, 511