Publicado Exploit GeoHot Hack PS3 (Leed Primer Mensaje)

knightRAMZA escribió:lloro de felicidad, y al parecer geohot no ha hecho su aparicion ni en su blog ni en ningun lado si alguien sabe algo,haganoslo saber

f5inet escribió:

knightRAMZA escribió:lloro de felicidad, y al parecer geohot no ha hecho su aparicion ni en su blog ni en ningun lado si alguien sabe algo,haganoslo saber

yo lei la noticia en su twitter y Mathieulh le ha dicho que bonita foto

knightRAMZA escribió:
jajaja Muchas personas estan demostrando que las fotos son fakes

PuMa escribió:

knightRAMZA escribió:
jajaja Muchas personas estan demostrando que las fotos son fakes

Como?

knightRAMZA escribió:

PuMa escribió:

knightRAMZA escribió:
jajaja Muchas personas estan demostrando que las fotos son fakes

Como?

Entra al blog de geo y ve los comentarios hay esta tu respuesta

franph escribió:dentro de dos semanas s l dia de los inocentes en Estados Unidos,igual ha kerido adelantarlo.

Igual lo ha conseguido,aunke s raro ke a una persona ke le gusta aparecer n los medios,cuelgue la foto y calle.

[Lande] escribió:o alguien le ha hackeado la web y pone hello gehot o geo lo ha conseguido y ha conseguido meterle algo de mano al GAMEOS.

odarriba escribió:

[Lande] escribió:o alguien le ha hackeado la web y pone hello gehot o geo lo ha conseguido y ha conseguido meterle algo de mano al GAMEOS.

No creo que nadie tenga un montaje de la PS3 como se puede "medio ver" en la esquina de la fotografía... Y sobre loq ue dicen de modificar un Language file.... Supongo que todo tendrá sus hash de comprobación, pero bueno, que coj****, si pudo acceder a ese archivo de la flash y reescribirlo, ya puede acceder a todo el firm! (bueno, suponiendo que el GameOS no este firmado y encriptado, por lo que ya podemos rezar por que sea algo hecho en la memoria o algo similar)

No sé, no creo que Geohotz se ande con fakes... no lo necesita, ya tiene suficiente fama como para estropearlo con un fake, ¿no creeis?

<TitanMKD> Mathieulh geohot exploit is on xmb or on PUP ?
<flurix> yer we want to know please
<Mathieulh> xmb
<TitanMKD> ha fine
<Mathieulh> it is not an exploit per se
<Mathieulh> just rco editing
<zyron> i think geo changes stuff in ram - but his is not code injection
<zyron> maybe only text modification
<Mathieulh> which he did by replacing a rco in dev_flash
<TitanMKD> Mathieulh but it means he has decrypted it and launched it from linux side maybe
<Mathieulh> yes +
<Mathieulh> yes *
<fxchhat> but devèflash encrypted ?
<Mathieulh> yes it is
<TitanMKD> Mathieulh it is run from otheros ?
<Mathieulh> the code that writes the file is
<TitanMKD> Mathieulh why does it don't explain it here
<TitanMKD> Mathieulh at least to give details of what he has really done without giving source code of course
<Mathieulh> he edited a rco from the dev_flash
<TitanMKD> ok
<Mathieulh> mounted the dev_flash in linux as rw
<Mathieulh> then replaced the file
<Mathieulh> unmounted
<Mathieulh> reboot to gameos
<TitanMKD> ok fine
<zyron> ok - and the rco's are not signed?
<Mathieulh> he had to use his exploit of course
<Mathieulh> no that's the lame thing about it
<Mathieulh> that's why I suggested geohot to look into them
<Mathieulh> they are not signed or encrypted
<flurix> so ram is not cleared?
<Mathieulh> the sole security on them rely on the fact that dev_flash is originally mounted as ro
<Mathieulh> which prevents from overwritting the files
<TitanMKD> and what if the len is too long bufferoverflow maybe
<Len> im too long?
<Mathieulh> let's just say you can do nasty things with them if you know how to
<TitanMKD> Mathieulh yes it's interesting
<zyron> but rco's are just resource files if i understand correctly.
<zyron> the bits in flash that are code are probably signed/encrypted?
<glitcher> thanks mathieulh for details.
<TitanMKD> Mathieulh i will have prefered xmb decrypted + patch and launched from otheros
<TitanMKD> Mathieulh but it's next step if one day we found the metldr com protocol ...
<Mathieulh> well it would be cleaner to decrypt lv2 with priv1 priviledges
<Mathieulh> and the loaders
<Mathieulh> and patch it
<Mathieulh> and load it
<Mathieulh> but it is harder to do
<Mathieulh> you would get full priviledges once in the gameos if you did that though
<TitanMKD> yes but that require developer working together
<TitanMKD> Mathieulh god has not done the world in 1 day
<zyron> "<@Mathieulh> [17:54:56] and they have pointers and are executed by vshmain"
<zyron> do that mean that rcos can be used as entrypoints to homebrew?
<TitanMKD> it's same for PS3 full crack
<zyron> or am i stretching it?
<TitanMKD> where are located these rco ?
<Mathieulh> in v_flash/vsh/resource
<zyron> in flash memory i think
<Mathieulh> in dev_flash/vsh/resource *
<flurix> is it only rco files?
<Mathieulh> to get them you either mount dev_flash
<Mathieulh> and grab them
<Mathieulh> or you decrypt update packages
<Mathieulh> using loaders
<Mathieulh> zyron in theory they could grant you code execution by vsh.self or one of the libsysutils sprx
<Mathieulh> which have higher priviledges than game selfs
<Mathieulh> but still not as much as the kernel itself
<Mathieulh> and certainly not as much as lv1 ones

Oren_Hishii escribió:Mirar este detalle en la foto...

LuzbelFullHD escribió:Ah, muy interesante. Pues no es lo que yo pensaba
Aún no se ha conseguido descifrar y arrancar GameOS.
Lo que ha hecho ha sido acceder a la flash con acceso de lectura y escritura (ante solo se accedia a una parte que nos dejaba ver el HV) , y cambiar allí el texto .
Luego ha cambiado al GameOS de forma normal y el texto de esta pantalla aparece cambiado

pabloc escribió:

LuzbelFullHD escribió:Ah, muy interesante. Pues no es lo que yo pensaba
Aún no se ha conseguido descifrar y arrancar GameOS.
Lo que ha hecho ha sido acceder a la flash con acceso de lectura y escritura (ante solo se accedia a una parte que nos dejaba ver el HV) , y cambiar allí el texto .
Luego ha cambiado al GameOS de forma normal y el texto de esta pantalla aparece cambiado

Y esto en palabras menos tecnicas....

pabloc escribió:

LuzbelFullHD escribió:Ah, muy interesante. Pues no es lo que yo pensaba
Aún no se ha conseguido descifrar y arrancar GameOS.
Lo que ha hecho ha sido acceder a la flash con acceso de lectura y escritura (ante solo se accedia a una parte que nos dejaba ver el HV) , y cambiar allí el texto .
Luego ha cambiado al GameOS de forma normal y el texto de esta pantalla aparece cambiado

Y esto en palabras menos tecnicas....

pabloc escribió:

LuzbelFullHD escribió:Ah, muy interesante. Pues no es lo que yo pensaba
Aún no se ha conseguido descifrar y arrancar GameOS.
Lo que ha hecho ha sido acceder a la flash con acceso de lectura y escritura (ante solo se accedia a una parte que nos dejaba ver el HV) , y cambiar allí el texto .
Luego ha cambiado al GameOS de forma normal y el texto de esta pantalla aparece cambiado

Y esto en palabras menos tecnicas....

f5inet escribió:[...]ha cambiado parte de una flash que esta sin proteger (o sea, sin firmar/cifrar)

LuzbelFullHD escribió:

f5inet escribió:[...]ha cambiado parte de una flash que esta sin proteger (o sea, sin firmar/cifrar)

Sin proteger, pero a la que antes no teníamos acceso.

Eso sí, a grandes rasgos estamos como hace unos días (sin cargar GameOS, sin saber como usar metldr, etc. )

f5inet escribió:

LuzbelFullHD escribió:
Eso sí, a grandes rasgos estamos como hace unos días (sin cargar GameOS, sin saber como usar metldr, etc. )

el siguiente paso logico es cargar el LPAR de gameOS

<TitanMKD> Mathieulh i will have prefered xmb decrypted + patch and launched from otheros
<TitanMKD> Mathieulh but it's next step if one day we found the metldr com protocol ...

f5inet escribió:, o sea, reprogramar la MMU con la particion de memoria tal como se lo esperaria cualquier programa de GameOS

geohot 6 minutes ago

When I posted this, I didn't know the PS3 had real custom themes(what I get for not actually being a user). This is how custom themes worked on the PSP pre firmware 3.70

And to people who think the picture is fake, what do you think about the moon landing?

pabloc escribió:

LuzbelFullHD escribió:Ah, muy interesante. Pues no es lo que yo pensaba
Aún no se ha conseguido descifrar y arrancar GameOS.
Lo que ha hecho ha sido acceder a la flash con acceso de lectura y escritura (ante solo se accedia a una parte que nos dejaba ver el HV) , y cambiar allí el texto .
Luego ha cambiado al GameOS de forma normal y el texto de esta pantalla aparece cambiado

Y esto en palabras menos tecnicas....

LuzbelFullHD escribió:[...]
Uhm, interesante. Siempre he tenido curiosidad por saber que supone un LPAR realmente
¿ solo es tema de MMU y controlar los accesos a memoria ?
Tiene sentido, aunque supongo que combinado con los servicios que decida darle el HV. Por ejemplo, puedo capar el acceso a determinados registros mapeados en memoria para que no acceda al bus USB, pero puede darle ciertas llamadas del HV que le den un acceso controlado al USB.
¿ tienes algún enlace a doc. que explique en que consiste realmente un LPAR ?

el_aprendiz escribió:Ahora en el IRQ:

<TitanMKD> Mathieulh geohot exploit is on xmb or on PUP ?
<flurix> yer we want to know please
<Mathieulh> xmb
<TitanMKD> ha fine
<Mathieulh> it is not an exploit per se
<Mathieulh> just rco editing
<zyron> i think geo changes stuff in ram - but his is not code injection
<zyron> maybe only text modification
<Mathieulh> which he did by replacing a rco in dev_flash
<TitanMKD> Mathieulh but it means he has decrypted it and launched it from linux side maybe
<Mathieulh> yes +
<Mathieulh> yes *
<fxchhat> but devèflash encrypted ?
<Mathieulh> yes it is
<TitanMKD> Mathieulh it is run from otheros ?
<Mathieulh> the code that writes the file is
<TitanMKD> Mathieulh why does it don't explain it here
<TitanMKD> Mathieulh at least to give details of what he has really done without giving source code of course
<Mathieulh> he edited a rco from the dev_flash
<TitanMKD> ok
<Mathieulh> mounted the dev_flash in linux as rw
<Mathieulh> then replaced the file
<Mathieulh> unmounted
<Mathieulh> reboot to gameos
<TitanMKD> ok fine
<zyron> ok - and the rco's are not signed?
<Mathieulh> he had to use his exploit of course
<Mathieulh> no that's the lame thing about it
<Mathieulh> that's why I suggested geohot to look into them
<Mathieulh> they are not signed or encrypted
<flurix> so ram is not cleared?
<Mathieulh> the sole security on them rely on the fact that dev_flash is originally mounted as ro
<Mathieulh> which prevents from overwritting the files
<TitanMKD> and what if the len is too long bufferoverflow maybe
<Len> im too long?
<Mathieulh> let's just say you can do nasty things with them if you know how to
<TitanMKD> Mathieulh yes it's interesting
<zyron> but rco's are just resource files if i understand correctly.
<zyron> the bits in flash that are code are probably signed/encrypted?
<glitcher> thanks mathieulh for details.
<TitanMKD> Mathieulh i will have prefered xmb decrypted + patch and launched from otheros
<TitanMKD> Mathieulh but it's next step if one day we found the metldr com protocol ...
<Mathieulh> well it would be cleaner to decrypt lv2 with priv1 priviledges
<Mathieulh> and the loaders
<Mathieulh> and patch it
<Mathieulh> and load it
<Mathieulh> but it is harder to do
<Mathieulh> you would get full priviledges once in the gameos if you did that though
<TitanMKD> yes but that require developer working together
<TitanMKD> Mathieulh god has not done the world in 1 day
<zyron> "<@Mathieulh> [17:54:56] and they have pointers and are executed by vshmain"
<zyron> do that mean that rcos can be used as entrypoints to homebrew?
<TitanMKD> it's same for PS3 full crack
<zyron> or am i stretching it?
<TitanMKD> where are located these rco ?
<Mathieulh> in v_flash/vsh/resource
<zyron> in flash memory i think
<Mathieulh> in dev_flash/vsh/resource *
<flurix> is it only rco files?
<Mathieulh> to get them you either mount dev_flash
<Mathieulh> and grab them
<Mathieulh> or you decrypt update packages
<Mathieulh> using loaders
<Mathieulh> zyron in theory they could grant you code execution by vsh.self or one of the libsysutils sprx
<Mathieulh> which have higher priviledges than game selfs
<Mathieulh> but still not as much as the kernel itself
<Mathieulh> and certainly not as much as lv1 ones

Quizás esto de respuesta a muchas de vuestras dudas sobre la foto

XorHack v2.0: The Updated PS3 Exploit Toolkit
After using the XorHack for a while I realised it was missing some things so I decided it was time for an update. New syscalls have been added to give finer control over data access, now providing 8, 16, 32 and 64 bit reads and writes. Also some new ioctls were added to provide additional useful functions for your userland code. Lastly new userland applications were added which now give the ability to read, write and execute memory from the command line

Download XorHack v2.0 here


Hypervisor Exploit Changes
At the innermost level some more syscalls are now added to the hypervisor when initially exploiting the PS3. These use different syscall numbers to the previous exploit code in order to group them all together rather than scattering them all over the place. This should make keeping track of them easier. There are now nine syscalls added to the PS3 upon exploiting. These are added as syscalls 32 to 40 inclusive. Previously syscalls 16 and 20 were used for 64bit peek and 64bit poke, but these syscalls are no longer setup.

Kernel Module Changes
In the middle level I added interfacing support to the nine new syscalls as well as a new ioctl to let user apps convert lpar addresses to real addresses and yet another to let user apps perform an ioremap on memory. I also fixed the syscall that executes code via a real memory address since previously it wasn’t saving the link register, which is not good.. Lastly I tracked down the problem I was having with calling ioctls from userland code. It turns out there are issues sending ioctls to a 64bit kernel from 32bit userland code. When you send the ioctl from your userland code there is a hidden function that attempts to “make it compatible” before sending it on to the kernel. This was transparently causing some ioctls to not make it to my kernel code. Things like this are why I hate linux hehe. It looked like fixing this was going to require a rebuild of sections of the kernel, so instead I brute force tried all ioctl numbers until I found a nice bunch that made it through ok and settled for using them instead. When sending these ioctls a handle to the XorHack device is used, so I am not too worried about them going astray and wreaking havoc.

User Library changes
Finally the on outermost level I added support for calling the new syscalls to read and write 8, 16, 32, or 64 bits at a time. In doing so I support unaligned addresses without the user having to check or worry about such things. If the address being accessed is aligned it will access it in a single syscall of the specified size. If the address is unaligned it will either use multiple syscalls or a syscall of a larger access size. I also added functions to easily check if the system has been exploited yet, to perform the lpar address to real address translation, io-remapping of addresses and to execute code at a given real address. A new header file xorhack_sc.h was added which contains translations between syscalls as they would be used in kernel mode and the userland interface. I have only done a few here, but it should be enough to follow the pattern and create translations for any other syscalls. If anyone does complete these translations, please send it to me to include in the next version of XorHack.

Sample Application Changes
As well as the above additions and changes to userland code I have added three new command line applications; ps3peek, ps3poke and ps3exec which allow reading, writing and executing of memory. The ps3peek and ps3poke tools work in a similar fashion. Both are able to perform 8bit, 16bit, 32bit and 64bit data accesses and can access multiple amounts of the data size in one call. The ps3peek tool can print data to screen as hex values and ascii characters similar to the display of a hex editor, or be printed as binary data and redirected into a file. The ps3poke tool does not print data to screen but can write data to memory from values passed on the command line or values read from a file.

Here are some examples of what these tools can be used for.

Dumping the hypervisor
This reads 0×10000000 bytes (16MB) of data starting at address zero using a data access size of 8 bytes (64bits) and prints it in binary form which gets redirected into the hvdump.bin file. Note that the 64bit access is used since it requires 8 times less syscalls to get the same amount of information as if we used the default 8bit access.

ps3peek 0 -s 0×1000000 -d 8 -b > hvdump.bin

Reading the status register for spu0
ps3peek 0×20000044024 -d 4

Loading metldr..
Scripts can be written using ps3peek, ps3poke and ps3exec and utilising files to store values between calls. By doing so many tasks can be done such as the setting of the required registers to load metldr.

Everyone loves pictures
The following is a picture taken with my dodgy G1 iPhone camera to show peek and poke in action. One day I will get a decent camera…

Seco escribió:buena pregunta

As some people in the comments called, it's an RCO file edit, just like RCO edits on the PSP(almost same format too). RCO files are resource files for VSH plugins, live in the dev_flash, and aren't signed. To edit them on your system, patch your hypervisor to allow encrypted access to the partition(flash on old systems, hd on new), and mod ps3pf_storage. dev_flash is just a FAT partition, mount it in Linux and change what you'd like.