Page 75 of 87 FirstFirst ... 256574757685 ... LastLast
Results 741 to 750 of 863

Thread: Rumor: PS3 JailBreak 2 v3.55 Dongle Plays v3.60+ Game Backups?

  1. #741
    mellss Guest
    I tried it, it work like True blue firmware and his package (ps3peektest.pkg) call a new syscall. I get "Peek Result: 10" (so it works)
    Has anyone tried his cfw with trueblue plugged in?

  2. #742
    HeyManHRU Guest
    Nabnab, sorry if this just sounds like I guess (which it isn't), but is it the game "Skate"? I've seen a file named "HED-DATA" in it which I haven't seen in any other game save before so I am a bit curious.

  3. #743
    Nabnab Guest
    I don't know about Skate (didn't test this game) but i can tell you that Hunted the game of the SKYRIM editor is one of this game

  4. #744
    Ombra Guest


    Guys, i'm i the only one thinking about this??

    Then you should be able to use a peek&poke enabled MFW to grab a dump without losing the dongle... hell you can even put a switch...

    Just saying...

  5. #745
    Tidusnake666 Guest
    Honestly, savegame exploit? If PS3 can be cracked, it won't be buffer overflow attack. We've seen alot of this on early ps3 cracking stages, even TIFF exploit, that very few remember, na dthat lead into nothing. IIRC, RSX has an awesome control over overflow attacks and immideatly calls lv1_panic (I can be wrong, it was sooooo long ago since I've read about this), so, savegame exploits are not the way to achieve anything.

  6. #746
    Nabnab Guest
    Tidusnake666 I never talk about a buffer overflow attack when you don't need and i never talk about a TIFF exploit, RSX is not related to the step loading (and i was just showing a example from wii, psp, even XBOX)

    Let's take the example of the game i was talking about

    -Transfer your modified Payload based on the one from the game
    -Insert your BR Game
    -the PS3 system load the BR Game, execution of the payload from the savedata
    and after the BR Game boot completely (but actually the payload use specific syscall
    to load certain program) no problem of buffer overflow attack or tiff exploit in here

    Also don't need RSX to calls lv1_panic, it's the Cell execute LV1_panic if something is incorrect but in here you use a file that the system already know and loaded on a background step/Kernel mode privilege

  7. #747
    drphuz Guest
    I totally understand what Nabnab is saying.... #justsaying

  8. #748
    Tidusnake666 Guest
    Oh, sorry, I meant Cell, not RSX, it was late. Later, I understood a mistake, but I was so close to been asleep

    It seems like an interesting approach. I've followed wii scene from the very beginning. Let's see where this is gonna take us.

  9. #749
    WTF Name Guest
    for the eboot.bin, the first section to be decrypt would it be always ".ELF" (hex code 7F 45 4C 46)

    1) if it is true , then can be brute-force the key(this key is specified for this section, one eboot.bin can have few sections encrypted, each with different key from metadata) as we know the answer of first 4 bytes must be this ?
    2) after this , the key (key 1) to solve this section (first section) is found.
    3) since this key should match with the metadata information, similar to BF the key(key 0) which can decrypt all metadata information in the rest of eboot.bin file
    4) go back each section , found the metadata info, decrypt it with key 0 to found (key 2), (key 2) would decrypt the 2nd section
    5) similarly, use key 2 to decrypt the third metadata info, find key 4, then decrypt 3rd section ...
    and go on ...

    this is just my first guess, please correct me and give any idea if you have ~

  10. #750
    tapion64 Guest
    Everything I know about eboot.bin's structure pretty much comes from here ( and various other things I've read. eboot.bin, from what I remember, is a self with added NPDRM encryption (I could be wrong about that).

    In any case, the .ELF you're seeing is in the SCE header, and doesn't have to do with the keys. After the SCE header is some SELF info and then metadata info, the metadata info are the keys to decrypt the rest of the keys for the file, but they are themselves encrypted.

    Since we don't currently know how to decrypt metadata info for 3.6+, and there's no viable method to bruteforce, our only option is to wait for someone to leak those keys or leak how to decrypt lv0 to get those keys.

Page 75 of 87 FirstFirst ... 256574757685 ... LastLast

Tags for this Thread

Posting Permissions

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