I'm also finishing a tutorial (i'm validating it step by step) called "How To Build GeoHot exploit easily from scratch (from kernel build to exploit run)" with included automatic scripts.
I think I will add a new thread in PS3 Guides for that (I hope I have right to create new Thread, else I will contact you).
Thnx for sharing
PS: I got an sms today from UPS so my delivery will be tomorrow I hope I will find time after work to do it until end of this week
If I will be able to get a tool at a low price to pulse the bus, I will dump my own immediately
And release it
Would an avr have the speed to do the 40ns?
well i tried this... but i just not SPAM it... like pressing Button at millions... i thought that i need to do it at once and tried and nothing happened and i just unsolder everything from ps3 and assembly ps3!
But i thought that my button didnt work... now i think its working but i need to press button millions time. So... here we go... i used USB 5v and GND think its ok
To my understanding you have to hit exactly at the time it is deallocating the memory. (interrupting the signal)
you should read the articles linked from geohot's log:
So it seems like you have to try until you get it right.The first step is to allocate a buffer. The exploit then requests that the hypervisor create lots of duplicate HTAB mappings pointing to this buffer. Any one of these mappings can be used to read or write to the buffer, which is fine since the kernel owns it. In Unix terms, think of these as multiple file handles to a single temporary file. Any file handle can be closed, but as long as one open file handle remains, the fileís data can still be accessed.
The next step is to deallocate the buffer without first releasing all the mappings to it. This is ok since the hypervisor will go through and destroy each mapping before it returns. Immediately after calling lv1_release_memory(), the exploit prints a message for the user to press the glitching trigger button. Because there are so many HTAB mappings to this buffer, the user has a decent chance of triggering the glitch while the hypervisor is deallocating a mapping. The glitch probably prevents one or more of the hypervisorís write cycles from hitting memory. These writes were intended to deallocate each mapping, but if they fail, the mapping remains intact.
I will dump it when all the necessary hardware arrives at my house and precompiled version of the exploit to dump the hypervisor is released since i'm too lazy too code it myself
Gave your circuit a run - alas it does not "appear" to work. Wired into the PS3, it won't even hiccup (vs say, directly grounding the line) Just to make sure, I rebuilt the thing from all new parts (again). Any suggestions?
Edit: Finally got "something" after making a modification (pin 6 held high), basically getting it to successfully install the exploit (twice), but then crashing soon there after. Over the course of two hours managed to get it to hit twice, so it may need a bit of work, but the general principle does seem sound - question is, is it too slow, or something else?
Last edited by CJPC; 02-04-2010 at 01:49 AM