Sponsored Links

Sponsored Links

Page 2 of 12 FirstFirst 1234 ... LastLast
Results 11 to 20 of 114



  1. #11
    Junior Member hacked2123's Avatar
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by Maniac2k View Post
    @hacked2123: Shouldn't it be enough to do the same the original PSJB does? I think, if the log is complete everythin it does should be there.
    This isn't the complete log. From what I gather from the description of it, its only the procedural part of the device. At the very least there will be a point that the PSJB sends "Install Package Files"'s hex of
    [Register or Login to view code]

    That is NOT included in the retail firmware, and therefore must be sent from the PSJB.

  2. #12
    Member tmaster's Avatar
    Sponsored Links
    Sponsored Links
    Disane came up withe this for the hex code, This is the shellcode.

    1st PART

    [Register or Login to view code]

    This is the actual shellcode it repeats 32 times and it patches the lv2 (this info is from Rich). It probably tries to make the PC jump to this code sequence, I'm not sure if the same shell code could work on other firmwares.

    This is the second part. Looks more like RAW data or Encrypted data to me...

    [Register or Login to view code]


  3. #13
    Senior Member PSPSwampy's Avatar
    Sponsored Links
    Sponsored Links
    My though on this was to get a USB A-A cable, then plug one end into PC and the other to the PS3.

    Would need to code the PC specially to send the data through to the PS3 - I've been having a look around the net to see if there are any c# examples of using the PC's USB port as a "slave" device. I've not worked with the USB port much before in code, but I can't help thinking that this route would be possible.

    The final solution would be to have the byte stream from the PSJailbreak sent through from the PC, thus triggering the exploit.

    I'll continue to have a look, but if any of the other DEVs here have previous experience (& example source code) maybe this might be a FREE way forward (well the cost of an A-A cable!)

    It is late though so i may be talking complete BS - feedback welcome (especially from fellow PC devs)



    PSPSwampy.

  4. #14
    Quote Originally Posted by PSPSwampy View Post
    maybe this might be a FREE way forward (well the cost of an A-A cable!)
    I don't believe PC USB ports are designed to be used as USB Host devices. There was a program back in the day that used USB to USB to transfer files, Laplink ([Register or Login to view links]), but they had a controller in the middle, which leads me to believe it really can't be done for sure. :-/

    I know the PSP however has the ability to be host, as well as receive (camera for instance)... but that doesn't mean I know we can change the Device ID or Hardware ID. :-/

  5. #15
    I think there are some duplicated bytes in the log. For example the beginning of the second block. First a configuration (09 02...) descriptor is send followed by a lot of interface descriptors (09 04...). Some of the bytes seems to be doubled.

    [Register or Login to view code]

    The lines with 09 00 and 02 00 shouldn't be there.

  6. #16
    I think we must sniff the PSJailbreak code in different PS3 systems, I think they do a kind of challenge/response, but some code pieces could be different on each PS3.

  7. #17
    The only things the second block does is sending one configuration descriptor and after that the same interface descriptor repeated 292 times. I don't counted them but the length descriptor says it has an overall length of 2637 byte. Divided by 9 (as every descriptor is 9 byte in this block) you get 293. I'm looking forward to count this manually, if i get to the same number this will prove the log contains errors as described above.

  8. #18
    Quote Originally Posted by hacked2123 View Post
    I don't believe PC USB ports are designed to be used as USB Host devices. There was a program back in the day that used USB to USB to transfer files, Laplink ([Register or Login to view links]), but they had a controller in the middle, which leads me to believe it really can't be done for sure. :-/

    I know the PSP however has the ability to be host, as well as receive (camera for instance)... but that doesn't mean I know we can change the Device ID or Hardware ID. :-/
    why the hell not. i'm sure you can at least spoof it

  9. #19
    I'd be welcome to test any implementations of the code on a CFW PSP or a JB'ed iOS device, via USB.

  10. #20
    @Maniac2k:
    Very good observations, thanks for the help. Yes, it looks like we're missing a device descriptor.. also, in the first block, we get a configuration+interface descriptor, then a lot of data, probably the injected code. However, This dump isn't very helpful, it only seems to show raw sent data. Since USB is host-driven, then we would still need to know what request makes that device send that information..

    Anyways, you are right about those extra bytes in the second block, but there are no duplicated data in the log, simply because the wDataLength is correct, so this means that the device does this on purpose somehow.

    I see that the device sends 4 times the configuration 0 descriptor+payload, then two times the configuration 1 descriptor+292interface descriptors (the same descriptor for the same interface, but with some glitches). The guy also says there's a 'disconnect/connect' signal or something.. But I don't really see/understand how this works.

    The initial RE said something about a USB hub emulating 6 devices being plugged in/unplugged, and also a JIG device being plugged in. Without the proper device descriptors, there's not much we can do I think.

    By the way, from the Interface descriptor, it looks like the Class ID/SubClass ID/Protocol ID (defined by usb.org) are for a 'Device Firmware Update' device with protocol 0x02 : [Register or Login to view links]

    FE with subclass 0x01 means : "Device Firmware Upgrade. Device class definition provided on [Register or Login to view links] ." which is the infamous "DFU" mode.. I believe that's the actual JIG 'id'.

    You can read how it all works here : [Register or Login to view links]

    So what I think happens is that the device id is not necessary, it can be anything, we don't care.. but what happens is that the device gives it two configurations, the first one is full of data to exploit the device, then it gives its second configuration with its interface being the DFU device... since it may not work, or maybe it needs to send it a lot of times to get it through? I don't know.. but anyways, just wanted to let you know that the 0xFE/0x01 class/subclass is for "DFU" devices!
    Last edited by kakarotoks; 08-28-2010 at 11:27 PM Reason: Automerged Doublepost

 
Sponsored Links

Page 2 of 12 FirstFirst 1234 ... LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - PS3 Forums - Privacy Statement - Site Rules - Top - © 2015 PlayStation 3 News