Hacking How did they re-secure the Ps3?

[Deleted User]

To my recollection, the Ps3's private keys were completely cracked open, and known publicly. This means that anyone could have signed games, homebrew, whatever, to run code.

If this is true, then why are we not able to simply sign stuff even on current firmware, to still go ahead and run our own code? I mean, if we know how they lock updates, then we should be able to see what they've done, and simply follow their methods to the T and regain control each and every time.... so what gives?

Sorry, I just had this sudden thought pop into my head and thought I'd ask, genuinely curious.

 

[godreborn]

there r a few reasons. first, the 3.55 keys were revoked using a file in the core os, so later firmware can't be signed using those keys. the unknown variable is now actually unknown so we can't get the private keys for anything about 3.55. and, lv 0.2, which I believe required a hardware revision - the key is unknown. if you've ever used PUAD to decrypt an update pup, it will error on the core os due to lv 0.2. it will still decrypt all other files, but it will skip that one. lv 0.2 seems to be a hash calculator for lv 0, so it will detect modifications.

edit: there's also metldr 2 with a different key on some 2K systems, 3, and 4K systems. I'm sure the bootldr key has been changed as well. both of these required a hardware revision.

 

[Deleted User]

there r a few reasons. first, the 3.55 keys were revoked using a file in the core os, so later firmware can't be signed using those keys. the unknown variable is now actually unknown so we can't get the private keys for anything about 3.55. and, lv 0.2, which I believe required a hardware revision - the key is unknown. if you've ever used PUAD to decrypt an update pup, it will error on the core os due to lv 0.2. it will still decrypt all other files, but it will skip that one. lv 0.2 seems to be a hash calculator for lv 0, so it will detect modifications.

So let me get this straight. For above 3.55, they added a file. This file is programmed to not be allowed to be signed with the 3.55 key. If it finds itself to be signed with said key, then it won't work. Then they covered it up with a new key that it would accept, that was a true random key?

So essentially a new crypto key inside the old one? If so, that's fucking genius.

 

[godreborn]

yes, the file's name is: spu_pkg_rvk_verifier.self. rvk probably stands for revoke. it's in the core os.

 

[Deleted User]

yes, the file's name is: spu_pkg_rvk_verifier.self. rvk probably stands for revoke. it's in the core os.

Huh. Cool. As I said, interesting fix, because people were sure there was nothing they could do to fix it. Thanks for the information mate, it's much appreciated!

 

[godreborn]

I'm not entirely sure how the random variable works though. with ECDSA, there's supposed to be some sort of carrier message that contains it since the system must know what it is.

 

[Deleted User]

I'm not entirely sure how the random variable works though. with ECDSA, there's supposed to be some sort of carrier message that contains it since the system must know what it is.

Yeah, I don't think we'll ever know how that works completely. Not unless The Doctor wants to jump in and do it for us haha.

 

[godreborn]

the original variable may have been stored on the ps3 itself due to sony's stupidity, but the new one is likely stored on sony's servers. it should be different for each firmware.

edit: I can see how it could be protected via an online update, but one u download yourself or one that's on a game - I'm not sure.