[HN Gopher] Sony PS5 ROM keys leaked - jailbreaking could be mad...
       ___________________________________________________________________
        
       Sony PS5 ROM keys leaked - jailbreaking could be made easier with
       BootROM codes
        
       Author : gloxkiqcza
       Score  : 222 points
       Date   : 2026-01-01 15:57 UTC (7 hours ago)
        
 (HTM) web link (www.tomshardware.com)
 (TXT) w3m dump (www.tomshardware.com)
        
       | MuffinFlavored wrote:
       | 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?
        
         | peddling-brink wrote:
         | > 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.
        
       | hypeatei wrote:
       | 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.
        
         | gruez wrote:
         | 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".
        
           | EPWN3D wrote:
           | 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.
        
       | m00dy wrote:
       | https://news.ycombinator.com/item?id=46445107
        
       | naoru wrote:
       | 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.
        
         | ghshephard wrote:
         | Would that not break every other firmware release that relied
         | on that older key?
        
           | toast0 wrote:
           | 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.
        
             | wincy wrote:
             | 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
        
               | jtbayly wrote:
               | 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?
        
               | toast0 wrote:
               | 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.
        
               | jtbayly wrote:
               | 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.
        
               | toast0 wrote:
               | 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.
        
               | zorgmonkey wrote:
               | 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...
        
               | zorgmonkey wrote:
               | 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...
        
               | m4rtink wrote:
               | 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.
        
               | Uvix wrote:
               | 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.)
        
               | Dylan16807 wrote:
               | You can get a similar level of protection against evil
               | maids by requiring a wipe to downgrade.
        
         | j45 wrote:
         | Even if trivial it could be manufacturing savings.
        
         | EPWN3D wrote:
         | 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.
        
           | firesteelrain wrote:
           | HSM or TPM?
        
             | tosti wrote:
             | Hypothetically Secure Memory
             | 
             | (I guess)
        
             | wolvoleo wrote:
             | 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.
        
         | bri3d wrote:
         | 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.
        
           | trebligdivad wrote:
           | 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?
        
             | bri3d wrote:
             | 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.
        
       | sagacity wrote:
       | 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.
        
       | embedding-shape wrote:
       | > 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.
        
         | Sesse__ wrote:
         | > 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.
        
           | mschuster91 wrote:
           | 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.
        
             | lawlessone wrote:
             | 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.
        
               | dfxm12 wrote:
               | The consoles were reportedly selling at a profit (at
               | least in the US) by 2009. Reports about the USAF condor
               | cluster surfaced in 2010.
        
               | lawlessone wrote:
               | i'm sure they profited overall, but this was costing them
               | a little right?
        
           | dontlaugh wrote:
           | 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.
        
           | rockskon wrote:
           | 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.
        
             | dfxm12 wrote:
             | 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/archiv
             | e/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.
        
               | rockskon wrote:
               | 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.
        
           | coretx wrote:
           | 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 ?!
        
         | xav_authentique wrote:
         | 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
        
         | Brian_K_White wrote:
         | 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.
        
       | Thaxll wrote:
       | I guess this is similar to TPM / secure boot on a pc?
        
         | bri3d wrote:
         | 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.
        
       | OptionOfT wrote:
       | > 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?
        
       | nopurpose wrote:
       | 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?
        
         | MSFT_Edging wrote:
         | 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.
        
         | bri3d wrote:
         | 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
        
       | Retr0id wrote:
       | 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
        
         | croes wrote:
         | 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.
        
         | tonyhart7 wrote:
         | 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
        
           | jaredwy wrote:
           | Hacking the xbox is a great read The Hardware Hacking
           | Handbook by no starch is a good modern intro.
        
           | fbias wrote:
           | 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
        
       | TheRealPomax wrote:
       | ... you mean every PS _still_ uses the same key?
        
         | t-3 wrote:
         | 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.
        
         | downrightmike wrote:
         | 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...
        
       | neilv wrote:
       | 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.
        
         | doublerabbit wrote:
         | 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?
        
           | neilv wrote:
           | > _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.
        
             | doublerabbit wrote:
             | 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?
        
               | neilv wrote:
               | > _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.
        
       | shipscode wrote:
       | Jailbreaking, emulation and gaming communities are so far gone at
       | this point that it's hard to understand the impact here.
        
         | lpcvoid wrote:
         | What do you mean?
        
           | doublerabbit wrote:
           | 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.
        
             | shipscode wrote:
             | 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.
        
               | eek2121 wrote:
               | Please see my comment above.
        
             | eek2121 wrote:
             | That's because jailbreak became irrelevant. The EU mandated
             | sideloading, and for those of us elsewhere, there is this:
             | https://sidestore.io/
        
             | ls612 wrote:
             | 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 ;)
        
       | mystraline wrote:
       | 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
        
       ___________________________________________________________________
       (page generated 2026-01-01 23:00 UTC)