A PS3 Key Held for 20 Years Was Recovered by Reading the One Register That Should Have Been Cleared

By Indie Kings | September 28, 2026

Updated September 28, 2026: Researchers have recovered a per-console security key from the PlayStation 3 that had been protected for close to 20 years. Per zecoxao's technical writeup, the key belongs to lv0ldr, the loader that checks and decrypts system software before the rest of the system boots, and it was recovered by glitching a register cleanup at a precise moment to catch an intermediate value from the AES key expansion. The writeup credits jestero with the final result, a body key on a CECHL-series console. No jailbreak exists yet, and the writeup is explicit that everything it says about custom firmware is theoretical.

Glitch attack on the PS3 Cell processor SPU to recover the lv0ldr per-console key

Image: Glitch capture from the lv0ldr key recovery. Credit: zecoxao.

The chain, and where the gap is

To understand what was recovered and why it matters, the boot chain has to be laid out, because the whole result is a function of position in that chain.

Per the writeup, something from somewhere in memory loads lv0ldr, which loads lv0. That same source then loads metldr, which loads isoldr, appldr, rvkldr, lv1ldr and lv2ldr. Each of those in turn loads something specific: isoldr loads the isolated SPU modules, appldr loads the userland apps, rvkldr loads the revocation lists, lv1ldr loads the hypervisor, and lv2ldr loads the kernel.

The writeup is blunt about why the chain used to look closed: Sony patched the ECDSA vulnerability on later models, so "there should be no room to where we could craft and sign". And then the observation that makes twenty years of work possible: the gap is in the two first loaders, lv0ldr and metldr.

That is the structural reason this matters. QuasiCFW, the hack that works on all unhackable consoles, was built by kafuu with esc0rtd3w and bguerville out of a random 2010 post describing a possible vulnerability in the wdsd command register. It lets you patch any region of lv0, lv1 and lv2 as soon as lv0ldr exits its loading. So the entire modern PS3 homebrew scene already depends on patching after lv0ldr. What was missing was any ability to modify and sign lv0ldr itself, and that is what this key provides.

Getting the ROM off the die

The route to the key started with physically getting the boot ROM off the Cell processor, and the account is worth reading because the first attempt failed.

Per the writeup, the simplest way to obtain the very first boot ROM is via decapping and imaging. The team contacted someone who could do that work, and the initial theory was that the ROM would be in the PPE area near the pervasive region. Proxima, who had substantial experience decoding ROMs, handled the decode side once pictures of the bits arrived.

It was, in the writeup's word, "a massive disappointment": the ROM they imaged was not the SPU ROM, but the microcode ROM, the code that sets up complex PPE instructions into simple machine code. That dead end happened around Christmas 2025.

The recovery came from insisting on the wrong-sounding hypothesis. The team insisted the SPU regions should be checked "even though it made no sense to check for bits in 8 supposedly identical places". They were. The ROM existed as a bit cluster of 8192 mirrored bits, so 0x400 bytes with the proper decoding. 0x400 is 1,024 bytes, and having it mirrored means half of it is a reflection of the other half.

That is a small target and it took two attempts, a paid arrangement with an anonymous decapper, and a wrong initial guess. The writeup is direct about all three.

The key was locked out by design

With the ROM in hand, the group analysed the code and found, per the writeup, "the entire AES handling of the lv0ldr and metldr, minus of course the key".

The key was deliberately unreachable. It was channeled through 32-bit reads of channel 66 and then locked out from any future access. In other words Sony did not leave the key sitting in a register where software could walk up to it. It is passed through a DMA channel in a form that is read once and never readable again.

Several attempts failed to get at it, and the writeup lists them without embellishment: writing specific values to channel 64, messing with isolation status, and what it calls "a myriad of other attempts". The conclusion the team reached was that the key, which is per-console, would have to be obtained by glitching, or by a DPA, DFA or SPA attack to get at it some other way.

The glitch, and why register 7

This is the part of the work that is genuinely elegant, and the writeup presents it as an accident of observation followed by deliberate targeting.

First jestero noticed something odd while using the anergistic tool: SPU registers would maintain their values through multiple executions of SPU code. Normally a register is overwritten on each execution. Here, values survived, which meant that if any register held the channel 66 key or a key derived from it, it could be read out after the fact.

Then the targeting decision, and it is the part worth understanding. The team chose register 7 for a specific structural reason: register 7 is only used during the AES key expansion of the channel 66 derived key. It is not used for anything else. So the register that would transiently hold expansion intermediates is also a register that is dead the rest of the time, which makes a preserved value there far more likely to be the key material rather than something incidental.

The attack is therefore: glitch the cleanup at a precise timing and read register 7. The writeup puts it plainly, that if the key could be obtained by glitching the cleanup and reading register 7, "we could then derive backwards (AES allows that), and obtain both the body key AND the cmac key".

The result, per the writeup: "Finally, after a while, jestero got his CECHL lv0ldr perconsole body key."

Why an intermediate key is as good as the original

The step that makes the whole thing work is that AES key expansion is reversible, and that is a property most people do not associate with AES.

AES is a block cipher, so encrypting and decrypting with the same key are inverses. But key expansion is the separate process that derives round keys from the original key, and the writeup treats it as reversible in the same practical sense: given an intermediate value produced during expansion, it is possible to derive backwards and recover what came before.

The practical consequence is that catching a derived key is as good as catching the original one. Sony's protection was that the key is channeled through channel 66 and locked out. Had the register preserved the original key, the attacker would still have needed the channel 66 key. Because register 7 holds an expansion intermediate of a key derived from channel 66, recovering it lets the attacker run the derivation backwards to the original, and forwards to the CMAC key.

So one glitched register read yields both keys mentioned in the writeup: the body key and the CMAC key. The writeup notes the CMAC key matters because it is what allows the recovered material to be used to produce valid signatures rather than only decrypt.

What this does and does not give you today

The writeup is unusually careful here, and the care is the point. It states plainly that the following is "all theoretical now but should be practical at some point", and then lists it.

Stated capability	What it would require
Obtain the channel 66 key	Would allow encrypting and "signing" a custom lv0ldr and metldr
Load arbitrary code	Encrypt and sign your own lv0ldr and use it to load whatever is wanted, "modded signatures and all"
Decrypt lv0ldr.2 and metldr.2	Would expose the future signature keys, which the writeup notes "are useless by now"
CFW on all PS3 models	Depends mostly on kafuu's QuasiCFW, which is what allows true CFW on Slim 3000 and Super Slim
Unbrick on all PS3 models	Requires the CPU key, hardware master key or channel 66 key to be dumped, or at least one derived key for lv0ldr or metldr

So the honest position is that this is a key recovery, not a jailbreak. The writeup says the future keys from lv0ldr.2 and metldr.2 "are useless by now", which is a reminder that the boot chain has moved on. And the unbrick capability is conditioned on keys that are separate from what was recovered.

The repair angle is separate and concrete. Per the writeup, the same access could eventually help recover badly damaged systems, work around failed Blu-ray or Wi-Fi hardware, and pair replacement hardware with a console. The writeup also notes that no workshop could fix most PS3 hardware errors without the earlier SYSCON key work, and that the earlier syscon and testbench key work was what made QuasiCFW possible for all later models.

The credit chain, which is the real story here

The writeup opens by refusing to take sole credit, and that structure is itself the most durable finding in the document.

It names the previous work by wildcard, the author, ZeroTolerance, Proxima, golden, DJ and MinaRalwasser, who obtained the master keys used to decrypt SYSCON firmwares and their patches, plus the keys needed to interact with the testbench and diagnose console state. The stated consequence: without that work, QuasiCFW would not have become a reality for later models, and without it no workshop could fix most PS3 hardware errors. The writeup ties this to Project Frankenstein, described as born of collaboration between people dedicated to making backwards compatible PS3s.

It then credits kafuu with esc0rtd3w and bguerville, who took a random 2010 post about a possible wdsd command register vulnerability and turned it into QuasiCFW. And it names jestero for the register observation and the final key, and Proxima again for the ROM decoding. The decapper is credited only as Anonymous, with the price arrangement and the exchange of words left unstated.

Two details about how this work happens are worth recording. The failed first attempt was resolved by insisting on an SPU hypothesis that "made no sense" given eight supposedly identical regions, which is a reminder that a physical duplication you assume is symmetric may not be. And the actual attack came from an anomalous observation about register persistence, found with a tool built for unrelated purposes, which was then turned into a targeted attack by noticing which register was used only during key expansion.

FAQ

What exactly was recovered from the PlayStation 3?

A per-console body key for lv0ldr on a CECHL-series console, credited to jestero. The writeup also states that the attack yields the CMAC key as well, because register 7 is used only during the AES key expansion of the channel 66 derived key, and the expansion can be run backwards to recover the original material.

How was the key obtained, given Sony locked it out?

The key was channeled through 32-bit reads of channel 66 and locked out from future access, so direct reads were impossible. The attack was to glitch the cleanup at a precise timing and read SPU register 7, which jestero found retains values across multiple SPU code executions. Register 7 is used only during the AES key expansion of the channel 66 derived key, which is why it was the target.

How does recovering an intermediate key help if the original is protected?

Because AES key expansion is reversible in the practical sense the writeup relies on. Recovering a derived key from register 7 allows deriving backwards to the original, and forwards to the CMAC key. So a single glitched register read yields both the body key and the CMAC key, and the CMAC key is what allows valid signatures rather than decryption alone.

Is there a PS3 jailbreak or custom firmware available now?

No. The writeup describes everything in its future section as "all theoretical now but should be practical at some point", and VideoCardz states plainly that there is no downloadable jailbreak based on this work yet. Full CFW on Slim 3000-series and Super Slim models would also depend on kafuu's QuasiCFW, which the writeup credits with most of that capability.

Which PS3 models are affected, and which already had custom firmware?

Older PS3 systems can already run full custom firmware. Later Slim and Super Slim models use a different boot process and have remained incompatible with traditional CFW, and those are the models this research targets. The recovery was demonstrated on a CECHL-series console.

Could this help repair a broken console?

Potentially, per the writeup, which lists recovering badly damaged systems, working around failed Blu-ray or Wi-Fi hardware, and pairing replacement hardware with a console. It notes that the earlier SYSCON key work was what allowed workshops to fix most PS3 hardware errors, and that unbrick capability on all models would additionally require the CPU key, hardware master key or channel 66 key to be dumped, or at least one derived key for lv0ldr or metldr.

Bottom Line

The most interesting part of this is not that a PS3 key was recovered, it is which register was read and why that choice turned a locked-out secret into a readable one. Sony did not leave the key accessible. Per zecoxao's writeup it was channeled through 32-bit reads of channel 66 and then locked out from any future access, and the group's direct attempts failed, including writing values to channel 64 and messing with isolation status. What made it possible was jestero noticing through the anergistic tool that SPU registers retain their values across multiple executions of SPU code, and then the team choosing register 7 specifically because it is used only during the AES key expansion of the channel 66 derived key. Glitch the cleanup at the right moment, read register 7, and the expansion intermediate is sitting there. Since AES key expansion can be run backwards, an intermediate is as good as the original: one glitched read yields both the body key and the CMAC key, and the CMAC key is what makes valid signatures possible rather than decryption alone.

That is a properly elegant piece of work, and the route to it had two failures that the writeup reports without softening. The first decapping attempt imaged the wrong ROM entirely, returning the microcode ROM rather than the SPU ROM, which was a dead end around Christmas 2025. The recovery came from insisting on the SPU regions be checked "even though it made no sense to check for bits in 8 supposedly identical places". They were not identical. The ROM existed as 8192 mirrored bits, or 0x400 bytes. A paid arrangement with an anonymous decapper, a wrong initial hypothesis about the PPE region, and a duplicated memory region that turned out not to be.

What it does not give you is a jailbreak, and the writeup is careful in a way the coverage was not. Every item in its future section is prefaced as "all theoretical now". The recovered keys would let someone encrypt and sign a custom lv0ldr and load arbitrary code, decrypt lv0ldr.2 and metldr.2 to obtain signature keys that the writeup notes are "useless by now", and combined with kafuu's QuasiCFW, enable CFW on all PS3 models including the Slim 3000-series and Super Slim that have never supported it. The unbrick capability is separately conditioned on the CPU key, hardware master key or channel 66 key being dumped, or at least one derived key, which is not what was recovered. The repair applications, by contrast, are the more credible near-term benefit: recovering damaged systems, working around failed Blu-ray or Wi-Fi hardware, pairing replacement parts. The writeup notes that no workshop could fix most PS3 hardware errors before the earlier SYSCON key work, and QuasiCFW only exists because kafuu, esc0rtd3w and bguerville took a random 2010 post about a wdsd command register vulnerability seriously.

The structure of the document is worth noting as much as its contents. It opens by refusing sole credit, naming the SYSCON and testbench key work by wildcard, ZeroTolerance, Proxima, golden, DJ and MinaRalwasser as the foundation without which QuasiCFW would not exist and no workshop could fix most PS3 errors, and crediting Project Frankenstein as the product of that collaboration. It is a twenty-year research effort reported in the first person plural with the current step attributed to jestero and the ROM decoding to Proxima, and it states its own limits. For a site with no coverage of the PS3 boot chain, the Cell processor, SYSCON, QuasiCFW or console boot security at all, this is the most technically substantive homebrew story available, and the interesting thing about it is that the breakthrough came from noticing a register that should not have kept its contents, then working out which register would be holding the thing you wanted.

Source: zecoxao, Glitching the "Almost" Perfect Code, which is the primary source for the boot chain order and what each loader loads, the patched ECDSA vulnerability on later models and the gap being in lv0ldr and metldr, the decapping and imaging route and the failed first attempt at the microcode ROM around Christmas 2025, the SPU ROM found as 8192 mirrored bits or 0x400 bytes after insisting on checking eight apparently identical regions, the AES handling analysis and the key being channeled through 32-bit reads of channel 66 and locked out, the failed direct attempts, jestero's observation of SPU register persistence via anergistic, the choice of register 7 and why, the glitching of the cleanup and deriving backwards to obtain both the body and CMAC keys, the theoretical future capabilities, and the credit list including kafuu with esc0rtd3w and bguerville for QuasiCFW from a 2010 wdsd vulnerability post. VideoCardz, Hackers crack PS3 bootloader, opening path to custom firmware on Slim and Super Slim consoles, September 27, 2026, is the source for the announcement date and the statement that no downloadable jailbreak exists yet