When Sony creates a newer hardware revision with a different metldr key, they would have to issue 2 different firmware updates: one of the current hardware, and one for the new hardware. This is because if they update the metldr keys, all of the ldrs down the chain will need to be re-encrypted with the new key, and signed with the new key. (In theory, they could also publish a single unified update which decides which one to install at runtime.)
So assuming we have current hardware, with the currently known and leaked metldr key, and Sony publishes an update, we can:
- Decrypt the update, and all levels of the firmware from lv0 downwards (we have the decryption key)
- We can update any revocation list they provide, we can update any whitelist they provide, we can remove any signature checks they add.
- We can re-encrypt the update (its symmetric, and we have the keys), and we can resign the update (we have the private ECDSA keys)
- We can install our newly “hacked” update…
Lets say Sony tries to be smart and adds some self CRC/Hash calculation code to their new firmware:
- We can decrypt the firmware
- We can update the CRC calculation code to always return the correct expected value
- We can encrypt, sign and install our hacked new firmware.
- Sony can’t tell the difference between a hacked firmware and a real one.
Let’s say our user is dumb, has a current hardware PS3 and updated it to Sony’s new firmware with a whitelist for old apps and a revokelist for old firmware, and newer firmware updates are signed with new PKI keys:
- We can flash the flashrom (using a hardware flasher) with our own firmware since we have the metldr keys.
- Alternatively a “modchip” can be installed beside the flashrom to provide the firmware code.
- The console has to accept it because metldr will decrypt it and verify the signature.
This is what khrak is referring to when he says that its broken in an unfixable way. There is absolutely nothing Sony can do short of updating metldr, or having some secret backup metldr with different keys to fix the issue on current hardware. Even with a backup metldr, geohot (who due to egotistic reasons has not revealed how he got the metldr keys) can probably recover the new metldr keys using whatever exploit he used again.