this is the usb traffic between the psjailbreak device and ps3.
it contains the exploit code but it doesn't contain the binaries on the psjailbreak itself. i.e it won't let you clone the jailbreak but it will give the devs a great heads up on how to use the exploit and deliver it to the ps3 in different ways.
It could be possible to code a driver for the pc which when the jailbreak is plugged in, would give the response the same as the ps3 does.
I would then think the device would then show up as a flash memory device, and you should be able to copy any contained files from that.
What most people here want is the code contained it the Atmel-chip onboard the jailbreak, but that's not easy to get.
What we could do, is to connect the serial port on the pc to the usb port on the ps3, somehow, then send the data. Of course that would only work if the data is static, or if we knew the algorithm for generating a response. I haven't read much of this thread, so I don't know, but I bet a lot of people here do.
For example I'm having a hard time figuring out what the oris opcode would do to 64bit registers, does it still take a 16bit immediate value in 64bit chips? And if so which 16 bits in the 64bit register does it OR the immediate value with?
It sets bits 32-47 (note on ppc bits are numbered MSB 0, LSB 63). I'll explain the most common idiom used in the shellcode:
The shellcode actually looks quite well written (although shows hallmarks of being partially produced with a compiler). I've basically got a good handle now on how it all works, although I've not got an lv2 dump so some of it's guesswork. e.g. at offset 0xc4, there's a call to 0x800000000007c01c which I think is memcpy, but I'm just assuming that for now.
For disassembly tips, 0x12-0x80 is PIC code, entry r3=start of file+0x1000.
0x80-0x1ac add offset 0x8000000000700000 to start of file
0x1ac-0x6f0 add offset 0x8000000000050990 to start of file.
If you can get your head around the various relocations the code undergoes, it's fairly easy code to follow.
Originally Posted by Karl69
If you look through the exploit in the first packet, there is relative coding like this here:
The values after .long are probably addresses which are firmware dependent and would have to be changed depending on the FW version. Again I am guessing here...
Spot on. This table (terminated by .long 0) is a table of addresses to which 0x8000000000000000 is added and then patched by the next 4 bytes (helpfully easily disassembled). You'll see the 3 instructions that get written here are sequential.
Last edited by tragedy; 08-31-2010 at 07:08 PMReason: Automerged Doublepost