177w ago - 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...
http://pastie.org/757313 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 :-)
I tried adding game_bg_overlay=0 to the config.bin file but that didn't work either. There used to be a view mode called "Game list (user backgro...
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:
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.
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
SPI line from cell to bridge needs to maintain it's tristatedness, pullup it breaks, pulldown it breaks
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...
I read http://bit.ly/70vySc (http://www.ibm.com/developerworks/power/library/pa-cellsecurity/#N100D4)
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?
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.
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.
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.
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
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!
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!
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.
(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!
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!