Page 12 of 12 First ... 21112
  1. #111
    Join Date
    Jan 2010
    Posts
    27
    Quote Originally Posted by proskopina View Post
    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.

    Mick

  2. #112
    Join Date
    Aug 2010
    Posts
    5
    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.

  3. #113
    Join Date
    Mar 2009
    Posts
    135

    [Register or Login to view code]

    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.


    [Register or Login to view code]

    This is a standard prologue for a stack frame - it's saving registers on the stack.


    [Register or Login to view code]

    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.
Reply With Quote Quote

  • #114
    Join Date
    Feb 2010
    Posts
    32
    Quote Originally Posted by tragedy View Post
    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
    Nice work... Maybe this will help adapting the exploit to older firmwares.

    Have you been able to find the parts in the shellcode which would be version dependent?

    Karl

  • Reply to Thread
    Page 12 of 12 First ... 21112

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •  

    Log in

    Log in