The above video goes away if you are a member and logged in, so log in now!
Here's a disassembly of psgroove 1.0's payload.
Soo, could anyone with twitter acc be so kind to ask Mathieulh if:
1) JB found a hole (like buffer overflow) in Sony's code or is it merely mimicking Sony's "service sticks".
2) Did 3.42 close the hole or simply moved patchable blocks around?
3) Chances to getting to lvl1
4) Could we expect new version of PSGroove without unecessary usb device driver stuff (no need to set device address anymore? Afaik porting PSGroove to some devices stopped, because nobody know how to change the address)
I found this quite interesting, especially the claim that they actually installed a virtual device driver for the USB operations.
The importance of that claim is that it implies that it should also be possible to install a virtual device driver for the BDVD drive, which I think will be needed for improved game compatibility as well as for filesize independence on external drives.
Those improvements will require storage of entire game images (so as to cope with hidden file content) and the use of FAT32 will require storage of those images to use a split-file method, similar in principle to that of USBAdvance and also used by OPL. And implementation of access to the file system inside such a game disc image will require a proper virtual device driver, rather than just some hooks into an existing device driver struct that appears to be how the current redirection from BDVD to HDD is done.
Such an implementation will be a lot more complex than the current payload, and may thus not even be suitable for the same type of payload usage (the size may be excessive), but that need not be a show-stopper.
It should also be possible to run applications that load similar device drivers embedded in those applications, so as to implement a PS3 equivalent of OPL, but for PS3 games. This could then have alternate cores for emulating BDVD access on different storage devices just like the PS2 OPL does, with support for internal HDD, external USB drives and networked storage, just like with the existing PS2 OPL.
But of course nothing like that will happen very shortly, as there is a lot of other stuff that must happen first, such as the development and release of a legal homebrew PS3SDK, and finding more information on how such software constructs as PS3 device drivers should work (up to now an internal Sony trade secret).
The information we have so far is obviously very sketchy and incomplete (though fascinating), and we will need to expand on it and clarify how everything really works to be able to work efficiently with improvements and/or any spin-off projects.
Since some of the later posts seem to refer to disassemblies of the PSGroove code, can someone (preferably garyopa) please confirm whether or not the payload listing in the first post of the thread is from a PSGroove unit or from one of the original PSJailbreak sample units ???
Best regards: dlanor
Originally Posted by garyopa
That's it. The original.
Originally Posted by dlanor
1) already on the wiki, it uses a buffer overflow. It does pretend to be a service stick, but the ps3 rejects it as it's not signed.
Originally Posted by medi01
2) closed it
3) guessing probability is pointless. you either know how to do it or you don't & afaik nobody knows right now.
4) afaik set device address is not for the payload, it's to emulate the hub & all the devices that are plugged into it.
Or probably he was working in Sony and they kicked him out.
Originally Posted by Kenshindono
Originally Posted by medi01
1) Thanks, could you post link to the mentioned wiki page please? The vulnerable code wasn't in BIOS or Sony has managed to update it?
Originally Posted by smf
3) It could have been that psjb stays in lvl2 because there was simply no need to go higher, that's why I asked.
I can't access the wiki from here, but if you go to the root then I'm sure it's linked from there.
Originally Posted by medi01
Sony designed it so that it would be hard to escalate from lv2 to lv1, we won't find out how good a job they have done until someone comes up with an exploit. The people behind psjailbreak may have one, but as you say they didn't need to use it. Exploits are like poker, you don't show your hand until you really have to.
Thanks for tha answers, smf.
One thing that still confuses me is, if hack is done on "service stick" level, which should be able to run even if there is something wrong with firmware, it should work no matter what's in the firmware, right? If this code were updatable, it would mean that an unsuccessfull update could brick PS3 so badly, that even the "service stick" woudn't help. But doesn't this defeat the whole point of the "service stick"?
hack is not done on service stick level.
is ps3 detects a real service stick on power-eject boot it will send some data data to it, and the stick responds by processing that data in some special way and sends it back. if the data is what ps3 expects to receive - service mode.
the jailbreak dongle simulates an usb hub with events of connection and disconnection of various usb devices, including the service stick. but that service stick only shows up as the device with the same usb identifier, and sends back arbitrary data to the ps3 - which is not valid. so, service mode is not entered.
carefully arranged events of connection and removal of various usb devices with malformed usb device descriptors cause an overflow in usb management code of the ps3 firmware and eventually trigger execution of code contained in those usb descriptors, which eventually leads to execution of the payload.
the only thing in common with the service mode is that you need to start up the ps3 by power,eject combination, which causes it to look for service stick on usb ports at boot time.