no, the key to decrypt lv0 is found in bootloader, then inside lv0 you will find apploader keys and all other loader keys for lv1 and lv2 etc.. ask him to upload a decrypted lv0.elf and we can have a look our ourselves
really makes me wonder what pleasure some get from making fake cfw on youtube and talking rubbish on ps3 websites. there's so many of them out there. it's pretty childish really. just amazes me. Why would you do it? I don't get it
you said it. they're children. it gives them their jollies from other people's misery. i get poking fun every now and then with buddies, but as you grow up, you realize the world is much nicer when everyone is nicer.
Agreed, on that until "anonymous" replies back with new information (if he ever does, that is) we will close this up as from the sound of things the key doesn't appear valid anyway. Back to the waiting game it seems
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!
Some files inside that could be not be decrypted: [Register or Login to view links]
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 <public build> (C) 2011-2012 by naehrwert
NP local license handling (C) 2012 by flatz
Loaded loader curves.
Loaded vsh curves.
Using keyset [lv0ldr 0x0000 04.25]
ELF written to C:\cygwin\home\xxx\425ofw\update_files\CORE_OS\lv0 .elf
From zecoxao: [Register or Login to view links] this one is from 3.55, since i didn't have any other than this and the jig one. [Register or Login to view links] and updated keys file
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 ([Register or Login to view links]) 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 [Register or Login to view links] (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 :
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 [Register or Login to view links] (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:
 - WA (Writing and Assignment) is not interested in a lot ... But do not rule ...
 - 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 ...
 - 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