Sponsored Links

Sponsored Links

Page 12 of 12 FirstFirst ... 2101112
Results 111 to 114 of 114



  1. #111
    Registered User is0mick's Avatar
    Join Date
    Jan 2010
    Posts
    27
    Sponsored Links
    Sponsored Links
    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
    Registered User DanielSV's Avatar
    Join Date
    Aug 2010
    Posts
    5
    Sponsored Links
    Sponsored Links
    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.
    Last edited by DanielSV; 08-30-2010 at 02:11 PM

  3. #113
    Senior Member tragedy's Avatar
    Join Date
    Mar 2009
    Posts
    135
    Sponsored Links
    Sponsored Links
    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:
    Code:
                    li      %r31, 1
                    rldicr  %r31, %r31, 63,0        #r31 = 0x8000 0000 0000 0000
                    mr      %r3, %r31
                    oris    %r3, %r3, 5         # r3 = 0x8000 0000 0005 0000
                    ori     %r3, %r3, 0xB3C         # r3 = 0x8000 0000 0005 0b3c
                    mr      %r4, %r31
                    oris    %r4, %r4, 0x70         # r4 = 0x8000 0000 0070 0000
                    ori     %r4, %r4, 0x1AC         # r4 = 0x8000 0000 0070 01ac
    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:
    Code:
     3ac:	fb 81 00 80 	std     r28,128(r1)
     3b0:	fb a1 00 88 	std     r29,136(r1)
     3b4:	fb e1 00 98 	std     r31,152(r1)
     3b8:	fb 41 00 70 	std     r26,112(r1)
     3bc:	fb 61 00 78 	std     r27,120(r1)
    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:
    Code:
     150:	00 04 90 e0 	.long 0x490e0
     154:	e8 82 0f 08 	ld      r4,3848(r2)
     158:	00 04 90 e4 	.long 0x490e4
     15c:	e8 7c 00 20 	ld      r3,32(r28)
     160:	00 04 90 e8 	.long 0x490e8
     164:	f8 64 00 00 	std     r3,0(r4)
     168:	00 04 f0 a8 	.long 0x4f0a8
    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 PM Reason: Automerged Doublepost

  4. #114
    Registered User Karl69's Avatar
    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

 

Sponsored Links
Page 12 of 12 FirstFirst ... 2101112
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News