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?
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.
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
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...
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.
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
I totally understand what Nabnab is saying.... #justsaying
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.
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 ~
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.