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!

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

#229 - CJPC - February 5, 2010 // 5:27 am
CJPC's Avatar
Well - Gave the altered diagram a try (2+6 to the switch) - also had no luck. Open to suggestions on some modifications, if not we are going to have to get a bit more creative.

If I had to guess, it seems like conee might be onto something, as in the switch not totally triggering properly - however the PDF does not seem to agree - says to pull the lines high for a low pulse, then again - nothing seems to agree!

#228 - yellowsnow - February 4, 2010 // 11:48 pm
yellowsnow's Avatar
I believe you are right at far as the way the 555 is wired I think it should be wired in astable mode it uses two resistors and continually pulses on a specified frequency also I dont think that you need HEF4016 also the wiki page provides a formula to calculate the time of the pulse LOW=ln(2)*R2*C(in Frads (F) im not firmiliar with the ln value but if someone with better electronic knowledge wants to comment I think we could figure a smaller easier to source (all Radioshack parts) pulse "generator".

#227 - conee - February 4, 2010 // 9:53 pm
conee's Avatar
Quote Originally Posted by Mdiv View Post
PSPICE sims with that very circuit gave a high pulse for 30-35 nS then rolled off down to 0V at 45-50 nS. If you want to replace the bilateral switch for a transistor it might work a little bit better and be more accurate timing wise. Base to pin 3, Collector to PS3, Emitter to ground. Also, talking to my tutor the smaller the capacitor the more defined the pulse will be with less roll off.

So if you can, try C = 10pF, R = 3k6 Ohms (40nS)
If no luck try C = 10pF, R = 3k1 Ohms (to allow for 5 nS delay).

you know what i think is the problem, i don't think the people using your circuit understand that the 555 triggers on a negative pulse. what i think the problem CJPC and others are having is that with the way your 555 is wired (especially with the reset held high), it'll switch only ONCE, and that's when your button is let go.

for whoever is using his circuit, you have to keep the trigger held at 5V UNTIL you want the pulse to go through, and then let go of the button (if you're using a momentary switch / pushbutton). quite frankly i feel like the pulse width may not be the deciding factor as to why everyone is having issues with the glitch working. if CJPC was able to get it to work twice, i feel like a difference of +-5ns isn't significant, but rather it's the fact that when people think it SHOULD be triggering, it isn't.

#226 - CJPC - February 4, 2010 // 8:07 pm
CJPC's Avatar
Well - in theory yes it would work, assuming you can find a PIC that can handle the job fast enough (and, make up some code to whip on there).

#225 - mushy409 - February 4, 2010 // 7:59 pm
mushy409's Avatar
I don't know if this has already been asked, but can the 50ns low pulse be achieved by using a pic chip (12F629 or similar) and a bit of code to trigger the pulse instead of using a switch?

As mentioned earlier, transistors are much faster than tactile buttons. Could this be done?

For example: PIC 12F629 that pulls an output low for 50ns, but does this say 4 times a second? Surely this would result in more 'hits' for the exploit?

Correct me if I'm wrong.

#224 - PS4 News - February 4, 2010 // 6:59 pm
PS4 News's Avatar
No surprise here since it was released before the exploit, but to quote:
I just wanted to confirm to anyone willing to try geohot's hack on the ps3 that it does work on 3.15 (it has been tested)
10 minutes ago from web
Mathieu Hervais

#223 - TUHTA - February 4, 2010 // 6:38 pm
TUHTA's Avatar
ok CJPC i will try your diagram so IT WiLL WORK i believe! i will write later some progress!

#222 - semitope - February 4, 2010 // 6:32 pm
semitope's Avatar
I'm sure somebody can write a simple program to send whatever that button does at a much higher frequency that the human hand can. "Just do it"!

#221 - CJPC - February 4, 2010 // 6:25 pm
CJPC's Avatar
Quote Originally Posted by TUHTA View Post
Thanks a lot CJPC!!! But can you show ur one? What did you use?

how many time you press Button to get exploited?

Mine has still yet to fully work, but umm - A LOT, by that, i mean a TON, over the course of about an hour of hitting the button and rebooting, i got it to trigger twice - not very useful yet. The 555 might be too slow to do the trick often enough (not too sure yet).

But, mine was like the diagram, except I hard wired pin 2 to VCC, vs the switch - will try the switch method a bit later - pretty much what I posted (noting Pin2 to VCC vs the switch) HERE and HERE.

#220 - TUHTA - February 4, 2010 // 6:20 pm
TUHTA's Avatar
Thanks a lot CJPC!!! But can you show your one? What did you use?

how many times you press Button to get exploited?