Sponsored Links

Sponsored Links

Page 75 of 87 FirstFirst ... 2565737475767785 ... LastLast
Results 741 to 750 of 861



  1. #741
    Junior Member mellss's Avatar
    Join Date
    Oct 2011
    Posts
    19
    Sponsored Links
    Sponsored Links
    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
    Senior Member HeyManHRU's Avatar
    Join Date
    Dec 2010
    Posts
    3,021
    Sponsored Links
    Sponsored Links
    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
    Senior Member Nabnab's Avatar
    Join Date
    Dec 2011
    Posts
    157
    Sponsored Links
    Sponsored Links
    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
    Registered User Ombra's Avatar
    Join Date
    May 2005
    Posts
    5

    Lightbulb

    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...
    Attached Thumbnails<br><br> Attached Thumbnails

    Psjb2-Trueblue-WP.jpg  

  5. #745
    Senior Member Tidusnake666's Avatar
    Join Date
    Sep 2008
    Posts
    802
    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
    Senior Member Nabnab's Avatar
    Join Date
    Dec 2011
    Posts
    157
    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
    Senior Member drphuz's Avatar
    Join Date
    Jan 2011
    Posts
    169
    I totally understand what Nabnab is saying.... #justsaying

  8. #748
    Senior Member Tidusnake666's Avatar
    Join Date
    Sep 2008
    Posts
    802
    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
    Junior Member WTF Name's Avatar
    Join Date
    Oct 2011
    Posts
    25
    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
    Registered User tapion64's Avatar
    Join Date
    Feb 2012
    Posts
    4
    Everything I know about eboot.bin's structure pretty much comes from here (ps3devwiki.com/wiki/SELF_File_Format_and_Decryption) 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.

 

Sponsored Links
Page 75 of 87 FirstFirst ... 2565737475767785 ... LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News