Open Source PS3 Jailbreak Released
tlhIngan writes "Despite all the lawsuits and injunctions by Sony to keep the PS3 Jailbreak out of modder's hands, it appears that a third party has made a clone. The best part is, it only requires a cheap (approximately $40) development board by Atmel, and the requisite software is open-source. Get the Atmel code from GitHub and apply a small patch which will enable backup play (the code by itself only lets you run unsigned code, the patch allows for BD backups). The code is GPLv3. It would be highly ironic if someone ported this to Linux USB Gadgets, then you could use a Linux device to jailbreak your PS3, to which Sony removed Linux functionality. An Android phone would be suitable."
Oh, and another solution: Mark updates with an expiration date such that the unit will refuse to run if its firmware is too stale.
If they ever do that, I will have to kill somebody. Besides the obvious reason, I have a driving wheel that won't work unless the system date is set before 12-22-08. The bug has been there for well over a year and there's no sign its getting fixed.
Consider that the one and only reason I bought a PS3 over a 360 is to play GT5. See how well that decision worked for me?
Not a typewriter
I have blue screened my development workstation before because I had a bad descriptor that the Windows Audio driver tried to parse and it brought down the kernel. So I knew this sort of thing would be possible. I think attacking the USB host controller driver is going to become a much more common method of infection in the next few years.
But to get that far...you need dedication. You need to love the hardware. When you see it, it's like the matrix...behind the 1s and 0s and circuit board traces, there is a setting, characters, and a plot.
From there, that's how you can see the attack on the heap. That's actually the most complicated part, in my opinion. You are trying to fool the kernel into handing you a certain portion of memory. It's like social engineering...and that's what makes it hard. The kernel is interrogating you, and you have to give the right answers. Not only the right answers, but the answers must be corrupted in just the right way.
Everything from this point can be built on the work of someone before you. Pretty much all exploits eventually launch shellcode somewhere. They all need some way to launch the shellcode, and hooking a system call (in this case, free()) is a favored way to go about that. Then you need some way to do the hook, which in this case was the smashing the Heap.
So you sit there and think...how do I drop shellcode in? What function do I hook? How do I hook it? Dots appear...and then you connect them, and you annotate the connections, and you go back and you start from scratch again because you see a better way, and then finally...it all comes together.
:(){