Long time PS3 scener from Spain, Waninkoko, has giving his insight into the development of 3.61 CFW and the consequences of running it. While i don’t get much of what he has been talking about on TeknoConsolas, he certainly is informative in bringing up the issues of metldr, appldr, lv2ldr, etc, the security architecture in PS3 where he is making the spotlight on which to hack in order to decrypt those keys in the process of building up the custom firmware.
Bah, I’m not even sure what i have been dissing about just now, but one thing for sure, someone is looking to get the ludicrous 3.61 CFW out of the misery. And yeah, Waninkoko probably is returning back to the scene after tweetedly leaving few months ago. Check his translated post below (Thanks to PS3-Addict for getting me a cache of the post after the original link is down):
Waninkoko’s 3.61 CFW theory
Private keys can not be calculated from a firmware> = 3.56, and they ARE NOT AVAILABLE, and this, no site … They are private, and only the Sony has.
If we were able to extract a time it was a mistake by Sony developers, who applied the wrong encryption algorithm, which helped us with some data and mathematical operations to calculate the private keys.
You can create a CFW 3.61, the only obstacle are the public keys, which can be extracted, with varying degrees of difficulty, but they can be …
Each loader is encrypted with a private key, and decrypts it with the corresponding public key.
Loader but the lowest level in FW, stood and decrypts it with the root key, which is invariable, because-as the root public key used to encrypt and decipher what is in the Loader Metldr.
Obviously, this Metldr should have the public key used to decrypt the Loader, and not Metldr IN NO EVENT be updated. So the root key can not be changed from one version to another firmware, because-that nothing would work.
So if we want to create a CFW 3.61, by changing the LV2 to add new functions, we have the whole chain of hacker Loaders to reach the final.
METLDR -> LV0LDR -> LV0 -> LV1LDR -> LV1 -> LV2LDR -> LV2
It’s more or less the chain of Loaders, I do not know if there are some variations in FW 3.61.
METLDR, as I said can not be updated
METLDR LV0LDR decrypts with the Root Key (LV0LDR Loader is the lowest level, if it fails METLDR) and executes it.
LV0LDR LV0 decrypts with the key LV0-Key (this key can be changed between different firmware versions because LV0LDR can be updated by encrypting LV0 with a private key and updating LV0LDR for it decrypts it with the new public key corresponding ), and executes it.
LV0 decrypts LV1LDR ….
LV2LDR decrypts with LV2 LV2-Key and executes it.
However, if we want a CFW, we must decipher LV0LDR (with the Root Key, which was published by Geohot and that will never change), change LV0LDR change the encryption key LV0 (it is a key exchange can to decrypt an encrypted LV0 with a private key that we know of) …
What private key? any … since it is us who will impede the key … we figure LV0LDR with the Root Key, you can then edit however you want LV0 LV0 now that is decrypted with a different public key, which we know the private key.
It modifies the whole chain up Loaders LV2, modifying and encrypting it with the new key that we have chosen …
This is the method in its broad lines (when I say encrypt / decrypt, I am not referring to the content of Loaders, because it works with-AES is a symmetric encryption which makes no sense talk about key public / private, I really am referring to the root of these Loaders, signature, which uses RSA and intervene where the public / private key, with the sole purpose of verifying that these were not Loaders modified).
For FW 3.61, the subject is a bit more complex, because the public key-RSA and AES are not easy to obtain, but there are ways to get them, people who possess them, it’s not impossible …
Now he must know that CFW can be installed only if you are on a FW 3.55 or lower, because the early versions use a higher discount new mode, which verifies the packets (data on PUP), checking of new signatures (which did not previously exist and which are now mandatory), we do not own, nor the public key or private key.
We can extract the public key, but the private key can be forgotten, and there is no form of chain to prevent it.
The “updater” is a separate application of FW and nothing to do with what has been explained above.
That said, switching to a CFW 3.56/3.60/3.61, you can not revert to another CFW (ie you are stuck with this version of CFW or an official FW), and it is inevitable. . because, said that in creating the CFW, you can change the VSH (or whatever it is), to use the old “update” (which does not check for new signatures and does nothing to install new CFW).
APPLDR or change to enable us to load the new “update”, but modified to not check for new signatures (the new “update” can be changed, of course, but we must also modify the APPLDR FW currently installed to re-encrypt this “update” with a private key known so that APPLDR be able to decrypt and execute).
He also posted some clarifications over his 3.61 CFW theory at Elotrolado.
1. I myself have said that somehow know some details of the FW 3.60/3.61, so if I dropped something wrong and tell, do not take this to the letter.
2. This is an explanation for that, with a vocabulary more or less simple, people will understand.
3. LV0LDR … I cast, but is normal when most of the knowledge I have a bit rusty (not that lv0ldr remembered at all in the time of writing the text, but I put so as is because the explanation I gave at first was not addressed to sceners far, so I cared little confused with bootldr lv0ldr and details LV0 load).
4. Mind you, when I talk about appldr to update, do not say that appldr care of it and the security checks, not even close. I mean, one option is to modify APPLDR in order to patch, and reforming the PUP updater and avoid check these headers (logically this method only allows you to upgrade to new CFW if you are in a CFW with APPLDR amended, and the PUP not work on other CFW or OFW).
Again, you do not take the text literally. NO is intended for the sceners, but ordinary people who have no idea about all this and wonders what happens to a CFW 3.60/3.61, omitting many details and going over things. And as I said in the text, 3.60/3.61 know certain details so I can be wrong at some point (rather text could be associated with CFW 3.56 in any case …).
Let us know what you think of Waninkoko’s theory, is it something viable in getting 3.61 CFW up and running for the masses?