› Foros › PlayStation 3 › Scene
Africa escribió:psn_hypervisor escribió:Bueno, eso no es 100% correcto tampoco actualmente.
Pese a lo que dices es cierto, lo de que si cambias la key de geohot por una de las originales, te funcionaria. Eso si es cierto logicamente.
Pero, a partir del firmware 3.56 eso no funcionaria, precisamente a partir de ese firmware Sony puso una comprobacion en el lv0 encargado de la carga de los ejecutables para verificar si esta autorizado o no su carga, pero solo si usa una clave que no sea la del 3.56 (la clave del 3.56 ya no podia ser calculada mediante fuerza bruta).
Es por esto por lo que no existe un cfw basado en el 3.56 mayoritariamente.
Un saludo
Pareces saber de lo que hablas, y yo soy muy curioso, así que te expongo la parte más difícil de entender, para ver si consigues clarificarnoslo más a todos.
Está claro que si tuvieramos las keys buenas para firmar en lugar de las de Geohot, todo sería "legal" a los ojos de la consola. Como las que tenemos no son del todo correctas, sony las mete en una blacklist (llámalo chekeo, llámalo lv0) y eh voila, ya no funciona nada.
Hasta ahí yo creo que todos de acuerdo...
Yo creía que esto no avanzaba, porque realmente no teníamos las verdaderas keys, y solo las que sacó geohot (ya revocadas en 3.56), sin embargo tu dices que aunque tuvieramos las buenas tampoco funcionarían en +3.56. Eso es precisamente lo que no entiendo (ni yo ni muchos). ¿Como coño sabe la consola que este o aquel programa no deben funcionar si son tan "legales" a sus ojos como granturismo por ejem.?
Es más, si alguna vez hubieramos tenido verdaderas keys buenas.. ¿para que coño sirve un cfw? Firmamos todo como si fueran de la store y ni multiman ni leches....
Entiendo que no se dispongan de herramientas y que lo que se haya ido empleando sean parches y pegotes para ir haciendo tiempo, hasta conseguir todo lo necesario, y que conseguirlo no tenga fecha prevista, hasta ahí llego... pero no entiendo lo de que aunque se lograra el santo grial, no serviría de nada en una consola actualizada.
A ver si nos lo pudieras explicar un poco mascadito antes de que cierren el hilo...
Saludos.
il $r9, -0x250
stqd $LR, 0x10($SP)
stqd $r80, -0x10($SP)
stqd $r81, -0x20($SP)
stqd $r82, -0x30($SP)
stqd $r83, -0x40($SP)
stqd $r84, -0x50($SP)
ori $r83, $r3, 0
stqd $SP, -0x250($SP)
a $SP, $SP, $r9
il $r84, 0x2E
ai $r82, $SP, 0x90
ai $r81, $SP, 0x30
ai $r80, $SP, 0x60
shlqbyi $r3, $r82, 0
[...alguien que sepa sabra encontrar cual es esta subfuncion con solo eso]
psn_hypervisor escribió:Africa escribió:psn_hypervisor escribió:Bueno, eso no es 100% correcto tampoco actualmente.
Pese a lo que dices es cierto, lo de que si cambias la key de geohot por una de las originales, te funcionaria. Eso si es cierto logicamente.
Pero, a partir del firmware 3.56 eso no funcionaria, precisamente a partir de ese firmware Sony puso una comprobacion en el lv0 encargado de la carga de los ejecutables para verificar si esta autorizado o no su carga, pero solo si usa una clave que no sea la del 3.56 (la clave del 3.56 ya no podia ser calculada mediante fuerza bruta).
Es por esto por lo que no existe un cfw basado en el 3.56 mayoritariamente.
Un saludo
Pareces saber de lo que hablas, y yo soy muy curioso, así que te expongo la parte más difícil de entender, para ver si consigues clarificarnoslo más a todos.
Está claro que si tuvieramos las keys buenas para firmar en lugar de las de Geohot, todo sería "legal" a los ojos de la consola. Como las que tenemos no son del todo correctas, sony las mete en una blacklist (llámalo chekeo, llámalo lv0) y eh voila, ya no funciona nada.
Hasta ahí yo creo que todos de acuerdo...
Yo creía que esto no avanzaba, porque realmente no teníamos las verdaderas keys, y solo las que sacó geohot (ya revocadas en 3.56), sin embargo tu dices que aunque tuvieramos las buenas tampoco funcionarían en +3.56. Eso es precisamente lo que no entiendo (ni yo ni muchos). ¿Como coño sabe la consola que este o aquel programa no deben funcionar si son tan "legales" a sus ojos como granturismo por ejem.?
Es más, si alguna vez hubieramos tenido verdaderas keys buenas.. ¿para que coño sirve un cfw? Firmamos todo como si fueran de la store y ni multiman ni leches....
Entiendo que no se dispongan de herramientas y que lo que se haya ido empleando sean parches y pegotes para ir haciendo tiempo, hasta conseguir todo lo necesario, y que conseguirlo no tenga fecha prevista, hasta ahí llego... pero no entiendo lo de que aunque se lograra el santo grial, no serviría de nada en una consola actualizada.
A ver si nos lo pudieras explicar un poco mascadito antes de que cierren el hilo...
Saludos.
Ignorando a todos los trolls lacayos, aqui te pongo en donde se tiene el problema de lo que comentaba.il $r9, -0x250
stqd $LR, 0x10($SP)
stqd $r80, -0x10($SP)
stqd $r81, -0x20($SP)
stqd $r82, -0x30($SP)
stqd $r83, -0x40($SP)
stqd $r84, -0x50($SP)
ori $r83, $r3, 0
stqd $SP, -0x250($SP)
a $SP, $SP, $r9
il $r84, 0x2E
ai $r82, $SP, 0x90
ai $r81, $SP, 0x30
ai $r80, $SP, 0x60
shlqbyi $r3, $r82, 0
[...alguien que sepa sabra encontrar cual es esta subfuncion con solo eso]
Solo se tiene que parchear una linea de esa subfuncion (analizandola entera para ver donde logicamente) para que el lv0 le de igual que ejecutable se este cargando y cual no.
Teniendo en cuenta que en este foro se menosprecia, se insulta, a quien menos se le deberia por parte de algunos de sus integrantes, no dire nada mas al respecto, solo que en esa parte esta la solucion y el problema en si.
Un saludo
ori $r83, $r3, 0
ori rt, ra, s10 Or word immediate. The sign-extended value s10 is logically ORed with each
word element of register ra, and the results are placed in the corresponding
elements of register rt.
ViKT0RY escribió:No controlo mucho de assembler del CELL, pero basandome en http://cell.scei.co.jp/pdf/SPU_Assembly ... ge_v14.pdf diría que esta línea:ori $r83, $r3, 0
ori rt, ra, s10 Or word immediate. The sign-extended value s10 is logically ORed with each
word element of register ra, and the results are placed in the corresponding
elements of register rt.
Es la que hace la chicha, es la única comparación real que hay en ese código.
Y para la gente que no se aclara con el tema de las keys. Hay una clave privada maestra, que se usa para firmar (autenticar) al resto de posibles claves privadas. Geohot generó una de esas claves privadas, no se sabe si realmente llegó a conseguir la clave maestra y con ella generó esta nueva clave, o si simplemente calculó esa clave privada en particular en base a otros ejecutables ya firmados.
Un ejemplo de como funciona todo esto lo teneis en GnuPG: http://www.lostscene.com/manuales/gnupg.php
Lo siento, pero mi "kung fu" no es tan bueno. Sigo sin entender porque si tuvieramos la verdadera llave maestra las cosas seguirían sin funcionar, ya que lo firmado "oficialmente por sony" si que sigue funcionando en 3.60+.
Por ejemplo, uncharted3 no funciona desde multiman aunque multiman estuviera firmado con la firma buena, eso lo puedo entender... Pero no puedo llegar a entender que ese mismo uncharted3 pasado a formato "live arcade" y firmado con una clave buena como si fuera de sony no funcionara. ¿Como coño va a saber la consola si lo ha firmado sony o yo, si las rubricas son las mismas?
Y por supuesto ya se, que puede o no puede hacerse público en función de la pasta que haya en juego...
En fin que no nací ayer, pero ese concepto de que la consola distinga entre lo bueno y lo malo si ambos bandos tuvieran las mismas llaves no lo concibo, soy así de obtuso.
Si somos miles de usuarios que poseen "la negrita" en su casa y viendo la capacidad de calculo de la misma, es muy descabellado intentar por fuerza bruta?
Se hablo muchas veces de glitchear el procesador para volcar la ram, sea el firm que sea, cual es el impedimento para obtener CUALQUIERA de las keys con ese proceso?
con dual boot se podria conseguir no? es decir, tu tienes ofw 3.70 por ejemplo, y las keys "quedan" en la ram, despues tienes la ram alimentada para que al reiniciar con dual boot no se limpie la ram (creo que si no desconectabas la ps3 de la corriente en kaso de slim o la apagabas desde el boton en caso de las fats) la ram no se limpia no?y dsp poner el cfw 3.55 con linux y volcar todo.
O con una ps3 debug que se trague todo con el 3.70? instalar el linux y volcar?
Otra duda que tengo, tu por ejemplo ahora con las keys NPDRM. Bajas ese uncharted 3 desde la store, con la key desencriptas el edata y lo vuelves a empaquetar en pkg para instalarlo, deberia funcionar en una ps3 con ofw no? o al firmarlo como usamos las keys de la 3.55 estariamos en las mismas?o las keys que tenemos NPDRM se podrian utilizar para 3.60+?
NaVaJa90 escribió:tengo entendido que de hardware no es diferente, que solo cambia el core_os, y hace poco salio un tutorial de como convertir una retail en una debug. Y lanzar un juego desde el menu(tipo demo) no necesita syscall, acuerdate cuando geohot saco su cfw solo con la opcion de install package.
murcielago escribió:Tengo una idea, si lograramos cablear el bus de datos de 2 consolas ps3 una en 3.55 y la otra en 3.70 y cuando este corriendo la 3.70 , en la otra consola con firmware 3.55 le instalamos el awesome peek poker ponemos un switch y le indicamos que lea la ram de la 3.70 , o cablear de ram a ram se podria usar el generador de pulsos de jaicrab para que la ram se mantenga viva
http://jaicrab.blogspot.com/2010_04_01_archive.html
http://jaicrab.blogspot.com/2010_06_01_archive.html
corremos el awesome peek poker y tenemos el ram
http://ps3.dashhacks.com/2010/10/10/awe ... 2-released
Se hablo muchas veces de glitchear el procesador para volcar la ram, sea el firm que sea, cual es el impedimento para obtener CUALQUIERA de las keys con ese proceso?
Ese método funcionaría siempre, si no fuera porque hace falta linux para poder usarlo. ¿Has visto algun linux en OFW 3.70? Ahí tienes el problema.