PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

Home PS4 News - Latest PlayStation 4 and PS3 News

October 23, 2012 // 12:20 pm - Following up on the PS3 3.60 Keys leak comes a bright light at the end of the PlayStation 3 tunnel, as today an anonymous user has leaked the PS3 LV0 Keys meaning 4.21, 4.25 and 4.30 CFW updates are incoming!

Download: PS3 SCETool v0.2.9 + Keys for LV0 (125.2 KB)

[Register or Login to view code]

To recap, below are the confirmed legit and working PlayStation 3 LV0 Keys:

ERK = CA7A24EC38BDB45B98CCD7D363EA2AF0C326E65081E0630CB9AB2D215865878A
RIV = F9205F46F6021697E670F13DFA726212
PUBLIC = A8FD6DB24532D094EFA08CB41C9A72287D905C6B27B42BE4AB925AAF4AFFF34D41EEB54DD128700D
PRIVATE = 001AD976FCDE86F5B8FF3E63EF3A7F94E861975BA3

PS3 Key dump from appldr 4.25 in SCETool format:

[Register or Login to view code]

From zadow28 comes lv0.elf: yep working: (4.21) / (4.25)

I've extracted and decrypted some off the loaders, go search for keys: (the 4.elf I uploaded is the appldr.elf)

[Register or Login to view code]

Some files inside that could be not be decrypted:

Going throw appldr 4.25 dosen't look like there are revision 1C keys in there for 4.25 eboots.

One thing i found out thats interesting.. the lv0 had 6 files inside. 3 that could be decrypted = appldr/isoldr/lv2ldr. 3 that couldn't. But if you look in hex you would notice that the 3 unknown files is simply headers. I also noticed in the rest of the lv0 files there are encrypted hex sections.

So my guts says that you should try match the headers with some of the encrypted data/hex there you would probably find the missing lv1ldr if you succeed.

From haz367: added to scetool, decrypts fine

scetool 0.2.9 (C) 2011-2012 by naehrwert
NP local license handling (C) 2012 by flatz

  • Loaded keysets.
  • Loaded loader curves.
  • Loaded vsh curves.
  • Using keyset [lv0ldr 0x0000 04.25]
  • Header decrypted.
  • Data decrypted.
  • ELF written to C:\cygwin\home\xxx\425ofw\update_files\CORE_OS\lv0.elf

From zecoxao: this one is from 3.55, since i didn't have any other than this and the jig one. and updated keys file

Usage: scetool -d lv0 lv0.elf

From aldostools: add this to keys file:

[Register or Login to view code]

Please the leaked keys in: home\username\.ps3

Name them:

  • lv0-ctype
  • lv0-iv-key
  • lv0-key-key
  • lv0-priv-key
  • lv0-pub-key

No version number required.

From Cyberskunk: Just be patient people... WE HAVE 100% WORKING solutions with no brick risk or complications.. tested for the last month not just spat out as fast as possible. After OFW 4.30 release.. not long..

From danixleet: Can we add these ( to SCETool to resign 4.x games for 3.55? Appldr needs to be reversed before us end user's get the updated keys file for SCETool...

Anyway Lv0 now decrypted for ever but it still need a lot of RE work to be able to get decrypted loaders from it since Sony had changed a lot of security algorithms to protect this loaders inside Lv0. Also we will not find 4.xx appldr keys inside the decrypted Lv0 so it still need more work to figure out how Sony store this keys right now.

1) Yes with the leak of lv0 keys we can decrypt lv0 > extract appldr > decrypt appldr with metldr keys > locate the keysets >> unicorns

This then enables us to decrypt any eboot / sprx etc for games and resign them with 3.55 keys .. (That is what is what you're looking to do)

2) fail0verfl0w exposed a flaw in sonys encryption ECSDA or whatever its called lol...

  • what does this mean? it means we can calculate the private keys
  • what are private keys ? there used to encrypt sony files.. aka SELF. SPRX etc, etc

So up until 3.55 we can calculate every key sony used to SIGN there files, thus making valid application, thus enabling homebrew etcc or whatever. 3.56+ that has been fixed and we can no longer calculate the private key... but yes we can still grab the public keys, as they are within the FW..

Public Keys Decryption / Private Keys Encryption

3) geohot released hes NPDRM tools which had static private keys, sony apparently blocked them keys, once npdrm was worked out, new tools had been released to select different keys, aka dont use geohots tools, there flop, even math stated this..

4) you can use any sony npdrm private key in scetool and produce homebrew with will execute on any OFW... aka 3.60++ .... sony can't block there own keys, cause then all there old psn games etc would not work unless updated and there not gonna back date the updates for extremely old games lol..

5) yes we can decrypt all current games and resign them for 3.55 if needed..

6) lv0 private key cant be changed as bootldr cant be updated, so for example, every new fw out can now become CFW... or for instance step 1)... aka you download 4.30 extract the pup or install and nor dump... decrypt lv0 etc etc (step 1) and add the new appldr keys to scetool... their chain of trust was "fixed" in 3.60 but once you pwn bootldr its game over, as bootldr would hold lv0 keys and lv0 signing cant be updated.. so pwnddd for lifeeee !!!

From KaKaRoToKS (via comes an update on his previous exploit as well:

Since the LV0 keys have now been leaked, I believe I can now share this info with you, to help out those who are trying to build their own 4.x CFW:

The NPDRM ECDSA signature in the SELF footer is checked by lv2. It first asks appldr to tell it whether or not the signature is to be checked, and appldr will only set the flag if the SELF is a NPDRM with key revision from 3.56+ (the ones without private keys). This means that the SELF files signed with the new 3.56+ keys still don't have their ecdsa checked (probably to speed up file loading).

If appldr says the ecdsa signature must be checked, then lv2 will verify it itself, and return an error if it's not correct. There are many ways to patch this check out.

1 - Patch out the check for the key revision in appldr
2 - Patch out the "set flag to 1" in appldr if the key revision is < 0xB
3 - Patch out the code in lv2 that stores the result from appldr
4 - Patch out the actual sigcheck function from lv2.
5 - Ignore the result of the ecdsa from lv2.

Here is one of the patches (the 4th one, patching out the check function from lv2) :
In memory 0x800000000005A2A8, which corresponds to offset 0x6a2a8 in lv2_kernel.elf, replace :

[Register or Login to view code]

With :
[Register or Login to view code]

This is for the 4.21 kernel (that was the latest one when I investigated this), I will leave it as an exercise to the reader to find the right offsets for the 4.25 and upcoming 4.30 kernel files.

And here's another bit of info... in 4.21 lv2, at memory address 0x800000000005AA98 (you figure out the file offset yourself), that's where lv2 loads the 'check_signature_flag' result from appldr, so if you prefer implementing method 3 above, just replace the 'ld %r0, flag_result_from_appldr' by 'ld %r0, 0' and you got another method of patching it out. Either solutions should work just the same though. Enjoy homebrew back on 4.x CFW....

p.s: Thanks to flatz and glu0n who helped reversed this bit of info.

From marcan42 (a PS3 dongle developer): The correct name for the PS3 keys that were released is "bootldr keys", not "lv0 keys": named after the verifier, not what is verified. bootldr is the name of the code living at address 0 in Flash (which is loaded by the SPU isolated mode boot ROM). Keys are named after the verifier because we decided so originally, and everyone else stuck to it. No point in changing it now.

To quote (via

"The first-stage bootloader is in ROM and has a per-console key which is effectively in tamper-resistant silicon. The second-stage bootloader (bootldr) is encrypted with the per-console key, but is not upgradable and is the same for all consoles (other than the encryption wrapper around it). This second-stage bootloader verifies lv0.

Sony signed lv0 using the same broken process that they used for everything else, which leaks their private key. This means that the lv0 private key was doomed from the start, ever since we demonstrated the screwup at the Chaos Communication Congress two years ago.

However, because lv0 is also encrypted, including its signature block, we need that decryption key (which is part of bootldr) before we can decrypt the signature and apply the algorithm to derive the private key. We did this for several later-stage loaders by using an exploit to dump them, and Geohot did it for metldr (the "second root" in the PS3's bizarre boot process) using a different exploit (we replicated this, although our exploit might be different).

At the time, this was enough to break the security of all released firmware to date, since everything that mattered was rooted in metldr (which is bootldr's brother and is also decrypted by the per-console key). However, Sony took a last ditch effort after that hack and wrapped everything after metldr into lv0, effectively using the only security they had left (bootldr and lv0) to attempt to re-secure their platform.

Bootldr suffers from the same exploit as metldr, so it was also doomed. However, because bootldr is designed to run from a cold boot, it cannot be loaded into a "sandboxed" SPU like metldr can from the comfort of OS-mode code execution (which we had via the USB lv2 exploit), so the exploit is harder to pull off because you don't have control over the rest of the software.

For the exploit that we knew about, it would've required hardware assistance to repeatedly reboot the PS3 and some kind of flash emulator to set up the exploit with varying parameters each boot, and it probably would've taken several hours or days of automated attempts to hit the right combination (basically the exploit would work by executing random garbage as code, and hoping that it jumps to somewhere within a segment that we control - the probabilities are high enough that it would work out within a reasonable timeframe). We never bothered to do this after the whole lawsuit episode.

Presumably, 18 months later, some other group has finally figured this out and either used our exploit and the hardware assistance, or some other equivalent trick/exploit, to dump bootldr. Once the lv0 decryption key is known, the signing private key can be computed (thanks to Sony's epic failure).

The effect of this is essentially the same that the metldr key release had: all existing and future firmwares can be decrypted, except Sony no longer has the lv0 trick up their sleeve. What this means is that there is no way for Sony to wrap future firmware to hide it from anyone, because old PS3s must be able to use all future firmware (assuming Sony doesn't just decide to brick them all...), and those old PS3s now have no remaining seeds of security that aren't known. This means that all future firmwares and all future games are decryptable, and this time around they really can't do anything about it.

By extension, this means that given the usual cat-and-mouse game of analyzing and patching firmware, every current user of vulnerable or hacked firmware should be able to maintain that state through all future updates, as all future firmwares can be decrypted and patched and resigned for old PS3s. From the homebrew side, it means that it should be possible to have hombrew/linux and current games at the same time. From the piracy side, it means that all future games can be pirated. Note that this doesn't mean that these things will be easy (Sony can obfuscate things to annoy people as much as their want), but from the fundamental security standpoint, Sony doesn't have any security leg to stand on now.

It does not mean that current firmwares are exploitable. Firmware upgrades are still signed, so you need an exploit in your current firmware to downgrade. Also, newer PS3s presumably have fixed this (probably by using newer bootldr/metldrs as trust roots, and proper signing all along)."

In summary, you can sign homebrew with old NPDRM keys which haven't been revoked. We don't have 3.60+ private keys for RETAIL signing (not NPDRM), but we don't need them as NPDRM keys can be used instead and the homebrew signed as NPDRM content.

In conclusion, according to afiser while Sony can update lv0 they must use the same keys to encrypt it each time or else bootldr wouldn't be able to load it. PlayStation 3 3k+ consoles have LV0.2 so it's not the same key. For those interested in examining them some LV0 dumps can be found via as well.

Update: From woulph_alfa via Spanish site ( comes the following theory on the encryption, roughly translated:

I bring you good info compiled by me. I've been throwing a couple of hours to file the 4.25 appldr good here's a short summary of what is the content of. Elf

I will explain:

[1] - WA (Writing and Assignment) is not interested in a lot ... But do not rule ...
[2] - AX (allocation and execution) party quite important since it is the only part of "executable" You can look at the content from 100 to 01ba10 Possibly OFFSET is the one responsible for making the decryption of the RIV and ERK. Apart from checks ...
[3] - A (Assignment) and finally the most interesting part of the file, in this section I think is where the KEY to decrypt the RIV and ERK (See the second image there is the structure)
[4, 5, 6] - WA (Writing and Assignment) Here are the keys of the appldr from 4.25 up to the first keys appldr


[Register or Login to view code]

What is the encryption method that uses NO IDEA AS IF WE HAD A LONG AND THE ....

Possibly a little further investigation, if anyone wants me to help out ... welcome! OJO not expect great progress on my part, because currently I have no means eager.

PS3 LV0 Keys Leaked: 4.21, 4.25 and 4.30 CFW Updates Incoming!

PS3 LV0 Keys Leaked: 4.21, 4.25 and 4.30 CFW Updates Incoming!

PS3 LV0 Keys Leaked: 4.21, 4.25 and 4.30 CFW Updates Incoming!

Follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 CFW forums for the latest PlayStation 3 scene and PS4 Hacks & JailBreak updates with PlayStation 4 homebrew PS4 Downloads.

#175 - GotNoUsername - October 31, 2012 // 9:15 pm
GotNoUsername's Avatar
It is possible to create a CFW that can be installed on the non down gradable PS3's but y need a HW - Flasher to "install" it. But you will need good dev's for that ! There is nearly no chance in getting the private keys again Sony fixed their random number Problem after 3.55++. So Privat keys are calculated correctly and so we can't get them

#174 - Foo - October 31, 2012 // 9:15 pm
Foo's Avatar
What is this downgrade thing I see?

#173 - StanSmith - October 31, 2012 // 9:13 pm
StanSmith's Avatar
Quote Originally Posted by windrider42 View Post
I have heard they are the real deal, and guys already fixed Borderlands 2 for 3.55

Yep. They do work and I did patch Borderlands 2 to work in 3.55 myself.

#172 - Ps3scener - October 31, 2012 // 9:04 pm
Ps3scener's Avatar
in regards to the keys and the fw updates coming, it is possible to create a 4.30 jailbreak that does not require 3.55 installation. i have some files to leak which could help a experienced dev team create the jailbreak that we are all waiting for. all i ask is for a reply.

#171 - technodon - October 31, 2012 // 9:01 pm
technodon's Avatar
key works on 4.31 too, checked the psn passphrase and they are both the same

#170 - Hernaner28 - October 31, 2012 // 8:34 pm
Hernaner28's Avatar
Well, come on now, chuchi chuchi, we want Worms Revolution fixed I would buy it, it's really cheap, but firstly I don't have PSN access, and secondly I don't own a credit card and PSN cards are expensive.

Wouldn't you love drinking bear and playing it 4-player with friends?? Hmm yeah it sounds weird but it'd be cool .. lol

#169 - niwakun - October 31, 2012 // 2:26 pm
niwakun's Avatar
Keysets that dont work from the recent PS3 keys release

APP Type Key set
001C, 001D, 001E

NPDRM Type Key set

keys work from 3.61 - 4.21 .............. 4.25 - 4.30 keys are not valid

#168 - ConsoleDev - October 31, 2012 // 12:14 pm
ConsoleDev's Avatar
Nice to hear these things, but too bad that the private keys are missing

#167 - PS3GAMER20111 - October 31, 2012 // 12:05 pm
PS3GAMER20111's Avatar
Keys are confirmed true by pr0p0sitionjoe and he said we are going to see many new psn games working on 3.55.

salute to pr0p0sitionjoe.

#166 - G Sus - October 31, 2012 // 12:01 pm
G Sus's Avatar
yup can't confirm there real, lol

Also from oakhead69:

OK here is the process I used to reverse the V4 Keys, EDATKEY1 and EDATHASH1 from my PS3. 99% of what I will post here is already public domain, I will just pull it together in one place here. I used IDA and a customised version of KDS Best's SPU Emulator

JuanNadie posted here the SH1 hashes of the EDAT keys and hashes and I can confirm that these are correct. The encrypted EDAT hashes and keys can be found in the 4.xx appldr.elf. sorg posted these. So the 3 keys you are missing are the KEY, the IV and the ERK.

The KEY and the IV are in the appldr and are un-encrypted. You can use the IDA or an SPU emulator to figure it out, just work backwards from the below spu code at 28BE4 (I think this offset is for F/W version 4.27 if I remember correctly)

The ERK is generated from the contents returned by channel 73. The appldr reads channel 73, 3 times which is the FW version check channel. So in FW 4.30 it will return 0xkk04kk30 0xkkkkkkkk 0xkkkkkkkk where k is the hash initilisation for generating the ERK. 04 30 is F/W version number.

The appldr strips out the F/W version leaving you with the 0xkkkkkkkkkkkkkkkkkkkk 10 byte hash initialisation (ch73 in the code below).

To get the values from channel 73 and you will have to write an isolated SPU to read these values. It has to be an isolated SPU as channel 64 controls the access to channel 73 and one of the last things the appldr does it to isolate channel 73 by writing 0x60000 to channel 64. This information was posted one forum somewhere, just can't remember where. Just Google it (may edit my post later when I find it).

I wrote my spu isolated module based on the dump_encdec_keys by glevand. Just Google and you will find the associated wikis and gits. is a good starting point. You will have to do a bit of hand calculation for the branch offsets to shoehorn in some code something like this to read ch73 3 times.

[Register or Login to view code]

OK so you should now have the encrypted keys (sorg posted) the KEY, the IV and the hash seed for the ERK. When you find the encrypted keys based on the post from sorg this will lead you as it did me to the following code in the appldr.

[Register or Login to view code]

Independently of me redcfw also found the same SPU code and generated C code from it and posted it. I had already generated the following C# code from the SPU code and below is an example for edathash1, it was good to see him confirm the same code as at the time I had still had not figured out how to read ch73.

[Register or Login to view code]

There you have it how to reverse the EDATKEY1 and EDATHASH1 from your CFW 4.xx PS3. Sorry bit of a brain dump, will tidy the post up later if I get the time and add more links to the information sources. I am sure I should credit more people than I have here. If and when I add the source links I will add credits.

Please do not ask me for any of the keys needed here or for the final EDAT keys as I will not post them for obvious reason. As I have already said 99% of this information is already available in forums and wikis. I have just pulled the information together here. Hope you have as much fun as I did playing with the SPU code.