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


77w ago - 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)

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

ERK = CA7A24EC38BDB45B98CCD7D363EA2AF0C326E65081E0630CB9AB2D215865878A
RIV = F9205F46F6021697E670F13DFA726212
PUBLIC = A8FD6DB24532D094EFA08CB41C9A72287D905C6B27B42BE4AB925AAF4AFFF34D41EEB54DD128700D
PRIVATE = 001AD976FCDE86F5B8FF3E63EF3A7F94E861975BA3
CURVE_TYPE = 0x33

PS3 Key dump from appldr 4.25 in SCETool format:

From zadow28 comes lv0.elf: yep working: http://rghost.net/41097133 (4.21) / http://rghost.net/41097551 (4.25)

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


Some files inside that could be not be decrypted: http://rghost.net/41097841

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: https://dl.dropbox.com/u/35197530/lv0.elf this one is from 3.55, since i didn't have any other than this and the jig one. https://dl.dropbox.com/u/35197530/keys and updated keys file

Usage: scetool -d lv0 lv0.elf

From aldostools: add this to keys file:

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 (https://dl.dropbox.com/u/35197530/keys) 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 pastie.org/private/3np6uj6md1occbctdeir6a) 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 :

With :

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 games.slashdot.org/comments.pl?sid=3205473&cid=41747075):

"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 ps3devwiki.com/wiki/Loaders#Loader_encapsulation_in_lv0 as well.

Update: From woulph_alfa via Spanish site (ps3sos.com/showthread.php?29532-Keys-LV0-liberadas/page23) 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

KEY SAMPLE

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.








Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!

Comments 244 Comments - Go to Forum Thread »

Quick Reply Quick Reply

G Sus's Avatar
#214 - G Sus - 75w ago
wouldnt that mean we could use FSM to install cfw and then use the new Lv2diag.self to get out of it, in fw 3.60 and above ?

even if not the cfw, does this give us the possibility of a tool to get out of FSM ? above 3.55

ConsoleDev's Avatar
#213 - ConsoleDev - 75w ago
Maybe someone more experienced than me could help to clarify this thing.. It seems that zadow28 managed to find a lv2diag.self file signed with the 3.60/3.61 keys in the ps3tmgui program that was a part of the official SDK.

If possible can someone tell me more about that?

DO NOT TRY THIS!



G Sus's Avatar
#212 - G Sus - 75w ago
i'd keep hope too, theres always some up and coming smartass that looks at things differently or just spots something others have missed. 1 little thing can suddenly change the game completely. the algorithym used to calculate per console keys has to be hidden somewhere within the cfw, and all parts the fw is now readable. so its technically just a case of finding it and undestanding how to exploit it.

sadly that don't just take a clever person, that takes a clever person that is actually interested in doing it, and not afraid of any consequences. for all we know it could have already been done.

Hope is a great thing, its free and you can have as much of it as you want.

UrKoS's Avatar
#211 - UrKoS - 75w ago
I hold hope for a 4.31 installable cfw.

Sent from my GT-I9100 using Tapatalk 2.

G Sus's Avatar
#210 - G Sus - 75w ago
i believe that now all keys are known , it means you could technically make a cfw that could be installed on any ps3 ofw. however. its not really as simple as that. the keys only mean you can decrypt it all. it dont mean you will understand what your seing or even be able to find a flaw or weakness in it. (per console keys)

What it effectively means is now that it can all be decrypted there is the possibility that someone will find out how the fw and ps3 gos about the verification of per console keys etc. and then copy the process, and make a new cfw that will update on ofw above 3.55.

it don't mean it will happen , it just means it could be possible if someone is smart enough to work it out. or at least thats how i understood it, ive been wrong before though. what is more likely is. now you'll just get a 4.31 cfw that installs only on 3.55 or below.

I bet theres a hell of a lot of code to read for devs. look how many files theyve been given access too in just a few months. The PS3s life will have ended before anyone gets round to making cfw install above 3.55 ofw. I reckon the few people that probably could do it aint even working on it, (they have no need) and the rest wouldn't know where to start.

but like i say, I'm often wrong, and this is highly likely to be one of those times.













Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News