Publicado Exploit GeoHot Hack PS3 (Leed Primer Mensaje)

Javi5 escribió:

airmalaga escribió:A mi me mola la forma que lo ha conseguido, mediante ataque de glitching. No es novedoso, seguro que muchos de vosotros lo habéis "oido comentar" , hace unos añitos reventaron tarjetas de encriptación de ciertas plataformas. La estresas hasta que salta un bug, se queda tonta y aprovechas para leer y escribir.

jejeje, qué recuerdo dándole caña a las visas con esos unloopers v4 rojos!!! No sé yo quién acababa más mareado algunas visas problemáticas o nosotros mismos

Ah ojo con este sistema porque hay posibilidades serias de petar el chip. Pero no sólo grabando, sino hasta leyendo pudes petarlo si te pasas con el voltaje un poco. El tema del voltaje es la clave, hay que llevarlo hasta el máximo posible, pero sin pasarse ya que así salta antes el glich. Con un voltaje demasiado bajo el chip no suele soltar prenda. Para estos menesteres es INDISPENSABLE (lo digo por si alguien coge el toro por los cuernos) una fuente de alimentación totalmente estabilizada, ya que se suele jugar con tensiones muy bajas que deben ser muy precisas. Por décimas de voltios he freido varios chips de éstos.

Un abrazo!

No hay que aplicar ningún voltaje, se trata de cortocircuitar a masa durante 40nS, y si te pasas mucho de esos 40nS entonces sí que es posible que tengas un bonito pisapapeles.

LuzbelFullHD escribió:No hace falta un ataque en tiempo real pinchando el HW. Usas el exploit, paras el resto de procesos para que no cambien nada, y vas volcando tranquilamente mediante software la memoria.


Puedes tener más de un SPE en modo aislado.


Yo sigo diciendo que todo es mas sencillo, que la mayoria de las cosas van normales sin cifrar por la memoria y se ejecutan como procesos normales. ¿ o creeis que todos los movimientos del linux a memoria pasan por el HV para que les cifre y le descifre los datos de la memoria ?

En cuanto a que el montaje del SPE aislado no puede ser cifrado porque en el momento del inicio no hay nada cargado para cifrar/descifrar , tampoco es así. Y esto ya no es especulación mia, viene en la documentación de IBM.
Es precisamente la capacidad que tiene el SPE de que le metas algo cifrado (así nadie lo ha tocado ni manipulado), ponerse en modo aislado , descifrarse dentro ( y al estar aislado ya nadie puede modificarlo ) y ejecutarse en el modo aislado, lo que da seguridad al Cell.

La memoria de un SPE es de 256KB , así que le caben unas claves algo mas gordas que una de 128 bits. Aparte que la clave la tiene en HW, y es una facilidad HW la que descifra, sin tener que tener un cargador/descifrador SW.

Dejo pendiente mirarme las referencias de ibm (no es de mi agrado leerme articulos tecnicos en ingles).
Pero si que puedo decir una cosa.

En cuanto a que el montaje del SPE aislado no puede ser cifrado porque en el momento del inicio no hay nada cargado para cifrar/descifrar , tampoco es así. Y esto ya no es especulación mia, viene en la documentación de IBM.
Es precisamente la capacidad que tiene el SPE de que le metas algo cifrado (así nadie lo ha tocado ni manipulado), ponerse en modo aislado , descifrarse dentro ( y al estar aislado ya nadie puede modificarlo ) y ejecutarse en el modo aislado, lo que da seguridad al Cell.

Visto que lo que habia leido no estaba bien me he pasado por ibm.
Cierto que la memoria local del spe es de 256K (la memoria falla), asi que si que es capaz de almacenar la clave sin problemas. Pero es que ademas no es el el encargado de almacenarla(por lo menos de forma logica, fisicamente se tiene que encontrar dentro del SPE)
Despues de leer el articulo de ibm sobre seguridad en cell..
Sabiendo que al obtener el control del hypervisor(u Os como lo llaman ellos) el sistema era vulnerable,la arquitectura fue diseñada para evitar esa vulnerabilidad. Un SPE puede funcionar de manera autonoma, asi que cuando ponemos un SPE en modo isolated (es cierto, el numero que quieras, esto me pasa por leer a terceros y no a IBM) se impide cualquier orden externa excepto cancerlar ese SPE (cuando se cancela primero se borra y despues se libera de forma transparente)el encargado de esto es el secure processing vault.
Para montar un SPE en modo isolated tiene que pasar por "the runtime secure boot" que verifica la integridad de esa informacion, no permitiria creacion de tuneles de comunicacion ni ninguna manera de exportar la informacion fuera del SPE.
EL hardware root of secrecy funciona en paralelo al secure boot y proporciona una comunicacion encriptada mediante el root key. Solo los SPE en modo isolated trabajan sobre informacion encriptada mediante la root key.

La ultima defensa seria mediante la encriptacion. Se puede meter la informacion en el SPE isolated y procesarla encriptandola de nuevo añadiendole un timestamp impidiendo asi capturar esos datos y poder usarlos en momentos posteriores o un ataque repetitivo.

http://www.ibm.com/developerworks/power ... 6&S_CMP=LP
Para quien quiera leerselo entero.

Y mi conclusion, aunque hayamos encontrado un agujero para colarnos, en el desarrollo del Cell se tuvo en cuenta esta vulnerabilidad que hemos encontrado. La integridad del Cell sigue intacta.

xakmsx escribió:

Javi5 escribió:

airmalaga escribió:A mi me mola la forma que lo ha conseguido, mediante ataque de glitching. No es novedoso, seguro que muchos de vosotros lo habéis "oido comentar" , hace unos añitos reventaron tarjetas de encriptación de ciertas plataformas. La estresas hasta que salta un bug, se queda tonta y aprovechas para leer y escribir.

jejeje, qué recuerdo dándole caña a las visas con esos unloopers v4 rojos!!! No sé yo quién acababa más mareado algunas visas problemáticas o nosotros mismos

Ah ojo con este sistema porque hay posibilidades serias de petar el chip. Pero no sólo grabando, sino hasta leyendo pudes petarlo si te pasas con el voltaje un poco. El tema del voltaje es la clave, hay que llevarlo hasta el máximo posible, pero sin pasarse ya que así salta antes el glich. Con un voltaje demasiado bajo el chip no suele soltar prenda. Para estos menesteres es INDISPENSABLE (lo digo por si alguien coge el toro por los cuernos) una fuente de alimentación totalmente estabilizada, ya que se suele jugar con tensiones muy bajas que deben ser muy precisas. Por décimas de voltios he freido varios chips de éstos.

Un abrazo!

No hay que aplicar ningún voltaje, se trata de cortocircuitar a masa durante 40nS, y si te pasas mucho de esos 40nS entonces sí que es posible que tengas un bonito pisapapeles.

Entonces no exactamente lo mismo que los chip de las visas, pero en esencia se actua igual.

PauSaDRaMaTiCa escribió:Visto que lo que habia leido no estaba bien me he pasado por ibm.
Cierto que la memoria local del spe es de 256K (la memoria falla), asi que si que es capaz de almacenar la clave sin problemas. Pero es que ademas no es el el encargado de almacenarla(por lo menos de forma logica, fisicamente se tiene que encontrar dentro del SPE)
Despues de leer el articulo de ibm sobre seguridad en cell..
Sabiendo que al obtener el control del hypervisor(u Os como lo llaman ellos) el sistema era vulnerable,la arquitectura fue diseñada para evitar esa vulnerabilidad. Un SPE puede funcionar de manera autonoma, asi que cuando ponemos un SPE en modo isolated (es cierto, el numero que quieras, esto me pasa por leer a terceros y no a IBM) se impide cualquier orden externa excepto cancerlar ese SPE (cuando se cancela primero se borra y despues se libera de forma transparente)el encargado de esto es el secure processing vault.
Para montar un SPE en modo isolated tiene que pasar por "the runtime secure boot" que verifica la integridad de esa informacion, no permitiria creacion de tuneles de comunicacion ni ninguna manera de exportar la informacion fuera del SPE.
EL hardware root of secrecy funciona en paralelo al secure boot y proporciona una comunicacion encriptada mediante el root key. Solo los SPE en modo isolated trabajan sobre informacion encriptada mediante la root key.

La ultima defensa seria mediante la encriptacion. Se puede meter la informacion en el SPE isolated y procesarla encriptandola de nuevo añadiendole un timestamp impidiendo asi capturar esos datos y poder usarlos en momentos posteriores o un ataque repetitivo.

http://www.ibm.com/developerworks/power ... 6&S_CMP=LP
Para quien quiera leerselo entero.

Y mi conclusion, aunque hayamos encontrado un agujero para colarnos, en el desarrollo del Cell se tuvo en cuenta esta vulnerabilidad que hemos encontrado. La integridad del Cell sigue intacta.

Esto dice Geohot al respecto.

"Right now, I'm playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It's not, it's kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking."

Poco más que añadir.

¿Apostamos? .. D

Yo diria que para esta proxima semana ya tendremos algo de soft "extra" para la consola, basicamente si pensamos que tenemos infinidad de grupos de desarrollo trabajando en la consola por todo el planeta ¡¡ no creo que tarden muchos dias en lanzar alguna novedad para la misma. Eso si viendo la complejidad del desarrollo me da a pensar que posiblemente tengamos chip en el mercado ..

emipta escribió:¿Apostamos? .. D

Yo diria que para esta proxima semana ya tendremos algo de soft "extra" para la consola, basicamente si pensamos que tenemos infinidad de grupos de desarrollo trabajando en la consola por todo el planeta ¡¡ no creo que tarden muchos dias en lanzar alguna novedad para la misma. Eso si viendo la complejidad del desarrollo me da a pensar que posiblemente tengamos chip en el mercado ..

Desde luego cuento con lo del chip.

No me gusta interrumpir el hilo si no es para aportar algo pero ya que sacasteis el tema.

¿Los modchips se encargan de eso? ¿De meter impulsos determinados a la placa para que se salte chequeos?


PData: No metais el link del IRC, que la mayoria de las veces se mete algun tontolaba a molestar sin saber del tema. Dejemos el IRC para los que controlan y ya recibiremos información en el hilo. NO es necesario estar en las conversaciones, esto va a ir muy lento.

hardcore087 escribió:No me gusta interrumpir el hilo si no es para aportar algo pero ya que sacasteis el tema.

¿Los modchips se encargan de eso? ¿De meter impulsos determinados a la placa para que se salte chequeos?

Básicamente un chip hace lo que le diga el código que le metes tu mismo en memoria que haga, los chips que conocemos habitualmente de otras consolas hacen bastante más que meter un impulso de 40ns, generalmente alteran o sobreescriben totalmente la bios del sistema o el firmware del lector dependiendo de donde vayan soldados.

Geohot esta hablando por irc
sherlockh installing the exploit via software exploit would be great
19:51 geohot lol @software exploit
19:51 geohot it doesn't exist
19:51 RichDevX did you read the transcript?
19:51 RichDevX you could tell it was planned to get attention
19:52 geohot just some clever trolls
19:52 S1m0n3 hello geohot
19:52 geohot who almost knew what they were talking about
19:52 geohot but the hypervisor doesn't do things like parse strings
19:52 Infel morning folks
19:53 *** Malk1 quit (Ping timeout: 264 seconds)
19:53 Ofca RichDevX: isn't lv2 encrypted?
19:53 hudson i never got an answer from them how big the HV is :/
19:54 geohot 1.5 MB
19:54 Ofca hudson: less than 2MB?
19:54 *** D-BlooD joined #ps3dev
19:54 hudson thanks
19:55 hudson i thought it was something like 16k
19:55 hudson 1.5 meg is a bit more to reverse
19:55 Ofca 16k for c++ program would be a bit too small I think
19:55 geohot it's not the 360
19:55 geohot theres a lot in the hypervisor
19:56 *** JcT joined #ps3dev

Joder para el HV, ¿qué le metieron para ocupar 1.5MB?, ahora sí que tengo gran curiosidad por verlo descifrado...

geohot the real driver thats win is the RSX one
20:22 geohot but its the hardest to write
20:23 geohot you can write storage driver to get full nand/hd access
20:23 knyz lol
20:23 geohot although thats easier with hv patches
20:23 *** Aragan joined #ps3dev
20:23 Ofca wasn't the main concern now making the hack permanent somehow?
20:23 knyz I already compile a driver for the RSX, but have to much bug for now... (kernel panic and freeze) i need to fix him
20:23 Ofca or is pulsing the bus every boot acceptable?
20:23 knyz I need the times too
20:24 geohot pulsing the bus every time
20:24 geohot but build something automatic
20:24 Davee pulsar cannon
20:24 Davee gotta plan an awesome name
20:24 knyz you need to use GCC
20:24 Ofca bah, that's the easy way out ;p
20:24 geohot really the bootloader should get the exploit
20:24 geohot and add a couple nice hv calls
20:25 geohot which the kernel can use in drivers
20:25 Ofca but bootloader is prolly encrypted, or at least signed?
20:25 geohot nah
20:25 geohot its a bld file
20:25 Infel you know, i have a question about all this, it was more like an arguement that came up after this whole thing got found out, but alot of people are saying that its going to be possible to give the ps3 NTSF support with all this cracking of it...
20:25 knyz Check OpenSSL
20:25 *** cottonWRK joined #ps3dev
20:25 *** ResaKa joined #ps3dev

acabar de comentar que se podría ejecutar desde un pic o un atmel el pulso en un usb lo cual sería una instalación más limpia.
Además (este tio es un guru como la mayoria de los del chat) comenta que le gustaria ver un ataque en frio de un spu para ver si de verdad esta el motor de cifrado dentro

esto es de novela de intriga buff ya estoy viendo el titulo geohot and cia vs cell

edito:geohot también ha comentado que la root key es genérica para todas las máquinas

POCHIGO escribió:acabar de comentar que se podría ejecutar desde un pic o un atmel el pulso en un usb lo cual sería una instalación más limpia.

Eso ya se comentó hace un par de días, sería el mismo punto de ahora pero se sacaría la alimentación del integrado desde el USB de la consola, así nos evitamos tener que hacer una conexión externa, en realidad no cambia el planteamiento, sólo se abarata y simplifica.

Edito, lo de la root key, ¿cómo lo puede saber con seguridad?.

Cuidado que hay gente que me parece que esta confundiendo las cosas por aqui, NO CREAIS que va a ser necesario UN CHIP que meta pulsos "atontadores" por asi decirlo para usar la consola con HOMEBREW o backups... como se ha dicho varias VECES...
este exploit es para quien tiene conocimientos avanzados de programacion y electronica en PS3 y otros campos como C++ etc etc, pero no ES para viles mortales como la mayoria de los que estamos aqui.
QUE SI DESPUES HACE FALTA UN CHIP? y quien tiene la bola de cristal para saberlo??? pero seguro que el chip que haga falta, no sera uno que haga el trabajo que se necesita hoy en dia para que el Hpervisor largue sus secretos...se entiende?

eso del ROOT KEY es muy importante, seguro que GEOHOT dijo eso???

<ifcaro> but root key is different for every ps3?

<knyz> loool

<geohot> no

<hudson> heh

<geohot> root key is uniform

un copy paste del log del chat

POCHIGO escribió:<ifcaro> but root key is different for every ps3?

<knyz> loool

<geohot> no

<hudson> heh

<geohot> root key is uniform

un copy paste del log del chat

Pues si es la misma root key, la historia cambia por copleto señores. La complejidad del invento se reduce considerablemente, pues es una variable fija para todas las ps3. Me gusta este dato mucho, la verdad.
Parece que cada hora que pasa se van dando pasitos hacia el objetivo.

P.D.: lo del pic ya lo dije post atrás, creo que al hard algo habrá que tocarle casi seguro.

Saludos!

He metido la información en el wiki: wiki/Scene_de_PlayStation_3#George_Hotz.27s_silver_platter

Alguien con conocimientos más profundos del kernel de linux y de virtualización debería completar la segunda parte del software del exploit, que no queda muy detallada.

Y a ver si esos expertos en HW publican ya un circuito bueno, bonito y barato con el que poner a tierra el bus de memoria durante 40ns, que la información es muy poca.

<|Omega|> geohot: What do you think about go?

<geohot> the game?

<RichDevX> psp?

<geohot> i can pwn you at it

<geohot> i can probably pwn that too

<GaZ-_-> go the movie was gud

<geohot> idk, i don't have a psp

<Raffo> geohot you can pwn us at the game but we pwn ya in girlz!

<Raffo>

<geohot> actually...

<|Omega|> geohot: The Programming language.

<RichDevX> there's few k exploits for psp, that have been kept private

<geohot> omg, world doesn't need more programming languages


Quizas si alguien le alcanza una PSP Go, se divierta un ratito...y libere algo tambien

Ornella escribió:Quizas si alguien le alcanza una PSP Go, se divierta un ratito...y libere algo tambien

Y si no le dan ideas y se centra unica y exclusivamente en ps3, que me da que en cuanto salga el nuevo timo de Apple(en 2 meses, 3 para el modelo 3g )este se olvida de la play.

se podria saltar la proteccion del blueray para dumpear la informacion en el HD?

lacion escribió:

niusito escribió:No se ha dicho nada de la encriptacion del software extraido?, Geohot parece que decia que es bastante jodido, y que la clave es eso, si alguien sabe algo que postee

eso es una ip publica de ono, tiene todo el derecho del mundo a publicarla.

tu has leido mi mensaje? estas colocado campeon? o eres retrasado?

niusito escribió:

lacion escribió:

niusito escribió:No se ha dicho nada de la encriptacion del software extraido?, Geohot parece que decia que es bastante jodido, y que la clave es eso, si alguien sabe algo que postee

eso es una ip publica de ono, tiene todo el derecho del mundo a publicarla.

tu has leido mi mensaje? estas colocado campeon? o eres retrasado?

guarda tus modales (campeon)pq lo mismo te baean o nos chapan el kiosko...¡¡

saludos

bomber360 escribió:[
guarda tus modales (campeon)pq lo mismo te baean o nos chapan el kiosko...¡¡

saludos

aqui se estan editando mensajes mios y poniendo gilipolleces en ellos, campeón, a ver si lo cierran de verdad, ya que los moderadores no hacen nada contra estas personas, y hay doscientos mensajes de basura y uno con informacion de verdad

thanos1 escribió:geohot the real driver thats win is the RSX one
20:22 geohot but its the hardest to write
20:23 geohot you can write storage driver to get full nand/hd access
20:23 knyz lol
20:23 geohot although thats easier with hv patches
20:23 *** Aragan joined #ps3dev
20:23 Ofca wasn't the main concern now making the hack permanent somehow?
20:23 knyz I already compile a driver for the RSX, but have to much bug for now... (kernel panic and freeze) i need to fix him
20:23 Ofca or is pulsing the bus every boot acceptable?
20:23 knyz I need the times too
20:24 geohot pulsing the bus every time
20:24 geohot but build something automatic
20:24 Davee pulsar cannon
20:24 Davee gotta plan an awesome name
20:24 knyz you need to use GCC
20:24 Ofca bah, that's the easy way out ;p
20:24 geohot really the bootloader should get the exploit
20:24 geohot and add a couple nice hv calls
20:25 geohot which the kernel can use in drivers
20:25 Ofca but bootloader is prolly encrypted, or at least signed?
20:25 geohot nah
20:25 geohot its a bld file
20:25 Infel you know, i have a question about all this, it was more like an arguement that came up after this whole thing got found out, but alot of people are saying that its going to be possible to give the ps3 NTSF support with all this cracking of it...
20:25 knyz Check OpenSSL
20:25 *** cottonWRK joined #ps3dev
20:25 *** ResaKa joined #ps3dev

POCHIGO escribió:<ifcaro> but root key is different for every ps3?

<knyz> loool

<geohot> no

<hudson> heh

<geohot> root key is uniform

un copy paste del log del chat

Señores al tema que nos lo chapan,

creo que esto es lo más interesante en estas última 25 páginas, a parte de la espera de un circuito con un Pic en condiciones.

Un saludo

xukin escribió:

thanos1 escribió:geohot the real driver thats win is the RSX one
20:22 geohot but its the hardest to write
20:23 geohot you can write storage driver to get full nand/hd access
20:23 knyz lol
20:23 geohot although thats easier with hv patches
20:23 *** Aragan joined #ps3dev
20:23 Ofca wasn't the main concern now making the hack permanent somehow?
20:23 knyz I already compile a driver for the RSX, but have to much bug for now... (kernel panic and freeze) i need to fix him
20:23 Ofca or is pulsing the bus every boot acceptable?
20:23 knyz I need the times too
20:24 geohot pulsing the bus every time
20:24 geohot but build something automatic
20:24 Davee pulsar cannon
20:24 Davee gotta plan an awesome name
20:24 knyz you need to use GCC
20:24 Ofca bah, that's the easy way out ;p
20:24 geohot really the bootloader should get the exploit
20:24 geohot and add a couple nice hv calls
20:25 geohot which the kernel can use in drivers
20:25 Ofca but bootloader is prolly encrypted, or at least signed?
20:25 geohot nah
20:25 geohot its a bld file
20:25 Infel you know, i have a question about all this, it was more like an arguement that came up after this whole thing got found out, but alot of people are saying that its going to be possible to give the ps3 NTSF support with all this cracking of it...
20:25 knyz Check OpenSSL
20:25 *** cottonWRK joined #ps3dev
20:25 *** ResaKa joined #ps3dev

POCHIGO escribió:<ifcaro> but root key is different for every ps3?

<knyz> loool

<geohot> no

<hudson> heh

<geohot> root key is uniform

un copy paste del log del chat

Señores al tema que nos lo chapan,

creo que esto es lo más interesante en estas última 25 páginas, a parte de la espera de un circuito con un Pic en condiciones.

Un saludo

GRACIAS , dice algo de acceder completamente al disco duro y la nand?

Basicamente ...

le piden a geohotz que saque un driver para el RSX ya que es lo mas esperado
y contesta que si, pero que también es el más dificil de hacer

le piden a geohotz que haga un driver con acceso completo a la nand (flash) y al disco duro
y contesta que sería más facil parchear el hipervisor y usar los drivers actuales de linux

alguien se tira el pisto de que tiene ya un driver RSX pero que le falla y se le cuelga mucho
no le hacen caso (supongo que en plan callate y anuncialo cuando funcione)

le preguntan a geohotz si es malo estar haciendo lo del pulso al bus de memoria cada vez que se arranca linux
y dice que hay que hacerlo pero que se deberia automatizar y que lo suyo es que fuese en el cargador de arranque
( refiriendose al kboot de linux y no al firmware, para que asi cada vez que arranques tengas el exploit cargado )
le indican que el cargador de arranque (refiriendose al firmware) va cifrado
y les contesta que no

en el otro "quote" le pregunta si la clave maestra principal es diferente para cada PS3 y contesta que no

Eso seria una facilidad que la clave fuera la misma en todas las ps3 , sino cada uno tendra que guisarselo solo con su PS3 cosa que veo muy probable .
Un saludo

si la clave es diferente para cada consola pasaria igual que con los lectores de la 360 y yasta, que tambien lo queremos todo hecho señores...

algun adelanto?

Most escribió:algun adelanto?

si,que aparecio un faker nuevo en el IRC llamado PS3decoder diciendo que consiguio las keys...sacando eso nada nuevo

mmm otra vez con eso de los fakes, es que la verdad ya cansanm hasta el momento habra que esperar que salga a la luz algun driver d RSX o un parche en el HV, ambos yo los veo tardados puesto que ni se ha descifrado el HV y la escritura en RSX es lo mas dificil

mira,lo cierto es que falta mucho y no se consiguio nada aun,paciencia en menos de lo que creemos algo saldra,es mas lei en el IRC que decian todos los que saben, que "antes de los dias soleados" seguro tendran algo interesante....haciendo referencia al final del invierno supongo

k otro año mas va a pasar

otro año mas NO,es cuestion de 2 meses,3 a lo sumo ...si para ese entonces no hay nada,entonces pregunten.... mientras tanto toca esperar ese tiempo

Most escribió:algun adelanto?

Si, mas paginas de post interesantes como el tuyo desde la ultima vez que miraste.

PD: Lo siento pero por mas que miro de morderme la lengua no me he podido callar esta vez. Si no se incluyieran este tipo de post no haria falta preguntar.

Pues si hay que esperar se espera. A mi siempre me moló el rollo este de la scene en las consolas. Y parace que con eso de que la PS3 es "impenetrable" le da aun más morbillo a la espera. Estoy deseando que saquen algo funcional para empezar a trastearla.
Imaginaos, ¿será posible por fin poder reproducir mkv directamente?...por soñar que no quede. Un saludo y gran trabajo el de los sceners!!

Jur...

Todas las infracciones han sido apuntadas y se ha avisado a la administración para que tome las medidas pertinentes.

Si el hilo no os interesa para hablar del Exploit , por favor no posteis (ya se ha avisado en numerosas ocasiones, y cualquier infracción de las normas puede suponer baneo del foro).

Un saludo.

Most escribió:algun adelanto?

no

Bueno, son casi 1.000 respuestas y un montón de páginas, no las he leído todas, así que ... si lo que cuento en este post ya está en el hilo, por favor ... no me comáis.

En PSX-Scene también están como locos con el exploit.

garyopa, uno de los admins, ha colgado diseños de un par de circuitos para enviar los pulsos:





Todavía más sencillo:





Y aquí la explicación:

It was called a "LOAD INTERRUPT", and it was how I got my computer to suddenly start running my own debug
code that I had already poked into memory, at any time I wanted, in any program I was running in the foreground.

Geohot's exploit is not "rocket science", just many weeks of Red Bull fuelled nights and days of brain-storming!

The way it works you push the button, and no matter how long you push it, or how rough your push-button is, or how many times you hammer the sucker.

You get one nice clean pulse out of the circuit, and with simple correct values you can make sure it is around a 40ns pulse, or adding another simple circuit you could program it to either be a little shorter or lower as need be.

Of course your PS3 has to be setup looking for this sudden change in the system, but unlike older technology which does not have any "cell security", the PS3 does, so instead of using a normal way to cause the CPU to change, he forces the databus to change its state, and PS3 ends up branching into his code that he already setup in advance.

I just finish gutted three junked PS3 models at my shop, and tomorrow I see if I can find the other fourth PS3 model (there is 4 common motherboard designs, not counting the slim (which can't run "otheros")) and do some high-res scans of the area were you can solder your "one-shot" button pushing maddness hardware onto.

Now I also see alot of people asking what version of Sony firmware? -- He mentions v2.4.2 (what's that?), when if you a Linux person you would understand that is the version of Linux kernal that he used.

This exploit does not matter (currently, Sony may issue a patch in v3.16 or v3.20) but it can run all current releases of Sony firmware.

Anyhow, I going to bed now.

I just thought I post this to stop all the people PMing, what is a "glitch", where do I get v2.4.2 of Sony firmware!

This exploit is not for the mainstream of users, it is for people that want to play around and find a real opening into the PS3 hardware, all Geohot did is produce a small crack in the dam of the security system.

As for the media and him claiming he HACKED the PS3, well this is more like a baby learning to move his index finger on their own without someone grabbing their hand and wiggling it for them, our PS3 BABY still does not know even that he has feet or knees yet, does even know what it is like to crawl, forgot about running the quarter-mile (backups!)

We are just able to wiggle a couple of fingers and smile or cry depending on mood of your newborn PS3 baby now, thanks in part to Geohot's 5 weeks of hacker madness.

Fuente:
http://psx-scene.com/forums/showthread.php?t=63534


Saludos!

ese tipo de circuitos los estoy estudiando en la carrera, cuando me afiance un poco más en el tema a ver si puedo echaros una mano

fidillo escribió:

Buen trabajo fidillo. Con el timer 555 consigues el montaje más sencillo. Paginas atras alguien dijo que no se podia hacer con el 555, cosa que no entendi mu bien...

¿No le has puesto zocalo al integrado?

Lo del 555 me ha hecho gracia para enviar pulsos jaja es "super estable". Podéis utilizar cualquier uC que trabaje a un ciclo maquina con un reloj apropiado. Con un código algo así:

PULSO:
CPL P0.1
JMP PULSO

Si no os basta con la intensidad del puerto del uC podéis poner un BJT en activa. Hay que tener en cuenta que tipo de puerto tiene el uC, drenador abierto, pull up...

Aunque utilizar un uC solo para esto... lo mejor es utilizar algún circuito secuencial, la idea de los biestables tipo D no esta mal.

A ver, yo (al igual que otros) ya he dicho por activa y por pasiva que el 555 no vale, pero bueno, allá cada uno en lo que prueba y en lo que invierte su tiempo. Si miráis el datasheet del 555 podéis ver al final de la tabla de la página 3, que los tiempos de subida y de bajada del 555 son de 100 ns, es decir, que el chip es tremendamente LENTO, y que no vais a poder generar un pulso de sólo 40 ns ni de coña, porque cuando se produzca el trigger, tardará 100 ns en subir, luego mantendrá el pulso 40 ns y luego tardará 100 ns en bajar, con lo que tendréis un pulso de unos 240 ns. Hay que usar otra solución, como pueda ser un microcontrolador con una frecuencia de reloj de al menos 25 MHz, o el circuito de biestables que han puesto por aquí arriba.

¿Pero y no se puede generar el pulso de 40 ns con las mismas herramientas que geohotz?¿O es que estas son muy caras o dificiles de conseguir?

doragasu escribió:A ver, yo (al igual que otros) ya he dicho por activa y por pasiva que el 555 no vale, pero bueno, allá cada uno en lo que prueba y en lo que invierte su tiempo. Si miráis el datasheet del 555 podéis ver al final de la tabla de la página 3, que los tiempos de subida y de bajada del 555 son de 100 ns, es decir, que el chip es tremendamente LENTO, y que no vais a poder generar un pulso de sólo 40 ns ni de coña, porque cuando se produzca el trigger, tardará 100 ns en subir, luego mantendrá el pulso 40 ns y luego tardará 100 ns en bajar, con lo que tendréis un pulso de unos 240 ns. Hay que usar otra solución, como pueda ser un microcontrolador con una frecuencia de reloj de al menos 25 MHz, o el circuito de biestables que han puesto por aquí arriba.

Con un microcontrolador microchip 18F4550 puedes llegar cómodamente a los 48 MHz... comprobado por mi (tiene un PLL que multiplica la frecuencia de un cristal, y este puede ser de 4, 8 , 12, 20... alguna vez cuando requerí algo de velocidad y precisión lo use en modo a 48 MHz y funciono de perlas)

Otros micros: 18F4450, 18F2550...

adarauzo escribió:¿Pero y no se puede generar el pulso de 40 ns con las mismas herramientas que geohotz?¿O es que estas son muy caras o dificiles de conseguir?

Evidentemente amigo mio, por eso se intenta encontrar alternativas a las herramientas utilizadas por George Hotz.

Una placa FPGA para realizar un pulso de 40 ns, es lo que se suele llamar un "overkill". Viene a ser como matar una mosca con una bomba. Tremendamente eficaz, tremendamente innecesario y derrochante. Ese tipo de placas de prototipado FPGA sirve para un monton de cosas más que para un timer de 40ns.

Y si, el 555 es util hasta los 100ns, más allá es inutil porque simplemente no es tan rápido. En la electronica los cambios de 0 a 1 (0 voltios a 5 voltios) no se producen de forma instantanea, no se generan como un angulo de 90º vertical, sino que tiene una pendiente, y eso implica que pasa un tiempo desde que está a 0 voltios hasta que alcanza los 5 voltios, que seria un "1" digital y viceversa. Dependiendo del diseño y la fabricación del componente será más rapido o más lento, y uno lento no quiere decir peor, solamente que está diseñado para otro tipo de aplicaciones.

Silverdisc escribió:

adarauzo escribió:¿Pero y no se puede generar el pulso de 40 ns con las mismas herramientas que geohotz?¿O es que estas son muy caras o dificiles de conseguir?

Evidentemente amigo mio, por eso se intenta encontrar alternativas a las herramientas utilizadas por George Hotz.

Una placa FPGA para realizar un pulso de 40 ns, es lo que se suele llamar un "overkill". Viene a ser como matar una mosca con una bomba. Tremendamente eficaz, tremendamente innecesario y derrochante. Ese tipo de placas de prototipado FPGA sirve para un monton de cosas más que para un timer de 40ns.

Y si, el 555 es util hasta los 100ns, más allá es inutil porque simplemente no es tan rápido. En la electronica los cambios de 0 a 1 (0 voltios a 5 voltios) no se producen de forma instantanea, no se generan como un angulo de 90º vertical, sino que tiene una pendiente, y eso implica que pasa un tiempo desde que está a 0 voltios hasta que alcanza los 5 voltios, que seria un "1" digital y viceversa. Dependiendo del diseño y la fabricación del componente será más rapido o más lento, y uno lento no quiere decir peor, solamente que está diseñado para otro tipo de aplicaciones.

Gracias por la aclaración. Esto debe de ser tremendamente laborioso para todos los que estén investigando