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 // 8: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 PS4 Downloads.

#239 - meatballz77 - February 5, 2010 // 3:45 pm
meatballz77's Avatar
Quote Originally Posted by yellowsnow View Post
Just got back from the Shack with lots of 555s and parts ready to get this goin' PLEASE: if anyone knows what ln is in the formula posted for astable 555 timers is then please comment.


I'm guessing ln is the natural log function.

#238 - yellowsnow - February 5, 2010 // 3:32 pm
yellowsnow's Avatar
Just got back from the Shack with lots of 555s and parts ready to get this goin' PLEASE: if anyone knows what ln is in the formula posted for astable 555 timers is then please comment.


#237 - yellowsnow - February 5, 2010 // 1:23 pm
yellowsnow's Avatar
I still think an astable 555 rig is the way to go no need to use any complicated parts as a trigger.

#236 - PS4 News - February 5, 2010 // 12:14 pm
PS4 News's Avatar
I removed some off-topic posts... please keep this thread on track guys. The goal here is to build a low-cost solution to dump the HV, without using an expensive FPGA like GeoHot or a SX28-based solution like xorloser did HERE.

If no reliable alternative is found, the next cheapest way would be via SX28 but please use that thread for discussion of that method, parts needed, etc.

#235 - Mdiv - February 5, 2010 // 7:08 am
Mdiv's Avatar
Hi Conee,

6 + 2 connect is a fail on my part, meant to be 4 + 2 wired together. The reason I don't think an inverter is best to use is because you would want to have zero signal at the PS3 pin. Using an inverter your going to have +Vcc at the PS3 pin which, i think, will ruin the data stream.

The first diagram I drew with a bilateral switch was pure ignorance on my part, though it allows there to be no connect between the PS3 pin and a voltage source (gnd or +Vcc) until you press that button and then it will not impede the signal between PS3 and gnd. A better solution would be to use a transiter, no?

Can you explain why you think a pull up resistor is needed in the design?

If you dont have access to testing equipment you will be hard pushed to get the timing circuit to work first time with my first diagram. I hate 555 timers and generally avoid them. I wish there was a tv screen in our lab which has 60+ FPGAs with the latest vBasic and orcad software.

#234 - SCE - February 5, 2010 // 7:03 am
SCE's Avatar
Thanks for the reply.

My order is still not shipped and I want to buy an inverter. The shop has three inverters:

CD4069BE - Hex Inverter (Unbuffered)
CD4502 - Strobed Hex Inverter/Buffer (3-State)
CD4007BE - Dual Complementary Pair Plus Inverter

Which one should I order?

#233 - conee - February 5, 2010 // 5:24 am
conee's Avatar
Quote Originally Posted by SCE View Post
conee, thanks four your help.

Do you have any tools or a PS3 to test the diagram? I have ordered CD4016BE and LM555N, will I be able to achieve 40 ns with these?

eh, i don't really like mdiv's bilateral switch. it should work, but the inverter would be more reliable. i don't really like having an additional output impedance, but mdiv said he simmed it and it worked fine, so i'll trust his word on that. i'll see if i can still find my copy of spice lying around and sim my diagram with the inverter, haven't used it since second year at uni.

since you've already ordered the switch, you might as well just use it. follow my latest diagram for the pullup resistor and 555 wiring, and then wire up the switch the way mdiv had it (enable0 to vcc, and input / output on the y0 z0 lines). i'll be visiting a friend at uni in week or so, if you guys still haven't gotten this thing to work i'll drop by the lab and scope one physically to see what the output characteristics really are.

#232 - SCE - February 5, 2010 // 4:10 am
SCE's Avatar
conee, thanks four your help.

Do you have any tools or a PS3 to test the diagram? I have ordered CD4016BE and LM555N, will I be able to achieve 40 ns with these?


#231 - conee - February 5, 2010 // 12:51 am
conee's Avatar
forgot a couple things in my post. first off, i realized that you could design the trigger better with a pull up resistor and the switch in a different position. i've updated the diagram and reposted it. secondly, i forgot that the 555 requires you to return the trigger pin back to high before the end of the outgoing pulse. realistically i don't know how you're going to accomplish this. i guess if you push and let go of the button really quick you'll get it every once in a while. i'll try and think of a better solution to this.

#230 - conee - February 5, 2010 // 12:33 am
conee's Avatar
Quote Originally Posted by CJPC View Post
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!

oh wow. i fail at reading. i thought you were going for a normal 5v pulse, rather than pulling it low for 40ns. in that case i don't understand why you're even using the bilateral switch (an inverter would be faster and better). the 555 is not designed to pulse low. you should be using the 555 to pulse high, and then inverting the output. replace the bilateral switch with a hex inverter like the 7400 seres after the 555. don't connect pin 2 to 6 either on the 555, it won't work. i've botched up his diagram using mspaint so you get the general idea.