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

January 26, 2010 // 7:06 pm - As a BIG follow-up to his Sample PS3 Linux Isolated SPU Loader Code, GeoHot has now released his coveted PS3 hack so end-users can exploit their non-Slim PlayStation 3 Entertainment System!

Essentially what it does is modify the PS3's hypervisor adding two calls for reading/writing to all of the system memory.

To quote: "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 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.

Good luck!"

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.

How it works:

geohot: well actually it's pretty simple
geohot: i allocate a piece of memory
geohot: using map_htab and write_htab, you can figure out the real address of the memory
geohot: which is a big win, and something the hv shouldn't allow
geohot: i fill the htab with tons of entries pointing to that piece of memory
geohot: and since i allocated it, i can map it read/write
geohot: then, i deallocate the memory
geohot: all those entries are set to invalid
geohot: well while it's setting entries invalid, i glitch the memory control bus
geohot: the cache writeback misses the memory
geohot: and i have entries allowing r/w to a piece of memory the hypervisor thinks is deallocated
geohot: then i create a virtual segment with the htab overlapping that piece of memory i have
geohot: write an entry into the virtual segment htab allowing r/w to the main segment htab
geohot: switch to virtual segment
geohot: write to main segment htab a r/w mapping of itself
geohot: switch back
geohot: PWNED
geohot: and would work if memory were encrypted or had ECC
geohot: the way i actually glitch the memory bus is really funny
geohot: i have a button on my FPGA board
geohot: that pulses low for 40ns
geohot: i set up the htab with the tons of entries
geohot: and spam press the button
geohot: right after i send the deallocate call

On the Isolated SPUs

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?

GeoHot Releases PS3 Hack, Exploit Your System and Enjoy!

Follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 CFW forums for the latest PlayStation 3 scene and PS4 Hacks & JailBreak updates with PlayStation 4 homebrew.

#289 - HeyManHRU - July 12, 2012 // 5:08 am
HeyManHRU's Avatar
Ha, I'm surprised this thread hasn't been closed yet. Anyway please don't bump old threads unless there is new news or you want some help with something, thanks

#288 - elser1 - July 12, 2012 // 4:31 am
elser1's Avatar

#287 - dyceast - July 12, 2012 // 4:17 am
dyceast's Avatar
I guess pinoytechno wanted to finally let out his thanks to Geohot, even though he left the scene along time ago

#286 - elser1 - July 12, 2012 // 4:03 am
elser1's Avatar
this is way old news. its not really relevant anymore. big thanks to geohot tho for doing what he did.. if only he was still going hard and releasing all he knows to us end users.

#285 - tigereye - July 12, 2012 // 3:13 am
tigereye's Avatar
Let the games begin!

#284 - pinoytechno - July 12, 2012 // 1:41 am
pinoytechno's Avatar
geohot thanks

#283 - androvsky - February 14, 2010 // 7:21 pm
androvsky's Avatar
Quote Originally Posted by Raze1988 View Post
Well, he DID say "Where my homebrew at?". So he basically says it's now possible for him to run unsigned code.

Too bad he'll not work on any homebrew

If I'm reading it right, geohotz is saying it's now possible for him to run unsigned code... in OtherOS. Where it's already possible to run unsigned code. There's a slight possibility of decrypting, patching, and running parts of signed code, but since I doubt GameOS can be run on top of OtherOS, I'm not sure how much previously signed code can run without the correct OS.

Yeah, the PS3 has had homebrew for years, no one bothered. Not having RSX access shouldn't have been that big a detriment, but apparently everyone would rather hack the system than simply use the existing Cell-accelerated 2D SDL libraries IBM provided last year. It's not like we need 3D for most of the stuff people are asking for (XBMC, 90% of emulators). And if you really want 3D, I'm sure Mesa would gladly take any offered patches to their current Cell-accelerated OpenGL driver.

My point is I wonder how many people actually want homebrew. Yes, Slim owners are out of luck with OtherOS, but people that really care about homebrew can still pick up the older systems, usually for less money.

#282 - PS4 News - February 14, 2010 // 7:09 pm
PS4 News's Avatar
Yea, but he also said the same thing three weeks ago HERE (reposted below) so unless he was only speculating then it doesn't seem to be anything new.
George Hotz said...
Read your last paragraph in your last comment, and you'll see why I'm right.

You can't expect to know everything and dump every piece of code. This hack is enough for homebrew, full linux, and even backups.

#281 - Raze1988 - February 14, 2010 // 7:01 pm
Raze1988's Avatar
Well, he DID say "Where my homebrew at?". So he basically says it's now possible for him to run unsigned code.

Too bad he'll not work on any homebrew

#280 - PS4 News - February 14, 2010 // 6:50 pm
PS4 News's Avatar
Here are some more relevant extracts from the latest blog post:
Mathieulh said...
Good job in managing to use the loaders to decrypt your files, this will definitely be useful

Mathieulh said...
The cell is an off the shelves cpu but the hardware root key can only be written once, from my understanding, the secure boot doesn't occur unless the root key is set, but once it is it becomes mandatory. Also although tempering with the XDR at runtime using hardware would allow us to hack the console in a very effective way, the hardware required to match the xdr bus speed is currently way too expensive to be affordable to most people, making it quite an unefficiant broad hack, not to mention parts of the XDR can be checked by the isolated loader which would make it harder for us to go that route when such time comes.

George Hotz said...
Yea, the SPU does check the integrity, but it doesn't matter. 2 options, either predecrypt and patch the binary, or have the SPU decrypt the unaltered version and patch it on the fly before it runs.

And the problem with a direct RAM interface is more the wiring it up than the cost.

George Hotz said...
You can decrypt everything except the loaders themselves. If it's ever in the XDR, you can dump it, so all the bus sniffing equipment is useless at this point. The loader decryption happens all on the die of the cell.

But for all practical goals, you don't need the loaders, and for most, you don't even need the loaders to be runable outside GameOS.

AnonymousR said...
I never expected to see this from IBM, but thanks for mentioning it, I suspect this is the document you were talking about:$File/rc24596.pdf
It actually seems even cheaper than I imagined (250-700$?). I was expecting a FPGA around the range of 2000$.

George Hotz said...
Nah, you'll probably never dump the LS. Hardware security is simple and well understood.

Although, if I was really trying to dump it, I'd try a brownout attack. Lower the power to the chip when the ram is erasing. You only need to get a tiny little part of metldr to get the keys.

George Hotz said...
The builders know how to load metldr in an SPU already.

And some people here don't understand the concept of asymmetric cryptography, no matter if you could manipulate the individual electrons in the processor, you can't create your own valid pkg files.

George Hotz said...
Understanding ISDF files.
The #Change lines are actually commented out (anything beginning with # is a comment) for now they are less important. Focus on the Parsed lines.

This example describes the instruction il

Lines from file:
1. # Immediate Load Word
2. 010000001 iiiiiiiiiiiiiiii ttttttt
3. Parsed "O R, I" il {{t}} {i}
4. Stop

1. A comment for the reader of the file to know the instruction
2. A bitmask to identify it. 0 and 1 must exist in the instruction. i and t are variables created from those regions.
3. Parsed is how to print the disassembled instruction to the user. The first parameter after Parsed is a format string describing the other parameters. O is opcode, R is register, I is immediate. il is the opcode, t is the register), and i is the immediate. Curly braces around i mean value of. Double curly braces around t mean value of register indexed by variable.
4. Stop parsing, this instruction is done.