- Join Date
- Apr 2005
As I mentioned in another thread, one of the areas CJPC is seeking to examine from the dump is the boot flag data, as he is interested in being able to convert his Service Mode PS3 to a Debug one, or better yet Retail PS3 consoles to Debug units optimistically.
02-10-2010 #62NaTaS69 Guest
Cool news. Keep the updates coming.
02-10-2010 #63SiZMiK Guest
excellent news, good luck with it.
It's all a bit exciting
02-10-2010 #64Progeria GuestOriginally Posted by PS3 News
will be fun to follow when dumps get released
edit: good timing for the ida and ida sdk releases that got released not so soon ago
02-10-2010 #65veggav Guest
- Join Date
- Apr 2005
Even bushing from the Wii hacking scene agrees (http://xorloser.com/?p=175#comments), to quote:
I used an FPGA (Spartan3E starter kit) to do this — but for some reason, I was unable to get 40ns pulses to have any effect whatsoever. I kept stretching the pulse width until it started affecting execution — by the time I had the exploit working, my pulse width was approx 200us — yes, that’s 20,000 times the length of the suggested glitch. Did anyone else run into this problem?
This hack is fairly annoying to get working, in the sense that you spend a lot of time mashing a button. It’s also not horribly great for the hardware — you’re briefly overdriving a bus-driver transistor inside the Cell, and you’re probably doing a little bit of damage each time you do it. It may not matter in the long run, but it just feels wrong.
I’ve been able to also trigger the exploit by pulling the Vref on one of the XDR chips down to ground — on the whole, it seems slightly less reliable than the RQ2 glitch, but it’s a lot easier on the hardware and a slightly easier place to solder to.
I think the biggest issue affecting reliability is the timing of the glitch, so I’m putting my effort into fixing that — I think I’ve found a signal I can abuse for the purpose.
For example, the HTAB entries take around [51.748028] time was 0x12afa9, 0x1b per, 0, which is like 1/5 reboots.. most of the time its 0xfc000 so a a bit faster but harder to glitch.
In layman's terms, CJPC has done more button-pushing and PS3-resetting in the last 2-3 days than most people have in the last 2-3 years.
02-10-2010 #67CJPC Guest
Yeah the biggest problem is really the fact that the exploit itself is well a glitch. I mean, the hardware works perfectly, I can get it to start to exploit the box within 20 seconds of trying , every time.
The problem is, 90/100 times the exploit crashes / locks up the ps3 / errors , resulting in the need to reboot, and restart.
Once the exploit is planted, then we start running our own kernel module to dump out the real memory. The way we we're doing it is well, unreliable and prone to massive corruption (not to mention slow)
[Register or Login to view code]
(it looks better in a Hex Editor!)
But, with dumping memory to a file you run into other issues. You can't just use FileI/O in a kernel module any more, and you can't access lv1_peek from user mode either, so you need to make some additional code to handle it, which is what were working on now - although I'm open to any suggestions to get it done faster, its such a pain after your kernel module crashes, and having to reboot and re-exploit the PS3!
02-10-2010 #68mushy409 Guest
I bet he has blisters like walnuts on his fingers!
Good job guys, the PS3 is going to be THE console to own this year. The bank has been broken, now for the safe
02-10-2010 #69moshebe Guest
Great news guys, keep up the good work !
02-10-2010 #70njenge Guest
Great news, hope this can lead us to heaven.