Winocm's 3.60 Ram dump - Possible solution?

[Slynk]

Couldnt you compare the EBOOT file from the original release of say Portal 2 with the patched one that has the 3.55 key to get the new key?
Maybe a dumb idea, but if I know the content of a file unencrypted I should be able to come up with the key they use, right?

Nah, the way a self is set up, even if there was a plaintext attack for AES which there might be, it wouldn't work. Here's how self encryption is set up:

1) The keys we need are used to decrypt the first section of the metadata that houses a key.

2) That key is used to decrypt the rest of the metadata which houses a bunch of keys and headers for the encrypted sections of the file.

3) Each header tells the loader which key in the list goes with what section. Not every key is used. Usually most aren't used (something like 3x the amount of keys that are actually used).

So now the problem is if you had a 3.55 self that was only re-encrypted, not changed, and signed for 3.6+, the only plaintext you could use is the decrypted sections from the last step. The keys are all generated when signing the self so the encrypted first key, headers, and key list are all different. Now you may be able to find each key associated with the sections from the last step, but you don't know where the key should go in the list as you don't have the decrypted headers telling you which key it is. So those keys couldn't be used as plain text to attack section two. You'd need to be able to attack section two to get the plaintext for one. With that plain text, you could attack to get the loader key.

Just my two cents :P

[_gf_]

one question guys.
lv0 key cannot be changed by sony because the bootldr isnt updateable....am i right? if yes, why is everyone talking about a 3.60+ dump? a <=3.55 dump would be enough because the lv0 key never change...

[ironhide666]

3.60 lv0 have the loaders encripted and the keys for them. so the need is for retrieving that key and decrypt appldr to get its key.

lv0 key is impossible to get without an exploit for the BL

[modshroom128]

after the check 3.65 has different keys than its predecessor.
Where is fail0verfl0w when you need them?

[Beshkie]

X nah, not a single line of code, at least not for the implementation
but finding the exploit itself
is EASY
except no one has gone looking
I’ve seen lots of askings and whining, very little looking xD
if someone who remotely knows spu reversing starts looking
he’ll find it
at the very worse in a matter of hours
the bug is retardly stupid to begin with
LV0, EID0, anything with coreOS imo should not be done without a hardwareflasher. Atleast with that you can undo the mess.

yeah
I am a bit of a red head here xD
you keep saying that, but I suck at SPU assembly icon wink Mathieulh Explains The Loader Exploit To Obtain 3.60 Application Keys

you’d find it even if you fail at it
you just need to know where to look
just look at how selfs are processed by ldrs
and you’ll find it
hell, I’ll help you, it’s about overflowing a certain buffer
yes, that is what defyboy and I tried to document in the ps3devwiki : bootprocess and loader locations etc. icon smile Mathieulh Explains The Loader Exploit To Obtain 3.60 Application Keys

well if you know how selfs are processed by loaders, it’s easy
another hint
it happens before the ecdsa check
my earlier guess btw was that it was a header overflow, which gave access to the local storage

It’s a retarded exploit
if you want to know what it is, I’ll tell you
the function that copies the SCE header from the shared LS to the isolated Local Store
doesn’t check the header’s size
o/ icon smile Mathieulh Explains The Loader Exploit To Obtain 3.60 Application Keys

it’s just THAT retarded
implementing it isn’t easy though
cause loaders have failsafes and shit
header size fail
lol
?

but now that you know, you can try it on your own
X1 yes
you craft a self with a HUGE header
so it overwrites ldr code as it gets copied to the isolated LS
and you wait the loader to jump to it
lolol must try heh icon biggrin Mathieulh Explains The Loader Exploit To Obtain 3.60 Application Keys

X1 it’s a total bitch to implement
but feel free xD
if someone pwns the bl with this and gets the keys, he’ll have my kudos
cause finding the exploit is the easy part
Sony’ll fix it now, but it’s not like I care much
their “unhackable” ps3s are probably already on the way


Some of the tidbits explaining how big the exploit is in the eyes of SONY’s M.I.B.

why would they care about bootldr keys?
ps3devnews etc. host metldr keys, appldr keys etc.
X1 cause you can get lv0 decrypted
once you get lv0 decrypted
you get appldr
once you get appldr
you get 3.60 application keys
once you get that
you warez
also, with those keys you can sign your own lv0, no ps3 fw update can beat you then

yah
you can have your 3.60+ custom firmware then
and warez even more
and mess with the psn again
and so on


FROM
-the guy afraid to get sued

Seems like this is a good idea and no one has picked up on it, Thanks Modshroom, shame a lot of this is over my head, >Best get reading<