geohot on the PS3 ...

[crispie]

http://geohotps3.blogspot.com/

[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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

That's what I was thinking, too.

[jimparis]

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:

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.

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).

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]

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]

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]

How can you claim that the Slim is vulnerable to this when it doesn't have OtherOS?

[laichung]

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]

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]

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]

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]

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]

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?)

[jimparis]

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]

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]

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]

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.

[lotharx]

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]

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?