122w ago - Following up on the previous PS3 Keys leak and PS3 4.30 Decryption, on this Halloween Day even more PS3 Keys ranging from 3.65 to 4.30 including Appldr and NPDRM (PSN) have now surfaced with details below!

From danixleet: VSH.self can be decrypted, as its signed with appldr keys for this firmware version.. With this recent leak of Appldr / NPDRM keys we can now make SEN/Spoofer's for when a new OFW is released.. Here is OFW 4.30 VSH.self & VSH.elf.

From IRC:

[itwong] just came across lv2diag.421.self? is this for downgrading 3.60++ ps3s?
[Rare] no
[itwong] what is this for ?
[itwong] euss, any idea what that lv2diag.421.self does?
[euss|_] itwong, you have the file, you tell me
[itwong] im wondering if it will kick the console out of factory mode
[itwong] cuz for 3.56+, before once it enters factory mode, i will be stuck in that mode
[r3pek] on a side note: http://www.multiupload.nl/3CHY6IQVXU
[r3pek] it's the file itwong was talking about

From slarty1408 on the multiMAN 3.15-4.20+ [EBOOT_FIX]: Hi ppl I've added 2 more sets of keys FW 4.00-4.11 and FW 4.11-4.20+ (4.00-4.30 keys added) it should fix most retail eboots now i think I've only tested it with:

Transformers Fall of Cybertron = FW 4.11

XCOM Enemy Unknown = FW 4.21

Both went through fine have not got time to test as for kids and work good luck ppl let me know if i missed anything ? Thanks...

PS: Please say thanks to deank for this tool as he done all the hard work... I've just done hex code to file.

From CaptainCPS-X: Advice for those decrypting EBOOT.BIN's, and expecting the game to run without problems. Games don't only use encrypted EBOOT.BIN, there are encrypted .SPRX / .SELF / .SDAT as well, so only patching EBOOT.BIN will not work on all game backups, maybe some games don't make use of secondary encrypted files, but there are many that do.

From aldostools: To decrypt/resign the EBOOT you always should provide the klicensee as parameter (if the SELF use klicensee):

You can use the batch above just for updates with eboot, when the command window pauses after it makes .elf you then edit the elf sys_proc_param at hex 13 BC C5 F6 from 41 to 34, or this new hex that was mentioned. Save .elf then let command window continue.

"--np-content-id=UP0082-BLUS30927_00-SDPATCH000000002" in the batch needs to be changed to whatever the name of the sony update is without A102-V100-PE.pkg part for example.. you can get rid of all the np stuff, content id, & change self type to APP, for disc eboots.

For NPDRM sprx/self bruteforce or use IDA and and follow calls on NP_exit_spawn to the parameter for Klicensee key on the EBOOT.elf
then in the batch change --np-app-type=USPRX & add --encrypt "self/SPRXname.elf" "self/SPRXname.self" -l "klickey" in place off --encrypt EBOOT.ELF EBOOT.BIN then if .sprx rename .self to .sprx

You can use the "free" klic on EBOOT.BIN w/ sprx/self "-l 72F990788F9CFF745725F08E4C128387" and if you want make SCE Version TRUE in HEX at offset 397 changing 00 to 01 on EBOOT.BIN. This should basically be it, although I am tired so you'll figure out if you cant then just wait.

From zadow28: i actuallly managed to dump the sysrom also. Don't know much about it though, but here it is.

From zadow28: i have various dumps this is from rex: LV1-FW4.21.BIN another one from
xmb rogero, yeah i patch the lv1: lv1.bin

More important its how we use this. Also i dumped the sysrom, not sure if thats the same, as sycon. If it is then its what we need, on QA.

From zecoxao: i'll provide the link for you to analyze. also this dump contains both kernels, DEX kernel and CEX kernel, on 4.21 REX ros0 and 1. sysrom is probably SYS(CON EEP)ROM. Download: 20090102-121542-FLASH-NOR-FW4.21.7z

From PatrickBatman comes an NPDRM Batch File, to use: Drag and drop eboot on to it (--np-content-id=SET074-NPUB30409_00-BTTF10200000GAME. Change this to the game content id your doing --np-app-type=EXEC change this in NPDRM .bat to UEXEC only if the game is an update)

From sorg: according to LV1loader, ch73 should contain version value. so for v4.21 it looks:

So conclusion. You need to dump the bootloader 2 to get the keys for the lv0 version 2 its the same files just different headers aka keys. they secured the new consoles so good, that they dont work with flashers. don't hang me up on that.
but guess that's the problem. So unless someone finds an way, to read strait from the motherboard.

From zecoxao: cool, ps2_netemu gets decrypted. i suppose now it'll be possible to get the ps2 klicensee and try to achieve ps2 emulation on ps3 by iso loading.

From aldostools: As leaked lv1ldr keys, these lv2ldr and isoldr keys can be used to decrypt the lv2 and iso selfs for 4.20-4.31 (4.20, 4.21, 4.23, 4.25, ... 4.30, 4.31) And as far as I know the revision for [lv2ldr] is revision=0000 (not revision=001F)

Here is an updated KEYS file: aldostools.org/temp/keys My "ps3keys" app can be used to convert the keys from scetool format to .ps3 format for MFW Builder, deank's [EBOOT_FIX], etc.

From zecoxao: Unless there's a fail in the ECDSA code, i hardly think it's possible to get any more private keys. There was one, it was fixed. Now everything must be signed 3.55 and below. regarding 3.56 and above, you can see true ECDSA working, and thus the concept of private public key criptografy is shown. you can know the public key but you can't know the private key, because only some people know about it, and i'm talking the ones who make the firmware, so the decision to get private keys is pointless now.

From zadow28: private keys are out off the question thats for sure. But if you really examine the lv0 and lv0.2 it makes sense bootldr2 is just like the normal bootldr. just without the randomfall exploit, so no calculation. the new consoles uses the same lv0 as we know it just with header lv0.2. pretty easy to test cut hex at offset 0x0000000000000500 in the lv0 (old) copy the lv0.2 thats 0x00000000000004F0 long so fits perfect. Run throw scetool

of course we cant decrypt it, since we dont have the new bootldr keys. (bootldr2) Now for the lv0.. inside are 4 isolated headers. after a lot of hex editing you would find that they belong to appldr/lv1ldr/lv2ldr/isoldr. thats strictly for the new version. funny thing is, that they didn't made new files at all, just new headers, with the same result.

So on new consoles, example the decrypted lv1ldr would, look 100% the same, as the one we can decrypt. Also the loader headers are different length, than the old version.So that suggestion that they change the algorithm, no crypto expert, but still.

Actually there are two files, hidden inside the ps3tmgui.exe lv2diagnose ones signed with 3.60 keys. of course it would be console suicide to use them, still wonder no one have found that out yet.

yes i know it was there, but the possibillty that it would brick someones console is very high, and i dont know that much about, the lv2diagnose. this is from sdk 4.0 (prodg) so guess its used when the dex have an softbrick, when debugging. happens a lot when using prodg. you can get into FSM just not out most likely nothing at all is gonna happen.. still you never know.

From aldostools: lv1ldr 4.20-? -> these are the same keys for lv1ldr 4.30-? lv2ldr 4.20-? -> these are the same keys for lv2ldr 4.30-? isoldr 4.20-? -> these are the same keys for isoldr 4.30-?

And the selfs with the the following names are also decrypted with the isoldr keys for 4.20-4.30: spp_verifier 4.20-? spp_verifier 4.30-? spu_pkg_rvk_verifier 4.20-? spu_pkg_rvk_verifier 4.30-? I would appreciate if someone could explain me how to decrypt sv_iso_for_ps2emu.self and me_iso_for_ps2emu.self

Regarding the Appldr table, I believe that the key *not "0x1E"*, it is not even an appldr key. It could be a key for some other purpose.

The keys for 4.20-? were added to the wiki... IMO the version should be 4.20-4.26 (4.26 SEX is the latest 4.2x) or simply 4.20-4.31
The spp_verifier/spu_pkg_rvk_verifier were not added... they decrypt with isoldr keys for versions 4.20-4.31
The "appldr" that I think are not appldr "4.31" keys are the erk=46BD089122... IMO, appldr keys revisions 1C, 1D, 1E are 4.20-4.31

From zadow28: yes they work for all , they follow the hexidimal letters so so after 0x1F its should be 0x20 4.31 = 0x20, you can count back from there.

From Mustapha: Interesting string in the decrypted ps2_netemu.elf caution: image counts exceeded, %d maximum to show/SELECT IMAGE TO BOOT. Up/Down to select, Cross to boot, Triangle to exit... Hmm, Sony has a PS2 disc image front end ready to go?!

From Abkarino: Here it is just for you Zadow from your old friend Abkarino. There is 2 dumps i had uploaded for you or for any body else willing to play with it. This is a dump from metldr.2 console and from updated metldr console (3.6x) that both can not be downgraded. Hope to hear good news from you.

[21:20:11] flatz: there is a package which have NPDRM eboot.bin
[21:20:19] flatz: and non-NPDRM self
[21:20:30] flatz: self doesn't have footer signature
[21:20:34] flatz: so you can replace it with custom one
[21:20:46] flatz: and app will load it

And there you have it. the so called argument between math and kakaroto was over this specific thing (the NPDRM footer).

There might be more packages like this one

WORKS ON ALL FIRMWARE VERSIONS! IF YOU WANT A HEN, DO NOT UPDATE IF YOU'RE ON OFW!

We need to know in which version this was patched, credit to flatz for the finding, i'm just reporting back. How to test:

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.

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.

I have now added the the PS3 4.31 isoldr and lv2ldr keys from anonymous (via pastie.org/private/avbxlh6jg7089sh5m4bg) posted below to the main article as well for those following, hopefully with these final keys a PS3 MFWBuilder 4.31 update will arrive soon.