Увы и ах, но теперь этот блог закрыт. Geohot вышел из соревнования по взлому PS3. В моем ридере остались последние 17 записей с его блога о PS3. Вот они (от последнего к первому):
- OtherOS Supported on «3.21OO»
- Don’t Update
- Wait, you are removing a feature?
- Custom Themes?
- On the Isolated SPUs
- Here’s your silver platter
- A Level Playing Field
- What it is and what it isn’t
- I know some function names…
- Hello hypervisor, I’m geohot
- No ECC
- I don’t think…
- Messing with the Configuration Ring
- New Approach
- SPI hardware is done
- Cell SPI
- A Real Challenge
Here is a video demoing my «custom firmware». It’s not any sort of version string change; I would have added something showing off the new features of 3.21, but oh wait, there aren’t any.
This can be installed without having to open up your PS3, just by restoring a custom generated PUP file, but only from 3.15 or previous. It’s possible this CFW will also work on the slim to actually *enable* OtherOS; I’ll know when my infectus gets here.
No release date yet, use the proxy hack to play online with 3.15
Note to the people who removed OtherOS, you are potentially turning 100000+ legit users into «hackers.» There was a huge(20x) traffic spike to this blog after the announcement of 3.21. If I had ads on this site I guess I’d be thanking you
A note to people interested in the exploit and retaining OtherOS support, DO NOT UPDATE. When 3.21 comes out, I will look into a safe way of updating to retain OtherOS support, perhaps something like Hellcat’s Recovery Flasher. I never intended to touch CFW, but if that’s how you want to play…
Two things, some people seem to think CFW will enable some sort of piracy. It won’t. It’ll just be a custom version of 3.21 that doesn’t lose OtherOS support. Hacking isn’t about getting what you didn’t pay for, it’s about making sure you do get what you did.
And this is about more than this feature right now. It’s about whether these companies have the right to take away advertised features from a product you purchased. Imagine if an exploit were found in Safari on the iPhone, but instead of fixing it, Apple decides to pull web browsing altogether. Legally, they may be within their right to do so, but we have to show them it’s the wrong move for the future of the product and the company.
For now, it looks like proxying the query for new firmwares is working. My investigation into 3.21 has begun.
First off, I want to apologize to all the people who use Linux on their PS3. Before releasing, I weighed the pros and cons, and considered the possibility of an impact on OtherOS support. My logic was this. OtherOS support had already been removed from the Slim(not for technical reasons; I believe it only existed in the first place to promote the Cell for IBM) The builders had apparently no intention of including it in future products. So for the purposes of openness why not release? Not like anything else has(or probably will be) done on the PS3.
Now you go and remove a feature that people expected to be included with the expensive device they purchased, citing «security concerns». What security concerns? It’s not like the exploit can be run even close to without the users knowledge. You have to open the fucking thing up. How could this harm users? Your blog post doesn’t list positive reasons for upgrading like I think most users expect. Instead it lists things you will lose if you don’t upgrade. Seriously?
The PlayStation 3 is the only product I know that loses features throughout it’s life cycle. Software PS2 emulation, SACD playback, and OtherOS support are all just software switches you can flip. It’s unbelievable you would go and flip one, not just on new boxes you are shipping, but on tens of millions already in the field.
Again I’m sorry users. Sony, I expected more from you.
As some people in the comments called, it’s an RCO file edit, just like RCO edits on the PSP(almost same format too). RCO files are resource files for VSH plugins, live in the dev_flash, and aren’t signed. To edit them on your system, patch your hypervisor to allow encrypted access to the partition(flash on old systems, hd on new), and mod ps3pf_storage. dev_flash is just a FAT partition, mount it in Linux and change what you’d like
Today I verified my theories about running the isolated SPUs as crypto engines. I believe that defeats the last technical argument against the PS3 being hacked.
In OtherOS, all 7 SPUs are idle. You can command an SPU(which I’ll leave as an exercise to the reader) to load metldr, from that load the loader of your choice, and from that decrypt what you choose, everything from pkgs to selfs. Including those from future versions.
The PPU is higher on the control chain then the SPUs. Even if checks were to be added to, for example, verify the hypervisor before decrypting the kernel, with clever memory mappings you can hide your modified hypervisor.
Ah, but you still didn’t get the Cell root key. And I/we never will. But it doesn’t matter. For example, we don’t have either the iPhone or PSP «root key». But I don’t think anyone doubts the hackedness of those systems.
I wonder if any systems out there are actually secure?
In the interest of openness, I’ve decided to release the exploit. Hopefully, this will ignite the PS3 scene, and you will organize and figure out how to use this to do practical things, like the iPhone when jailbreaks were first released. I have a life to get back to and can’t keep working on this all day and night.
Please document your findings on the psDevWiki. They have been a great resource so far, and with the power this exploit gives, opens tons of new stuff to document. I’d like to see the missing HV calls filled in, nice memory maps, the boot chain better documented, and progress on a 3D GPU driver. And of course, the search for a software exploit.
This is the coveted PS3 exploit, gives full memory space access and therefore ring 0 access from OtherOS. Enjoy your hypervisor dumps. This is known to work with version 2.4.2 only, but I imagine it works on all current versions. Maybe later I’ll write up how it works
I’ve gotten confirmation the exploit works on 3.10. Also I’ve heard about compile issues on Fedora. I did this in Ubuntu. I think this qualifies as a nice tutorial at least for the software side 
This is a good article for what it means for the less technical. A good more technical writeup is here.
Good luck!
Right now, I’m playing with the isolated SPEs, trying to get metldr to load from OtherOS. Interesting thing, I am not using the exploit. I always assumed the enable isolation mode register was hypervisor privileged. It’s not, it’s kernel privileged, which means using hypervisor calls you can all get to it. So, get to hacking. Here is the code I am playing with.
I’m not that opposed to releasing the exploit, but I think the majority of you are going to be disappointed, even if you do get it working. Unless you have pushed the HV to it’s limits, this exploit really isn’t going to do much for you…yet. So install OtherOS and start playing around. If people start coming up with convincing reasons why they need the exploit to go further, I’ll release it. It’s just a waste to release if people can’t make use of it.
As far as the GPU goes, I have full access to the GPU memory space 0×2800… But without a driver, it’s useless. 3D video card drivers are notoriously hard to write, look at the ATI and NVIDIA ones for linux. The best are still the closed source manufacturer ones. I’m not even sure I believe that the HV restricts video card access, just that the OtherOS driver is 2D. If someone skilled in video card driver development comes forward, and they can explain in detail what the HV is restricting, I’ll send them the exploit.
And something has to be done about the comments. Theres a couple of good ones, mixed in with tons of trash. Please, if you don’t have something technical and useful to say, don’t say it. This is not the place for congratulations(go back to the hello hypervisor post), debates about piracy(go somewhere else, the internet is big), or trying to convince me to do X.
First off, this is not a release blog like «On The iPhone«. If you are expecting some tool to be released from this blog like blackra1n, stop reading now. If you have a slim and are complaining this hack won’t work for you, stop reading now. WE DO NOT CONDONE PIRACY, NOR WILL WE EVER. If you are looking for piracy, stop reading now. If you want to see the direction in which I will take this blog, read the early entries in the iPhone one. Information on this blog is for research purposes only.
That aside, I’ll tell you what I have so far. I have added two hypercalls, lv1_peek and lv1_poke. peek reads memory in real space(including all the MMIO), poke writes it. I can also add other arbitrary hypercalls as I see fit.
The hypervisor is complicated, it is written in C++ and is PPC, which I am not that familiar with yet. At first I was trying to add a hypercall to add arbitrary real memory to the LPAR, but it kept crashing(because I can’t code), which is really annoying, because I have to wait while Linux reboots.
Some people pointed out that I have not accessed the isolated SPEs. This is true. Although as far as doing anything with the system, it doesn’t matter. The PPE can’t read the isolated data, but it can kick the isolated SPEs out. Decrypt the PPE binary you need using the intact SPE and save the decrypted version. Kick out the SPE, and patch the decrypted version all you want. And interesting note, by the time you get to OtherOS, all 7 working SPEs are stopped.
Despite this, I am working on the isolated SPEs now(which I can now load), because what I’d really like to do is post decryption keys here so you guys can join the fun.
And now if calls have restrictions I don’t like, I zap them
I have read/write access to the entire system memory, and HV level access to the processor. In other words, I have hacked the PS3. The rest is just software. And reversing. I have a lot of reversing ahead of me, as I now have dumps of LV0 and LV1. I’ve also dumped the NAND without removing it or a modchip.
3 years, 2 months, 11 days…thats a pretty secure system
Took 5 weeks, 3 in Boston, 2 here, very simple hardware cleverly applied, and some not so simple software.
Shout out to George Kharrat from iPhoneMod Brasil for giving me this PS3 a year and a half ago to hack. Sorry it took me so long
As far as the exploit goes, I’m not revealing it yet. The theory isn’t really patchable, but they can make implementations much harder. Also, for obvious reasons I can’t post dumps. I’m hoping to find the decryption keys and post them, but they may be embedded in hardware. Hopefully keys are setup like the iPhone’s KBAG.
A lot more to come…follow @geohot on twitter
Just cause I can’t read the ram bus doesn’t mean I can’t mess with it.
…glitching the memory bus like a savage with a screwdriver is going to work.
Tomorrow, I’ll try a real attack.
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. 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 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.
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 = 0×28000000000(3 bytes in, 4 bytes out)
IOIF1 = SC = 0×24000000000(1 byte in, 1 byte out)
MMIO in cell = 0×20000500000
CELL ROM = 0×100(from datasheet, not seen in PS3)
XDR RAM = 0x0ish-0×10000000
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.
Spent today rigging this up. Soldered to the bridge side of the SPI and the Cell side of the SPI. Cut the traces. The FPGA passes through the pins while the switch is on. So I power up the system with the switch on, chip gets configured, then turn the switch off to connect the Cell SPI to my USB parallel adapter. Now it’s just a matter of the PC side SPI software and figuring out a way to use the myriad LV1 registers available to me to map the hypervisor.
**Update**
MMIO over SPI doesn’t appear to work
I have control over the BIC(Bus Interface Controller) through the FlexIO interface though. Now I just have to figure out what these things are.
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.
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
Discussion