Sponsored Links

Sponsored Links

Details and Payloads for Dumping PS3 Per Console Keys Surface


Sponsored Links
151w ago - PlayStation 3 developers have been busy recently working on payloads for dumping the PS3 per console keys, as once the per_console_key_0 is obtained with full EID decryption dongles and burned BR-D's may be a thing of the past.

Below are details from sphinxkoma and the PS3 Wiki (ps3devwiki.com/index.php?title=Talk:Per_Console_Keys) on dumping the per_console_key_1 via Kaz... it's only a matter of time for per_console_key_0 which unlocks everything we need.

To quote: PS3 Per Console Keys

EID crypto is very complicated, it is done so on purpose. first of all EID0 isn't decrypted with one key, and one algorithm alone. it is decrypted in several parts which use different algos and keys. the keys are all derivations of a per console key (per_console_key_1) which is stored inside metldr and copied by it to sector 0 and never leaves isolation. that same key is a derivation of the per console key (per_console_key_0) used to encrypt metldr and the bl in the first place as well.

isoldr clears that key from sector 0 before jumping to the isolated module. but before doing so it encrypts it with another keyset and stores it in a buffer so that the isolated module can use the new crafted key. since the operation is AES, if you know that keyset you can decrypt the crafted key and get the eid root key without pwning a loader or metldr through an isolated module.

that is not like you really need it because you can already use the crafted key to decrypt some of eid0, but not all of it. and the crafted key also uses the first elf section to be built as in your isolated module will have a small section which only contains a key. and that key is used as another layer by isoldr to encrypt the buffer with it. so basically you have 2 encryption layers over the root key. the final key then decrypts a specific part of the EID.

eid crypto is actually done smart. that is because most of it originally comes from the cell bootrom, as in they reuse the same algo used for metldr binaries and bl in the eid crypto, including some of the keys and the steps. and you cannot decrypt all of the eid sections unless you gathered every single keys and steps. and there are a lot then you still have to figure out wtf it is you decrypted because eid is actually full of keys.

1. payloader3 create new possible source of or precompiled:

payloader3-341.pkg: [Register or Login to view links]
payloader3-315.pkg: [Register or Login to view links]

2. Install payloader3 pkg on the ps3

3. export in the terminal set
a. export PS3LOAD = tcp: ipaddress.of.ps3
b. start socat (socat tcp-recv: 18194 stdout)

4. payloader3 pkg start on ps3

5. It is quite likely to see is not the picture (black screen) but you will hear a distinct sound (like C64) Now things are different feasible:

a. X 4eck then starts with ps3load ethdebug
b. then you will want to circle back to the xmb and invites ethdebug (for Debuging pkg files)

6. Use your ps3load the mode used to send your ps3 dump_eid_root_key.self (ps3load dump_eid_root_key.self) Now you should see debug Terminal in your debugging and then hopefully you'll find the PCK .. (theoretically)

The per console key is used to derive other keys, some of which Sony can't change as this appears to be the bottom of their encryption chain. It's also important to note that this method is intended for dumping per_console_key_1 and per_console_key_n while per_console_key_0 is currently still required.

However to speculate, in future PS3 CFW updates users may need to be on a Custom Firmware to begin with (or downgrade to one first) and then run a .PKG to get their per console encryption key, followed by using it in a PS3 MFW Builder and installing the resulting modified PS3 Firmware on their PlayStation 3 console.

From ps3devwiki.com/index.php?title=Per_Console_Keys#per_console_root_key_0:

  • metldr is decrypted with this key
  • bootldr is decrypted with this key
  • might be obtained with per_console_root_key_1? (largely speculative, not nec. true - need more looked into, only based on the behavior of the other derivatives known to be obtained through AES)

Finally, from the PlayStation 3 Wiki (ps3devwiki.com/index.php?title=Per_Console_Keys and ps3devwiki.com/index.php?title=Boot_Order#Chain_of_Trust for the PS3 boot order) pages:

Per Console Keys

per_console_root_key_0

  • metldr is decrypted with this key
  • bootldr is decrypted with this key
  • might be obtained with per_console_root_key_1? (largely speculative, not nec. true - need more looked into, only based on the behavior of the other derivatives known to be obtained through AES)

per_console_root_key_1 / EID_root_key

  • derived from per_console_key_0
  • stored inside metldr
  • copied to sector 0 by metldr
  • cleared by isoldr
  • Used to decrypt part of the EID
  • Used to derive further keys
  • can be obtained with a modified isoldr that dumps it
  • can be obtained with a derivation of this key going backwards

obtaining it

launch the patched isoldr with your prefered method

Option 1 - dumper kernel module

  • modify glevands spp_verifier_direct to dump the mbox to wherever_you_want and then (use the payload below as an example)
  • the example code on how to dump the mbox can be found on the Option 2 - dumper payload below

Option 2 - dumper payload

[Register or Login to view links]


  • patched isoldr to dump it
  • DO NOT CREATE AN MFW USING THIS IT WOULD BRICK
  • patched isoldr: [Register or Login to view links]
  • this can be loaded as the payload stage2 in the payload marcan used to load linux
  • [Register or Login to view links]
  • [Register or Login to view links]
  • this can also be loaded as with lv2patcher and payloader3
  • [Register or Login to view links]

Comments

  • What this selfs do is dump your ISOLATED SPU LS through your mbox, so you only need a way to cach this info with PPU code in lv2 enviroment aka a dongle payload or linux kernel
  • This has been tested and proven to work on 3.55 MFW
  • In the dump the remaining dump is the metldr clear code. metldr clears itself and all the registers an jumps to isoldr.
  • Overwriting that code lets you dump your key + metldr
  • Consider that per_console_key_1 and per_console_key_n are in fact still in need decryption.
  • per_console_key_0 particularly needs to be dumped once revived from per_console_key_1.

per_console_root_key_2 / EID0_key

  • this key can be obtained through AES from EID_root_key
  • EID can be partially decrypted by setting this key in anergistics and fireing aim_spu_module.self
  • Load aim_spu_module.self + EID0 + EID0_key in anegistics = decrypted EID0
  • This code is to decrypt your EID0 on your PC [Register or Login to view links]
  • The prerequisites are:
  • dump your EID0 from your ps3 and save it in the same folder as EID0
  • dump your EID0_key from your ps3 and put it on the code above where the key is needed
  • load all of them in anergistic
  • EID0_key could also be obtained with EID_root_key directly in the following manners:
  • knowing the algorithm (located in isoldr)and applying it to the EID_root_key
  • letting isoldr apply that algorithm directly in anergistic
  • the process is exactly as the one above (modifing anergistic to feed isoldr with EID_root_key

obtaining it

  • patched aim_spu_module to dump it
  • DO NOT CREATE AN MFW USING THIS IT WOULD BRICK
  • [Register or Login to view links]

per_console_root_key_n

  • these are further derivations of the per_console_key_1/EID_root_key

Documentation

  • polarssl.org/trac/browser/trunk/library/aes.c

From VenomousX: How to obtain this EID_root_key?

  • Patch isoldr to dump the local storage of sector 0
  • Load the patched isoldr
  • Dump the local storage
  • You will find eid_root_key
  • Use it to decrypt the eid0.

How to load back the isoldr:

  • Use glevand's tools, spp_verifier_direct to be specific: "spp_verifier_direct is a kernel module which shows you how to run isolated SPE modules on OtherOS++ Linux by using metldr directly.
  • It decrypts default.spp profile.
  • Once you get the eid rootkey, load aim_spu_module.self with eid0 and the eid root key within anergistics it will decrypt it.
  • You can modify it easily to run other SPE modules.
  • Has been done and tested on 3.41 and 3.55 (not by myself)

So yes, you can obtain the eid rootkey and partially decrypt the eid0, but the problem if you want to modify the eid0 (say... to get a DEX idps to convert CEX=>DEX (which doesnt have much got use for end-users, only devs)) then you'd need to re-encrypt the EID0, which you can't. Not with those keys at least.

Oh, and while PS3 rootkeys are per console, and usually FW independent. However I dont know about 3.6+ because I didn't test it on it. But it might be true that 3.6+ eid rootkey have changed since $ony changed a load of keys with 3.6+. So using the 3.55 eid_root_key on 3.6+ to decrypt anything probably wont work.

Sony PlayStation 3 hacker [Register or Login to view links] states the following on this via Twitter: "There are 3 per console keys. it tells you how to obtain 2 (per console key 1 and per console key n) not THE root key. It will not lead to a new CFW, it is fun for devs, you can decrypt a lot of eid and reverse it.. it is not newb friendly at all."

PlayStation 3 hacker defyboy has also added the following: "I don't think this is a step closer to discovering the per-console root key. The EID root key is generated at factory and incorporated into metldr. metldr is encrypted with your per-console root key and stored on flash. Please note that while it is speculated that the EID root key is a derivative of the root key, that does not mean that it can be used to calculate the root key. Infact, being able to do so is idiotically counter-intuitive of the purpose of having two separate keys.

The per-console root key is likely burnt into the CPU via One Time Programming over the JTAG port, of which is disabled after programming. There is a hardware decryption routine that uses this key called Runtime Secure Boot, you cannot access or invoke this routine because it only runs when you load an encrypted image into an isolated SPU.

This is IBM's design, not sony's. This was designed to be a very secure multi-purpose processor and it was designed by a company that designs security and military systems for governments and large organizations, not a company that mostly makes consumer grade TV's and DVD Players. It was Sony's implementation of the secure chain of trust that failed but I don't see IBM's part failing anytime soon.

This paper explains everything: [Register or Login to view links]

Anyway, Sony cannot change metldr or bootldr on current hardware so they no longer have control of those, we only need to dump bootldr to get the lv0 key, this is the highest level sony can change. If we get the lv0 key we can generate a private key where we will be able to decrypt/re-encrypt the entire chain of firmware for current/future firmware."

The Per Console Key in the Cell decrypts bootldr, which is encrypted with the PCK. Bootldr decrypted is the same in EVERY console to date (except possibly the 3K series). When bootldr decrypts lv0, bootldr will be as if it were nowhere to be found. Then you go from there to the Chain of Trust.

Below is Gitbrew's feedback on the PS3 Per Console Key and future developments from them, as follows:

what do you think about the new method of getting the per_console_key?

Durandal: Glevand and many others have been working feverishly to develop methods of obtaining this key. It's nice to see it's paid off. I'm looking forward to a day when the PS3 is as open a development as the PSP.

Snowy: One step closer, sooner or later ibm is going to finally send a cease and desist. We'll put that right up next to dasmoovers sign.

Do you have anyone working on an easy to use tool for the key? we are already used to gitbrew pkgs

Durandal: If we weren't, we'd have to quit gitbrew and join PS360...

Snowy: I'm pretty sure anything related to the rootkey, we might leave out just so that people actually learn how to get their own keys. As a sort of accomplishment type thing, but eventually there will be simple pkg files released to do it.

What next projects are we going to see from gitbrew regarding the ps3 scene? can we see some sort of "one day one announcement", like you did a couple of weeks ago?

Durandal: Well RSX is taken care of, NPDRM is getting very close to being irrelevant, and I've heard there's almost usable versions of psl1ght floating around. I guess the next really big thing you'll see is the release of the gitSkeet flasher.

We teamed up with progskeet and rebug to create a special edition of the progskeet2 that will have solderless clips and the kind of support and documentation only gitbrew is capable of providing. It also gives us an opportunity to branch out into the actual hardware exploitation as well. As far as having announcement a day weeks, expect to see more of them in the not so distant future.

What is your thought on the recent discoveries on the ps3 scene?

The new jb2 dongle AKA true blue.

Durandal: I'm always very wary of dongles. Usually they're just a ploy to make a buck, and these days it doesn't take long for someone to reverse what the software they're trying to hide does. Expect to see the same happen here. If we want to deter others from trying to peddle their software in a dongle form, we should make a point of reversing a dongle's functionality
and implementing it in a package. I'm sure that group paid a lot of money to get all those dongles made, and they'd hate to see that money go to waste.

Snowy: Yet again as durandal said, dongles are dongles, regardless someone is going to take a crack at them and release a free version of it. Cobra hasn't even been touched by most of the developers, and those who have touched it don't really care for piracy. I would like to thank dean for taking the first step in making psx backups working though, a small step but none the less towards the proper direction for the scene.

Finally, FiniteElement via ps3devwiki.com/index.php?title=Special:Contributions/FiniteElement states the following hint for those interested, to quote: "(you have all you need already just read carefully (compare option2 code with the kernel module code))

He also updated the PS3 SPU Isolated Modules Reverse Engineering page with the changes documented here: ps3devwiki.com/index.php?title=SPU_Isolated_Modules_Reverse_Engineering&diff=prev&oldid=6328





Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!

Comments 860 Comments - Go to Forum Thread »

• Please Register at PS3News.com or Login to make comments on Site News articles. Thanks!

violato135's Avatar
#850 - violato135 - 108w ago
Can I NOT use a dongle and jailbreak a ps3 without it???

imajei's Avatar
#849 - imajei - 108w ago
I don't have a dongle so can someone with a tb upload a decrypted ghost recon eboot i have an idea please

thats a pretty please i'm bored and need something to do thanx to the good ol community lol.

do i need a tb dongle to do this?

fantopoulos's Avatar
#848 - fantopoulos - 108w ago
i have a true blue will do my best to get a dump for you to proceed where we were stuck for a long time but no it seems like we are going uphill again thanks shadoxi for starting this elf dumper , amazing work cheers triple thumbs up

Asure's Avatar
#847 - Asure - 108w ago
shadoxi we can figure out the original ELF size using SCEtool to get this info right? (find start of elf64 header, + size = end of elf)

Example


Then we know the section headers start at 0x17EC228

Last section STRTAB:


So elf ends at 0x17EC0F7 + 0x12C. We add padding to 0x17EC228, and insert clean elf64 section headerd dump from original eboot.bin, right? Or does this dump ELF+section headers+some extra stuff we can cut off?

Anybody care to post a dumped elf (raw, with this tool) so i can look at it?

shadoxi's Avatar
#846 - shadoxi - 108w ago
Following up on the previous update, today I am releasing my True Blue USB dongle PS3 ELF dumper which works with any PlayStation 3 Firmware greater than 3.56 to dump the encrypted TB EBOOT / ELF files once they are loaded.

Download: [Register or Login to view links] / [Register or Login to view links] (Mirror) / [Register or Login to view links] (Mirror #2) / [Register or Login to view links] (Mirror #3) / [Register or Login to view links] (Mirror #4) / [Register or Login to view links] (Mirror #5) / [Register or Login to view links] (Mirror #6) / [Register or Login to view links] / [Register or Login to view links] (Mirror) / [Register or Login to view links] (DUMPEDBOOT.bin and DUMPEDBOOT1.bin) by arnes_king / [Register or Login to view links] by gibson25 / [Register or Login to view links] (np_trp_prx.rar) / [Register or Login to view links] (Mirror) / [Register or Login to view links] by mellss

Tested on:

  • Original 355 -> ok
  • True Blue CFW v2 -> ok
  • ...

There are some bugs (size of dump ...) but it works. It's ELF dumper from memory and it work with True Blue cfw v2 and any 3.55 firmware because it doesn't use lv2 peek/poke.

Warning: It will not brick your ps3. But I am not responsible for any damage.

HOWTO:

  • Enable dev_blind with multiman
  • copy libsysutil_np_trophy.sprx from /dev_blind/sys/external/external to dev_hdd0/ and rename it "orignal_libsysutil_np_trophy.sprx"
  • copy my modified "libsysutil_np_trophy.sprx" to /dev_blind/sys/external/
  • load a True blue game from multiman
  • exit multiman
  • run your game
  • wait few minutes (if you get black screen after 3 minutes reboot ps3)
  • exit game
  • go to ftp
  • in dev_hdd0/ there are your decrypted DUMPEDBOOT.bin
  • copy and rename it with another name.

Howto uninstall patch - Two ways:

  • You could uninstall this patch by replacing modified libsysutil_np_trophy.sprx by orginal libsysutil_np_trophy.sprx
  • Or update in recovery mode

Thanks to: Ps3dev

Brief Guide:

1 - Install TB ELF Dumper first as stated in its readme file.
2 - Start Multiman, it will make a dump of multiman eboots, so you must delete it first by browsing to dev_hdd0 then delete all DUMPEDEBOOT.BIN files you found there.
3 - Back to multiman game selection then select any TB game then launch it.
4 - Start the game from XMB then wait for some times until game start.
5 - Exit game now then start multiman again then browse to dev_hdd0 and now you must found a decrypted game dump.

From PlayStation 3 developer deank (via pastebin.com/avcM5iuU) comes a revision as follows:

Download: [Register or Login to view links] (np_trp_prx.rar) / [Register or Login to view links] (Mirror)

// Author: Shadoxi
// Modified:

// Backup the original /dev_flash/sys/external/libsysutil_np_trophy.sprx to /dev_hdd0
// Replace /dev_blind/sys/external/libsysutil_np_trophy.sprx by this sprx


#include
#include

#include
#include

#include
#include
#include
#include

SYS_MODULE_INFO (sceNpTrophyhook, 0, 1, 0 );
SYS_MODULE_START( _start );
SYS_MODULE_STOP ( _stop );

SYS_LIB_DECLARE( sceNpTrophyhook, SYS_LIB_AUTO_EXPORT | SYS_LIB_WEAK_IMPORT );
SYS_LIB_EXPORT ( loader_sprx, sceNpTrophyhook );

int _start(void);
int _stop(void);
void DumpELF_Payload(void);
void loader_sprx(const char* PATH_PRX);

static void write_message (char const * message)
{
unsigned int write_length;
char const * end;
for (end = message; *end != '\0'; ++end);
sys_tty_write(SYS_TTYP_PPU_STDERR, message,end - message, &write_length);
}

void DumpELF_Payload(void)
{
write_message("Dumping ELF from RAM...\n");
int fd;
uint64_t nread;
uint64_t ptr= 0x00010000ULL; //ELF offset in RAM;
uint64_t sizeelf = 35*1024*1024; //Need a way to get size of ELF

char dump_path[30]="/dev_hdd0/RAMDUMP-00.BIN";
for(uint8_t i=0; i

Sponsored Links

Sponsored Links
Sponsored Links

Sponsored Links







Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News