182w 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 :-)
152 Comments - Go to Forum Thread »
I really don't understand what he's trying to do... Could someone could explain it more basically?
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.