Publicado Exploit GeoHot Hack PS3 (Leed Primer Mensaje)

Entonces es posible q luego se necesite un modchip q realice lo de los 40ns o eso es solo para conseguir el exploit o aun es pronto para saber nada??

A ver 40ns es una frecuencia de 25 MHZ, se podría usar un oscilador astable con un 74HC04 y un cristal de 25 MHZ, pero la duda está en si no habrá problema en que se siga enviando pulsos bajos a la memoria, de ser así habría que agregar un Flip-flop D, como un 74HC74 para solo un pulso..pero vamos que estoy pensando en voz alta ....ahh y los que piensan en un PIC pues la tienen dificil, habría que conseguir uno que soporte un cristal de 50MHZ por lo menos, auqnue existen otras familias como los Freescale y los Atmel que servirían para tal propósito...
O alguien que haga un programa en PC para sacar el pulso por la salida de audio al cuál habría que adicionarle un driver para que no sobre pase los 3.3V o el voltaje de la memoria de la PS3..uff mejor me callo, no valla a ser que confunda a medio foro + 1

Saludos

osomon69 escribió:Entonces es posible q luego se necesite un modchip q realice lo de los 40ns o eso es solo para conseguir el exploit o aun es pronto para saber nada??

Aun es demasiado pronto para saber si ara falta un modchip o simplemente esto se pulira mas para que se acceda mas facilmente. Lo unico que nos queda es la paciencia y la intriga.

Saludos y buenas noches

bueno me he leido todo y aqui desparramo dudas: el exploit este de hardware t permite cargar codigo en memoria sin la intervencion dl hv, cierto?en binario?en c?en principio este codigo debe primero encriptarse antes d ser metido en memoria,cierto?eso lo conseguimos con las keys que son como el "exploit de software",no?al lanzar el exploit,salimos a una pantalla donde introducimos codigo?perdonar que este tan perdido

En definitiva, lo primero que se necesita es un método "fácil y rápido" para cruzar la PS3 durante 40nS, GeoHot lo hizo con un FPGA pero eso es como matar moscas a cañonazos, tiene que existir un método mucho más facil para conseguir esos 40nS...

Este post va para record.....
Aver si experimentan pronto

xakmsx escribió:En definitiva, lo primero que se necesita es un método "fácil y rápido" para cruzar la PS3 durante 40nS, GeoHot lo hizo con un FPGA pero eso es como matar moscas a cañonazos, tiene que existir un método mucho más facil para conseguir esos 40nS...

En realidad como dicen por ahí arriba no cualquier microcontrolador te puede dar 40ns precisos... los PIC por ejemplo, trabajando a ciclo de máquina de 4 ciclos de reloj, "creo" que necesitarían mínimo ir a 100Mhz para hacerlo.... y tal cosa no existe.

Otros dispositivos como los ATMEL que van a ciclo de máquina = ciclo de reloj, con uno que fuera a 25Mhz suficiente pero vamos...

los 40 ns de nivel los consigues en 1boleo con cualquier 555 i 1 pulsador.no tiene misterio.el misterio es porque son precisamente 40 ns,este tio es un jefe

Terminaran apareciendo pequeños circuitos (si no aparecen esta misma noche) de un cristal con un interruptor junto con un temporizador el cual haga un envio de 40ns y luego se pare. Vamos, teniendo en cuenta esto, no me parece tan raro que dijera que le fue relativamente sencillo llegar aqui, partiendo de que este sistema es curiosamente antiguo o que a nadie se le habria pasado por la cabeza utilizar en una consola con la supuesta seguridad que lleva.

Es como querer entrar a una caja fuerte de alta seguridad con una llave inglesa ... acojonante, pero un merito cuanto menos merecido.

Fonfo escribió:bueno me he leido todo y aqui desparramo dudas: el exploit este de hardware t permite cargar codigo en memoria sin la intervencion dl hv, cierto?en binario?en c?en principio este codigo debe primero encriptarse antes d ser metido en memoria,cierto?eso lo conseguimos con las keys que son como el "exploit de software",no?al lanzar el exploit,salimos a una pantalla donde introducimos codigo?perdonar que este tan perdido

Son preguntas interesantes, ya que creo que lo que hacen las funciones es acceder a memoria para leer y escribir, creo que en C, pero desconozco que tipo de datos es "u64"... y tampoco estoy seguro sobre el tema de la encriptación.

Lo que he entendido es que al lanzar el exploit se añaden esas 2 funciones de bajo nivel que interactuan con el hw, y que se podrian usar en futuros códigos para otros propósitos, no te va llevar a una pantalla para introducir código no...

Ésto es sólo la primera piedra, queda muuucho trabajo por delante.

ErDaByz escribió:

xakmsx escribió:En definitiva, lo primero que se necesita es un método "fácil y rápido" para cruzar la PS3 durante 40nS, GeoHot lo hizo con un FPGA pero eso es como matar moscas a cañonazos, tiene que existir un método mucho más facil para conseguir esos 40nS...

En realidad como dicen por ahí arriba no cualquier microcontrolador te puede dar 40ns precisos... los PIC por ejemplo, trabajando a ciclo de máquina de 4 ciclos de reloj, "creo" que necesitarían mínimo ir a 100Mhz para hacerlo.... y tal cosa no existe.

Otros dispositivos como los ATMEL que van a ciclo de máquina = ciclo de reloj, con uno que fuera a 25Mhz suficiente pero vamos...

Creo que algunos PIC ya vienen con ciclo de máquina a 1/2 del oscilador, pero eso complicaría más las cosas para el público general. La idea del oscilador con un 74HC04 y un Flip-Flop -D como el 74HC74 sería suficiente para el pulso, si alguien tiene el tiempo para hacer el circuito y probar yo haría el esquema eso si hay que averiguar si se necesitan un pulso de 3.3V a 0.0 V o cuál es el valor máximo de Vcc, por que de necesitar 3.3V tendríamos que usar tecnología cmos, o sea la serie CD40XX ..
Alguien se apunta para las pruebas?



Saludos.

PD: Con un LM555 es imposible sacar un pulso de 40ns, según el Datasheet lo mínimo sería 10uS.

Esto es para escribir un libro, de sociología aplicada a la red...
La que se ha liado en unos días...

lo de los 40ns, desde luego es para quitarse el sombrero.

marvic, tengo 3 PS3 antiguas esperando que hagas un esquema ... el problema es que no se si yo tendre tiempo, pero todo sea por darle un poco de vidilla al foro ... que veo que esta algo apagado .........

Otra duda que tengo es a qué memoria accede esto.

This is the coveted PS3 exploit, gives full memory access and therefore ring 0 access from OtherOS. Enjoy your hypervisor dumps

Significa esto que accede al EIB, es decir, los 4 anillos que conectan PPE y SPEs??
Accede a la memoria principal??

. They have been a great resource so far, and with the power this exploit gives, opens tons of new stuff to document. I'd like to see the missing HV calls filled in, nice memory maps, the boot chain better documented, and progress on a 3D GPU driver. And of course, the search for a software exploit.

Dice que con el poder que da este exploit, le gustaria ver nuevas llamadas al HV implementadas, buenos mapeos de memoria, la cadena de arranque mejor documentada y progresar en el driver 3D de la GPU. Y por supuesto, la búsqueda de un exploit software...

Esos serán los siguientes pasos...

Lo dificil era saber por donde habia que empezar a meterla....

Ahora habra miles de personas probando, es cuestion de tiempo.... Pero no creo que hablemos de mucho.

Que buena noticia que haya soltado el exploit!!
Haber ahora los entendidos en el tema con que nos sorprenden!

Pillo sitio

Saludos

Pero dónde estan los puntos¿? xD que yo sólo veo uno y he visto la imagen unas cuantas veces. A desempolvar los programadores del digital

Fonfo escribió:los 40 ns de nivel los consigues en 1boleo con cualquier 555 i 1 pulsador.no tiene misterio.el misterio es porque son precisamente 40 ns,este tio es un jefe

Despues de estar mirando circuitos un rato tambien pienso que el 555 es lo mas sencillo, no creo que seamos los unicos alos que se nos ha ocurrido y seguramente veamos pronto un diagrama adaptado a esto, aparte porque es algo relativamenete facil de conseguir

alex_murcia escribió:Dice que con el poder que da este exploit, le gustaria ver nuevas llamadas al HV implementadas, buenos mapeos de memoria, la cadena de arranque mejor documentada y progresar en el driver 3D de la GPU. Y por supuesto, la búsqueda de un exploit software...

Esos serán los siguientes pasos...

Un xploit de software? ... ummmm, no me parece logico si realmente queremos que esto llegue a alguna parte ... ya con la 360 sigo pensando que depender de kernels y de placas no modificables, hace que la scene no avance demasiado. Ahora mismo la cosa pinta bien porque Sony no ha reaccionado, pero todo se vera ... y si tenemos en cuenta que el proximo firm 3.20 cerrara muchas puertas a este xploit, atacar por software es simplemente ridiculo, a menos que esto nos abra puertas de cara a desarrollar mas hardware por donde atacar la seguridad de la consola.

Edy escribió:marvic, tengo 3 PS3 antiguas esperando que hagas un esquema ... el problema es que no se si yo tendre tiempo, pero todo sea por darle un poco de vidilla al foro ... que veo que esta algo apagado .........

sería posible que averiguaras que voltaje alimenta la memoria donde hay que aplicarle los 40ns, para empezar ya que hay que decidir si usamos 74HC o los CD40xx....menos mal que esos IC cuestan menos de €1 ambos..

Saludos

Con un LM555 es imposible sacar los 40ns

soy el unico que sueña con dark alex trasteando por dentro la ps3 y reprogramandola?¿?¿¿?

y otra pregunta que me ha surgido.....

edito:
pensais que esto solo sera aplicable a las fat? no se, creo que para meterle mano como ahora si son necesarias las fat, pero creo que cuando esto este mas avanzado se le podra meter mano sin tener que depender del otherOS

marvicdigital escribió:

Edy escribió:marvic, tengo 3 PS3 antiguas esperando que hagas un esquema ... el problema es que no se si yo tendre tiempo, pero todo sea por darle un poco de vidilla al foro ... que veo que esta algo apagado .........

sería posible que averiguaras que voltaje alimenta la memoria donde hay que aplicarle los 40ns, para empezar ya que hay que decidir si usamos 74HC o los CD40xx....menos mal que esos IC cuestan menos de €1 ambos..

Saludos

Aun recuerdo cuando teniamos que comprar el 2323 para el circuito de la 360 y los lectores Liteon 734 .... que me costaron 20 euros creo la unida ... piensas que eso me preocupa? El tema del voltaje seguramente ya lo habran comentado en otros foros ... mirare de ponerme mañana, pero entre el tema del homebrew de Wii, el Cygnos de 360 y ahora esto, voy a petar ......

marvicdigital escribió:

Edy escribió:marvic, tengo 3 PS3 antiguas esperando que hagas un esquema ... el problema es que no se si yo tendre tiempo, pero todo sea por darle un poco de vidilla al foro ... que veo que esta algo apagado .........

sería posible que averiguaras que voltaje alimenta la memoria donde hay que aplicarle los 40ns, para empezar ya que hay que decidir si usamos 74HC o los CD40xx....menos mal que esos IC cuestan menos de €1 ambos..

Saludos

Con un LM555 es imposible sacar los 40ns

Si tio, estaba leyendo el datasheet y no me habia fijado

Muy buenas, espero no molestar este intercambio de ideas tan interesante que estais teniendo, pero tengo una pequeña duda que me gustaria que alguien me contestara.

Quisiera saber la reacción que ha habido en el chat por parte de los personajes reconocidos que han participado activamente estos dias atrás alli, sus ideas en relación a si van a trabajar "oficialmente" en ello y si se va a formar algún grupo de trabajo. Puede que parte de lo que he preguntado sea evidente pero me resulta muy interesante.

Gracias de antemano.

Edy escribió:

alex_murcia escribió:Dice que con el poder que da este exploit, le gustaria ver nuevas llamadas al HV implementadas, buenos mapeos de memoria, la cadena de arranque mejor documentada y progresar en el driver 3D de la GPU. Y por supuesto, la búsqueda de un exploit software...

Esos serán los siguientes pasos...

Un xploit de software? ... ummmm, no me parece logico si realmente queremos que esto llegue a alguna parte ... ya con la 360 sigo pensando que depender de kernels y de placas no modificables, hace que la scene no avance demasiado. Ahora mismo la cosa pinta bien porque Sony no ha reaccionado, pero todo se vera ... y si tenemos en cuenta que el proximo firm 3.20 cerrara muchas puertas a este xploit, atacar por software es simplemente ridiculo, a menos que esto nos abra puertas de cara a desarrollar mas hardware por donde atacar la seguridad de la consola.

Hola Marvic, tiempo sin saber de ti =P. pues si, un exploit via software es bastante inviable (vease x360), pues se depende de una version especifica del kernel, y rebooters para acceder a los superiores, pero si entendi lo que dijo geohot, sony la tiene complicada para tapar este xploit, puede complicarlo si, segun sus palabras.

bueno un saludo ... =)

locura, intentad no llenar el hilo de sms tontos que no dicen nada porque al final habrá que escribir algo interesante y hay mil paginas....

si aun no hay mas datos, no pregunteis lo mismo...

un saludo y animo que ya comienza la fiesta!!!

por cierto, este Geohot sabe mucho no?? =)

Gary_Lester escribió:Muy buenas, espero no molestar este intercambio de ideas tan interesante que estais teniendo, pero tengo una pequeña duda que me gustaria que alguien me contestara.

Quisiera saber la reacción que ha habido en el chat por parte de los personajes reconocidos que han participado activamente estos dias atrás alli, sus ideas en relación a si van a trabajar "oficialmente" en ello y si se va a formar algún grupo de trabajo. Puede que parte de lo que he preguntado sea evidente pero me resulta muy interesante.

Gracias de antemano.

Te aseguro que ahora mismo estan incluso los antiguos mienbros del Team Messiah en el tema ... aunque solo sea por curiosear un poco. Todo depende de que otro golpe de suerte haga que parte de lo que actualmente se ha conseguido, pueda avanzar un poco mas. Asi empezo el hombrew channel en Wii ... y fijaros ahora.

Edy escribió:

alex_murcia escribió:Dice que con el poder que da este exploit, le gustaria ver nuevas llamadas al HV implementadas, buenos mapeos de memoria, la cadena de arranque mejor documentada y progresar en el driver 3D de la GPU. Y por supuesto, la búsqueda de un exploit software...

Esos serán los siguientes pasos...

Un xploit de software? ... ummmm, no me parece logico si realmente queremos que esto llegue a alguna parte ... ya con la 360 sigo pensando que depender de kernels y de placas no modificables, hace que la scene no avance demasiado. Ahora mismo la cosa pinta bien porque Sony no ha reaccionado, pero todo se vera ... y si tenemos en cuenta que el proximo firm 3.20 cerrara muchas puertas a este xploit, atacar por software es simplemente ridiculo, a menos que esto nos abra puertas de cara a desarrollar mas hardware por donde atacar la seguridad de la consola.

Sino he entendido mal todo el embrollo este... el exploit sigue siendo por hardware... otra cosa es que lo haya probado por software añadiendo funciones en el hypervisor.

Usease que dudo mucho que por actualización de firmware puedan arreglarlo... como bien dice él.. debería funcionar con cualquier otro firmware distinto al que él tiene.

VDF_Demon escribió:

Edy escribió:

alex_murcia escribió:Dice que con el poder que da este exploit, le gustaria ver nuevas llamadas al HV implementadas, buenos mapeos de memoria, la cadena de arranque mejor documentada y progresar en el driver 3D de la GPU. Y por supuesto, la búsqueda de un exploit software...

Esos serán los siguientes pasos...

Un xploit de software? ... ummmm, no me parece logico si realmente queremos que esto llegue a alguna parte ... ya con la 360 sigo pensando que depender de kernels y de placas no modificables, hace que la scene no avance demasiado. Ahora mismo la cosa pinta bien porque Sony no ha reaccionado, pero todo se vera ... y si tenemos en cuenta que el proximo firm 3.20 cerrara muchas puertas a este xploit, atacar por software es simplemente ridiculo, a menos que esto nos abra puertas de cara a desarrollar mas hardware por donde atacar la seguridad de la consola.

Hola Marvic, tiempo sin saber de ti =P. pues si, un exploit via software es bastante inviable (vease x360), pues se depende de una version especifica del kernel, y rebooters para acceder a los superiores, pero si entendi lo que dijo geohot, sony la tiene complicada para tapar este xploit, puede complicarlo si, segun sus palabras.

bueno un saludo ... =)

O te has colado de post ... o te has puerto nerviosina preciosa. Sera Edy no??? Exactamente, actualmente querer atacar con software la PS3 es como querer ejecutar un juego de PS2 en la PS3 slim a golpe de maza.

alex_murcia escribió:...pero desconozco que tipo de datos es "u64"...

Me respondo a mí mismo tras hechar un vistazo al código fuente. Se supone que las funciones implementadas por geohot leen y escriben en memoria (como he dicho antes no se si en el anillo EIB o en memoria principal) un unsigned long, es decir 32 bits.

Edy escribió:Te aseguro que ahora mismo estan incluso los antiguos mienbros del Team Messiah en el tema ... aunque solo sea por curiosear un poco. Todo depende de que otro golpe de suerte haga que parte de lo que actualmente se ha conseguido, pueda avanzar un poco mas. Asi empezo el hombrew channel en Wii ... y fijaros ahora.

Por eso decia que parecia una pregunta evidente pero queria saber algo a ciencia cierta. Es realmente positivo que se produzca una verdadera competencia entre varias "mentes tan brillantes" y si además no se producen asperezar y colaboran entre si el proceso puede ser muy interesante para todos los que nos interesa esto aunque no tengamos suficientes conocimientos del tema.

Gracias por contestar tan rápido.

Intento aclarar

Fonfo escribió:bueno me he leido todo y aqui desparramo dudas: el exploit este de hardware t permite cargar codigo en memoria sin la intervencion dl hv, cierto?

El OtherOS ya te permite cargar y ejecutar codigo en memoria. Asi que no.
Lo que hace el exploit es mapear con acceso de lectura y escritura toda la memoria de la PS3. En condiciones normales, el hipervisor no te deja llegar a ciertos sitios como:
- a la zona de memoria donde esta el propio hipervisor, para que no podamos ver sus fallos ni como funcionar ni conocer sus secretos. Y por supuesto para que no podamos modificarlo o borrarlo
- la GPU. si quieres hacer algo con la GPU , se lo pides por favor al hipervisor, y nada de 3D, que si no le haces la competencia al GameOS

Con el exploit, si tendrias acceso, aunque el driver 3D o las nuevas versiones de las funciones del hipervisor se las tiene que hacer uno mismo, y no va a ser sencillo

Fonfo escribió:en binario?en c?en principio este codigo debe primero encriptarse antes d ser metido en memoria,cierto?eso lo conseguimos con las keys que son como el "exploit de software",no?al lanzar el exploit,salimos a una pantalla donde introducimos codigo?perdonar que este tan perdido

No. El exploit está en C, se compila como cualquier otro ejecutable de linux (bueno, en realidad es un módulo del kernel)
y en CONJUNTO y de forma SINCRONIZADA con el hardware, consigue el acceso de escritura total a la memoria antes comentado.
Si ejecutas este modulo del kernel a la vez que activas el HW del famoso pulso de los 40, consigues liar al hipervisor y que te de el acceso total.

Este codigo no esta cifrado en modo alguno, repito que en OtherOS el código es normal. Todo lo que se habla de claves, se refiere a que teniendo ya acceso total a la memoria, pues se podria buscar las claves que se usan para los firmwares o para los ejecutables del GameOS. (esta busqueda no es tan facil, ya que siguen quedando medidas de proteccion en la PS3, y estas claves estan en los famosos SPE aislados del resto del sistema )

Bueno, una vez que todo sale bien, el exploit que ya puede modificar el HV al tener acceso te crea 2 nuevas funciones en el HV, una para leer cualquier byte de la memoria y otra para escribirlo.
Asi que para tocar algo de la memoria, pues llamas al HV que ya es tu amigo

Con esto ya puedes, por ejemplo, sacar todo el codigo del HV y desensamblarlo en busqueda de algun bug que te lleve a otro exploit en el que ya no necesites el HW de los pulsos, y que también debería estar en la SLIM

alex_murcia escribió:Son preguntas interesantes, ya que creo que lo que hacen las funciones es acceder a memoria para leer y escribir, creo que en C, pero desconozco que tipo de datos es "u64"... y tampoco estoy seguro sobre el tema de la encriptación.

u64 suele ser "unsigned long int" o "unsigned int" según la plataforma. En cualquier caso , es un valor sin signo de 64 bits,
y suele usarse para almacenar direcciones de memoria en la mayoria de las plataformas actuales, que tiene un bus de direcciones de 64 bits

alex_murcia escribió:
Lo que he entendido es que al lanzar el exploit se añaden esas 2 funciones de bajo nivel que interactuan con el hw, y que se podrian usar en futuros códigos para otros propósitos, no te va llevar a una pantalla para introducir código no...
Ésto es sólo la primera piedra, queda muuucho trabajo por delante.

Eso es.

Edy escribió:

Gary_Lester escribió:Muy buenas, espero no molestar este intercambio de ideas tan interesante que estais teniendo, pero tengo una pequeña duda que me gustaria que alguien me contestara.

Quisiera saber la reacción que ha habido en el chat por parte de los personajes reconocidos que han participado activamente estos dias atrás alli, sus ideas en relación a si van a trabajar "oficialmente" en ello y si se va a formar algún grupo de trabajo. Puede que parte de lo que he preguntado sea evidente pero me resulta muy interesante.

Gracias de antemano.

Te aseguro que ahora mismo estan incluso los antiguos mienbros del Team Messiah en el tema ... aunque solo sea por curiosear un poco. Todo depende de que otro golpe de suerte haga que parte de lo que actualmente se ha conseguido, pueda avanzar un poco mas. Asi empezo el hombrew channel en Wii ... y fijaros ahora.

Nyaaaaa .. que pena edy, bueno igual de paso salude a marvic, y te saludo a ti de paso waaa k pena ...

en cuanto a lo del exploit, se compila como un OtherOs, o se ejecuta junto con un OtherOs, asumo sera la primera, pero siempre me interesa saber, bastante curioso el metodo...

chauss

malas noticias, acabo de ver en los datasheets de algunos CD40xx que tenía en mente pero todos requieren de un pulso de clock de unos 100 ns a 5V y para llegar a los 40ns se requiere una alimentación de 15V, nada aconsejable ..habrá que hacer una interfaz con un transistor para pasar de 5V a 3.3V, usando los 74HC nada complicado pero que agranda un poco más el circuito..

Saludos

¿por que me borran los mensajes sin explicacion?¿esto que es la poli de eeuu? Primero dispara y despues pregunta jur!

Doggab escribió:

Edy escribió: Ahora mismo la cosa pinta bien porque Sony no ha reaccionado, pero todo se vera ... y si tenemos en cuenta que el proximo firm 3.20 cerrara muchas puertas a este xploit, atacar por software es simplemente ridiculo, a menos que esto nos abra puertas de cara a desarrollar mas hardware por donde atacar la seguridad de la consola.

Sino he entendido mal todo el embrollo este... el exploit sigue siendo por hardware... otra cosa es que lo haya probado por software añadiendo funciones en el hypervisor.

Usease que dudo mucho que por actualización de firmware puedan arreglarlo... como bien dice él.. debería funcionar con cualquier otro firmware distinto al que él tiene.

Correcto, me parece que van a tener chungo tapar esto con un simple firmware, ya que al parecer son llamadas a muy bajo nivel que interactuan directamente con el hardware, y supongo que el mismo firmware estará construido sobre ese nivel.

Por cierto, no soy ni mucho menos un experto ni me sé a la perfeccion el hardware de la ps3. El hypervisor que es exactamente?? El PPE??? O es software independientemente de sobre que procesador corra??

Hombre, LuzBelFullHD, a tí quería yo verte por aquí
Gracias por tu post, me ha aclarado cosas.

Entonces a que memoria se accede LuzBel, al anillos entre procesadores? A memoria principal??

Todo lo que se habla de claves, se refiere a que teniendo ya acceso total a la memoria, pues se podria buscar las claves que se usan para los firmwares o para los ejecutables del GameOS. (esta busqueda no es tan facil, ya que siguen quedando medidas de proteccion en la PS3, y estas claves estan en los famosos SPE aislados del resto del sistema )

Esas claves están en algún registro del procesador?? Accediendo al EIB no se puede ver lo que corre por los SPEs??

marvicdigital escribió:malas noticias, acabo de ver en los datasheets de algunos CD40xx que tenía en mente pero todos requieren de un pulso de clock de unos 100 ns a 5V y para llegar a los 40ns se requiere una alimentación de 15V, nada aconsejable ..habrá que hacer una interfaz con un transistor para pasar de 5V a 3.3V, usando los 74HC nada complicado pero que agranda un poco más el circuito..

Saludos

a falta de saber que memorias son .... incluso 3.3 me parece un voltaje alto ... pero vamos, que es un voltaje logico con el que empezar, y menor seria complicar el esquema demasiado como para ponerse a realizar tantas pruebas.

PD: me voy a la cama ... que aqui son las 3.30 de la madrugada ...

alex_murcia escribió: El hypervisor que es exactamente?? El PPE???

Digamos que es algo parecido a esto:



Salvo que hay que pasar por el frente con un anillo a 40ns para que no te vea y luego hacer lo que quieras sin que el ojo se de cuenta

Creo que es uno de los SPU de los 7 del Cell que se encarga de supervisar todo lo que le llega y la CPU o algo así.

Saludos

marvicdigital escribió:

alex_murcia escribió: El hypervisor que es exactamente?? El PPE???

Digamos que es algo parecido a esto:



Salvo que hay que pasar por el frente con un anillo a 40ns para que no te vea y luego hacer lo que quieras sin que el ojo se de cuenta

Creo que es uno de los SPU de los 7 del Cell que se encarga de supervisar todo lo que le llega y la CPU o algo así.

Saludos

que grande!!!

Simple pero efectiva la respuesta

vaya

he conseguido compilar el módulo del kernel en mi yellow dog 6.1 con kernel 2.6.31 ,
pero al intentar insertar el módulo se queja de que no encuentra el simbolo ".irq_to_desc"

seguiré probando ...

Si si, eso ya lo sabía es decir, se mas o menos cual es su función (del HV), pero no sé si es hardware o software, y en caso de ser software donde corre (procesador) y en que memoria se aloja...

Entonces a que memoria se accede LuzBel, al anillos entre procesadores? A memoria principal??
Todo lo que se habla de claves, se refiere a que teniendo ya acceso total a la memoria, pues se podria buscar las claves que se usan para los firmwares o para los ejecutables del GameOS. (esta busqueda no es tan facil, ya que siguen quedando medidas de proteccion en la PS3, y estas claves estan en los famosos SPE aislados del resto del sistema )


Esas claves están en algún registro del procesador?? Accediendo al EIB no se puede ver lo que corre por los SPEs??

Me autocito para unir todas mis dudas en un post.

Por cierto un hilo más que interesante para unas ligeras nociones del hardware de ps3:
http://www.elotrolado.net/hilo_curso-avanzado-cell-broad-engine-by-acid-burn_1277252


EDITO:

He encontrado esto leyendo por el blog:
lv1 is in ram, i r/w ram...

Por lo que me soluciona una duda...

El HV es software ( puedes verlo como algo intermedio entre una BIOS y un sistema operativo, no es una BIOS ya que no es basico y hace mas que inicializar las cosas, y tampoco es un SO, ya que no da tantos servicios y suele estar por encima para controlar a otro , o varios incluso a la vez , so en una maquina ) aunque se apoya en caracteristicas HW del Cell para la seguridad.

El EIB es el bus , pero no es la memoria en si. Las memorias de los SPE van aparte, y no estan mapeados en la memoria principal, tienes que usar DMA para mover los datos dentro y fuera de los SPE, que tienen su pequeña memoria local e independiente.
Pero ademas, un SPE se puede poner en modo aislado, de modo que no puedes hacer DMA ni desde el PPE ni otro SPE para trastear. Este es el modo que se usa para validar los ejecutables cifrados (como firmware o aplicaciones del GameOS )

Leeros esto el que sepa ingles y llorad.
http://www.ibm.com/developerworks/power ... lsecurity/

Por el momento el "xploit" solo da un poco más de acceso al sistema por parte de OtherOS, pero no es ni mucho menos la panacea.
En ese documento de IBM donde explican la seguridad del Cell, viene a decir más o menos algo como: "Estais jodidos"

Con unas pocas palabras más:
-No puedes ver dentro de la memoria del SPE aislado ni escribir en ella de ninguna de las maneras, solo comunicarte con él.
-No puedes modificar el programa que lleva el SPE aislado ni antes, ni durante el run-time, porque se comprueba por hardware que el programa no ha sido modificado.
-No puedes ver la rootkey principal ni por software ni por hardware.
-Todas las keys se encuentran cifradas por la rootkey y estan por lo tanto en una "cadena de confianza". Es decir, el sistema confia en ellas (comprobandolas obviamente) mientras la rootkey sea de confianza, que es la unica que no está cifrada, pero está "GRABADA" en el chip, y no se puede acceder a ella ni modificarla de ninguna forma excepto por el propio chip y su unidad de crypto, que tambien está hecha por hardware y evidentemente no te va a soltar la rootkey por nada del mundo.
-Todo está comprobado de que no esté comprometido tantas veces como el programa quiera, de forma arbitraria.
-Si haces algo de lo anterior, el sistema entra en paro total.
-Rezad a $Deity

Silverdisc escribió:Leeros esto el que sepa ingles y llorad.
http://www.ibm.com/developerworks/power ... lsecurity/

Por el momento el "xploit" solo da un poco más de acceso al sistema por parte de OtherOS, pero no es ni mucho menos la panacea.
En ese documento de IBM donde explican la seguridad del Cell, viene a decir más o menos algo como: "Estais jodidos"

Con unas pocas palabras más:
-No puedes ver dentro de la memoria del SPE aislado ni escribir en ella de ninguna de las maneras, solo comunicarte con él.
-No puedes modificar el programa que lleva el SPE aislado ni antes, ni durante el run-time, porque se comprueba por hardware que el programa no ha sido modificado.
-No puedes ver la rootkey principal ni por software ni por hardware.
-Todo está comprobado de que no esté comprometido tantas veces como el programa quiera, de forma arbitraria.
-Si haces algo de lo anterior, el sistema entra en paro total.
-Rezad a $Deity

tioooooooo,...que me iba a acostar y me la lias asi de esta manera...jodr..xdmamon:P

Gracias, me aclaras muchas cosas

Entonces, el paso más lógico a dar ahora es sacar dumps del HV para intentar ver como funciona, etc no??

Se pueden extraer esos dumps desde la memoria, pero la memoria es volátil, donde se aloja realmente el HV para que en el arranque se cargue (todo o en parte) en la ram?

Es el HV el que dice a los SPE cuando se ponen en modo aislado?? Es el que gobierna el DMA para el procesamiento de datos entre SPUs y EIB???

Gracias de antemano, maestro Luzbel

alex_murcia escribió:Gracias, me aclaras muchas cosas

Entonces, el paso más lógico a dar ahora es sacar dumps del HV para intentar ver como funciona, etc no??

Se pueden extraer esos dumps desde la memoria, pero la memoria es volátil, donde se aloja realmente el HV para que en el arranque se cargue (todo o en parte) en la ram?

Es el HV el que dice a los SPE cuando se ponen en modo aislado?? Es el que gobierna el DMA para el procesamiento de datos entre SPUs y EIB???

Gracias de antemano, maestro Luzbel

Para hacer la comprobacion, el SPE tiene que estar en modo aislado para usar la unidad de crypto. osea, que si lo mandas sin aislar, no descrifra ni cifra ni na'. En un hipotetico caso más favorable, podrias ejecutar homebrew, pero no podrias ejecutar codigo de sony (juegos, apps) porque no los podrias descrifrar.

O al menos es asi como yo lo entiendo.

Si, ya avisé unos mensajes mas atrás que lo de sacar las claves del SPE no iba a ser tan facil . Es mas, George Hotz tambien ha debido darse cuenta y por eso ha cambiado de opinion y ha sacado el exploit actual tan cual sin llegar a sacar las claves como pensaba en un principio.

De todos modos:
a) siempre puede encontrarse algún fallo. También nos decían antes que en OtherOS no podriamos tener acceso total a la memoria, porque el HV no dejaba, y mira en que situacion estamos ahora
b) el tema claves solo es util para GameOS. Si quieres un OtherOS con acceso total al sistema, ya tienes suficiente.

LuzbelFullHD escribió:Si, ya avisé unos mensajes mas atrás que lo de sacar las claves del SPE no iba a ser tan facil . Es mas, George Hotz tambien ha debido darse cuenta y por eso ha cambiado de opinion y ha sacado el exploit actual tan cual sin llegar a sacar las claves como pensaba en un principio.

De todos modos:
a) siempre puede encontrarse algún fallo. También nos decían antes que en OtherOS no podriamos tener acceso total a la memoria, porque el HV no dejaba, y mira en que situacion estamos ahora
b) el tema claves solo es util para GameOS. Si quieres un OtherOS con acceso total al sistema, ya tienes suficiente.

Eso me referia, puedes ejecutar homebrew (que ya se puede y se repetira siempre, se llama OtherOS), pero no podras ejecutar codigo de Sony, porque no lo podras descifrar de ninguna forma, y eso incluye a los juegos, los apps e incluso el GameOS, osea, el modo normal de una play, el firmware.

Para todo lo demás no es necesario el xploit de George Hotz. Solo hay que leerse el paper para darse cuenta.


El tema de las keys está jodido, porque no es que el hypervisor tenga algo que ver...es el propio cell por hardware el que controla los cifrados y descifrados de los datos, y engañar al software será más o menos dificil...pero engañar al procesador....está jodia la cosa, no hay instrucciones que le digan, #dame_la_root_key, como sí que hay de #mueve_un_dato_aqui, #compara_este_byte_con_este_otro, o #suma_esto_con_esto

Silverdisc escribió:

LuzbelFullHD escribió:Si, ya avisé unos mensajes mas atrás que lo de sacar las claves del SPE no iba a ser tan facil . Es mas, George Hotz tambien ha debido darse cuenta y por eso ha cambiado de opinion y ha sacado el exploit actual tan cual sin llegar a sacar las claves como pensaba en un principio.

De todos modos:
a) siempre puede encontrarse algún fallo. También nos decían antes que en OtherOS no podriamos tener acceso total a la memoria, porque el HV no dejaba, y mira en que situacion estamos ahora
b) el tema claves solo es util para GameOS. Si quieres un OtherOS con acceso total al sistema, ya tienes suficiente.

Eso me referia, puedes ejecutar homebrew (que ya se puede y se repetira siempre, se llama OtherOS), pero no podras ejecutar codigo de Sony, porque no lo podras descifrar de ninguna forma, y eso incluye a los juegos, los apps e incluso el GameOS, osea, el modo normal de una play, el firmware.

Para todo lo demás no es necesario el xploit de George Hotz. Solo hay que leerse el paper para darse cuenta.


El tema de las keys está jodido, porque no es que el hypervisor tenga algo que ver...es el propio cell por hardware el que controla los cifrados y descifrados de los datos, y engañar al software será más o menos dificil...pero engañar al procesador....está jodia la cosa, no hay instrucciones que le digan, #dame_la_root_key, como sí que hay de #mueve_un_dato_aqui, #compara_este_byte_con_este_otro, o #suma_esto_con_esto

en sintesis,no habra nada de nada?

Mmm me estoy perdiendo un poco ya.

Me podéis responder a mis últimas preguntas? Sobre todo la última, referente al modo aislado y el DMA. ¿No será el HV el que controle todo eso?