> 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
Take George Hotz as an example. He’s not in this thread and I doubt he wants to swing his massive dick but he’s a poster child for a pattern that comes up. Here are a few.
- Precocity and curiosity. Access to tech, resources, ways of actually getting answers instead of just hypothesizing. Though a curious mind will always conjure theories of all sorts.
- Working on an assortment of devices. Recent, old. Take them apart, ask how do they work. Read up about how they are constructed. Repeat.
- Robotics. Dead give away because robotics means embedded and embedded knowledge is gold. As is electronics knowledge among all the knowledge of how sensors actually work and what they do. You don’t wake up knowing how software and hardware interfaces. Along with learning this you learn a ridiculous amount regarding protocols, tools like logic analyzers and oscilloscopes, and patterns that repeat again and again. [0]
- Free time. This one is a given. This shit takes too long and all you’ve got are hunches along the way.
Take the recent CCC presentation on Miele appliances. The young presenter practically gives the punch line away: he fixes his parents’ house appliances, he rummages forum posts looking for information. He reads data sheets of processors and knows what pin does what. He looks at what others have done and wonders “what if?”. His whole presentation was so textbook and the appliance is an early 2000s model that it’s begging for someone with a shred of curiosity to take it apart and learn how it works. He finished by successfully dumping the firmware even when he thought it couldn’t be done. Along the way his “hunches” show he knows how things work because he’s worked on it before. The only people surprised are people who haven’t done it. He was going to succeed before he began - that’s how prepared you need to be.
Now, if you’re not a super talented 12 year old, that’s okay. Start programming microcontrollers and get comfortable with reading voltage levels and signals of GPIOs and peripherals. Learn how your firmware gets loaded at startup. Build some basic protocols and confirm on a logic analyzer. Decode your work with your eyes. Reading binary and hex should be second nature. Read and decode a USB protocol. An SPI protocol. And don’t complain it’s too much work.
Nitpicking: the media isn’t completely wrong. It can be used it just needs sone extra conditions but if they are given the leaked keys definitely help.
> 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.
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.
OtherOS existed for import tarifs reasons. Got removed when the need was gone. When the SCEA CISO warned Kaz Hirai removing it would lead to piracy, she got fired.
Then it happened.
Where do you have your bs from ?!
I thought they removed it because people were buying PS3's in bulk for datacenter use with OtherOS because the hardware was being sold for less than the cost of the parts with the expectation of getting their money back with game sales.
Is there any reason in particular you think this? Sony only removed the feature, citing "security concerns" mere months after George Hotz released the exploit. They would later go on to sue him. https://blog.playstation.com/archive/2010/03/29/ps3-firmware...
On the other hand, the Ps3 clusters were around since basically the console's launch. Additionally, the console had been selling at a profit, at least in the US, by 2009, before they removed the other os feature.
All this happened 16 years ago. If you're curious about stuff that has happened so recently, you can research it online.
I think this because it was all over the tech news outlets at the time that the primary reason was due to Sony losing money because of console hardware being sold below the price of the components themselves.
A company press release is not necessarily the be-all end-all full story when it comes to justifying something extremely unpopular with their customer base.
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.
I recall they lost a bit on selling the consoles to the USAF that were used as computer cluster. (The consoles afaik sell/sold? at below cost and rely on games to make up the extra cash) So they lose money on consoles that aren't having games bought.
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
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 on this hardware was just a curiosity to play with. Too slow and limited by the hardware to be useful.
> 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.
Wouldn't the other reason to have multiple manufacturer keys, be to guard against them losing the private key for one in a way that means they can't sign anything any more?
I mean, sure, but to what end does that madness lead? Who backs up the backups?
Usually this is to allow different departments / divisions / customers (in the case of an OEM model) to all sign code or encrypt binaries, although this is likewise a bit off as each enrolled key increases the amount of material which is available to leak in the leak model. Or to allow model line differentiation with crossover.
A TPM is a form of HSM (Hardware Security Module).
HSMs come in all sizes, from a chip in your phone (secure element) or even a dedicated part of a SoC chip, to a big box in a datacenter that can handle tons of requests per second.
The idea is having dedicated hardware to protect the private key material. This hardware can execute signing operations, so it can use the key but it can't share the key material itself. It is usually also physically hardened with techniques to extract said keys, like sidechannel attacks based on power draw, X-ray inspection, decapping etc.
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.
Wouldn't it be great if companies spent the time and effort needed for all these wonderful things that prevent the owner from using the hardware they own how they see fit and instead invested the resources into making the product better ?
All this is basically a fragile anti-user timebomb that will only generate more avoidable e-waste eventually.
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.
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.
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.
I hope this doesn't lead to further cracks, and PS5 multiplayer games being overrun with cheaters.
Once PS3 was cracked enough to run game mods, every PS3 GTA freeroam session was overrun with obnoxious cheaters, ruining it for everyone else. (Sorta like the tech industry.)
In most computer tech things, I'm all Linux, OpenWrt, Coreboot, GrapheneOS, etc., but the game console is one thing that that I like being locked down.
I don't, your forced under the mercy of that they keep supporting. At any time they can render your console usless and force you to upgrade.
Consoles are e-waste in my eyes, perfectly good for other uses but liocked to what the vendor wants to give. Limited by the hardware that's given and then nagged to buy latest model.
Why am I not allowed to turn an old PS4 in to a Linux router? It has a beast of a CPU, USB ports and suports SSD's, what's the issue?
> Shouldn't I be allowed to repurpose it for other uses than just a console when it becomes EOL?
Yes, once hardware becomes some kind of end-of-use, end-of-support, or end-of-life (exactly what, to-be-determined), the brand should be required to unlock any aspect that hasn't already been unlocked, so that people can reuse the hardware. (And maybe put the unlocks in escrow before then, in case the brand goes out of business.)
There are also situations in which hardware should be unlocked while within use and support. But probably not for a given gaming device, or not in a way that permits that hardware be used as the gaming device while unlocked.
Gaming consoles are a very rare thing that I want locked down, as long as I am sharing whatever pool of online gamers that device accesses. (Because online gaming has way too many people who haven't yet learned to play well with others, and cheating in multiplayer games is a thing that many do.)
And the fact that I have less control and ownership of a gaming device is one of the reasons why I use a dedicated device for gaming, and also isolate it on the guest VLAN.
Although, as someone who really tries hard to fight the environmental waste (I litter pick, I donate, I reuse, I repurpose) it hurts to see to walk by a second hand tech store with stacks of old consoles in the window (excluding retro here) knowing they will just end up in a landfilled polluting the world for the rest of entirety and cannot be used for anything more than a paper weight.
This isn't just gaming consoles.
My view is that cheating is a developer problem not hardware. If game companies actually enlisted proper moderation this wouldn't be an issue. Where can I report cheaters, How do I report cheaters? That's never a provided option to me. Although maybe now you i don't game online as much as I did, but even when you could, not one thing was done about it.
I kicked hackers back in the day in my CS:S servers. If they actually hired moderators who actually did their job then this wouldn't be so much of a problem.
Your right, and I don't disagree. Knowing that the device is locked down I cannot ensure that I am not being used for monterey gain.
Isolating to a VLAN should be the de-facto but most outside of tech have no idea what that is, so now you have a lockable console prone to monitoring all for the sake of mitigation of hacking and to force you to upgrade for cash grabs.
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?
Oh the travesty! People now have the keys to unlock hardware they paid money to and legally 'own', and can inspect their legally owned hardware as they choose!
iOS hasn't had a jailbreak since ios 15.5, or 17 if you own a iPhone 11.
Nintendo DS is now kind of EOL. So the era of Flashcarts and the likes are gone. I remeber the toothpick wrapped in tinfoil to flash a custom firmware trick and applying it to my DS. The recent lawsuit kind of killed the main provider to these carts.
PS3+, Nintendo Switch have had e-fuses which now look out the console when attempting CFW.
PC Games are now protected by Denuvo which are almost impossible to crack apart from a couple of folk, one who is slightly mental and another who only does racing games.
The android bootloader is being locked down to stop custom firmware. Microsoft is attempting to lock the user out unless you upgrade to Windows 11 with TPM.
Emulation is another game, but Nintendo throws a lawsut if you attempt. Sony is locking down by having to dump your own firmware although I am not sure about Xbox emulation.
Exactly. Not only that, the downstream effects and consolidation on platforms like Discord, Reddit, etc that heavily regulate the operators has a real chilling effect on making these tools and experiences less user-friendly than in the past. Feels like the golden era is way past us for people who have been in the game for a while.
lolwut? For phones it’s one thing but even the Switch has Atmosphere CFW for hackable or modded units and it seems like multiple switch emulators have emerged from the ashes of Yuzu. And for earlier consoles the situation is even more comprehensive with high quality emulators and homebrew firmware. And as a bonus, there’s a new game in town for cracking Denuvo in recent weeks ;)
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?
In this case, by using fault injection to induce a glitch into a test mode which bypasses secure boot and loads code from SPI, combined with a SPI emulator (and I2C to send the boot vectors).
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.
This is the same hardware as a PC, but TPM and UEFI “Secure Boot” happen way, way later in the boot process and aren’t present here; this is the hardware root of trust, in this case the AMD PSP boot firmware, which runs on an ARM system alongside the x86 cores. Intel’s version is called Boot Guard and runs on a combination of x86 sub-cores (TXE) and ME.
I've been firmly convinced for a while now that Sony purposely doesn't discourage jailbreakers too strongly. They quietly win loyalty by being just a little friendlier than Nintendo.
> 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
do you have any resource for outsiders to learn/delve into these topics ?????
I always fascinated by works of people that try to reverse engineer this secure system
Hacking the xbox is a great read The Hardware Hacking Handbook by no starch is a good modern intro.
Take George Hotz as an example. He’s not in this thread and I doubt he wants to swing his massive dick but he’s a poster child for a pattern that comes up. Here are a few.
- Precocity and curiosity. Access to tech, resources, ways of actually getting answers instead of just hypothesizing. Though a curious mind will always conjure theories of all sorts.
- Working on an assortment of devices. Recent, old. Take them apart, ask how do they work. Read up about how they are constructed. Repeat.
- Robotics. Dead give away because robotics means embedded and embedded knowledge is gold. As is electronics knowledge among all the knowledge of how sensors actually work and what they do. You don’t wake up knowing how software and hardware interfaces. Along with learning this you learn a ridiculous amount regarding protocols, tools like logic analyzers and oscilloscopes, and patterns that repeat again and again. [0]
- Free time. This one is a given. This shit takes too long and all you’ve got are hunches along the way.
Take the recent CCC presentation on Miele appliances. The young presenter practically gives the punch line away: he fixes his parents’ house appliances, he rummages forum posts looking for information. He reads data sheets of processors and knows what pin does what. He looks at what others have done and wonders “what if?”. His whole presentation was so textbook and the appliance is an early 2000s model that it’s begging for someone with a shred of curiosity to take it apart and learn how it works. He finished by successfully dumping the firmware even when he thought it couldn’t be done. Along the way his “hunches” show he knows how things work because he’s worked on it before. The only people surprised are people who haven’t done it. He was going to succeed before he began - that’s how prepared you need to be.
Now, if you’re not a super talented 12 year old, that’s okay. Start programming microcontrollers and get comfortable with reading voltage levels and signals of GPIOs and peripherals. Learn how your firmware gets loaded at startup. Build some basic protocols and confirm on a logic analyzer. Decode your work with your eyes. Reading binary and hex should be second nature. Read and decode a USB protocol. An SPI protocol. And don’t complain it’s too much work.
[0] https://m.youtube.com/watch?v=C1C-DrRZAfw
Nitpicking: the media isn’t completely wrong. It can be used it just needs sone extra conditions but if they are given the leaked keys definitely help.
> 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.
> 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.
OtherOS existed for import tarifs reasons. Got removed when the need was gone. When the SCEA CISO warned Kaz Hirai removing it would lead to piracy, she got fired. Then it happened. Where do you have your bs from ?!
I thought they removed it because people were buying PS3's in bulk for datacenter use with OtherOS because the hardware was being sold for less than the cost of the parts with the expectation of getting their money back with game sales.
Is there any reason in particular you think this? Sony only removed the feature, citing "security concerns" mere months after George Hotz released the exploit. They would later go on to sue him. https://blog.playstation.com/archive/2010/03/29/ps3-firmware...
On the other hand, the Ps3 clusters were around since basically the console's launch. Additionally, the console had been selling at a profit, at least in the US, by 2009, before they removed the other os feature.
All this happened 16 years ago. If you're curious about stuff that has happened so recently, you can research it online.
I think this because it was all over the tech news outlets at the time that the primary reason was due to Sony losing money because of console hardware being sold below the price of the components themselves.
A company press release is not necessarily the be-all end-all full story when it comes to justifying something extremely unpopular with their customer base.
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.
I recall they lost a bit on selling the consoles to the USAF that were used as computer cluster. (The consoles afaik sell/sold? at below cost and rely on games to make up the extra cash) So they lose money on consoles that aren't having games bought.
The consoles were reportedly selling at a profit (at least in the US) by 2009. Reports about the USAF condor cluster surfaced in 2010.
i'm sure they profited overall, but this was costing them a little right?
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
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 on this hardware was just a curiosity to play with. Too slow and limited by the hardware to be useful.
But it was fun.
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.
Wouldn't the other reason to have multiple manufacturer keys, be to guard against them losing the private key for one in a way that means they can't sign anything any more?
I mean, sure, but to what end does that madness lead? Who backs up the backups?
Usually this is to allow different departments / divisions / customers (in the case of an OEM model) to all sign code or encrypt binaries, although this is likewise a bit off as each enrolled key increases the amount of material which is available to leak in the leak model. Or to allow model line differentiation with crossover.
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.
HSM or TPM?
A TPM is a form of HSM (Hardware Security Module).
HSMs come in all sizes, from a chip in your phone (secure element) or even a dedicated part of a SoC chip, to a big box in a datacenter that can handle tons of requests per second.
The idea is having dedicated hardware to protect the private key material. This hardware can execute signing operations, so it can use the key but it can't share the key material itself. It is usually also physically hardened with techniques to extract said keys, like sidechannel attacks based on power draw, X-ray inspection, decapping etc.
Thanks - I know the difference
This also sounds very AI-like
Hypothetically Secure Memory
(I guess)
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...
Wouldn't it be great if companies spent the time and effort needed for all these wonderful things that prevent the owner from using the hardware they own how they see fit and instead invested the resources into making the product better ?
All this is basically a fragile anti-user timebomb that will only generate more avoidable e-waste eventually.
For some users, preventing downgrades to an insecure version is a better product since it protects against evil maid attacks.
(Although ideally they would itself trap that functionality behind a fuse, so you have to opt-in but can't be opted out.)
You can get a similar level of protection against evil maids by requiring a wipe to downgrade.
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?
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.
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...
Even if trivial it could be manufacturing savings.
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.
I hope this doesn't lead to further cracks, and PS5 multiplayer games being overrun with cheaters.
Once PS3 was cracked enough to run game mods, every PS3 GTA freeroam session was overrun with obnoxious cheaters, ruining it for everyone else. (Sorta like the tech industry.)
In most computer tech things, I'm all Linux, OpenWrt, Coreboot, GrapheneOS, etc., but the game console is one thing that that I like being locked down.
I don't, your forced under the mercy of that they keep supporting. At any time they can render your console usless and force you to upgrade.
Consoles are e-waste in my eyes, perfectly good for other uses but liocked to what the vendor wants to give. Limited by the hardware that's given and then nagged to buy latest model.
Why am I not allowed to turn an old PS4 in to a Linux router? It has a beast of a CPU, USB ports and suports SSD's, what's the issue?
> Why can't I turn an old PS4 in to a Linux router?
I simply sell my game consoles when I'm done with them.
They would make terrible Linux routers, even if they were unlocked.
Sure, you can do that. However the taste knowing that I will soon be nagged to update with less features working makes it a waste, I paid $$$ for it.
Shouldn't I be allowed to repurpose it for other uses than just a console when it becomes EOL?
> Shouldn't I be allowed to repurpose it for other uses than just a console when it becomes EOL?
Yes, once hardware becomes some kind of end-of-use, end-of-support, or end-of-life (exactly what, to-be-determined), the brand should be required to unlock any aspect that hasn't already been unlocked, so that people can reuse the hardware. (And maybe put the unlocks in escrow before then, in case the brand goes out of business.)
There are also situations in which hardware should be unlocked while within use and support. But probably not for a given gaming device, or not in a way that permits that hardware be used as the gaming device while unlocked.
Gaming consoles are a very rare thing that I want locked down, as long as I am sharing whatever pool of online gamers that device accesses. (Because online gaming has way too many people who haven't yet learned to play well with others, and cheating in multiplayer games is a thing that many do.)
And the fact that I have less control and ownership of a gaming device is one of the reasons why I use a dedicated device for gaming, and also isolate it on the guest VLAN.
This is now moot, we both have different views.
Although, as someone who really tries hard to fight the environmental waste (I litter pick, I donate, I reuse, I repurpose) it hurts to see to walk by a second hand tech store with stacks of old consoles in the window (excluding retro here) knowing they will just end up in a landfilled polluting the world for the rest of entirety and cannot be used for anything more than a paper weight.
This isn't just gaming consoles.
My view is that cheating is a developer problem not hardware. If game companies actually enlisted proper moderation this wouldn't be an issue. Where can I report cheaters, How do I report cheaters? That's never a provided option to me. Although maybe now you i don't game online as much as I did, but even when you could, not one thing was done about it.
I kicked hackers back in the day in my CS:S servers. If they actually hired moderators who actually did their job then this wouldn't be so much of a problem.
Your right, and I don't disagree. Knowing that the device is locked down I cannot ensure that I am not being used for monterey gain.
Isolating to a VLAN should be the de-facto but most outside of tech have no idea what that is, so now you have a lockable console prone to monitoring all for the sake of mitigation of hacking and to force you to upgrade for cash grabs.
> 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?
Oh the travesty! People now have the keys to unlock hardware they paid money to and legally 'own', and can inspect their legally owned hardware as they choose!
/sarcasm
Jailbreaking, emulation and gaming communities are so far gone at this point that it's hard to understand the impact here.
What do you mean?
iOS hasn't had a jailbreak since ios 15.5, or 17 if you own a iPhone 11.
Nintendo DS is now kind of EOL. So the era of Flashcarts and the likes are gone. I remeber the toothpick wrapped in tinfoil to flash a custom firmware trick and applying it to my DS. The recent lawsuit kind of killed the main provider to these carts.
PS3+, Nintendo Switch have had e-fuses which now look out the console when attempting CFW.
PC Games are now protected by Denuvo which are almost impossible to crack apart from a couple of folk, one who is slightly mental and another who only does racing games.
The android bootloader is being locked down to stop custom firmware. Microsoft is attempting to lock the user out unless you upgrade to Windows 11 with TPM.
Emulation is another game, but Nintendo throws a lawsut if you attempt. Sony is locking down by having to dump your own firmware although I am not sure about Xbox emulation.
Exactly. Not only that, the downstream effects and consolidation on platforms like Discord, Reddit, etc that heavily regulate the operators has a real chilling effect on making these tools and experiences less user-friendly than in the past. Feels like the golden era is way past us for people who have been in the game for a while.
Please see my comment above.
That's because jailbreak became irrelevant. The EU mandated sideloading, and for those of us elsewhere, there is this: https://sidestore.io/
lolwut? For phones it’s one thing but even the Switch has Atmosphere CFW for hackable or modded units and it seems like multiple switch emulators have emerged from the ashes of Yuzu. And for earlier consoles the situation is even more comprehensive with high quality emulators and homebrew firmware. And as a bonus, there’s a new game in town for cracking Denuvo in recent weeks ;)
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?
In this case, by using fault injection to induce a glitch into a test mode which bypasses secure boot and loads code from SPI, combined with a SPI emulator (and I2C to send the boot vectors).
https://m.youtube.com/watch?v=cVJZYT8kYsI
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?
This is the same hardware as a PC, but TPM and UEFI “Secure Boot” happen way, way later in the boot process and aren’t present here; this is the hardware root of trust, in this case the AMD PSP boot firmware, which runs on an ARM system alongside the x86 cores. Intel’s version is called Boot Guard and runs on a combination of x86 sub-cores (TXE) and ME.
https://news.ycombinator.com/item?id=46445107
... you mean every PS still uses the same key?
I've been firmly convinced for a while now that Sony purposely doesn't discourage jailbreakers too strongly. They quietly win loyalty by being just a little friendlier than Nintendo.
Odds are the Japanese leadership in charge of the hardware can't use a computer, so doesn't understand them.
Ref: https://www.pcmag.com/news/japans-cyber-security-minister-do...
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.