Editing Dumping Metldr

{{Wikify}}

files main: https://web.archive.org/web/*/http://ps3devwiki.com/files/devtools/dump-metldr/

[http://www.phrack.org/issues.html?issue=66&id=13&mode=txt archives/66/p66_0x0d_Power cell buffer overflow_by_BSDaemon.txt] [http://www.kernelhacking.com/rodrigo/docs/Cell-phrack.txt]

== How to use ==

 

ohai I'll tell you guys how to use mathldr<br/>

(I like to call it that, it's kinda catchy)<br/>

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<br/>

The static keys: http://web.archive.org/web/20150910133656/http://pastie.org/private/qwndjafrtkvhe9cikbxhg

 

<li>a unpacked copy of your flash (which you can obtain by using glevands [https://web.archive.org/web/*/http://ps3devwiki.com/files/flash/Tools/USB%20Flash%20Dump/ dump_flash.pkg]<br/>), you need:

<li><strike>EID0</strike> (not needed, commented out in run.sh) (if used, you will need to split eid from your flash [[Dev_Tools#dump_EID0.sh|dump_EID0.sh]]; use 'modprobe ps3dmproxy' if needed)</li>

and an unpacked copy of OFW (e.g. [https://web.archive.org/web/*/http://ps3devwiki.com/files/firmware/OFW-CEX/3.55/ 3.55 OFW-CEX]), you will need the following files from these:

<li>ps3tools [[Dev_Tools#fail0VERFLOW|fail0VERFLOW]] (to unpack your nor and the ofw ie norunpack and pupunpack)</li>

 

you can do this over ssh or on console.<br/>

{{keyboard|content=<syntaxhighlight lang="bash">wget https://web.archive.org/web/*/http://ps3devwiki.com/files/devtools/dump-metldr/metldrpwn.zip</syntaxhighlight>}}</li>

{{keyboard|content=<syntaxhighlight lang="bash">unzip metldrpwn.zip</syntaxhighlight>}}</li>

{{keyboard|content=<syntaxhighlight lang="bash">cd metldrpwn && make</syntaxhighlight>}}</li>

{{keyboard|content=<syntaxhighlight lang="bash">

insmod ./metldrpwn.ko

cat /proc/metldrpwn/debug

</syntaxhighlight>}}</li>

{{keyboard|content=<syntaxhighlight lang="bash">hd /proc/metldrpwn/dump  | less</syntaxhighlight>}}</li>

{{keyboard|content=<syntaxhighlight lang="bash">cp /proc/metldrpwn/dump /home/username/</syntaxhighlight>}}</li>

congrats you've completed about < 10 mins of actual work<br/>

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

 

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

 

and together they are eid0 root key<br/>

 

 

Example of eid_root_key with hardcoded version from minver 3.56+ console

 

== Mathieulh's explaination ==

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

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 generator 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 signature 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.

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 ?

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.

dump shared lsa (located at 0x3E000 in ls)<br>

until somewhere in the shared lsa, 0x40 byte change<br>

3) then dump the shared lsa and you have a decrypted header<br>

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.

Let's try to do just that, from your previous dump, you should 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, unsurprisingly, 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, 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).

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.<br>

It overwrites from 0x000 to 0x480 because I originally loaded the section of size 0x880 to 0x3FC00<br>

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

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.

 

'''Old partial/incomplete source: http://lan.st/showthread.php?t=4025'''

{{Reverse engineering}}<noinclude>[[Category:Main]]</noinclude>