> news sites are overhyping the release/leak/whatever of the rom keyseeds, saying it could be used to fully unlock the ps5. i've already stated on twitter and i'll state it again. rom and seeds alone are NOT enough to pwn a ps5, you either need fuses and nandgroups to complement it
> ... or alternatively, you need to find bugs in the rom that you can use to exploit the ps5. neither of these are easy and require immense work. also, decapping a ps5 apu to retrieve the fuses optically will prove useless to the end user because those fuses are encrypted/xored/obfuscated
> According to The Cybersec Guru, this is an unpatchable problem for Sony, because these keys cannot be changed and are burned directly in the APU.
I'm just speculating at this point, but what could prevent Sony from anticipating this exact situation and burning several keys in the APU? I mean, eFuse is not exactly a new technology. That way, once a key is leaked, Sony could push a firmware update switching the APU to a new key which hasn't been leaked yet.
I have seen some manufacturers enroll multiple manufacturer keys, probably with this notion, but this isn’t useful against almost any threat model.
If keys are recovered using some form of low level hardware attack, as was almost surely the case here, the attacker can usually recover the unused key sets too.
If the chip manufacturing provisioning supply chain is leaky the new keys will probably be disclosed anyway, and if the key custody chain is broken (ie, keys are shared with OEMs or third parties) they will definitely be disclosed anyway.
Yes, but console vendors generally prefer not to allow downgrades.
So if v1 is signed by key A, v2 is signed by key B and invalidates key A; a console that installs v2 wouldn't be able to install v1 after, but that's not a problem for Sony.
But, I'm not sure how many companies would be able to manage their keys properly to ensure that someone with access to key A doesn't have access to key B.
If these are asymmetric key pairs and the device side key was extracted from the device... Switching keys wouldn't help, and it's not a huge deal by itself --- having the device side key doesn't allow you to make a firmware image the device would accept.
Fun fact, the Nintendo Switch blows fuses [0] when they do a patch that’s for security/jailbreaking. If I recall there’s something like 12 or 16 fuses they can employ over the life of the product to ensure you can’t rollback updates that prevent piracy. Nvidia builds these fuses into the board.
So if you’ve blown 4 fuses you can’t do a patch that requires only 2 fuses to have blown, it’s a pretty wild solution.
It isn't that wild; the typical name for it is anti-rollback, and you probably have at least one device that implements it. Most Android devices have anti-rollback efuses to prevent installing older versions of the bootchain\bootloader; they might still allow you to downgrade the OS (depends on the vendor, if memory serves). Instead of using efuse counters, anti-rollback counters can also be implemented by Replay Protected Memory Block (RPMB), which is implemented by many flash storage (eMMC often supports RPMB, but other storage types can as well). It is possible to implement anti-rollback mechanisms on x86_64 by utilizing a TPM [0], but as far as I know, only Chrome OS does this.
Here's an excerpt about the anti-rollback feature from Nvidia's docs on how the Tegra X1 SoC in the switch 1 boots [0] (called Tegra210 in the document)
> By default, the boot ROM will only consider bootloader entries with a version field that matches the version field of the first entry, and will stop iterating through the entries is a mismatch is found. The intent is to ensure that if some subset of the bootloader entries are upgraded, and hence the version field of their entries is modified, then the boot ROM will only boot the most recent version of the bootloader. This prevents an accidental rollback to an earlier version of the bootloader in the face of boot memory read errors, corruption, or tampering. Observe that this relies on upgraded bootloader entries being placed contiguously at the start of the array.
Yeah, that shouldn't happen (although I think I've seen reports of eFuses blowing spontaneously as well as eFuses self-repairing)
If your console blows a fuse before Nintendo intends to, you won't be able to install firmware until a firmware is released that will run with that number of fuses blown. And, depending on how things are implemented, you might not be able to run the firmware that you have either.
> This isn’t the first time that Sony has had to deal with a security crisis with the popular PlayStation family. The PlayStation 3 was previously hit with a vulnerability when the company made a mistake with their cryptography on the console, allowing users to install homebrew software and allow piracy and cheating on popular titles.
Probably could have been avoided if Sony kept the Linux version of the Playstation still alive. Imagine what the (console) world would have looked like, if it was still alive. I never got the chance to even try it myself before it was gone, but I'm sure a lot of the homebrew community's energy could have been redirected towards it instead, hitting two flies with one swath.
I had Yellowdog on mine from the day I bought it until the day Sony erased it. It was not useful. I don't regret doing it and I HATE that they took it away, and I'm a linux/bsd/various-unix daily driver home and work since forever, but this linux system om on this hardware was just a curiosity to play with. Too slow and limited by the hardware to be useful.
More like it only happened because Sony restricted hardware access under Linux. If they had allowed GPU access, there would have been no motivation to attack the hypervisor.
It only ever was present because Sony wanted to cheat EU import tariffs - by allowing other operating systems, it could be imported under the lower general-purpose computer rate.
IMHO, removal of this feature should have triggered Sony having to pay back the amount of taxes cheated.
If anyone is interested in the cryptography mistake that Sony made I recommend watching the Console Hacking talk at 27c3 by the fail0verflow team: https://youtu.be/DUGGJpn2_zY?t=2096
How did the keys get leaked and where are they sourcing this from? Did Sony get compromised, disgruntled employee, what?
If there was a breach, I'd expect keys for the PS4 to be leaked as well which would be quite handy. There are soft jailbreaks you can do currently on the PS4, but they're not full on CFW (custom firmware) and don't persist reboots.
Based on the other comments it looks like it's the decryption keys for the bootrom, which obviously have to be available somehow to every PS5 for it to be able to boot. That means they probably compromised the processor or something, but no need to invoke "Sony get compromised" or "disgruntled employee".
The story implies that they're signing keys (ie it says the keys are used to check the validity of the boot firmware). If they were encryption secrets stored on the chip, they'd have been extracted, not leaked.
General question: (I don't know enough about cryptography)
Are these symmetric keys or asymmetric ones? Both allow you to decrypt, but only the former would allow you to make changes to it, whereas the latter would still require you to find an exploit in the next stage. I think?
given that there is no dev mode or ssh server running on a console, how do they even read low level binary code such as boot loader? Do they transplant memory chips?
Chip-off is a common way to retrieve the ROM of embedded devices. It often requires multiple chip-off reads and a reconstruction of the striped data across the chips.
> Now that the ROM keys have been leaked (and assuming they are valid), a hacker could then decrypt and study the official bootloader and potentially use that as a starting point to understand how the PS5’s boot system works.
https://xcancel.com/notnotzecoxao/status/2006525981113332025
> news sites are overhyping the release/leak/whatever of the rom keyseeds, saying it could be used to fully unlock the ps5. i've already stated on twitter and i'll state it again. rom and seeds alone are NOT enough to pwn a ps5, you either need fuses and nandgroups to complement it
> ... or alternatively, you need to find bugs in the rom that you can use to exploit the ps5. neither of these are easy and require immense work. also, decapping a ps5 apu to retrieve the fuses optically will prove useless to the end user because those fuses are encrypted/xored/obfuscated
The article says:
> According to The Cybersec Guru, this is an unpatchable problem for Sony, because these keys cannot be changed and are burned directly in the APU.
I'm just speculating at this point, but what could prevent Sony from anticipating this exact situation and burning several keys in the APU? I mean, eFuse is not exactly a new technology. That way, once a key is leaked, Sony could push a firmware update switching the APU to a new key which hasn't been leaked yet.
I have seen some manufacturers enroll multiple manufacturer keys, probably with this notion, but this isn’t useful against almost any threat model.
If keys are recovered using some form of low level hardware attack, as was almost surely the case here, the attacker can usually recover the unused key sets too.
If the chip manufacturing provisioning supply chain is leaky the new keys will probably be disclosed anyway, and if the key custody chain is broken (ie, keys are shared with OEMs or third parties) they will definitely be disclosed anyway.
Nothing. But if the keys weren't stored in an HSM (seems likely), attackers getting one of them implies they could get the others as well.
Would that not break every other firmware release that relied on that older key?
Yes, but console vendors generally prefer not to allow downgrades.
So if v1 is signed by key A, v2 is signed by key B and invalidates key A; a console that installs v2 wouldn't be able to install v1 after, but that's not a problem for Sony.
But, I'm not sure how many companies would be able to manage their keys properly to ensure that someone with access to key A doesn't have access to key B.
If these are asymmetric key pairs and the device side key was extracted from the device... Switching keys wouldn't help, and it's not a huge deal by itself --- having the device side key doesn't allow you to make a firmware image the device would accept.
Fun fact, the Nintendo Switch blows fuses [0] when they do a patch that’s for security/jailbreaking. If I recall there’s something like 12 or 16 fuses they can employ over the life of the product to ensure you can’t rollback updates that prevent piracy. Nvidia builds these fuses into the board.
So if you’ve blown 4 fuses you can’t do a patch that requires only 2 fuses to have blown, it’s a pretty wild solution.
Edit: it’s actually 22 fuses
[0] https://switchbrew.org/wiki/Fuses
It isn't that wild; the typical name for it is anti-rollback, and you probably have at least one device that implements it. Most Android devices have anti-rollback efuses to prevent installing older versions of the bootchain\bootloader; they might still allow you to downgrade the OS (depends on the vendor, if memory serves). Instead of using efuse counters, anti-rollback counters can also be implemented by Replay Protected Memory Block (RPMB), which is implemented by many flash storage (eMMC often supports RPMB, but other storage types can as well). It is possible to implement anti-rollback mechanisms on x86_64 by utilizing a TPM [0], but as far as I know, only Chrome OS does this.
[0]: https://www.chromium.org/developers/design-documents/tpm-usa...
I’m not following. Why would it be helpful to check how many fuses had been blown? And how could you have more blown fuses than you’re supposed to?
Here's an excerpt about the anti-rollback feature from Nvidia's docs on how the Tegra X1 SoC in the switch 1 boots [0] (called Tegra210 in the document)
> By default, the boot ROM will only consider bootloader entries with a version field that matches the version field of the first entry, and will stop iterating through the entries is a mismatch is found. The intent is to ensure that if some subset of the bootloader entries are upgraded, and hence the version field of their entries is modified, then the boot ROM will only boot the most recent version of the bootloader. This prevents an accidental rollback to an earlier version of the bootloader in the face of boot memory read errors, corruption, or tampering. Observe that this relies on upgraded bootloader entries being placed contiguously at the start of the array.
[0] https://http.download.nvidia.com/tegra-public-appnotes/tegra...
Firmware v1 requires a switch with zero fuses blown.
Firmware v2 requires a switch with no more than one fuse blown and blows the first fuse.
If you install v2, you can't install v1.
Nintendo can make 22 firmware releases that disallow rollback.
Got it. Thanks. For some reason I was imagining a new firmware that some people couldn’t install because they had blown too many fuses.
Yeah, that shouldn't happen (although I think I've seen reports of eFuses blowing spontaneously as well as eFuses self-repairing)
If your console blows a fuse before Nintendo intends to, you won't be able to install firmware until a firmware is released that will run with that number of fuses blown. And, depending on how things are implemented, you might not be able to run the firmware that you have either.
Even if trivial it could be manufacturing savings.
> This isn’t the first time that Sony has had to deal with a security crisis with the popular PlayStation family. The PlayStation 3 was previously hit with a vulnerability when the company made a mistake with their cryptography on the console, allowing users to install homebrew software and allow piracy and cheating on popular titles.
Probably could have been avoided if Sony kept the Linux version of the Playstation still alive. Imagine what the (console) world would have looked like, if it was still alive. I never got the chance to even try it myself before it was gone, but I'm sure a lot of the homebrew community's energy could have been redirected towards it instead, hitting two flies with one swath.
I had Yellowdog on mine from the day I bought it until the day Sony erased it. It was not useful. I don't regret doing it and I HATE that they took it away, and I'm a linux/bsd/various-unix daily driver home and work since forever, but this linux system om on this hardware was just a curiosity to play with. Too slow and limited by the hardware to be useful.
But it was fun.
> Probably could have been avoided if Sony kept the Linux version of the Playstation still alive.
The causality here is backwards; Sony removed Other OS support precisely because the first jailbreak (a glitching attack) relied on it.
More like it only happened because Sony restricted hardware access under Linux. If they had allowed GPU access, there would have been no motivation to attack the hypervisor.
It only ever was present because Sony wanted to cheat EU import tariffs - by allowing other operating systems, it could be imported under the lower general-purpose computer rate.
IMHO, removal of this feature should have triggered Sony having to pay back the amount of taxes cheated.
If anyone is interested in the cryptography mistake that Sony made I recommend watching the Console Hacking talk at 27c3 by the fail0verflow team: https://youtu.be/DUGGJpn2_zY?t=2096
How did the keys get leaked and where are they sourcing this from? Did Sony get compromised, disgruntled employee, what?
If there was a breach, I'd expect keys for the PS4 to be leaked as well which would be quite handy. There are soft jailbreaks you can do currently on the PS4, but they're not full on CFW (custom firmware) and don't persist reboots.
Based on the other comments it looks like it's the decryption keys for the bootrom, which obviously have to be available somehow to every PS5 for it to be able to boot. That means they probably compromised the processor or something, but no need to invoke "Sony get compromised" or "disgruntled employee".
The story implies that they're signing keys (ie it says the keys are used to check the validity of the boot firmware). If they were encryption secrets stored on the chip, they'd have been extracted, not leaked.
This is probably based on the research outlined in this ccc presentation: https://youtu.be/cVJZYT8kYsI
This also goes into a bit more detail regarding how these keys are used.
> https://thecybersecguru.com/news/ps5-rom-keys-leaked/#:~:tex...
Nasty filler to add that to the page.
General question: (I don't know enough about cryptography)
Are these symmetric keys or asymmetric ones? Both allow you to decrypt, but only the former would allow you to make changes to it, whereas the latter would still require you to find an exploit in the next stage. I think?
given that there is no dev mode or ssh server running on a console, how do they even read low level binary code such as boot loader? Do they transplant memory chips?
Chip-off is a common way to retrieve the ROM of embedded devices. It often requires multiple chip-off reads and a reconstruction of the striped data across the chips.
I guess this is similar to TPM / secure boot on a pc?
https://news.ycombinator.com/item?id=46445107
... you mean every PS still uses the same key?
As in, you can now craft your own "update" and sign the bootloader/entire package and it will flash?
edit:
> You still won't get a jailbroken PlayStation 5 with this leak, but it will make it easier for hackers to compromise the console's bootloader.
nope?
> Now that the ROM keys have been leaked (and assuming they are valid), a hacker could then decrypt and study the official bootloader and potentially use that as a starting point to understand how the PS5’s boot system works.
This would just allow further study.