PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

December 26, 2009 // 6:22 pm - This weekend GeoHot, the hacker responsible for several Apple iPhone hacks, has returned to Sony PS3 hacking after his initial announcement a few months back and has opened a PS3 hacks blog (linked above).

He recently made this Tweet:

"I just pulled everything from the USB bus... the Cell processor SPI bus, PS3 is going down :-)"

These are the latest posts on his new PS3 hacks blog:

Cell SPI

The Cell processor has an SPI port which is used to configure the chip on startup. Well documented here. It also allows hypervisor level MMIO registers to be accessed. In the PS3, the south bridge sets up the cell, and the traces connecting them are on the bottom layer of the board. Cut them and stick an FPGA between.

Quick theoretical attack. Set an SPU's user memory region to overlap with the current HTAB. Change the HTAB to allow read/write to the hypervisor! If that works it's full compromise of the PPU.

A Real Challenge

The PS3 has been on the market for over three years now, and it is yet to be hacked. It's time for that to change.

I spent three weeks in Boston working software only, but now I'm home and have hardware. My end goal is to enable unsigned code execution, making every unit into a test and opening up a third party development community, either through software or hardware (with a mod chip). The PS3 is a prime example of how security should be done, very open docs wise, and the thing even runs Linux. But it isn't unbreakable :-)

GeoHot Resumes Sony PS3 Hacking, Opens PS3 Hacks Blog

PlayStation Follow us on Twitter, Facebook and join us at our new site WWW.PSXHAX.COM!

#122 - Raze1988 - January 18, 2010 // 2:21 am
Raze1988's Avatar
What exactly does one gain from such dumps?

#121 - PS4 News - January 18, 2010 // 2:07 am
PS4 News's Avatar
Here is the next GeoHot update:
Messing with the Configuration Ring

Tried changing different values in the configuration ring. No good results.

The start vector doesn't matter, I can corrupt it and the system still boots fine. So somehow it's bypassing it, and is probably running the first stage loader in ROM. Therefore it's never on the bus. :-(

Changing almost anything else puts the system in Wait State, bit 20 of POR Status is high, and POR never completes. I was hoping to cleverly move some MMIO around to be able to access something I shouldn't, and strap up to an HTAB write. But change just about anything and the system doesn't boot. And the just about doesn't make me think I'm missing something obvious like a checksum. :-(

The SPI stuff is all documented here ($file/CellBE_HIG_65nm_v1.01_8Jun2007.pdf). Maybe someone has an idea about what to try. The only SPI MMIO accesses that work are the FlexIO ones, otherwise everything seems to match this document.

Here (below) is a dump of the raw config data and it's parsing.

Looks like I might have to take this up a notch, like glitching the RAM bus to enter a corrupt HTAB entry or something. Although for all I know they read back. Logic analyzer on the RAM XDR bus? That's gotta be a decrypted hypervisor. Or glitching the address pins? I hate these stupid fast buses, reasonable buses make cell phones nice.

[Register or Login to view code]

George Hotz said...
I have the alignment right, I have a little parser and changer.

SPE3 is disabled on mine, but you can't reenable it because it's hardware disabled as well (bit is ignored in config, figure out by reading partial_good). You can disable the others though, SPE2 is the one it needs to run the isolated code on.

George Hotz said...
Hehe, I wish I had something that could sniff the XDR... gotta be clever with a cheap FPGA if I want to do it... but for now back to football.

[quote]Mathieulh said...
I did give suggestions I told him that his approach is the wrong one (mostly one of the worst possible approach you would take in hacking the device). I did so ages ago as well (when he first announced to start working on the ps3) and I wasn't the only one to do so. Yet he chose to ignore and persist on his path, that's his choice, it doesn't make it less pointless and ineffective though.

I am sorry to bring this in but geohot right now makes me feel like if he is trying things while not understanding what he actually is doing, especially without reading prior documentation before his attempts. You want to know what the playstation 3 security is all about ? Don't ask me, read the publicly available IBM docs, then start investigating (though documenting is already a part of it to begin with)

Here you go a little help from Mr IBM for you:

#120 - xUb3rn00dlEx - January 17, 2010 // 2:31 am
xUb3rn00dlEx's Avatar
Thank you for clearing that up for me. I understand what you said about how people would think of it that way. I don't see him as trying to shut him down at all. I view it as more of a "Ductape doesn't fix dead people" approach. I think he's just trying to guide geo past what has been prodded before, so that more time is devoted elsewhere instead. (possibly where it matters a lot more )

However, I do believe that this "teaming up" if you can barely call it that is good, because you now have someone (plural where appropriate) who has studied the workings of the system, and someone who wants to poke and mess with it. This gives a much more "successful" approach if you will, because now the devs can be sort of like the "eyes" and geo will be the "hands."

I hope I'm making sense and not sounding too much a fool. Anyways I will be checking this page regularly for more progress between the two of them. Thank you for the update again.

#119 - SCE - January 16, 2010 // 11:55 pm
SCE's Avatar
New comments on the topic from Geohot:

George Hotz said...
Nice comments, except for the blackberry hack one. Yea, all bluray hacks are off the table, couldn't care less about people playing "backup" games. Didn't know libisolation existed, in fact, none of the cell datasheets seem to mention it. Nice find. I'm working on 2.80 right now, but if I find anything right now it'll be at the lowest hardware level. Definitely be nice to have a Cell Blade, but at $10,000ish thats out of my price range for this. And your magnetic scanning/manipulation device would be amazing, I have another project where I'd pay tons for access to that machine.

As far as legal issues go, we all have to root for the jailbreaking DMCA exception.

George Hotz said...
Cool, SPU2 is the isolated one

George Hotz said...
Nah, iPhone security is a joke compared to this. Just a basic boot chain with easy to dump ROMs. It's also very helpful that Apple rolled out the security in stages, giving us all time to learn. Theres nothing new in the ipt3, they just switched to nand flash, and the nand boot path doesn't have the exploit.

If I had dumps of everything on the PS3, this would be so much easier.

SPE has to be internally locked down, theres probably a dma_copy_lock_and_start function which is just "calls" to hardware.

Anony said...

IBM have published some info on how the security works (and some high level detail on libisolation):$file/CBE_Secure_SDK_Guide_v3.0.pdf

This may be of use to you, but if additional docs are included in the CDA version of the security SDK I'd say its information would probably contain more useful stuff. This document is a good primer none the less.

#118 - chipsy - January 16, 2010 // 8:11 am
chipsy's Avatar
I hope that he achieves something, because he has great potential with his skills, I know he can do it, he has my full support, I will be the first to donate but he must also come out with an untethered jailbreak for Ipod touch 3g

#117 - PS4 News - January 16, 2010 // 6:35 am
PS4 News's Avatar
Quote Originally Posted by semitope View Post
Mathieulh isn't offering much guidance beyond trying to shut him down. Basically it's don't bother trying it because I don't think it's likely to work.

I can see how people would think this, but when you devote countless hours like he has to learning the PS3's innerworkings most of what he says, even if not tested by himself, is done with merit.

In layman's terms, Mathieulh is "keeping it real" so that the overanxious people don't place a false sense of hope in something that is potentially leading to another dead end. It's nice to keep the faith (we all are for GeoHot!) but he is just trying to save GeoHot a little time along the way without obviously revealing too much... which I'm sure GeoHot appreciates as he will probably be resuming classes like CJPC in the next few weeks.

That said, below is a condensed summary of GeoHot's and Mathieulh's dialogue thus far from his blog and Twitter updates:
New Approach

The MMIO over SPI stuff doesn't appear to work, probably an efuse to disable it since the System Controller(or the bridge as I was calling it) doesn't need to use any of them.

A quick memory map:
IOIF0 = GPU = 0x28000000000(3 bytes in, 4 bytes out)
IOIF1 = SC = 0x24000000000(1 byte in, 1 byte out)
MMIO in cell = 0x20000500000
CELL ROM = 0x100(from datasheet, not seen in PS3)
XDR RAM = 0x0ish-0x10000000

On power up, the system controller downloads the configuration ring over SPI and calibrates the IOIF1 interface using the FlexIO registers. Then, according to the config ring, the reset vector is 0x2401FC00000, an address in the mapped System Controller memory. So the LV0 is sent(I can't imagine encrypted) over the FlexIO between the SC and the CELL.

So, how about this attack? Find some way to keep something resident somewhere in the memory space across powerups(does XDR go away? liquid nitrogen?). Move the reset vector there and write a little program to dump 0x2401FC00000 and somehow leak it to the outside world. Or sniff the FlexIO bus, any ideas?

I already know more about the Cell processor then I ever wanted to.

George Hotz said...
Crap, XDR isn't configured yet. All I have is the FlexIO to the SC. And at first when I put a scope on the FlexIO lines I thought there was no data...there is, it just looks a lot like noise

George Hotz said...
SPI line from cell to bridge needs to maintain it's tristatedness, pullup it breaks, pulldown it breaks

Mathieulh said...
Geohot have you ever heared of the cell's secure boot feature which relies on Hardware Root of Secrecy (basically using the stored hardware root key to decrypt the bootloader sent to the cpu) ?

If you didn't perhaps you should document yourself because this is precisely what the cell is using. This makes the argument of lv0 sent decrypted kinda void don't you think ?

(Yes the cell is designed around a security architecture, and it wont run plain untrusted boot code if it hasn't been setup to. (if a hardware root key is set, it will require an encrypted bootloader which only then will be assumed as trusted)

There is no point in trying things without having further knowledge of the system and the way it works. The plain boot code never leaves the isolated spu, that's how it works. Good luck sniffing any busses for it...

George Hotz said...
I read (

Even the most complicated systems I've seen don't have actual hardware security, the security is done in a bootrom somewhere. So where is that bootrom? For security, it would have to be in the cell itself. But then why is the start vector 0x2401FC00000 on IOIF1 and the start vector lock bit not set?

Some piece of code copies the boot code to the SPU, and does the signature verification(decryption is probably done using AES DMA). Then the SPU is isolated and unreadable.

If that code were in Cell ROM, like I imagined it to be, thats a secure system. But then why is the start vector in the System Controller and not Cell ROM?

Has the FlexIO between the System Controller and CELL been sniffed at the very beginning of startup?

George Hotz said...
Actually I think I made a mistake calling it LV0. If LV0 is the code that runs on the SPE, I agree it never exists anywhere decrypted but the SPE LS. The code I believe may exist runs before LV0 and loads it.

Mathieulh said...
Well of course the cell most likely has a rom as well as fuses programmed at factory to set the hardware root key on it.

I assume the rom is somewhere inside the cpu die and most likely cannot be dumped by software means, its sole purpose would be to authenticate the bootloader IF a hardware root key is set (the Cell IS after all an off the shelves cpu (though still designed for security)). I assume the cpu still has to be fed with the encrypted bootrom in order to decrypt/authenticate it, load it to the isolated spu and jump to it.

There are various IBM documentations regarding the cell's security architecture which is pretty much what the playstation 3 is using.

To be honest trying to sniff busses to dump the XDR will only lead you (if you ever even manage to match the bus speed with proper equipments) to dump the lv2 (or parts of it) and that's if you are lucky.

Of course feel free to try but I do not think you can hack into the ps3 from the hardware side except through decapping or cpu glitching or other fancy things.

George Hotz said...
Ext clock is nice, but I don't have anything that can latch at 400Mhz DDR, never mind wiring it up without impedance/wire length issues.

Obviously the chip has an MSR, but you can't give yourself HV privileges like that. Can only lower privileges.

GPU vector isn't in my version, and still doesn't bypass the IOMMU.

Tried every DMA attack I could think of last time, not happening.

And debug logic is 95% chance a waste of time, common e-fuse to add.

George Hotz said...
cool, the PS3 reset vector isn't locked down to ROM, it's 0x2401FC00000 in the system controller, $10,000 logic analyzer anyone? bunnie?
about 11 hours ago from web

Mathieulh said...
It's already possible to run code from otheros though (at least in older boxes) and contrary to popular beliefs, otheros isn't crippled, it just greatly lacks optimizations (which I think would still be easier to provide than hacking the ps3 itself) though I must confess that the challenge is appealing.

So, that is where it stands... as he posts more updates feel free to add them here as usual!

#116 - semitope - January 16, 2010 // 6:06 am
semitope's Avatar
Mathieulh isn't offering much guidance beyond trying to shut him down. Basically it's don't bother trying it because I don't think it's likely to work.

#115 - PS4 News - January 16, 2010 // 3:10 am
PS4 News's Avatar
Quote Originally Posted by xUb3rn00dlEx View Post
I'm just wondering have any of the devs already developed the same ideas as he is coming up with and have they attempted to exploit them already?

The Devs have invested more time delving into Sony's resources and learning how everything works to better-familiarize themselves with the system... GeoHot is taking a more "hands-on" approach, which is GREAT as he has the hardware and skills, but the general consensus with the Devs is they don't spend their time (or money) on things that prove improbable through research.

That being said, there is always the chance GeoHot will find something useful through his more direct methods, and if he does every one of the Devs will give him a BIG "congratulations" so it's good he goes against the "norm" way of thinking!
Quote Originally Posted by xUb3rn00dlEx View Post
Also, any news on the increase/decrease of cooperation between the dev team and geo?)

GeoHot hasn't been in touch directly at all in recent months, however, currently Mathieulh is offering him a little guidance through his blog comments. I will spend time extracting and posting it here a little later tonight so that it's viewable in a single, organized post.

#114 - xUb3rn00dlEx - January 16, 2010 // 1:08 am
xUb3rn00dlEx's Avatar
Just a question to the devs out there. Geo seems to have a lot of theoretical approaches to this (beautiful imho since I'm planning on going into theoretical physics) but I'm just wondering have any of the devs already developed the same ideas as he is coming up with and have they attempted to exploit them already? (I'm thinking yeah, and gotten nowhere.) I know the information is private, but a simple yes or no will do, or if unavailable, classified

(I just want to figure out whether or not this could possibly be a waste [ meaning that it's already been explored ] of time and different/ new approaches should be mapped. Also, any news on the increase/decrease of cooperation between the dev team and geo?)

Thanks and good luck guys!

#113 - CJPC - January 16, 2010 // 12:22 am
CJPC's Avatar
Generally speaking - hope he gets somewhere, but alas he won't.

I mean, the buses on the system are well - very fast. Furthermore, from the ground up the system was designed to be secure, they are not going to allow say "0 vs 1" to be sent across the config bus to just magically hack the box.

Do I wish it's that easy? Of course! Will it be - sadly no!