Editing Per Console Keys

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
= Explanation =
[[Category:Software]]
==per_console_root_key_0==


== naehrwert's blogposts - Individual Infos - December 24, 2011 ==
*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)''
See also [http://www.ps3devwiki.com/index.php?title=Boot_Order#Boot_Sequence Bootorder::Boot Sequence]


One of the PS3′s console specific cryptography works as follows:
==per_console_root_key_1 / EID_root_key==


At factory time there is a console specific key generated, probably from a private constant value and a console specific seed. Maybe that’s the key used for encrypting bootldr and metldr. Fact is, that metldr stores another console specific keyset (key/iv) to LS offset 0×00000. That keyset is probably calculated from the first one. At factory time the isolated root keyset (how I call it) is used to encrypt the console’s “Individual Infos”, like eEID. But not the whole eEID is encrypted the same way, special seeds are used to calculate key/iv pairs for the different sections. And not even that is true for every eEID section, because for e.g. EID0 another step is needed to generate the final section key(set). Each of the isolated modules using such an “Individual Info” has a special section that isoldr uses to generate the derived key(set)s. But the generation works in a way, that the section data is encrypted with aes-cbc using the isolated root keyset, so it is not possible to calculate the isolated root keyset back from the derived key(set)s, because aes shouldn’t allow a known plaintext attack. So far I can decrypt some of EID0′s sections, EID1, EID2 and EID4. EID5 encryption should be similar to EID0′s but I lack the generation keys for that one.
*derived from per_console_key_0
 
*stored inside metldr
Source: http://nwert.wordpress.com/2011/12/24/individual-infos/
*copied to sector 0 by metldr
 
*cleared by isoldr
== naehrwert's blogposts - eEID Cryptography - July 11, 2012 ==
*Used to decrypt part of the EID
 
*Used to derive further keys ''(per_console_key_0 is not the key which will be derived, but is the key which has derived per_console_key_1)''
When metldr is encrypted at factory, a special keyset is set in the binary before encryption. Later when an isolated loader is loaded by metldr, it will copy the keyset to LS offset 0x00000. It consists of eid_root_key and eid_root_iv. To not having to use the same key for all eEID parts, several subkeys are generated from special data called individual information seed. These seeds are stored in the metadata header of isolated modules loaded by isoldr. When isoldr will load a module, it will call a subroutine that encrypts each seed chunk (0x40 bytes) using eid_root_key and eid_root_iv. Then the so-called individual infos are passed in registers r7 to r22 (= 0x100 bytes in total) to the loaded module where they are used further. Usually isolated modules have a seed section of 0x100 bytes but all of them (except sb_iso_spu_module) have all zeroes but the first 0x40 bytes chunk. You can, for example, find the recently published EID0 seed in the metadata section of aim_spu_module. Appliance info manager is used to get e.g. the target ID or the PSID from EID0. This explains why the seed can also be found in isoldr directly, since that one is checking EID0 too.
*can be obtained with a modified isoldr that dumps it
 
*can be obtained with a derivation of this key going backwards
As you can probably think, a fair amount of reversing time and knowledge has gone into finding this, so stop calling us *swearwords* for not releasing information that could potentially lead to more piracy, because we think that this would do more harm to the “scene” than just keeping some information in private (for now). Also I can only encourage everyone that thinks about us this way or is greedy demanding for developers/reverse engineers to release their stuff, to fire up isoldr in IDA or disassemble it with objdump and try to reverse all this from start to end. We’ll see, who is able to pull this through on their own…
 
Source: http://nwert.wordpress.com/2012/07/11/eeid-cryptography/
 
== Kaz about per-console keys derivation ==
 
<pre>
EID crypto is very complicated, it is done so on purpose by SCE.
 
First of all, EID0 is not decrypted with one key, and one algorithm alone. It is decrypted in several parts which use different algorithms and keys. The keys are all derivations of a per-console key (eid_root_key / per_console_key_1) which is stored inside metldr and copied by it to sector 0 and never
leaves isolation. per_console_key_1 is itself a derivation of per_console_key_0 which is used to encrypt metldr and the bootloader in the first place.
 
isoldr clears eid_root_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
operations are symmetric 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. It is not like you really need eid_root_key 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 eid_root_key. The final
key then decrypts a specific section of the EID0.
 
EID crypto is actually done smartly. That is because most of it originally comes from the CELL bootROM, as in it
reuses the same algorithms used for metldr binaries and bootloader in the EID crypto, including some of the keys and steps.
You cannot decrypt all of the EID sections unless you gathered every single keys and steps. There are a lot then you still have to figure out wtf you decrypted because EID is actually full of keys.
</pre>
 
== adrianc about hardware crypto ==
 
<pre>
I now know exactly how the hardware crypto works. I have confirmed the existence of eFuses and the OTP (bootrom) is real, aka the pre-bootldr. That is where you will find the most primary root key.
BootROM is not encrypted. You just can't see it (the CBE itself returns zeroes when you try to read it).
The eFuses hold the root key, which is 48bits, at Cell BE die, located in persistent storage.
IBM documents state "A unique 48-bit customer ID can be defined by the customer." (ie. in eFuses).
</pre>
 
More about efuses in general:
* [http://paris.utdallas.edu/ssiri08/Tonti_SSIRI_eFuse_V2.pdf Tonti_SSIRI_eFuse_V2.pdf]
* [https://www.psdevwiki.com/ps3/File:wdB8mFS.png reference]
 
Source: gitbrew#otheros
 
= Keys =
 
== per_console_root_key_0 ==
 
* bootldr and metldr are decrypted with this key. See also [[Boot Order]].
* Might it be obtained with per_console_root_key_1 ? It need more looked into. It might be the case, 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


=== Obtaining It ===
=== Obtaining It ===


Launch the patched isoldr with your preferred method, let it be Option 1, or Option 2...
Launch the patched isoldr with your prefered method, let it be Option 1, or Option 2...


==== Option 1 - Dumper Kernel Module ====
==== Option 1 - Dumper Kernel Module ====


* Modify glevand's spp_verifier_direct to dump the mbox to wherever_you_want.
*modify glevands spp_verifier_direct to dump the mbox to wherever_you_want '''http://pastebin.com/uTBbnC9B'''
* http://pastebin.com/uTBbnC9B <- needs to be edited further


<pre>
<pre>
Line 90: Line 37:


==== Option 2 - Dumper Payload ====
==== Option 2 - Dumper Payload ====
*http://pastie.org/pastes/2101977


* http://pastebin.com/YwDKqgTj <!--// http://pastie.org/pastes/2101977 //-->
*patched isoldr to dump it
 
'''*DO NOT CREATE AN MFW USING THIS IT WOULD BRICK PS3'''
'''*DO NOT CREATE AN MFW USING THIS IT WOULD BRICK'''
*patched isoldr: http://www.multiupload.com/2MP5KY28EZ
* Patched isoldr to dump it: http://www.wupload.com/file/1153650416/dump_eid_root_key.self <- dead link


* This can be loaded as the payload stage2 in the payload marcan used to load linux.
*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://marcansoft.com/blog/2010/10/asbestos-running-linux-as-gameos/
** http://git.marcansoft.com/?p=asbestos.git
** http://git.marcansoft.com/?p=asbestos.git


* This can also be loaded as with lv2patcher and payloader3.
*this can also be loaded as with lv2patcher and payloader3
** payloader3.git <- ?dead link ?
**payloader3.git


==== Comments ====
==== 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.
*Overwritting 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. 


* What these SELFs do is dump the PS3 '''ISOLATED SPU''' LS through mbox, so you only need a way to catch this data with PPU code in lv2 environment aka a dongle payload or linux kernel.
==per_console_root_key_2 / EID0_key ==
* 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 then jumps to isoldr.
* Overwritting that code lets you dump your key + metldr.


== per_console_root_key_2 (EID0_key) ==
*this key can be obtained through AES from EID_root_key


=== Obtaining It ===
*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
**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


==== Using the reversed code ====
*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
**let isoldr apply that algorithm directly in anergistic
***the process is exactly as the one above (modifing anergistic to feed isoldr with EID_root_key


* This key can be obtained through AES from eid_root_key.
* The algorithm is located in isoldr.
* EID0_key can be gotten through a program such as openssl, using the following command (once installed):
<pre>
openssl aes-256-cbc -e -in eid0_key_seed -out eid0_enc_seed -nosalt -K (isoldr key) -iv (isoldr RIV) -p -nopad
</pre>


See [[Seeds]].
=== Obtaining It ===


==== Using anergistics (advanced users) ====
*patched aim_spu_module to dump it
 
 
EID0 can be decrypted by setting EID0_key in anergistics and fireing aim_spu_module.self:
* Load aim_spu_module.self + EID0 + EID0_key in anergistics -> decrypted EID0.
* This [http://pastebin.com/xdPYgqXG <!--// http://pastie.org/2000330 //--> code] decrypts EID0 on PC.
* The prerequisites are:
** Dump EID0 from your PS3.
** Dump EID0_key from your PS3 and put it in the code above where the key (eid_mkey?) is needed.
** Load all of them in anergistic.
 
Using similar steps, you can provide eid_root_key and obtain EID0_key:
* EID0_key can be obtained with eid_root_key directly by letting isoldr apply the algorithm in anergistic.
* It needs modifing anergistic to feed isoldr with eid_root_key.
* Patched aim_spu_module to dump EID0_Key:
'''*DO NOT CREATE AN MFW USING THIS IT WOULD BRICK'''
'''*DO NOT CREATE AN MFW USING THIS IT WOULD BRICK'''
** http://dl.dropbox.com/u/35197530/aim.self <- dead link
*http://www.multiupload.com/1XUOOYS9I0
 
== per_console_root_key_n ==
 
These are further derivations of the per_console_key_1 (EID_root_key).
 
See [https://github.com/zecoxao/ps3_decrypt_tools/ ps3_decrypt_tools by naehrwert, zecoxao and al.].
 
== cVTRM ==
 
SRK (Secret or Syscon Root Key - root hash secret (hsec)) (derivation from per console key?) is stored in Syscon along with SRH (Secret or Syscon Root Hash). SRK is used as HMAC hash to authenticate cVTRM data from flash. SRH is a hash of cVTRM data. SRH is computed at runtime and compared with SRH from Syscon.
 
You can fetch SRH with VTRM or SCM utilities from glevand's ps3-vuart-tools (you need to add the function to the tools to do so) or from GameOS directly if you do some patches at hypervisor level.
 
cVTRM uses SysCon Isolated Module to do all the cryptographic operations. It uses AES-CBC-128 to encrypt data. It seems like key is fetched from encrypted key table in Syscon (related to EID1?). Also this key can be computed using AES-XTS-128. IV contains all zeroes. Data and tweak keys for XTS are computed from eid_root_key using seeds from SysCon Isolated Module.
 
Here is an example of decrypted cVTRM blocks:
 
1B68B7B67048454E863ECA0665EFB086  1B68B7B67048454E863ECA0665EFB08670F3EADB (Drive Revocation List Hash)
70F3EADB96791F41F9A76F4D895DD582  96791F41F9A76F4D895DD5820DB108EC03D19250 (Content Revocation List Hash)
0DB108EC03D192500000000000000000
00000000000000000000000000000000
 
00000001000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
 
087E91AEFFB8E66A0000000000000000  6AE6B8FFAE917E08 (PSN) Account ID
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000


00000000000000000000000000000000
==per_console_root_key_n==
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000


* [https://dl.dropboxusercontent.com/u/35197530/zip/ps3linux-ps3vuart-tools.zip DEAD LINK] Here's a link with the added functions. Please test it and report if it works :)
These are further derivations of the per_console_key_1/EID_root_key


==Documentation==


{{Reverse engineering}}<noinclude>[[Category:Main]]</noinclude>
http://polarssl.org/trac/browser/trunk/library/aes.c
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Per_Console_Keys"