Dumping the .2 metadata keys from local storage

[zecoxao]

Hello. Since i literally lost a ps3 due to overheating a couple of minutes ago, i'm coming here to the forum to do some research on the bug that Mathieulh found some time ago, and possibly attempt to make something useful out of it, if only for collection purposes.

The bug (present in metldr) works the following way:
When you load an isolated module in metldr using isolation mode (either via lv2 syscalls or via lv1 hypercalls), metldr will load the module to the local storage for decryption. once it's decripted, it'll clear all of the local storage BUT the metadata of the loader. So this means one thing: we can obtain the metadata of any isolated module we want, by just loading said module in isolation mode and then dumping the Local Storage.

So i thought "why not load the modules responsible for the signatures of the .2 modules and then dump the metadata keys from the local storage and then use them to decrypt said modules?"

This likely can be done on any 3000 console (DECH-3000 or CECH-3000) and since we have HEN, we have both lv2 privileges as well as lv1 ones (just not lv1 peek and poke)

Sony isn't likely to further update the ps3, so why not do it?

Unfortunately, to understand how it's done i need some help in understanding:
1: how to load an isolated module (though a section of the wiki explains a portion of it)
2:how to dump the local storage (there is a homebrew made a very long time ago by adrianc called LSPWN that would dump it but there was never a source release)

i think people like @mysis or @habib should understand this better.

This is simply for collection purposes, so apologizes if it sounds too demanding

 

[Berion]

Could You attach lspwned? I cannot help You in Your problem but this tool missing in my basement. ^^

 

[Hollywood5082]

https://gbatemp.net/download/lspwn-v0-1-ps3-spe-local-storage-dumper.25975/

 

[zecoxao]

yes, it's the homebrew @Hollywood5082 attached. really really old. source promissed on 0.2, never delivered.
as for the isolated loading code, it was submitted to the wiki and can be found here:
https://www.psdevwiki.com/ps3/SPU_I...ngineering#Loading_Isolated_Modules_in_GameOS

 

[mizdx]

what's the point?

 

[Hollywood5082]

this app dumps the local store of an spe to /dev_hdd0/game/LSPWN0ADC/USRDIR/***PlayStation Store***.bin
a neat POC for devs, but also a n00b friendly introduction to the spe environment.​

Instructions :

1. run the app
2. copy the binary from the hdd using your preferred method
3. disasemble using ida and get a hands on look at the local store
4. ???
5. profit!​

 

[Hollywood5082]

If one person can create a eboot. Bin that calls the.2 then you can load it in the drive and decrypt it that way then dump the spe

 

[zecoxao]

what's the point?

The point is to collect the remaining signature keys (and signatures) from .2 module headers and add them to the wiki for documentation purposes

 

[habib]

but its useless though. the only thing different in metadata will be what? signatures? of no use?
if you want to get a valid metldr.2 loader. simply swap the .2 header on the corresponding file. e.g patch appldr.self with appldr.2 header thats valid

 

[zecoxao]

but its useless though. the only thing different in metadata will be what? signatures? of no use?
if you want to get a valid metldr.2 loader. simply swap the .2 header on the corresponding file. e.g patch appldr.self with appldr.2 header thats valid

I want to collect the metadata keys and signatures. i already know it's useless, but i want to further document the wiki and this is something that has to be done eventually, even though it's a boring job

 

[mysis]

That wiki link code is loading user space supplied isolated modules, but you want the metadata from e.g. isoldr right?

Yes it should be possible with lv2 access on a metldr.2 console. Right now i only have a decr-1400 model with me...

It might be possible to use: sys_spu_thread_read_ls or maybe an isospu variant of it after isoldr is loaded/decrypted or manually from the mmio address...e.g. could install an ofw dech with vulnerable rsx syscalls to easily dump it.

 

[zecoxao]

@mysis can you teach me? maybe on irc or something, i don't know where you hang around now

 

[zecoxao]

Btw, Mathieulh has this to say:

I realized
That you can use that bug
To gain code exec
In metldr
But it would be a pain
Basically
Because you can arbitrary force metldr to write the decrypted meta keys anywhere in LS
you could bruteforce a proper instruction
Basically trying garbage until you get something useful
(Using the bug to use metldr as an oracle to bf the instructions you want)
And once you get something valid, like a jump to an address in shared ls
Then you find some location you put have metldr copy your encrypted instruction to
And gain code exec
That's probably the only way to get metldr.2 code exec

And a nice reminder that if you do get metldr.2 code exec you also get the root key in return, and then you can convert to cex2dex using the leafs of an old system

Edit:

so if I were you, I'd target the clear code

location for it never changes and it's the best place to overwrite if you want a full dump

since CBC integrity is only on encrypt

you can bruteforce an instruction with a valid address somewhere in shared LS

it won't be easy

because you still need to do a block

so 0x10 at a time

best way is to use the bug

to bruteforce your way

as an oracle

basically retain anything that starts with a ppc instruction

and see if you have anything valid

that's presumably weeks of bruteforcing

but once it's done, you have something that works on all .2 consoles that bug exists on

Edit3:

also, if you use the bootloader bug along with that
you can get the .2 keys for both metldr and bl

 

[zecoxao]

So this is some food for thought, the post above, @habib @mysis and @bguerville

 

[mathieulh]

Metldr doesn't magically make the decrypted metadata available to you upon request, that would be quite the security oversight if this was done by design; you have to realize that this is exploiting a bug to make it happen.

If you need further details on how the bug actually works, please read the following wiki post I've made back in 2011:

https://www.psdevwiki.com/ps3/Dumping_Metldr#Mathieulh.27s_explaination

The bug is explained in depth in "STEP 1".

 

[mathieulh]

I am actually not 100% sure you can get code exec using this.
You would have to debug it

I am not sure if the offset is where it outputs the decrypted metadata header or where the decryption happens (probably the later)
if it's the later, it'd not work for code exec (unless you have extreme luck)

it's been so long that I don't remember (circa 2011), so if you want to make use of it, you will have to double check this.

 

[zecoxao]

currently tried to do this on a CECH-3000 on 4.86 with resource to sdk samples but haven't been able to get past the error 80010005
multiman was used for this to load the fself, and logs were outputted to /dev_usb001/logs.txt
i attach together a 7z in the hopes someone solves this.

 

[nCadeRegal]

Interesting theories here guys. I love watching the minds at work here. Nothing to see here....move along. Lol