I got what you mean, don't worry. When you have unencrypted eboot, what you do? Keys are 3.6 , or 3.7. RE adapt them for work, is what their dongle + tool do. Actually, just TUHTA could do something with unencrypted eboots, not you, nor me
I got what you mean, don't worry. When you have unencrypted eboot, what you do? Keys are 3.6 , or 3.7. RE adapt them for work, is what their dongle + tool do. Actually, just TUHTA could do something with unencrypted eboots, not you, nor me
On the blu ray the eboot is encrypted, probably with a custom key we've very little chance of getting, but the PS3 has the decryption key because appldr has to decrypt it before running it.
so after opening it, the copy in RAM is UNENCRYPTED, in RAM the eboot will be completely 100% decrypted otherwise it wont run! it's just a case of cleaning the dump and re signing it with the 3.55 keys.
and you'll find quite a few people around here know at least how to sign an eboot lol
yep, this will further advance the cfw scene.
Absolutely agree. The problem is, as you said: where is the decrypted eboot? We don't have it. That's why this tool is needed. Surely do a decrypt encrypt, not a separate process.
Reason because we cannot play with 3.6+ games, and why we want jb2 or wait TUHTA. So i repeat, upload eboot coming directly from indonesian BDRs is pointless.
But i can tell you, eboot goes on ram as is, 3.6. It's modified, worst. So what you find on ram, is a strange code, something either owning 3.6 keys you cannot decrypt.
appldr will decrypt it for us! Have you any idea what you're talking about? You do understand that all encrypted code has to be decrypted before it is executed. The appldr key in their FW will be the public key to their private key that they encrypted the eboot with, when the PS3 runs the game appldr will use THEIR KEY to decrypt it as it loads it into memory to be run.
So if you dump the ram you get a 100% completely free of all keys, clean as a whistle, decrypted eboot buried in the dump and because its a 3.55 FW dumping RAM shouldn't be an issue.
Yes uploading their encrypted eboots seems pointless for now but there are numerous comparisons that can be done with them so it helps.
Maybe I'm not making this clear enough. On blu ray eboot is encrypted. In RAM eboot is decrypted.. we can dump ram on 3.55, we cant on 3.56+
That's why this is different, it's a decrypted 3.60+ eboot somewhere we have access, it's just a case of grabbing it.
As I said before, the eboots are special fself, the eboot of driver san francisco has a debug header but the self is encrypted, so you cannot decrypt it. The eboot of pes 2012 is completely encrypted. We cannot do anything if before we didn't get the dongle and at least a special bd.
I got an elf from driver san francisco eboot, I could create so an eboot.bin, but I'm sure it won't work because the elf I got is yet encrypted.
I mean taking the dump with a dongle and the special bd of the game.
If this dongle is real one so i should buy one whatever tomorrow is the CFW but at least i respect the team work there for bringing life the ps3 scene.
thanks a lot for all the great work guys
I tried that Sniper eboot and it doesn't work.
some extra info from math...
Code:<Mathieulh> I kinda figured how it works already <Mathieulh> they patched lv1 and lv2 <Mathieulh> and they have lv2 to check if the self keyset is 0x10 or higher <Mathieulh> if so it's sent to lv1 through a separate hypercall than hvsc99 <Mathieulh> which sends the self or part of it to the usb hw <Mathieulh> which performs some crypto <Mathieulh> and returns a decrypted result to lv1 <Mathieulh> at least that's what I got out of a few minutes of debugging <Mathieulh> I am pretty sure the keys are on the dongle <Hewman> as in debug eboots? <Mathieulh> 3.60+ app keys
Posting Permissions
