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

November 13, 2011 // 10:53 pm - A few weeks back details and payloads for Dumping PS3 Per Console Keys surfaced followed by news of a PS3 Metldr Exploit, and today PlayStation 3 developer xx404xx on IRC has shared his PS3 Metldr / Per Console Key0 findings thus far.

Included below are a PS3 EID Rootkey Dumper (SELF) which is loaded through lv2patcher, an EID Decrypter Script, the required EID Static Keys and more, as follows:

[xx404xx] lol wtf you can write to metldr!!!!!!
[xx404xx] 0x17014 - Write eEID/Write metldr Holy crap, it writes passed data to the region of FLASH memory where eEID or metldr data is stored !!! And GameOS is allowed to use this service !!! Do not experiment with this service if you don't know what it does or else your PS3 will not work anymore !!!
[xx404xx] I highly recommend you all go look at that
[xx404xx] Is anyone taking a look at that paste bin? (via from lunuxx)
[xx404xx] Here's a pic from this leaked doc i found
[xx404xx] there's no per console key 0 in the guide
[xx404xx] and you need this leaked doc
[xx404xx] ill go upload it
[xx404xx] the per console key0 is only for my console......
[xx404xx] but you can obtain your own lv0
[xx404xx] im upploading the doc now
[xx404xx] i was hesitant about leaking this
[xx404xx] but here you go, you will need this info
[xx404xx] it has doc on the spu's
[stronzolo] what do you think about the picture who math posted on the twitter ?
[xx404xx] real
[xx404xx] he already told us how he does it....
[stronzolo] us = who ?
[branan] everybody. His thing about metldr from a couple days ago applies to bootldr just as well
[xx404xx] it's no secret
[stronzolo] so why math can do it... and others can't ? what's wrong ?
[xx404xx] lol if he didnt want other's knowing about it mabye he shouldnt tweet so many hint's.......
[xx404xx] we can do it
[xx404xx] read the docs
[xx404xx] he talk's about how we dump the local storage from the spu's
[stronzolo] 404 when do we know if your key is key 0 ?
[xx404xx] when someone prep's a step by step guide to dump bootldr
[xx404xx] Patent[How to dump lv0 with HW ;] that's all im going to say for know....there will be more later, and this is not a complete guide, but math gave you eveything else you need....
[XX404XX] Ik how math does the bootldr exploit
[antikhris] do tell...

On the PS3 True Blue Dongle:

[xx404xx] True blue is stupid
[xx404xx] it's the fselfs
[eussNL] its more than / just / fself, try unself one and you see what it is
[eussNL] its DRM'ed fself
[xx404xx] ps3 crunch is trying to make money on the new dongles......
[eussNL] well not surprising as GaryOPA is reseller
[xx404xx] where do you think
[xx404xx] it came from
[xx404xx] i dont mean drm
[eussNL] what?
[xx404xx] i mean the fself
[eussNL] there are plural items
[xx404xx] debug servers obv
[eussNL] well, they only have limited titles so there is your clue

From (

BootOrder explained (Thank's wiki) VERY IMPORTANT (per_console_key_0 is not the key which will be derived, but is the key which has derived per_console_key_1) We have pck1 using the dumper, in order to obtain pck you need to dump it out of ls. In order to do that with hardware you should look into math's comment's about dumping a shared lsa.

In order to do this with software you should either use math's bootldr exploit or you need to exploit the spe secure runtime.... (Not all that hard with the two recent exploit's)

With Runtime Secure Boot feature, an application can run a check on itself before it is executed to verify that it has not be modified and compromised.Secure Boot is normally done only at power-on time, but the Cell BE processor can Secure Boot an application thread multiple times during runtime. (PS3'S doesn't do this right as you can see in the failoverflow vid)

Passing execution: (

Spe execution control diagram: (

Error Reporting: (

A Debug support flag set in SC EEPROM at address 0x48C50. When this flag is set, the token is read from SYSCON and decrypted, this gets passed to various modules to unlock certain functionality.

Debug support flag is tied to EID which is supposed to be hashed and saves in SC EEPROM

[Register or Login to view code]

A FSELF support flag set in SC EEPROM at address 0x48C06. When this flag is set, the token is read from SYSCON and decrypted, this gets passed to various modules to unlock certain functionality.

[Register or Login to view code]

Eid Rootkey(1) Dumper (Load through lv2patcher) (You need this)

Decrypt your eid with this (You need this)

[Register or Login to view code]

Eid static key's (You need these)

1.00 Debug/DEX - aim_spu_module.self

[Register or Login to view code]

3.15 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

3.41 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

3.55 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

3.56 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

1.00 Debug/DEX - appldr

[Register or Login to view code]

3.15 Retail/CEX - appldr

[Register or Login to view code]

3.41 Retail/CEX - appldr

[Register or Login to view code]

3.55 Retail/CEX - appldr

[Register or Login to view code]

3.56 Retail/CEX - appldr

[Register or Login to view code]

1.00 Debug/DEX - isoldr

[Register or Login to view code]

3.15 Retail/CEX - isoldr

[Register or Login to view code]

3.41 Retail/CEX - isoldr

[Register or Login to view code]

3.55 Retail/CEX - isoldr

[Register or Login to view code]

3.56 Retail/CEX - isoldr

[Register or Login to view code]

1.00 Debug/DEX - lv1ldr

[Register or Login to view code]

3.15 Retail/CEX - lv1ldr

[Register or Login to view code]

3.41 Retail/CEX - lv1ldr

[Register or Login to view code]

3.55 Retail/CEX - lv1ldr

[Register or Login to view code]

3.56 Retail/CEX - lv1ldr

[Register or Login to view code]

1.00 Debug/DEX - lv2ldr

[Register or Login to view code]

1.00 Debug/DEX - spu_pkg_rvk_verifier.self

[Register or Login to view code]

1.00 Debug/DEX - spu_token_processor.self

[Register or Login to view code]

3.15 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.41 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.55 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.56 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.15 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

3.41 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

3.55 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

3.56 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

In related news, Sony PlayStation 3 hacker Mathieulh Tweeted the following comments on what appears to be the PS3 Firmware 3.73 lv0 bootloader decrypted:

Boot Loader SE Version 3.7.3 (Build ID: 4611,48369, Build Date: 2011-10-12_12:31:19) What's taking you so long ?

Boot Loader SE Version 3.6.6 (Build ID: 4534,47762, Build Date: 2011-06-16_13:24:46) I am bored....

Oh ! that's nothing just a little string from the 3.73 lv0....

By the way, I won't be posting keys, I won't be posting dumps and I won't be saying how it was done, time to work gentlemen.

It's a command prompt because I am using my own tool to decrypt selfs to elf and not the buggy unself. Not like an unself prompt couldn't be faked though.

You can't sign lv0 on a cech-3000 sorry. No, the new bootloader uses a new keyset.

The build number should be proof enough, as long as you can get your hands on a decrypted lv0 that is. Posting keys is not an option, posting hashes of the keys wouldn't bring you any additional proof because you have no way of verifying those, besides Sony's lawyers would claim that I'd be posting encrypted forms of the keys like they did in the fail0verflow trial, and I am not posting screenshots because lv0 contains copyrighted code.

So unless you have any other "proof" in mind that I could post legally without fearing prosecutions, feel free to tell me about these.

I am definitely not releasing it anyway, I've already said how I am not releasing anything anymore, EVER. I am a man of my word.

By the way instead of demanding, people should start looking at my "pwning metldr the "easy" way" post where I gave the first steps into exploiting the bootloader and one of the required exploits and start working from that, there is no point in making demands, asking for "proofs", keys and whatnot, I won't be sharing these, so you'd better start working; I've given you a nice starting point.

I am done talking about lv0 decryption, feel free to resume this talk once it becomes public and people can verify the strings I posted.

Although unconfirmed, eitjuhh has Tweeted the following: Don't flame ppl!.. lv0 decrypted from my debug console!!

Posted a little preview of the ps3swu.self from 4.00 -

Shortly following, he Tweeted (!/eitjuhh/status/144763029224038400): Found new keys in OFW 4.00 !! doesn't know which keys they are at this moment!.. but i think the new!/eitjuhh/status/144763029224038400/photo/1

bit i think they are the new klic_dec_key keys sony wrote them twice in other ofw's now 3 times??

60 00 00 00 E8 01 00 80 38 21 00 70 7C 08 03 A6 --- Second new key found!

And he Tweeted (!/eitjuhh/status/145054115750346752): Yesterday I did a second test! CFW is RUNNING ppl!!.. Tonight I will build in Peek&Poke! Video: soon, Release: Before Christmas !

From Sony PS3 hacker xorloser (CitizenX of scene release group PARADOX) via Twitter:

V3.60 and above have the secrets encrypted inside lv0, and the lv0 keys are not publicly available.

lv0ldr loads lv0 direct from flash rather than from memory, plus nothing else is running at this stage. So trickier, but doable.

From zecoxao comes a brief guide: How to Dump BOOTLDR Unencrypted (Decrypted)

Things you'll need:

  • PS3 on 3.55 OTHEROS++ (this was tested on a slim, but phats are probably achievable aswell)
  • Latest linux kernel (or any of the 3.x.x kernels by glevand precompiled)
  • Knowledge of linux ( such as , creating symlinks (ln -s), editing kboot.conf, sudoing, etc)

In case you don't have the latest kernel, but already have one installed distro:

[Register or Login to view code]

And now for the fun part:
[Register or Login to view code]

PS: Lv0 keys are STILL encrypted, so don't complain, you have your precious bootldr there, have fun with it.

Finally, from anonymous (via comes a PS3 dump bootldr how to exploit:

Must have a dex 3.55 real or made dex 3.55 ps3 also duel nand/nor installed chip base. In a 3.55 dex console, prepare a lv0.self with the metadata exploit. reboot. lv0 will hang since lv0.self will not run properly. bootldr will send info to lv0 before it hangs, after it decrypts it, running dex with certain switches set up like boot in dev mode Will allow this hang dump of bootldr to be saved to the local store.

But, essentially you will have a bricked ps3 so recovery of the local store wont happen. This is where the duel nand/nor comes in handy and allows you to recover from this and replace your messed up lv0.self with the original to boot up and recover the local store dump and the decrypted bootldr. This will allow the keys to bootldr these keys cannot be changed with any update.

We can then exploit lv0. The exploit of bootldr/lv0 will allow the ability to change the way private keys are made or give us the ability to reset up the private key fail and resign packages with any new firmwares.

This although is just a "well tested Theory" of course.

PS3 Metldr / Per Console Key0 Update, LV0 Bootloader Decrypted?

PS3 Metldr / Per Console Key0 Update, LV0 Bootloader Decrypted?

PS3 Metldr / Per Console Key0 Update, LV0 Bootloader Decrypted?

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.

#1 - chr15m - November 8, 2011 // 12:33 pm
chr15m's Avatar
Today an anonymous PlayStation 3 hacker has leaked a PS3 Metldr exploit, followed by a guide from Mathieulh on how to pwn metldr the "easy" way below.

Download: PS3 Metldr Exploit / PS3 Metldr Exploit (Mirror) / PS3 Metldr Exploit Dump / PS3 Metldr Exploit Dump (Binary File) / PS3 Metldr Exploit Layman's Guide by lunuxx

From GaryOPA: We received an 'an0nymous email' from some random one-time dropbox, containing a weird little attachment, with a simple note:

Program: metldr838exploit
Author: Unknown
Usage: Unknown
Reason: Unknown

Before posting we had one our PS3 crunching developers look it over, and it seems to be a set of 'C' code and headers and an compiled ELF and SELF that exploits the 'chain of trust' to dump an 'unecrypted' version of your PS3 'metldr'.

Now of course this is not really 'useful' for the average PS3 Jailbreak end-user, but we think it just might be the long waited for 'golden tickets' in the right hard-working hands of some talented 'developers' that are willing to try to help everyone out by pushing the PS3 'scene' to the next level, that almost everyone here has all have been waiting for!

Seems long-time 'scene' developer Mathieulh is claiming ownership of this 'metldr' exploit, and has now published his 'How-To' tutorial for it:

How to pwn metldr the "easy" way

Because some ungrateful person leaked my metldr exploit files I will now be explaining how it actually works, see this as my ultimate release of all times for an ungrateful scene (and scenes in the future)

That's about how I am pissed right now, because of course the person that leaked these files has no idea of how they actually work.

How to pwn metldr the "easy" way:

This is most likely how geohot exploited it in the first way, this takes (give or take) about 10 minutes to be performed. (yeah, not so much of a "I hacked the ps3 all on my own work, especially not when it partially relies on Segher's work, one of the reason geohot never shared the way he exploited metldr to anyone)

I will assume here, that you do not have the loader keys that were made readily available by geohot. This little tutorial also assumes that you have a working .self generating tool

Now You want to gain code execution to metldr, you know that metldr loads loaders to its own space, but you cannot run a loader because the loader needs to be signed and even though you know about the sign fail that Segher introduced at the CCC, you cannot use it because you don't have decrypted signatures to calculate a private key and to get signatures you need keys which you are currently trying to dump, so far you are stuck in a chicken and egg scenario.

The question is, do you really need keys to get a decrypted signature ? Well the real answer is no, thanks to a nifty fail that sony left in in metldr (and the bootloader), you can have the ldr to decrypt the metadata for you, isn't that neat ?

Here's how it works:


In a self file, at address 0x0C a value is used to calculate where the metadata is going to be decrypted, the "offset" is at self header + 0x0C its the "meta header offset" in the SCE structure, it takes the SCE offset + that value, so what you have to do is to have a calculation that is equal to 0x3E01F0 which happens to be where metldr copies over the shared metadata from the mailbox (which is sent over by the ppu), the trick is to have metldr to decrypt the metadata located at.

So basically you have to:

1) set the offset += 0x2000 dump shared lsa and keep increasing 0x2000 until somewhere in the shared lsa changes 0x40 byte
2) when it changes 0x40 bytes, you can add/subtract the proper amount to make it decrypt the proper locations
3) then dump shared lsa and we have decrypted header knowing that metldr uses SCE header 0xECF0, you could calculate it knowing the address 0x3E01F0 - 0xECF0 = the value you would patch at SCE header + 0x0C

ROM:0000F6C0 D2 68 87 E6 metadata_erk: .int 0xD26887E6 ; DATA XREF: ROM:0000F178o for example in CECHA , the address you want to decrypt it to is 0x3E1F0 so it should be 0x3E1F0 - 0xF6C0

Once you get the decrypted header, you have the key to decrypt the rest of the metadata. Here you go, you have your decrypted signature.

So far so good, now what's next ?


Contrary to popular beliefs, you do not need to know the public key to calculate the private key, you just need two decrypted signature, you now know how to dump these, so let's assume you just did, now all you have to do is to bruteforce the curve type by constantly reloading a self to metldr, the curve type being only 1 byte, that would be 64 possibilities.

CONGRATULATION, you just signed a loader !

Now what ?

Well Your first reflex would be to sign a loader and use it to dump whatever is in your Isolated Local Store, the first thing you will notice is that you have a bit of metldr's code as a leftover, after a few seconds of disassembly you will figure it's actually some piece of code that clears metldr's code and registers and jumps to some address which is matches your signed loader's entrypoint.

This seems like a more than likely candidate to exploit, as in your goal would be to overwrite that piece of code with your own, that way you would have the whole metldr code right before the point where everything gets cleared out.

Let's try to do just that, from your previous dump, you obviously know that the clear code is located from 0x400 to 0x630, (0x410 being where metldr jumps when it clears) your first attempt would naturally be to have a loader section to load at 0x400, well not so surprisingly, it fails, because you are not without a brain (at least you aren't supposed to be if you're reading and understanding this), you will assume that it is likely that metldr checks if you aren't loading your loader/self section below a certain address, which considering you know the loaders' entrypoint is most likely to be 0x12C00, this assumption is in fact correct as metldr will make sure you cannot load any loader at 0x12BFF and below, seems like a huge let down...

Well, maybe not, because yet again, you are not without a brain, you check out the hardware properties for the Local Store, and you find out that the memory wraps around (memory is a donut as someone once said at some ccc conference).

So what happens when you load your loader at let's say from 0x3F000 to 0x40000+some address? (like 0x40410 for example) ?

Well, it WORKS!
You could put the section at 0x3F000, if you made the length 0x1414 and the last instruction branches "up" to the dump code.

[Register or Login to view code]

This is what the exploit that got leaked (yeah that's not really their work eh but you figured that much by now did you not?) does. It overwrites from 0x000 to 0x480 because I originally loaded the section o size 0x880 to 0x3FC00

So now you get code execution on metldr at the best time possible because your code executes right after metldr copies the root keys from 0x00 to 0x30, which means you get to dump these too. (Although they are hardcoded in metldr's code anyway)

Here you go, you have a metldr dump !

Now as a final line, I'd like to say screw leakers, screw the scene, and this is my last contribution to it EVER. It seems I can't even trust fellow developers to keep my work safe and not leaking it. (Not like any of them would have been able to tell you how all this even works in the first place)

So long, everyone. Remember, don't ever bite the hands that feed you.

P.S. Oh! and btw, if you talented enough to make hardware to dump the shared lsa, you can decrypt any lv0 using this technique.

[Register or Login to view code]

From the PS3 Metldr Exploit ReadMe file:

[Register or Login to view code]

Also from Mathieulh attempting to defend himself from PS3 Scene Devs: Oh ! and to people who might doubt it's a leak (As in 2 people who might by some miracle have found the very same exploit), the leaked appldr-metldrexploit350.self file not only bares the same name but the same hash and obviously the same signature as the file I've given out to the few people that had it.

If you don't know about this, because of the rand functions involved, the chances of getting an identical signature on a self file are one to trillions, so yeah, definitely my stuff.

To people still claiming that the leaked files weren't crafted by me, look at "" the "/proc/metldrpwn/mathldr" line is a dead giveaway. IRC Log here:

Oh ! and just so you know, because the "donut fail" requires a signed ldr to work and gain code execution in metldr doesn't mean there is no way to pwn metldr.2 though obviously you can't use that particular exploit for this) Not like you really need to dump a metldr with an updated keyset, a hardcoded 3.60 min ldr version and some useless gcc optimizations though.

By the way, to Sony engineers' credit, they did check if you'd load a ldr at 0x40000+ they just didn't check if you'd load it at 0x3FFFF or below and have it a positive size

I wonder if people noticed the metldr.spu.cecha.elf, metldr.spu.cech2500.elf and the 1.3MB metldr-cecha.idb in my metldr's collection pic

I don't really care about the ps3 anymore anyway. Here is a protip before I am gone, you can load the bl more than once.

From Sony PS3 hacker adrianc: I hate to burst everyone's bubble but this means nothing. The chain of trust was fixed by moving loaders into lv0.

Until lv0 is either dumped or decrypted, the loaders, and therefore the keys will remain just out of reach. Cold boot exploits are not possible because lv0 sets up the loaders table before passing execution to lv1. Decrypting lv0 requires pwning the bootloader_PE, which is very difficult. If you could sniff the flexio you might be able to dump it that way. Or you could use what is known about the CBE secure boot to preempt bootldr. I suggest the IBM docs as reading material.

They are encrypted with the same key, which is burnt into the CBE efuses. This key is never passed along the chain of trust, so neither metldr or bootldr ever sees their own key. Metldr dumps will give you some perspective on how secure loaders work, and possibly stimulate some ideas for how you might be able to pwn bootldr. However, there is no easy 'find a key, use a key' solution to be found inside metldr.

This exploit does not enable you to find the hardware root key, merely a much weaker derivative which exists to prove the secure loader has been authorised by hardware.

Unconfirmed PS3 Bootldr Key:

[Register or Login to view code]

From naehrwert: and

[Register or Login to view code]

From izsh1911

[Register or Login to view code]

Related Tweets: 7492E57C2C7C63F44942268FB41C58ED... I found out a lot more too

94D100BE6E24991D65D93F3DA938858CEC2D133051F47DB4287AC86631719B31573EF7CCE071CA8A (placeholder for the future)

eidtool "eid0_hash_encrypt_section_0"

aes_omac1(section_in + 0xA8, section_in, 0xA8, key, 0x80);

From xorloser: The "metldr exploit" had already been replicated long ago by many ppl who feel no need for public acknowledgement.

Finally, from lunuxx via JailBreakScene: Well it works, go get your root key.

[Register or Login to view code]

Well in the first 3 lines of my dump:

[Register or Login to view code]

[Register or Login to view code]

From IRC: [eussNL] that is how you can verify your metldr dump, by looking for

[Register or Login to view code]

[Register or Login to view code]

Now we just need a way to do it ourselves without having to install linux on our PS3. They are different for each PS3 (box-specific key that Metldr is signed with, which has new keys for the rest). Lunuxx was just showing us that it is possible and safe to try. It also gives us reference to what a proper dump should look like. A more detailed guide is now available HERE.

More PlayStation 3 News...