Details and Payloads for Dumping PS3 Per Console Keys Surface

82w 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: http://www.multiupload.com/JKKZG58NOR
payloader3-315.pkg: http://www.multiupload.com/MB7NE5AJYC

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

http://pastie.org/pastes/2101977

• patched isoldr to dump it
  
• DO NOT CREATE AN MFW USING THIS IT WOULD BRICK
  
• patched isoldr: http://www.multiupload.com/2MP5KY28EZ
  
• this can be loaded as the payload stage2 in the payload marcan used to load linux
  
• http://marcansoft.com/blog/2010/10/asbestos-running-linux-as-gameos/
  
• http://git.marcansoft.com/?p=asbestos.git
  
• this can also be loaded as with lv2patcher and payloader3
  
• https://github.com/euss/payloader3.git
  

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 http://pastie.org/2000330
  

  ## channel.h
  //Add this defines.
  
  //SPU channels.
  #define SPU_RdEventStat 0
  #define SPU_WrEventMask 1
  #define SPU_WrEventAck 2
  #define SPU_RdSigNotify1 3
  #define SPU_RdSigNotify2 4
  #define SPU_WrDec 7
  #define SPU_RdDec 8
  #define SPU_RdEventMask 11
  #define SPU_RdMachStat 13
  #define SPU_WrSRR0 14
  #define SPU_RdSRR0 15
  #define SPU_WrOutMbox 28
  #define SPU_RdInMbox 29
  #define SPU_WrOutIntrMbox 30
  
  //MFC channels.
  #define MFC_WrMSSyncReq 9
  #define MFC_RdTagMask 12
  #define MFC_LSA 16
  #define MFC_EAH 17
  #define MFC_EAL 18
  #define MFC_Size 19
  #define MFC_TagID 20
  #define MFC_Cmd 21
  #define MFC_WrTagMask 22
  #define MFC_WrTagUpdate 23
  #define MFC_RdTagStat 24
  #define MFC_RdListStallStat 25
  #define MFC_WrListStallAck 26
  #define MFC_RdAtomicStat 27
  
  //MFC DMA commands.
  #define MFC_PUT_CMD 0x20
  #define MFC_GET_CMD 0x40
  
  //MFC tag update commands.
  #define MFC_TAG_UPDATE_IMMEDIATE 0
  #define MFC_TAG_UPDATE_ANY 1
  #define MFC_TAG_UPDATE_ALL 2
  
  ## channel.c
  // Copyright 2010 fail0verflow <master@fail0verflow.com>
  // Licensed under the terms of the GNU GPL, version 2
  // http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
  
  #include <stdio.h>
  #include <string.h>
  #include <stdarg.h>
  #include <stdlib.h>
  #include <unistd.h>
  
  #include "types.h"
  #include "main.h"
  #include "config.h"
  #include "channel.h"
  
  //Channel names.
  static char *ch_names[] = 
  {
  	"SPU_RdEventStat", //0
  	"SPU_WrEventMask", //1
  	"SPU_WrEventAck", //2
  	"SPU_RdSigNotify1", //3
  	"SPU_RdSigNotify2", //4
  	"UNKNOWN", //5
  	"UNKNOWN", //6
  	"SPU_WrDec", //7
  	"SPU_RdDec", //8
  	"MFC_WrMSSyncReq", //9
  	"UNKNOWN", //10
  	"SPU_RdEventMask", //11
  	"MFC_RdTagMask", //12
  	"SPU_RdMachStat", //13
  	"SPU_WrSRR0", //14
  	"SPU_RdSRR0", //15
  	"MFC_LSA", //16
  	"MFC_EAH", //17
  	"MFC_EAL", //18
  	"MFC_Size ", //19
  	"MFC_TagID", //20
  	"MFC_Cmd", //21
  	"MFC_WrTagMask", //22
  	"MFC_WrTagUpdate", //23
  	"MFC_RdTagStat", //24
  	"MFC_RdListStallStat", //25
  	"MFC_WrListStallAck", //26
  	"MFC_RdAtomicStat", //27
  	"SPU_WrOutMbox", //28
  	"SPU_RdInMbox", //29
  	"SPU_WrOutIntrMbox" //30
  };
  
  //MFC channel values.
  static u32 _MFC_LSA;
  static u32 _MFC_EAH;
  static u32 _MFC_EAL;
  static u32 _MFC_Size;
  static u32 _MFC_TagID;
  static u32 _MFC_TagMask;
  static u32 _MFC_TagStat;
  
  //Endian swap.
  #define _BE(val) ((((val) & 0xff00000000000000ull) >> 56) | \
                    (((val) & 0x00ff000000000000ull) >> 40) | \
                    (((val) & 0x0000ff0000000000ull) >> 24) | \
                    (((val) & 0x000000ff00000000ull) >> 8 ) | \
                    (((val) & 0x00000000ff000000ull) << 8 ) | \
                    (((val) & 0x0000000000ff0000ull) << 24) | \
                    (((val) & 0x000000000000ff00ull) << 40) | \
                    (((val) & 0x00000000000000ffull) << 56))
  
  void handle_mfc_command(u32 cmd)
  {
  	printf("Local address %08x, EA = %08x:%08x, Size=%08x, TagID=%08x, Cmd=%08x\n",
  		_MFC_LSA, _MFC_EAH, _MFC_EAL, _MFC_Size, _MFC_TagID, cmd);
  #ifdef DEBUG_CHANNEL
  	getchar();
  #endif
  	
  	switch (cmd)
  	{
  	case MFC_PUT_CMD:
  		printf("MFC_PUT (DMA out of LS)\n");
  		{
  			FILE *fp = fopen("out.bin", "a+");
  			fwrite(ctx->ls + _MFC_LSA, sizeof(u8), _MFC_Size, fp);
  			fclose(fp);
  		}
  		break;
  	case MFC_GET_CMD:
  		printf("MFC_GET (DMA into LS)\n");
  		{
  			static int round = 0;
  			                         //module debug output address, set both to 0x0 for none
  			static u64 data0[2] = {_BE(0xbeef0110dead0000), _BE(0xbeef0220dead0000)};
  			static u64 data1[4] = {_BE(0xbeef0110dead0000), _BE(0xbeef0220dead0000), 
  			                       _BE(0x0000000200000000), _BE(0x0000000000000000)};
  			                                  //^-- 1,2,3,4 (device type/id, pscode, psid)
  			if(round == 0)
  				memcpy(ctx->ls + _MFC_LSA, &data0, _MFC_Size);
  			else if(round == 1)
  				memcpy(ctx->ls + _MFC_LSA, &data1, _MFC_Size);
  			else if(round == 2)
  			{
  				//Load EID0.
  				printf("loading eid...");
  				FILE *fp = fopen("EID0", "rb");
  				fread(ctx->ls + _MFC_LSA, sizeof(u8), _MFC_Size, fp);
  				fclose(fp);
  				printf("done\n");
  			}
  			round++;
  		}
  		break;
  	default:
  		printf("unknown command\n");
  	}
  }
  
  void handle_mfc_tag_update(u32 tag)
  {
  	switch (tag)
  	{
  	case MFC_TAG_UPDATE_IMMEDIATE:
  		printf("-> MFC_TAG_UPDATE_IMMEDIATE\n");
  		_MFC_TagStat = _MFC_TagMask;
  		break;
  	case MFC_TAG_UPDATE_ANY:
  		printf("-> MFC_TAG_UPDATE_ANY\n");
  		break;
  	case MFC_TAG_UPDATE_ALL:
  		printf("-> MFC_TAG_UPDATE_ALL\n");
  		break;
  	default:
  		printf("-> UNKNOWN\n");
  		break;
  	}
  	
  	_MFC_TagStat = _MFC_TagMask;
  }
  
  void channel_wrch(int ch, int reg)
  {
  	u32 r = ctx->reg[reg][0];
  	
  	printf("CHANNEL: wrch ch%d(= %s) r%d(= 0x%08x)\n", ch, (ch <= 30 ? ch_names[ch] : "UNKNOWN"), reg, r);
  #ifdef DEBUG_CHANNEL
  	getchar();
  #endif
  	
  	switch(ch)
  	{
  	case MFC_LSA:
  		_MFC_LSA = r;
  		break;
  	case MFC_EAH:
  		_MFC_EAH = r;
  		break;
  	case MFC_EAL:
  		_MFC_EAL = r;
  		break;
  	case MFC_Size:
  		_MFC_Size = r;
  		break;
  	case MFC_TagID:
  		_MFC_TagID = r;
  		break;
  	case MFC_Cmd:
  		handle_mfc_command(r);
  		break;
  	case MFC_WrTagMask:
  		_MFC_TagMask = r;
  		break;
  	case MFC_WrTagUpdate:
  		handle_mfc_tag_update(r);
  		break;
  	}
  }
  
  void channel_rdch(int ch, int reg)
  {
  	u32 r = 0;
  	
  	printf("CHANNEL: rdch ch%d(= %s) r%d\n", ch, (ch <= 30 ? ch_names[ch] : "UNKNOWN"), reg);
  #ifdef DEBUG_CHANNEL
  	getchar();
  #endif
  	
  	switch (ch)
  	{
  	case SPU_RdDec:
  		break;
  	case MFC_RdTagStat:
  		r = _MFC_TagStat;
  		break;
  	case MFC_RdAtomicStat:
  		break;
  	}
  	
  	//Set register.
  	ctx->reg[reg][0] = r;
  	ctx->reg[reg][1] = 0;
  	ctx->reg[reg][2] = 0;
  	ctx->reg[reg][3] = 0;
  }
  
  int channel_rchcnt(int ch)
  {
  	u32 r = 0;
  	
  	printf("CHANNEL: rchcnt ch%d(%s)\n", ch, (ch <= 30 ? ch_names[ch] : "UNKNOWN"));
  #ifdef DEBUG_CHANNEL
  	getchar();
  #endif
  	
  	switch (ch)
  	{
  	case MFC_WrTagUpdate:
  		r = 1;
  		break;
  	case MFC_RdTagStat:
  		r = 1;
  		break;
  	case MFC_RdAtomicStat:
  		break;
  	}
  	
  	return r;
  }
  
  ## main.c
  int main(int argc, char *argv[])
  {
  	u32 done;
  	memset(&_ctx, 0x00, sizeof _ctx);
  	ctx = &_ctx;
  	parse_args(argc, argv);
  
  	//Remove old output.
  	system("rm -f out.bin");	
  
  	//Set module parameters.
  	//PU DMA area start address.
  	//Dummy to make the module happy.
  	ctx->reg[3][0] = 0xdead0000;
  	ctx->reg[3][1] = 0xbeef0000;
  	//PU DMA area size.
  	//ctx->reg[4][0] = 0x80;
  	ctx->reg[4][1] = 0x80;
  	//PU EID area start address (first param).
  	//Dummy to make the module happy.	
  	ctx->reg[5][0] = 0xcafe0000;
  	ctx->reg[5][1] = 0xbabe0000;
  	//First param size.
  	//ctx->reg[6][0] = 0x860;
  	ctx->reg[6][1] = 0x860;
  
  	ctx->ls = malloc(LS_SIZE);
  	if (ctx->ls == NULL)
  		fail("Unable to allocate local storage.");
  	memset(ctx->ls, 0, LS_SIZE);
  
  	//Write EID master key (to start of LS).
  	u8 eid_mkey[] = {/* ... */};
  	memcpy(ctx->ls, eid_mkey, sizeof(eid_mkey));
  
  	//...
  }

• 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
  
• http://www.multiupload.com/1XUOOYS9I0
  

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 moogie301 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: http://www.ibm.com/developerworks/power/library/pa-cellsecurity/

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