There have been a few new developments regarding the recent PS3 USB exploit. Working with impressive speed, Mathieulh and other developers have released an open-source version of the exploit called PS Groove. A much more detailed analysis of PS Jailbreak was also posted, although it is still not completely clear how the exploit works.
The PS Groove exploit uses an AT90USB board with the excellent LUFA library as I had expected. (By the way, send some donations to Dean Camera if you use that library. He’s a generous developer.) It attaches the proper config descriptors in the right order but contains a different payload. It will also allow you to disconnect the USB device after the exploit is complete.
Now that more details are public, the exploit is quite impressive. It is a heap overflow, not stack overflow as Gamefreax had suggested. Also, I was right that they had misread the descriptor lengths (0x4D vs. 0xAD).
The exploit involves using various config/interface descriptors to align shellcode on the heap. Then through some still-unknown mechanism, a heap overflow gives a user-controllable function pointer, which is later called after free(). The bug appears to be related to how the PS3 enumerates Sony’s internal test JIG device. This device may be probed by a different portion of the kernel, which trusts the device’s USB descriptors more.
Go check out the code and read the analysis. I’d love to hear more about how this exploit works and how it was discovered.
rdist 
Hi Nate, I find very interesting your discoveries and the info associated. I only read for fun, because I’m not interested in trying the USB PS3 exploit more than nothing because I don’t own a PS3.
But unexpectedly a friend of mine has contacted me recently about the possibility to apply the exploit with an arduino (he knows I have 1 arduino in my possession). With a little of research I think the psgroove exploit is not compatible with the arduino at the moment but someone is working on a possible port. Also a PSP port is ongoing.
My question is if you know something about these ports or the possibility to test the exploit with another method?
Thanks
Any microcontroller with a USB interface should be able to do this as it doesn’t appear timing is critical. You could probably even do it with a low-speed software USB stack, such as USBtiny.
Hi Nate,
Do you have any clue about where the exploitation takes place? Is it in an isolated SPE?
If so, can’t we extract the encryption key by comparing encrypted and decrypted binary code?
No, this is a kernel (lv2) exploit. It is not in the hypervisor or SPEs.