geohot on the PS3 ...

Technical discussion on the newly released and hard to find PS3.

Moderators: cheriff, emoon

crispie
Posts: 4
Joined: Sun Feb 29, 2004 3:01 am

geohot on the PS3 ...

Post by crispie »

androvsky
Posts: 33
Joined: Sun Nov 11, 2007 5:59 am

Post by androvsky »

I've been following this. Some of his assumptions contradict what little I recall of Cell security, but I could easily be wrong.

I'm guessing he's reading and writing memory from an external FPGA wired into the memory bus... assuming that's possible. But he's assuming that by playing with hypervisor calls he can somehow shut down the isolated SPU from the PPC and then run unsigned code. Seems unlikely to me.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

He says the hardware is simple, so I doubt he's directly reading/writing the XDR (at an effective 3.2GHz clock, a Spartan-3 probably couldn't do that anyway). I imagine it's some simpler glitching he's doing -- for example, just overwriting a particular bit while watching the initial configuration over the SPI bus, or similar. Still, I can't imagine that the Cell security would fall to something like changing RAM contents. Although Sony has made worse mistakes, so who knows.

It's been discussed here before, but I think a big reason the PS3 hasn't been hacked earlier is not only because of the increased security of the system, but also because Sony already gave us a large portion of the access we wanted through the OtherOS facility. But now that OtherOS is gone in new models, George Hotz is claiming success, and techniques for HD decryption are now public, it sounds like this might start to change...
TyRaNiD
Posts: 907
Joined: Sun Jan 18, 2004 12:23 am

Post by TyRaNiD »

Of course if Sony have done their job correctly then breaking into the HV in otheros mode gives you little, but no doubt they haven't done their job ;)
IronPeter
Posts: 207
Joined: Mon Aug 06, 2007 12:46 am
Contact:

Post by IronPeter »

It is "hv call table" from geohot:

http://2.bp.blogspot.com/_NJ4JFBfr1tY/S ... vcalls.PNG

compare with

http://wiki.ps2dev.org/ps3:hypervisor

The only difference i can note - many hv calls are copies of lv1_allocate_memory (it is new fact and can be easily checked). No other new info.

Is it possible to find names like "lv1_undocumented_function_xx" or "invalid_hypercall" in the debug info? Symbols must be stripped from lv0 code.

I am not sure, is that table handcrafted or actually taken from debug info.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

The lv1_mm_calls aren't identical. For example 0=lv1_allocate_memory and 6=lv1_query_logical_partition_address_region_info, but they're both lv1_mm_call in geohot's image.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

Also
  • 135, 136, 231 are "lv1_mm_call" in PNG and "undocumented" on wiki, maybe they're interesting
  • 233 is "undocumented" in PNG and not listed in wiki
otherwise they match up, in some cases the wiki has functions named where the PNG does not.
KriS
Posts: 6
Joined: Fri Nov 13, 2009 8:12 pm
Contact:

Post by KriS »

androvsky wrote:I've been following this. Some of his assumptions contradict what little I recall of Cell security, but I could easily be wrong.

I'm guessing he's reading and writing memory from an external FPGA wired into the memory bus... assuming that's possible. But he's assuming that by playing with hypervisor calls he can somehow shut down the isolated SPU from the PPC and then run unsigned code. Seems unlikely to me.
There is a doc about security on IBM site. It looks like that accessing lvl0 doesn't help too much if you want to run unsigned code. Most of the interesting stuff is done on hardware without any software access. On the other hand accessing RSX from OtherOS would be a nice feature :).
IronPeter
Posts: 207
Joined: Mon Aug 06, 2007 12:46 am
Contact:

Post by IronPeter »

Hmm... yes, really.

Probably, lv1_mm == lv1_memory_management?

Does hypercall know about its index in the interrupt table? Can that table contain one pointer many times?

If no, that picture is just blue-white-black paintwork.
KriS
Posts: 6
Joined: Fri Nov 13, 2009 8:12 pm
Contact:

Post by KriS »

More info about Geohot and PS3 on BBC news.

"In particular, he said, he would publish details of the console's "root key", a master code that once known would make it easier for others to decipher and hack other security features on the console."
semitope
Posts: 1
Joined: Wed Jan 27, 2010 12:04 am

Post by semitope »

Doubting what a hacker can do based on reading about the system is so funny. Unless you have hardware on your ps3 and are digging into it as well I don't think you really can comment on what he can or can't do. All you have is a theory of how it is supposed to work.

Someone on http://forum.beyond3d.com/showthread.php?t=56284&page=5 linked to this forum. Glad to see that there isn't the crazy misinterpretation of what Geohot says as there is in there.

When he says the spus are stopped he meant they were idle, not disabled. If he says he can kick a SPU, I am going to have to believe he can. He also posted those calls because he was showing he got them from the system itself which I doubt is what was initially done. Its basically like saying "this is how someone drives" vs seeing someone driving while in the car and documenting what they do
allanl1234
Posts: 4
Joined: Mon Dec 28, 2009 1:32 am

Post by allanl1234 »

Interestingly, this is Geohots comment on accessing the RSX from OtherOS:
"And actually, the RSX being restricted is just theory as far as I know. OtherOS under the hypervisor may have the access required to write a 3D driver, just no one wrote one."
Arwin
Posts: 426
Joined: Tue Jul 12, 2005 7:00 pm

Post by Arwin »

allanl1234 wrote:Interestingly, this is Geohots comment on accessing the RSX from OtherOS:
"And actually, the RSX being restricted is just theory as far as I know. OtherOS under the hypervisor may have the access required to write a 3D driver, just no one wrote one."
Hmm, that doesn't seem right. Remember FW 2.1?
allanl1234
Posts: 4
Joined: Mon Dec 28, 2009 1:32 am

Post by allanl1234 »

That's what I was thinking, too.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

allanl1234 wrote:Interestingly, this is Geohots comment on accessing the RSX from OtherOS:
"And actually, the RSX being restricted is just theory as far as I know. OtherOS under the hypervisor may have the access required to write a 3D driver, just no one wrote one."
Yes, that's what we've been saying all along:
http://forums.ps2dev.org/viewtopic.php?p=62306#62306 wrote:What it appears to have blocked is the lv1_gpu_memory_alloc(0) trick (it returns an error now) that unintentially allowed GPU DMA access to the RAMIN which was used to set up new 3D contexts and stuff. There's probably a hypervisor call that does that instead, it just hasn't been found.
http://forums.ps2dev.org/viewtopic.php?p=62560#62560 wrote:As IronPeter has said, it is very likely that there exists an undocumented hypervisor call which creates the classes we need for accelerated graphics. We just need to find that (and any help in doing so would be much appreciated).
http://forums.ps2dev.org/viewtopic.php?p=63160#63160 wrote:Sony has 'blocked' access to the RSX from the beginning by not providing a hardware driver or documentation on the RSX, and hiding it behind the hypervisor. That didn't stop people from finding a way around it. I don't think Sony is still actively trying to break RSX on Linux because it is not a real threat. People are looking at the HV calls because it is assumed that there are undocumented calls for setting up the GPU, so people with post-2.01 firmwares can get RSX access back.
Nothing new in that theory!
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

semitope wrote:Doubting what a hacker can do based on reading about the system is so funny.
Many developers here have done more than just "read about" the system. But even just with the literature, we can have a pretty good idea of what he can do.

He's glitched something either on the FlexIO bus, during SPI configuration, or similar, so that he has full read/write access to memory from within OtherOS (lv2). He can therefore dump and modify the hypervisor (lv1) and its loader (lv0), which certainly is useful for Linux development (e.g. it may let us find the undocumented magic for gaining access to the RSX). But you have to remember that the Cell was designed with read-write access to main memory being a known attack vector. If that security was implemented as described, he likely cannot get access to any of the encryption keys that would be necessary to decrypt the GameOS firmware or anything else that would allow hacks on the rest of the system. The ability to "kick out the isolated SPU" doesn't really affect that.
lotharx
Posts: 24
Joined: Wed Jul 16, 2008 2:55 pm

Post by lotharx »

He did it by flooding htab then sending a call after a simple hardware glitch, he published everything. He made a peek and poke for real addresses too including the supervisor LPAR.

Devs here I know can't use it because it isn't what Sony gave them(no "clean room"). It doesn't violate DMCA or EULA though..

Slim is also vulnerable to this by the way you just have to do it on bus with complex circuitry because of RF.

Here is the code part http://pastie.org/796066
Warren
Posts: 175
Joined: Sat Jan 24, 2004 8:26 am
Location: San Diego, CA

Post by Warren »

How can you claim that the Slim is vulnerable to this when it doesn't have OtherOS?
laichung
Posts: 123
Joined: Fri May 06, 2005 2:02 pm

Post by laichung »

Warren wrote:How can you claim that the Slim is vulnerable to this when it doesn't have OtherOS?
Half right, half wrong.

Because OtherOS just give you a platform to "Run a Code" (or the right term is, inject some code on the memory space).

But the exploit is based on the hole of non-ECC RAM.

So of course someone can build a hardware to inject those code to the memory space without OtherOS.

Yes, right now you still need a hole at XMB so that you can "Run Code" on slim.
lotharx
Posts: 24
Joined: Wed Jul 16, 2008 2:55 pm

Post by lotharx »

Warren wrote:How can you claim that the Slim is vulnerable to this when it doesn't have OtherOS?
Cause it has an identical interface on the RAM bus. Glitching RAM also dates back to the 80s so it's not a cutting edge reversing technique. It's been used a lot in paytv systems to get dumps when there was encryption and no debug interface, and then later injection or sim flashing.

The Slim 45nm CELL has the same instruction sets and PPC architecture too.

This wont be easy to prove though because of manufacturing or even POC boundaries mainly dealing with RF leakage and parity handling. He couldn't even do it with a $10k Spartan board and his finances.

This will be my last post, I just wanted to say. I personally don't see anything coming from his work besides criticism.
laichung
Posts: 123
Joined: Fri May 06, 2005 2:02 pm

Post by laichung »

jimparis wrote:
semitope wrote:Doubting what a hacker can do based on reading about the system is so funny.
Many developers here have done more than just "read about" the system. But even just with the literature, we can have a pretty good idea of what he can do.

He's glitched something either on the FlexIO bus, during SPI configuration, or similar, so that he has full read/write access to memory from within OtherOS (lv2). He can therefore dump and modify the hypervisor (lv1) and its loader (lv0), which certainly is useful for Linux development (e.g. it may let us find the undocumented magic for gaining access to the RSX). But you have to remember that the Cell was designed with read-write access to main memory being a known attack vector. If that security was implemented as described, he likely cannot get access to any of the encryption keys that would be necessary to decrypt the GameOS firmware or anything else that would allow hacks on the rest of the system. The ability to "kick out the isolated SPU" doesn't really affect that.
I wonder, is the XMB/GameOS run under lv0/lv1/lv2?
ouasse
Posts: 80
Joined: Mon Jul 30, 2007 5:58 am
Location: Paris, France

Post by ouasse »

Geohot released his exploit. It needs some hw tweak such as a pic for now. As the instructions say:
Usage Instructions:

Compile and run the kernel module.

When the "PRESS THE BUTTON IN THE MIDDLE OF THIS" comes on, pulse the line circled in the picture low for ~40ns.
Try this multiple times, I rigged an FPGA button to send the pulse.
Sometimes it kernel panics, sometimes it lv1 panics, but sometimes you get the exploit!!
If the module exits, you are now exploited.

This adds two new HV calls,
u64 lv1_peek(16)(u64 address)
void lv1_poke(20)(u64 address, u64 data)
which allow any access to real memory.

The PS3 is hacked, its your job to figure out something useful to do with it.
ssidx
Posts: 1
Joined: Wed Jan 27, 2010 5:42 pm

Post by ssidx »

So, with this exploit, you can alter data from GAMEOS in run-time? Outputting 'Hello world' in GAMEOS, for example. Or do you require a software exploit for that?
cheriff
Regular
Posts: 258
Joined: Wed Jun 23, 2004 5:35 pm
Location: Sydney.au

Post by cheriff »

ssidx wrote:So, with this exploit, you can alter data from GAMEOS in run-time? Outputting 'Hello world' in GAMEOS, for example. Or do you require a software exploit for that?
No, as quoted in the post above yours:
This adds two new HV calls,
u64 lv1_peek(16)(u64 address)
void lv1_poke(20)(u64 address, u64 data)
So two new hypercalls you may make from OtherOS. Thats it (for now?)
Damn, I need a decent signature!
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

laichung wrote:I wonder, is the XMB/GameOS run under lv0/lv1/lv2?
Gameos is lv2 just like otheros. The processor is capable of running multiple LPARs at once, so you could theoretically run gameos and otheros together, although the hypervisor doesn't allow that for simple resource reasons.
ps2devman
Posts: 259
Joined: Mon Oct 09, 2006 3:56 pm

Post by ps2devman »

George Hotz now points to an 'explanations' article

http://rdist.root.org/2010/01/27/how-th ... as-hacked/

He even commented it with its own photograph (for sure he's young!)
jonwil
Posts: 18
Joined: Mon Nov 12, 2007 8:57 pm

Post by jonwil »

Now that we can dump the hypervisor and reverse engineer it, does that mean we can search the undocumented HV calls for the (rumored to exist) GPU setup calls we need for full GPU access?
cheriff
Regular
Posts: 258
Joined: Wed Jun 23, 2004 5:35 pm
Location: Sydney.au

Post by cheriff »

jonwil wrote:Now that we can dump the hypervisor and reverse engineer it, does that mean we can search the undocumented HV calls for the (rumored to exist) GPU setup calls we need for full GPU access?
Yep.

Failing actually finding one undocumented just sitting there (which would be ideal as once learned, anyone can use it), someone with the hack could just as easily patch the page-table and give themselves access and start work on a driver through that.
Damn, I need a decent signature!
lotharx
Posts: 24
Joined: Wed Jul 16, 2008 2:55 pm

Post by lotharx »

cheriff wrote:
jonwil wrote:Now that we can dump the hypervisor and reverse engineer it, does that mean we can search the undocumented HV calls for the (rumored to exist) GPU setup calls we need for full GPU access?
Yep.

Failing actually finding one undocumented just sitting there (which would be ideal as once learned, anyone can use it), someone with the hack could just as easily patch the page-table and give themselves access and start work on a driver through that.
According to people outside of this community it has been unlocked the whole time. People here just wanted to port existing drivers to it, and it's too indifferent. I'm sure some people here will argue with that, but the people who stated that made more progress in a night than the people here did in years..literally. I'm sure Ironpeter and that mc person are good programmers though. The PS3 isn't just another PPC platform though..

As they stated in the push buffer thread they wont use reverse engineering to do it anyway. It's not compliant with the Bob Johnson company programmer standards XD
TyRaNiD
Posts: 907
Joined: Sun Jan 18, 2004 12:23 am

Post by TyRaNiD »

So if the geniuses outside "this" community knew about it the whole time then where is my accelerated graphics? After all it is easy to say that something exists but I have never seen any proof that anyone else has giving out any information on how to use it.

And I don't think people here just wanted to port existing drivers to it, but why not if something is sufficiently similar why would you not do so. Like most NVidia hardware (well perhaps worse than usual) hardware level documentation is sketchy at best and consists in many cases of either NDA'ed information (which cannot be used in public/free sources) or reverse engineered information which has a habit of being sometime inconsistent. Coupled with the general lack of interest in "hacking" the PS3 in the wider community obviously no-one cared enough to do deep, time consuming work in this field. But I guess people here obviously are crap. So what is it you have done again?
Post Reply