Dumping Metldr

From PS3 Developer wiki
Jump to: navigation, search

files main: http://www.ps3devwiki.com/files/devtools/dump-metldr/


archives/66/p66_0x0d_Power cell buffer overflow_by_BSDaemon.txt [1]

How to use[edit]

ohai I'll tell you guys how to use mathldr
(I like to call it that, it's kinda catchy)
just don't go crazy with it, it's possible mess your eid up if you attempt to rehash it and flash or attempt in any way to replace your eid
you can decrypt eid with root keys and static keys in the wiki key talk page
The static keys: http://web.archive.org/web/20150910133656/http://pastie.org/private/qwndjafrtkvhe9cikbxhg


  1. otheros++ with ss patches
  2. linux on your ps3 (im using ubuntu 10.10)
  3. a unpacked copy of your flash (which you can obtain by using glevands dump_flash.pkg
    ), you need:
    • metldr (aka asecure)
    • EID0 (not needed, commented out in run.sh) (if used, you will need to split eid from your flash dump_EID0.sh; use 'modprobe ps3dmproxy' if needed)

    and an unpacked copy of OFW (e.g. 3.55 OFW-CEX), you will need the following files from these:

    • isoldr
    • RL_FOR_PROGRAM.img (not needed, commented out in run.sh)
    • spp_verifier.self
    • default.spp
    • and obviously appldr-metldrexploit350.self from the files
  4. ps3tools fail0VERFLOW (to unpack your nor and the ofw ie norunpack and pupunpack)
  5. latest gitbrew linux kernel
  6. a desire to quit *****ing and complaining and get off your ass.
  7. motivation (see prerequisite #6)

Step by Step instuctions[edit]

Precompiled metldrpwn : http://www.ps3devwiki.com/files/devtools/dump-metldr/metldrpwn.zip

you can do this over ssh or on console.


  1. ssh into the ps3
  2. download the files:
  3. untar the files:
    Type This
    unzip metldrpwn.zip
  4. enter the directory and compile:
    Type This
    cd metldrpwn && make
  5. run the following commands now:
    Type This
    insmod ./metldrpwn.ko
    cat metldr > /proc/metldrpwn/metldr
    cat appldr-metldrexploit350.self > /proc/metldrpwn/mathldr
    cat RL_FOR_PROGRAM.img > /proc/metldrpwn/rvkprg
    cat eid0 > /proc/metldrpwn/eid0
    echo 1 > /proc/metldrpwn/run
    cat /proc/metldrpwn/debug
  6. there now you have a dump check it out:
    Type This
    hd /proc/metldrpwn/dump
  7. now copy the dump somewhere or youll lose it:
    Type This
    cp /proc/metldrpwn/dump /home/username/

now you have a copy in your home directory for safe keeping
congrats you've completed about < 10 mins of actual work

there you go: keys are in 0x00 to 0x20 (first 3 lines)



00000000 66 4d ee 51 65 6f 68 28 38 98 83 ea df ea 90 04 |fM.Qeoh(8.......|    // erk/key
00000010 01 f3 79 09 d6 a6 52 d9 ea 6d ef 04 51 69 ec 7b |..y...R..m..Qi.{|    // erk/key
00000020 7d 6a 3a e5 37 ba 48 4c fe bd 26 5c f5 b1 28 1f |}j:.7.HL..&\..(.|    // riv

the first 2 lines are erk the 3rd is riv
and together they are eid0 root key

example with hardcoded version of minver 3.50+ console[edit]

Rare example of eid_root_key with min version hardcoded into it.  Found in some rare  2501A's (believed to possibly be in 3.60+ as well, but unable to verify.)
00000000  F5 CC 0B 7F 4D 00 31 07 F2 BC 57 A4 B5 C3 8B E1  |õÌ..M.1.ò¼W¤µÃ‹á|  // erk/key
00000010  78 A9 CD BC 73 21 5A 5B 9D E0 B2 7B 13 BE 4D 21  |x©Í¼s!Z[.à²{.¾M!|  // erk/key
00000020  A7 72 F8 74 BE A9 E6 52 B3 D9 A6 85 05 69 D9 C7  |§røt¾©æR³Ù¦….iÙÇ|  // riv
00000030  00 03 00 50 00 00 00 00 32 7F FF 80 32 7F FF     |...P....2.ÿ€2.ÿ |  // min version/jump ladder

the last line contains min version hardcoded in first 8 bytes, and last 8 bytes is jump code beginning. (only difference.)


Example of eid_root_key with hardcoded version from minver 3.56+ console
00000000  BF 85 81 FF 99 E8 CB A8 32 DF 41 00 66 C9 5F C7 
00000010  4B A8 EE A8 9A 68 8E 15 81 1E 54 ED A8 EB 06 4C 
00000020  EB BF C3 41 4A 9E DF B0 ED A0 86 68 03 3D AD 87 
00000030  00 03 00 56 00 00 00 00 32 7F FF 80 32 7F FF 80

Some good reading on the subject for further understanding[edit]

3.56 and older Chain of Trust

Mathieulh's explaination[edit]

(needs cleanup)

Because some ungrateful person leaked my metldr exploit files I will now be explaining how it actually works, 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 place, 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)



The question is, do you really need keys to get a decrypted signature ? Well the real answer is no, thanks to a nifty bug that sony left in metldr, you can have the loader 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 located 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 0x3E1F0 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 in the shared Local Store. So basically you have to
1) set the offset += 0x2000
dump shared lsa (located at 0x3E000 in ls)
and keep increasing 0x2000
until somewhere in the shared lsa, 0x40 byte change
3) then dump the shared lsa and you have a decrypted header
knowing that metldr uses SCE header 0xECF0, you could calculate it knowing the address 0x3E1F0 - 0xECF0 = the value you would patch at SCE header + 0x0C


so it should be 0x3E1F0 - 0xF6C0


So far so good, now what's next ?


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 part of the Isolated Local Store, the first thing you will notice is that you have a bit of metldr's code as a leftover, after a bit of disassembly you will notice that it's actually some piece of code that clears metldr's code and registers and jumps to some address which matches your signed loader's entrypoint.
This seems a more than likely candidate to exploit, as 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.
Well, maybe not, should you check out the hardware properties for the Local Store, you would find out that the memory wraps around (memory is a donut as someone once said at some CCC conference).

Well, it WORKS!

 ROM:000008AC 33 7F 6C 80 brsl lr, cleanup_and_jump_entry
 ROM:000008B0 32 00 11 80 br loc_93C
 ROM:00000410 cleanup_and_jump_entry: ; CODE XREF: main+4Cp
 ROM:00000410 32 7F FF 80 br sub_40C

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 of 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 those 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 this is my last contribution to this scene. It seems I can't even trust fellow developers to keep my work safe.
So long, everyone.
Remember, don't ever bite the hands that feed you.

Old partial/incomplete source: http://lan.st/showthread.php?t=4025 (Link now deprecated)