PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

  1. #111
    Join Date
    Jan 2010
    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.


  2. #112
    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
    Quote Originally Posted by DarkNeo View Post
    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:

    [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.

    Quote Originally Posted by Karl69 View Post
    If you look through the exploit in the first packet, there is relative coding like this here:

    [Register or Login to view code]

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

    But then there is also "absolute" coding like this:

    [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.

  4. #114
    Join Date
    Feb 2010
    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?


+ Reply to Thread
Page 12 of 12 FirstFirst ... 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