meltdr2 decryption?
- Thread starter Goldenawp
- Start date
Berion
Developer
No one decrypt it yet - at least in public.
There is no "metldr2" in 3.60+ firmwares. Old meta loader was unified with boot loader (or lv0, I don't remember).
It is a file You can extract from firmware and decrypt if You know how.
On old firmwares, we using trick to get out already decrypted (it is encrypted per keys unit).
There is no "metldr2" in 3.60+ firmwares. Old meta loader was unified with boot loader (or lv0, I don't remember).
It is a file You can extract from firmware and decrypt if You know how.
On old firmwares, we using trick to get out already decrypted (it is encrypted per keys unit).
Last edited:
sandungas
Developer
I like to think in this using animals and a farm XD
Metldr is an egg with a chicken inside... and we are a little cat that doesnt really knows how to open an egg... but have lot of interest in taking a look inside the egg
So... we wait patiently to night, where the farmer takes an egg and opens it to cook it... and thats when we learn what is inside an egg
But the fact is we dont know how to open an egg :/
Metldr is an egg with a chicken inside... and we are a little cat that doesnt really knows how to open an egg... but have lot of interest in taking a look inside the egg
So... we wait patiently to night, where the farmer takes an egg and opens it to cook it... and thats when we learn what is inside an egg
But the fact is we dont know how to open an egg :/
Like all the loaders, metldr is a SPU self designed to run in the isolated SPU.
lv1 (ie the hypervisor running on PPU) is responsible for loading the metldr self into the isolated SPU with the necessary arguments & dealing with the outcome.
The metldr self binary is stored in lv1 memory at a static offset, ready for lv1 to copy when necessary.
Statistically speaking, you cannot bruteforce the ecdsa encryption on a PC (or even a distributed network) in a reasonable amount of time, at least not unless you find a weakness in the encryption procedure used to produce your encrypted target.
Keeping in mind anyway that bruteforcing is illegal, punishable under US federal law.
However it is perfectly legal to run a custom SPU executable that may read data from the isolated SPU memory & transfer it to the PPU.
The isolated SPU, like its name suggests, uses reinforced security, the local store (0x40000 bytes of memory reserved for each SPU for storage) is purposefully inaccessible to reading & writing by the PPU code, DMA/MFC access is disabled & the only way to exchange data between the isolated SPU & the PPU is mailboxes.
If lv1 (and maybe only lv2) is jailbroken, it is possible to write a PPU app that loads a isolated SPU payload which in turns loads metldr with appropriate arguments then using interrupts leaks data back to the PPU. The mailbox being limited to 4 bytes transfers, the interrupts are used as a synchronisation mechanism, signaling each mailbox 4 bytes reads/writes, until the entire data is collected & made available to the user. That's exactly what the ERK dumper (by flatz) does.
Using this technique, it is possible to leak crucial encryption keys (in unencrypted form) like the eid_root_key, a decrypted elf or whatever data you may be interested in. Currently this technique is only used on consoles where the hypervisor is jailbroken but it might be possible to adapt the technique to a situation where only the supervisor (lv2) is jailbroken, it needs confirmed though.
From here, there are 2 possible steps forward.
1. Wait until lv1 on metldr2 consoles gets jailbroken so that existing code can be used to leak data.
2. Try to adapt the existing isolated SPU leak code so it runs at supervisor level (lv2) rather than at hypervisor level (lv1).
There is already one publicly available supervisor (lv2) exploit on metldr2 consoles (used by ps3xploit PS3HEN) which was directly ported from the sceNetIoctl Vita kernel exploit used for a time in henkaku.
And I have another supervisor exploit that I keep private for the moment.
Given the relatively slow but constant progress made with metldr2 consoles over the past 3 years, and I am not talking just about the ps3xploit work btw, others have worked on one thing or another, I am confident that the hypervisor (lv1) should be exploited within a year or so by someone, who knows, after a while we may even end up with different exploitation options from different people. I expect that metldr2 will eventually lose its secrets.
lv1 (ie the hypervisor running on PPU) is responsible for loading the metldr self into the isolated SPU with the necessary arguments & dealing with the outcome.
The metldr self binary is stored in lv1 memory at a static offset, ready for lv1 to copy when necessary.
Statistically speaking, you cannot bruteforce the ecdsa encryption on a PC (or even a distributed network) in a reasonable amount of time, at least not unless you find a weakness in the encryption procedure used to produce your encrypted target.
Keeping in mind anyway that bruteforcing is illegal, punishable under US federal law.
However it is perfectly legal to run a custom SPU executable that may read data from the isolated SPU memory & transfer it to the PPU.
The isolated SPU, like its name suggests, uses reinforced security, the local store (0x40000 bytes of memory reserved for each SPU for storage) is purposefully inaccessible to reading & writing by the PPU code, DMA/MFC access is disabled & the only way to exchange data between the isolated SPU & the PPU is mailboxes.
If lv1 (and maybe only lv2) is jailbroken, it is possible to write a PPU app that loads a isolated SPU payload which in turns loads metldr with appropriate arguments then using interrupts leaks data back to the PPU. The mailbox being limited to 4 bytes transfers, the interrupts are used as a synchronisation mechanism, signaling each mailbox 4 bytes reads/writes, until the entire data is collected & made available to the user. That's exactly what the ERK dumper (by flatz) does.
Using this technique, it is possible to leak crucial encryption keys (in unencrypted form) like the eid_root_key, a decrypted elf or whatever data you may be interested in. Currently this technique is only used on consoles where the hypervisor is jailbroken but it might be possible to adapt the technique to a situation where only the supervisor (lv2) is jailbroken, it needs confirmed though.
From here, there are 2 possible steps forward.
1. Wait until lv1 on metldr2 consoles gets jailbroken so that existing code can be used to leak data.
2. Try to adapt the existing isolated SPU leak code so it runs at supervisor level (lv2) rather than at hypervisor level (lv1).
There is already one publicly available supervisor (lv2) exploit on metldr2 consoles (used by ps3xploit PS3HEN) which was directly ported from the sceNetIoctl Vita kernel exploit used for a time in henkaku.
And I have another supervisor exploit that I keep private for the moment.
Given the relatively slow but constant progress made with metldr2 consoles over the past 3 years, and I am not talking just about the ps3xploit work btw, others have worked on one thing or another, I am confident that the hypervisor (lv1) should be exploited within a year or so by someone, who knows, after a while we may even end up with different exploitation options from different people. I expect that metldr2 will eventually lose its secrets.
Last edited:
Maybe there is no lv1 exploit simply because nobody has really been seriously looking for one yet?
zeco mentioned that someone had recently investigated hypervisor calls for an exploitable bug but without luck.
That is about all I heard about hypervisor exploit research since PS3HEN was released. I dunno whether that person gave up or is still researching.
Of course, it doesn't mean to say that nobody else is investigating the hypervisor or working on an exploit.
At my end, I have been busy working on the file explorer project & dedicated time over the summer to write a new kernel exploit along with an improved kernel ROP chain even though it meant delaying the file explorer release. There is no particular hurry for it anyway.
But I haven't had any time to dedicate to the hypervisor so far. And I must admit that available free time has been real scarce too these past weeks.
I will be working on the hypervisor as soon as the file explorer project for the PS3 Toolset repo is released & I will do so even if someone else comes up with something in the meantime.
Last edited:
Berion
Developer
I will be waiting for it for sure. My interesting doesn't fading out, so even if this will be publish hacked after ten years, I'm still be happy.
Also waiting for file manager via toolbox (as I understood, it will be possible to copy data to i.e USB by this way or just only view tree?).
Also waiting for file manager via toolbox (as I understood, it will be possible to copy data to i.e USB by this way or just only view tree?).
I am only following my long term project plans, step by step & interest does not fade out in my case either. I am learning loads & enjoying the process. ;-)
As is, the file manager project supports all file systems that can be mounted natively by the PS3.
It features all standard file manager operations such as folder/file creation/deletion/copy/move/details.
I originally started with a 2 pane GUI like Irisman file manager (2 trees containing both files & folders) but I am currently working on another GUI more like Managunz (1 tree for folders & selected folder contents in a table or list).
I dunno yet which of them will be polished for release, I still need to test a few things before I make up my mind & esc0rtd3w is busy with life, he cannot help me with testing atm.
Additionally, I planned to add a few extra features such as text based files editor & binary file hex viewer, picture viewer, sound player, zip/unzip etc..
I don't know where I will set the limit though, I just want a basic tool that can fulfill most basic file related jobs on OFW, the more features I add & the more complex testing & releasing becomes, taking too much time overall & I must have this completed by the end of the year.
Last edited:
RoboKing's Cosmos
Member
Nope unfortunately you still gotta wait, sleirsgoovy aka zer0tolerance has given up on it before dunno if he'll try again or hand it over to someone else to research Metldr2
While it is risky to bruteforce metldr2 static key if it was done on a supercomputer we could technically use this decryption privately
On a second note there is lv0.2 once you unpack your nor or eMMC so maybe that file also needs attention a bit more than metldr.2
While it is risky to bruteforce metldr2 static key if it was done on a supercomputer we could technically use this decryption privately
On a second note there is lv0.2 once you unpack your nor or eMMC so maybe that file also needs attention a bit more than metldr.2
Last edited by a moderator:
Similar threads
-
-
PS4 FW11 decrypted? or SceShellCore.elf specifically
- Started by diamneth
- Replies: 0
-
-
PS2 How do you decrypt the .VOB ELFs from the SUDC v3 & v4 discs?
- Started by Kevstah2004
- Replies: 7