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

131w 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)

[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
CURVE_TYPE = 0x33

PS3 Key dump from appldr 4.25 in SCETool format:

[Register or Login to view code]

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)

[Register or Login to view code]


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:

[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 (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 :

[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 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

[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!

Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter, Facebook and drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene and PlayStation 4 scene updates and fresh homebrew PS3 Downloads. Enjoy!


  • Sponsored Links




#172 - Ps3scener - 129w ago
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 - 129w ago
technodon's Avatar
key works on 4.31 too, checked the psn passphrase and they are both the same

#170 - Hernaner28 - 129w ago
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 - 129w ago
niwakun's Avatar
Keysets that dont work from the recent PS3 keys release

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

NPDRM Type Key set
001C

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

#168 - ConsoleDev - 129w ago
ConsoleDev's Avatar
Nice to hear these things, but too bad that the private keys are missing

#167 - PS3GAMER20111 - 129w ago
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 - 129w ago
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. ps3devwiki.com/wiki/Making_Isolated_SPU_Modules_and_Loaders 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.

#165 - windrider42 - 129w ago
windrider42's Avatar
I have heard they are the real deal, and guys already fixed Borderlands 2 for 3.55.

Also from Abkarino: Revokation List key are confirmed by me with 4.31 prog.srvk using scetool:
[code]
C:\Users\MHassan\Desktop\SCETools>scetool -i C:\Users\MHassan\Desktop\SCETools\p
rog.srvk
scetool 0.2.9 (C) 2011-2012 by naehrwert
NP local license handling (C) 2012 by flatz
[*] SCE Header:
Magic 0x53434500 [OK]
Version 0x00000002
Key Revision 0x0000
Header Type [RVK]
Metadata Offset 0x00000000
Header Length 0x0000000000000200
Data Length 0x00000000000000E0[*] Metadata Info:
Key 05 51 4A D4 82 CD 77 0C C0 58 C1 53 3C B0 92 1B
IV B2 4E ED 49 39 2A 0D CB 03 58 15 9A F1 67 DD BD[*] Metadata Header:
Signature Input Length 0x00000000000001C0
unknown_0 0x00000001
Section Count 0x00000002
Key Count 0x0000000E
Optional Header Size 0x00000000
unknown_1 0x00000000
unknown_2 0x00000000[*] Metadata Section Headers:
Idx Offset Size Type Index Hashed SHA1 Encrypted Key IV Compressed
000 00000200 00000020 01 01 [YES] 00 [NO ] -- -- [NO ]
001 00000220 000000C0 02 02 [YES] 06 [YES] 0C 0D [NO ][*] SCE File Keys:
00: 80 B6 91 44 54 B7 D1 C1 8D 1A ED 39 81 7E E5 2F
01: 84 21 9F 5E 00 00 00 00 00 00 00 00 00 00 00 00
02: D0 BC 27 84 22 30 34 C8 21 DA 58 B6 F0 F7 4A E0
03: C9 FC BC 30 9C A2 15 06 D5 BA 02 F6 FF CC 13 2A
04: 63 BB 9C EF F8 D7 26 45 68 77 94 4C 66 9E A2 1B
05: 87 09 C6 27 3C B7 79 2D 62 6E 14 90 66 F5 BD 86
06: 4B B8 B8 38 51 20 BD 76 9F BA 83 66 04 75 EC 47
07: 6C 84 1D D2 00 00 00 00 00 00 00 00 00 00 00 00
08: D0 BC 27 84 22 30 34 C8 21 DA 58 B6 F0 F7 4A E0
09: C9 FC BC 30 9C A2 15 06 D5 BA 02 F6 FF CC 13 2A
0A: 63 BB 9C EF F8 D7 26 45 68 77 94 4C 66 9E A2 1B
0B: 87 09 C6 27 3C B7 79 2D 62 6E 14 90 66 F5 BD 86
0C: 5B D0 37 88 54 91 80 4C C1 F3 1F 70 AA 9D 0A B5
0D: 17 CA FB 25 69 19 85 85 D1 3A E4 37 00 00 00 00[*] Revoke List Header:
type_0 0x00000004
type_1 0x00000001
Version 04.31
Entry Count 0x00000006[*] Program Revoke List Entries:
Type Check Version Auth-ID/unk_3 Mask
lv2 == 04.31 0000000000000002 FFFFFFFFFFFFFFFF
Application == 04.31 vsh FFFFFFFFFFFFFFFF
Application == 04.31 10700005FE000001 FFFFFFFFFFFFFFFF
Application == 04.31 sys_init_osd FFFFFFFFFFFFFFFF
Application == 04.31 sys_audio FFFFFFFFFFFFFFFF
Application

#164 - ConsoleDev - 129w ago
ConsoleDev's Avatar
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!

Download: PS3 Keys 3.65 to 4.30 / PS3 Keys 3.65 to 4.30 (Mirror) / SCETool v0.2.9 with PS3 Keys by Brenza / True Ancestor + Haz367's Resigner.bat + PS3 Keys by DEFAULTDNB (run resigner.bat only, hit "0" to decrypt and hit "5" to sign for oldskool 3.55) / multiMAN 3.15-4.20+ [EBOOT_FIX].rar by slarty1408 / PS3 Downgrade 3.60++ (Lv2diag.421.self) from r3pek / VSH.elf (Rogero CFW 4.30) Patched for ReActPSN 2.xx by StealthLord / PS3 Keys for Deank ebootFIX / mMKeys v1.0 Alpha + multiMAN [EBOOT_FIX] testing App-Keys by romhunter / PS3 Keys Up To 4.31 Pack by razorx / PS3 SDAT/EDAT v3 and v4 Keys

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 tny.cz/72b4c5a7 (and pastebin.com/HciwadTZ / pastebin.com/9FVX1p5p / pastie.org/5144289) comes some PS3 NPDRM (PSN) and Appldr Keys up to 4.30:

[Register or Login to view code]

From anonymous (via pastie.org/5169661): This to finish the previously leaked keys. To the other team, we are on our way to pck0. Want a race?

[Register or Login to view code]

From aldostools on these keys: bad revision... they should be revision=0000 (corrected above now). Indeed they work for 4.20, 4.21, 4.25, 4.30 and 4.31.

From Brenza: Here's LV1 keys for 4.30 and 4.31

[Register or Login to view code]

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):

To decrypt:

[Register or Login to view code]



To resign add to the command line parameters:

[Register or Login to view code]



From PatrickBatman: Here just fix your own games: Put scetool (ver 0.2.9), data folder with added new keys, EBOOT.BIN and .bat below in a folder.

[Register or Login to view code]

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.

Download: sysrom.bin

Also the hypervisor is found in the dump.. use the PS3_HV_Dump.idc in ida pro it finds it.

[Register or Login to view code]

From zecoxao: Just figured it out: 20090102-111352-LV1-FW4.21.7z

i dumped it from Rebug Toolbox. and yes, it was on 4.21 REX

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:

[Register or Login to view code]

for v4.25:

[Register or Login to view code]

etc... But! for appldr v4.21, 4.25, 4.30 erk_hkey/iv iv_hkey/iv are the same. encrypted EDATKEY/HASH are also the same. so, ch73 should not contain FW version, IMHO.

From anonymous (via pastie.org/private/avbxlh6jg7089sh5m4bg) also comes the PS3 4.31 isoldr and lv2ldr keys below as well:

[Register or Login to view code]

From zadow28: Well the lv0.2 is simply the header(metadata) for the lv0 so if you cut the header of the normal lv0 and replace it with the lv0.2.

[Register or Login to view code]

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.

[Register or Login to view code]

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

[Register or Login to view code]

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.

Download: BINARY.rar

[Register or Login to view code]

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.

From zxz0O0 (Adrahil) comes PS3 SPP and RVK 4.25 Keys for decrypting the default.spp, prog.srvk and pkg.srvk from 4.xx Firmware below with additional details HERE:

spp_verifier 4.25 (probably 4.20 - 4.31):

[Register or Login to view code]

If you want to use with scetool you have to use manual keyset (scetool is confused because both keysets 3.55 and 4.25 have revision 0)

rvklist 4.25 (probably 4.20 - 4.31):

[Register or Login to view code]

scetool format:

[Register or Login to view code]

As always all of the current PlayStation 3 Keys decrypted can be found archived on the PS3 Wiki (ps3devwiki.com/wiki/Keys) for those seeking them.

Finally, from zecoxao comes one more crypto fail, PS3 selfs without npdrm footer as follows:

This pkg contains a self, that doesn't contain an npdrm footer.

Download: http://ares.dl.playstation.net/cdn/EP4345/NPEB00863_00/boMeZZKzGeQgZaUOIFJyVwxcPllEGyBkGYTIiDULXtjwOJZjZQXvytAflhKaWtJurFlnXtaFPYLiYxyGLvyTUoVeEPAzcKgONTTGV.pkg

[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:

Download: cachemgr.self / cachemgr.self (Mirror)

Replace cachemgr.self with that, and use ps3xport to put game on PS3.

More apps and patches:

[22:28:13] flatz: app:

[Register or Login to view code]

patch:

[Register or Login to view code]



app:

[Register or Login to view code]

patch:

[Register or Login to view code]

From IronMAN: This is ability to run your own self files on OFW but not on latest ofw, because it patched already.

4.46 - working.
4.65 - not working.

From zecoxao: lol, we tested again. IT VOOOOOOOOOOOOOOOOOOOOOOOOOOOORKS. ON FCKING LATEST FIRMWARE The code runs but the app crashes New cachemgr.self, shouldn't hang now...

From mysis: Sony seemed to forgot to implement an api for spawning npdrm child-processes, thats why those apps do use non-npdrm signed selfs.

[19:43:21] [flatz]: doesn't work at all on 4.66 OFW
[19:43:25] [flatz]: we can close thread

More PlayStation 3 News...

#163 - SoraKing11 - 130w ago
SoraKing11's Avatar
wait... so, was the key real?