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.
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: 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?
Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!
To tell it all I think that shortening the memory bus to ground for a shorter time could lead to the same results but with less troubles IF, a big IF the whole system shouldn't cook itself up in the try...
The point is to obtain the MMU could return an error code to HV stopping him from returning the invalid address routine cause he doesn't know how to do in that occurrence and freeing this way the target address, am I right , am I ?
Or to have the MMU could NOT to return anything to the HV, obtaining the same thing ?
I'm just trying to focus... sorry for the silly questions but I didn't had the time to read all the IBM things...
Well, if you read his earlier attempts, he's written more about the mechanism: something like allocating a big chunk of memory, and during that, tampering with the wires, make the instruction to address other parts of the memory, witch you should't have access to. And doing so, it doesn't requre that 'insane' speed due to big arrays. (you need only 1 exploitable address out of 0x100000)
On the other hand, it's not a rock-solid solution (need some/lot of try to get to work), so i think it is not impossible to achive the glitch with longer or sorter pulse..
Well, Geo has been not so clear in his explanation but assuming the pulse low is to be intended as a single cycle it should mean the pulse must be 25Mhz to last 40ns, what I'm wondering about is why this timing when the rambus clocks is 3,2Ghz probably made by 4x800Mhz of initial clock ?
Why not a single 1,25ns 1,8V pulse ?
Did he explained this to someone ?
Quarz@800Mhz do exists, maybe an high frequency oscillator could do the job if stuffed in order to output what we want... (I'm not specially skillfull in this field, so please, do not ask too much out of me.. just an idea to someone else..)
I think using some cheap uC (example attiny44) would work better. The a attiny24/44/84 has a speed around 20MIPS @ 20MHz (mostly 1 instruction per clock) but the best thing, it only require some resistor and an LPT port to program .. So it only has a speed of 50ns / clock (50ns/instruction) with 20MHz crystal, BUT maybe working with faster crystals.
The sdk is free at atmel.com (http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725), the programmer plugin can be obtained from Kanda.com (http://www.kanda.com/downloads2.php). The programmer schematic here (http://www.qsl.net/ba1fb/avrisp.gif) It's not granted to work with all LPT port, if you have problems with it search for alternatives...
And a little about the program, what has to be done:
-set data dir to input and port to 0 (low -- then it's in Hi-Z mode) (the pin connected to the ps3)
-loop until button push (other pin, input.. etc)
-set data dir to output, and then back to input (the "ps3 pin") (that's why the port 0)
-wait around 0,5-1 sec (to prevent multiple triggering)
-goto to loop (to be able to send signal again)
The cicrcuit should run on 5V, witch can be extracted from the usb port of the PS3 or of course from external source, but don't forget to connect the gounds
- to program, you have to power up the ic externally !!!BUT connect the programmer first, then power the device!!! (otherwise you can kill your LPT port)
- if you set the clk to external crystal, you have to use it during programming
- you have to set the fuses to use external crystal, and other settings (don't worry, these can be altered... not so the lock bits, so don't tamper with them)
I'm not here to advertise avr, but 555 with RLC? Come on... even logic gates works faster... and reliable
Believe me, 555 is not gonna work because it's pulsing high to ram bus and messing ram content. Xorloser solution is working because he is changing micro controller pin state output to input thus nothing interrupt ram bus except low pulse. It's working like relay in his case.
If you have a problem with soldering find end of ram bus trace you'll see blue resistor (at 20 or 60 GB) or little circle (at 80 GB) and scratch paint with razor, clean it with soft cloth, put solder paste on it and try to put little bit solder on it without cable. If you did successfully you can solder cable easily. Don't try to solder cable to trace this can destroy your trace if you didn't care enough.