SELF - SPRX: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
(→‎Table: add key table info)
Line 17: Line 17:
Basically here are the steps being involved by the loaders:  
Basically here are the steps being involved by the loaders:  


Loaders all have a static key and iv called respectively erk and riv, those are keys for the first decryption step which are used to decrypt the very first 0x40 bytes of the self's metadata using AES256CBC  
Loaders all have a static key and iv called respectively <abbr title="ERK - 256bit Encryption Round Key">erk</abbr> and <abbr title="RIV - 128bit Reset Initialization Vector">riv</abbr>, those are keys for the first decryption step which are used to decrypt the very first 0x40 bytes of the self's metadata using <abbr title="AES256CBC - Advanced Encryption Standard - 256 bit - Cipher-block chaining">AES256CBC</abbr>


Then the result is used as a key and iv to decrypt the rest of the metadata using AES128CTR, finally the decrypted metadata contains the keys and iv for each data sections which are still decrypted through AES128CTR. This security model is based on the fact that the first 0x40 bytes of the self's metadata once decrypted by the static AES256CBC key in the loader should never be the same from one binary to the other. The same goes for any other value used as an AES128CTR key or iv.  
Then the result is used as a key and iv to decrypt the rest of the metadata using <abbr title="AESCTR - Advanced Encryption Standard - Counter Mode">AESCTR</abbr>, finally the decrypted metadata contains the keys and iv for each data sections which are still decrypted through AES128CTR. This security model is based on the fact that the first 0x40 bytes of the self's metadata once decrypted by the static AES256CBC key in the loader should never be the same from one binary to the other. The same goes for any other value used as an AES128CTR key or iv.  


Loaders are also involved with inflating the binaries using zlib.  
Loaders are also involved with inflating the binaries using zlib.  


The self authenticity is based on other independent steps, HMAC-SHA1 and ECDSA for the actual signature.
The self authenticity is based on other independent steps, <abbr title="HMAC-SHA1 - Hash-based Message Authentication Code - Secure Hash Algorithm 1">HMAC-SHA1</abbr> and <abbr title="ECDSA - Elliptic Curve Digital Signature Algorithm">ECDSA</abbr> for the actual signature.
 


== Short references ==
*[http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES]
*[http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Block cipher modes of operation]
*[http://en.wikipedia.org/wiki/HMAC HMAC]-[http://en.wikipedia.org/wiki/SHA-1 SHA1]
*[http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]


= File Format  =
= File Format  =

Revision as of 08:22, 31 October 2011


SELF stands for Signed Executable and Linkable Format.

A screenshot of f0f's presentation at CCC2010.

It is the format used by the executables on the PS3 It consists of an elf whose sections might be encrypted using AES CTR and signed using ECDSA + HMAC-SHA1 It has a specific header here called SCE header where it stores all the parameters for this process


Cryptography

Here is a small summary on how the self cryptography works.

Basically here are the steps being involved by the loaders:

Loaders all have a static key and iv called respectively erk and riv, those are keys for the first decryption step which are used to decrypt the very first 0x40 bytes of the self's metadata using AES256CBC

Then the result is used as a key and iv to decrypt the rest of the metadata using AESCTR, finally the decrypted metadata contains the keys and iv for each data sections which are still decrypted through AES128CTR. This security model is based on the fact that the first 0x40 bytes of the self's metadata once decrypted by the static AES256CBC key in the loader should never be the same from one binary to the other. The same goes for any other value used as an AES128CTR key or iv.

Loaders are also involved with inflating the binaries using zlib.

The self authenticity is based on other independent steps, HMAC-SHA1 and ECDSA for the actual signature.

Short references

File Format

Notes:

  • Numbers are stored in big endian format.

SELF/SCE Header

Struct

typedef struct {

 uint32_t magic;                 /* 53434500 = SCE\0 */
 uint32_t version;               /* header version */
 uint16_t sdk_type;              /* 0x0 retail (type 0)
                                  * 0x1 retail
                                  * 0x2 retail (type 1)
                                  * 0x3 unknown
                                  * 0x4 unknown
                                  * 0x5 unknown
                                  * 0x6 unknown
                                  * 0x7 unknown
                                  * 0x8 unknown
                                  * 0x9 unknown
                                  * 0xA NPDRM
                                  * 0x8000 DEBUG
                                  */
 uint16_t header_type;           /* 1 self, 2 unknown, 3 pkg */
 uint32_t metadata_offset;       /* metadata offset */
 uint64_t header_len;            /* self header length */
 uint64_t elf_filesize;          /* ELF file length */
 uint64_t unknown;               /* UNKNOWN */
 uint64_t appinfo_offset;        /* app info offset */
 uint64_t elf_offset;            /* ELF #1 offset */
 uint64_t phdr_offset;           /* program header offset */
 uint64_t shdr_offset;           /* section header offset */
 uint64_t section_info_offset;   /* section info offset */
 uint64_t sceversion_offset;     /* version offset */
 uint64_t controlinfo_offset;    /* control info offset */
 uint64_t controlinfo_size;      /* control length */
 uint64_t padding;               /* UNKNOWN */ NEEDS CHECKING

} __attribute__((packed)) SELF;

Table

field offset type notes
magic 0x0 u32 Must be "SCE\0"
version 0x4 u32 This must be 2 or the Self loader will abort
sdk_type 0x8 u16 This corresponds to the revision of the key to decrypt the metadata header, see: appldr, key structure in loaders
  • known appldr keys: 0x0000 - 0x000F
  • known NPDRM keys: 0x0001, 0x0004, 0x0007, 0x000A
  • debug: 0x8000

key_obj = key_table[sdk_type]

header_type 0xA u16 1 self, 2 rvk, 3 pkg, 4 spp
metadata_offset 0xC u32 Offset to the checksums. Must be at least 20 bytes before the end of the header
header_len 0x10 u64 This is the length of the header (including the fake elf headers)
  • The total length of the header must be less that 8KB
Encrypted size 0x18 u64 The size of the encrypted part of the self file.
unknown 0x20 u64 Must be 3
App_info_offset 0x28 u64 An offset in the header, usually at 0x70. See App info header.
elf_offset 0x30 u64 offset to the elf header
phdr_offset 0x38 u64 offset to phdr
shdr_offset 0x40 u64 offset to shdr
encrypted phdr sizes/offsets table offset 0x48 u64 Offset to a table which maps phdr entries to the actual offset/size within the encrypted fself.

Because fselfs can be compressed, they might not match the values listed within the elf.

sceversion header 0x50 u64 Offset to a header which contains some version information, including an offset to the .sceversion section of the encrypted elf.

The playstation 3 doesn't care about this, and doesn't even check the header

Digest 0x58 u64
Digest Size 0x60 u64

comments

The real ELF data is located after the SCE header (see header size). It is encrypted, unless the flags are 0x8000. unfself works by cutting the SCE header from the (fake) SELF.

App Info

Struct

typedef struct {

 uint64_t authid;                /* auth id */
 uint32_t vendor_id;             /* vendor id */
 uint32_t self_type;             /* app type
                                  * 1 level0,
                                  * 2 level1,
                                  * 3 level2,
                                  * 4 application,
                                  * 5 isolated SPU module,
                                  * 6 secure loader,
                                  * 7 unknown
                                  * 8 NPDRM app */
 uint64_t version;               /* app version */
 uint64_t padding;               /* UNKNOWN */

} __attribute__((packed)) APP_INFO;

Table

field offset type notes
authid 0x00 u64
unknown 0x08 u32
app_type 0x0c u32
                         *1 -- level 0
                         *2 -- level 1 
                         *3 -- level 2 
                         *4 -- application 
                         *5 -- isolated SPU module 
                         *6 -- secure loader 
                         *8 -- NP-DRM application 
app_version 0x10 u64

Comments

Aligned to 0x10 bytes.

ELF Header

Struct

typedef struct {

 uint8_t ident[16];              /* magic */
 uint16_t type;                  /* type */
 uint16_t machine;               /* machine */
 uint32_t version;               /* version */
 uint64_t entry_point;           /* entry point address */
 uint64_t phdr_offset;           /* start of program headers */
 uint64_t shdr_offset;           /* start of section headers */
 uint16_t flags;                 /* flags */
 uint32_t header_size;           /* size of this header */
 uint16_t phent_size;            /* size of program headers */
 uint16_t phnum;                 /* number of program headers */
 uint16_t shent_size;            /* size of section headers */
 uint16_t shnum;                 /* number of section headers */
 uint16_t shstrndx;              /* section header string table index */

} __attribute__((packed)) ELF;

Table

Comments

See Spec here: ELF Header

Notes:

  • e_type: ET_PS3PRX=0xFFA4
  • EI_OSABI: ELFOSABI_CELL_LV2=0x66

ELF Program Headers

Struct

typedef struct {

 uint32_t type;
 uint32_t flags;
 uint64_t offset_in_file;
 uint64_t virtual_addr;
 uint64_t phys_addr;
 uint64_t segment_size;
 uint64_t segment_mem_size;
 uint64_t alignment;

} __attribute__((packed)) ELF_PHDR;

Table

Comments

See Spec here: ELF Program Headers

ELF Section Headers

Struct

typedef struct {

 uint32_t name_idx;
 uint32_t type;
 uint64_t flags;
 uint64_t virtual_addr;
 uint64_t offset_in_file;
 uint64_t segment_size;
 uint32_t link;
 uint32_t info;
 uint64_t addr_align;
 uint64_t entry_size;

} __attribute__((packed)) ELF_SHDR;

Table

Comments

Segment Information

Struct

typedef struct {

 uint64_t offset;
 uint64_t size;
 uint32_t compressed; // 2=compressed
 uint32_t unknown1;
 uint32_t unknown2;
 uint32_t encrypted; // 1=encrypted

} __attribute__((packed)) SECTION_INFO;

Table

field offset type notes
Encrypted Data Offset 0x00 u64
Encrypted Data Size 0x08 u64
unknown 0x10 u32 This has been 1 in all the examples I have seen.
unknown 0x14 u32 Always 0, as far as I know.
unknown 0x18 u32 Always 0, as far as I know.
unknown 0x1c u32 This is 2 for loadable segment types, and 0 for other types.

Comments

There is one of these entries for each phdr entry in the elf file so that the ps3 knows where to decrypt the data from. (because it might also be compressed.)

Notes:

  • There is one Segment Information for each ELF Program Header.

SCE Version Info

Struct

typedef struct {

 uint32_t unknown1;
 uint32_t unknown2;
 uint32_t unknown3;
 uint32_t unknown4;

} __attribute__((packed)) SCEVERSION_INFO;

Table

Comment

Control Information

Struct

typedef struct {

 uint32_t type; // 1==control flags; 2==file digest; 3==npdrm
 uint32_t size;
 union {
   // type 1 0x30 bytes
   struct {
     uint64_t unknown1;
     uint8_t control_flags[16];
     uint64_t unknown2;
     uint64_t unknown3;
   } control_flags;
   // type 2 0x40 bytes
   struct {
     uint64_t unknown1;
     uint8_t digest1[20];
     uint8_t digest2[20];
     uint64_t unknown2;
   } file_digest40;
   // type 2 0x30 bytes
   struct {
     uint64_t unknown1;
     uint8_t digest1[20];
     uint64_t unknown2;
   } file_digest30;
   // type 3 0x90 bytes
   struct {
     uint64_t unknown1;
     uint32_t magic;
     uint32_t unknown2;
     uint32_t license; /* 1 network, 2 local, 3 free */
     uint32_t type; /* 1 exec, 21 update */
     uint8_t content_id[48];
     uint8_t digest[16];
     uint8_t invdigest[16];
     uint8_t xordigest[16];
     uint64_t unknown3;
     uint64_t unknown4;
   } npdrm;
 };

} __attribute__((packed)) CONTROL_INFO;

Table

Comments

Metadata Information

Struct

typedef struct {

 uint8_t key[16];
 uint8_t key_pad[16];
 uint8_t iv[16];
 uint8_t iv_pad[16];

} __attribute__((packed)) METADATA_INFO;

Table

Comments

Notes:

  • The key and ivec fields are encrypted using AES256CBC.
  • This is not present if it is an FSELF.

Metadata Header

Struct

typedef struct {

 uint8_t key[16];
 uint8_t key_pad[16];
 uint8_t iv[16];
 uint8_t iv_pad[16];

} __attribute__((packed)) METADATA_INFO;

Table

Comments

Notes:

  • The metadata header is located after the metadata info in the SELF file.
  • It is decrypted using AES128CTR with the key and ivec entries from the metadata information.
  • The signature input length is the number of bytes which are used to generate the SHA-1 which is used to generate the ECDSA signature. The length should be eveything from the beginning until the signature itself. The decrypted version of the input data is used.
  • This is only present if the metadata Information is present.

Metadata Section Headers

Struct

typedef struct {

 uint64_t data_offset;
 uint64_t data_size;
 uint32_t type; // 1 = shdr, 2 == phdr, 3 == unknown
 uint32_t program_idx;
 uint32_t unknown;
 uint32_t sha1_idx;
 uint32_t encrypted; // 3=yes; 1=no
 uint32_t key_idx;
 uint32_t iv_idx;
 uint32_t compressed; // 2=yes; 1=no

} __attribute__((packed)) METADATA_SECTION_HEADER;

Table

Comments

Notes:

  • The metadata section headers are located after the metadata header in the SELF file.
  • The number of sections is indicated by the sectionCount entry in the metadata header.
  • They are decrypted using AES128CTR with the key and ivec entries from the metadata information.
  • Section data is decrypted using AES128CTR with the key and ivec from the metadata keys specified by keyIndex and ivecIndex.
  • Section data will also need to be uncompressed using zlib.
  • The dataOffsets of the metadata section headers match in general the segment information dataOffsets.
  • This is only present if the metadata header is present.

Section Hash

Struct

typedef struct {

 uint8_t sha1[20];
 uint8_t padding[12];
 uint8_t hmac_key[64];

} __attribute__((packed)) SECTION_HASH;

Table

Comments

Notes:

  • The metadata keys (section hash) are located after the metadata section headers in the SELF file.
  • The number of keys is indicated by the keyCount entry in the metadata header.
  • They are decrypted using AES128CTR with the key and ivec entries from the metadata information.
  • If the sha1Index points to a key, then key[sha1Index] and key[sha1Index+1] form the 160-bit hash. key[sha1Index+2] to key[key[sha1Index+6] form the 512-bit key for the HMAC-SHA1. The HMAC-SHA1 is calculated on the decrypted data and before the decompression.

Signature Info

Struct

typedef struct {

 uint32_t unknown1;
 uint32_t signature_size;
 uint64_t unknown2;
 uint64_t unknown3;
 uint64_t unknown4;
 uint64_t unknown5;
 uint32_t unknown6;
 uint32_t unknown7;

} __attribute__((packed)) SIGNATURE_INFO;

Table

Comments

Signature

Struct

typedef struct {

 uint8_t r[21];
 uint8_t s[21];
 uint8_t padding[6];

} __attribute__((packed)) SIGNATURE;

Table

Comments

Notes:

  • The signature is located after the the signature information in the SELF file.
  • It is even present if the signature information is not present.
  • It is decrypted using AES128CTR with the key and ivec entries from the metadata information.

Self Section Info

Struct

typedef struct {

 uint8_t *data;
 uint64_t size;
 uint64_t offset;

} SELF_SECTION;

Table

Comments

Extracting an ELF

ELF Header

Elf64_Ehdr elfHeader;

fseek ( selfFile, fix64 ( selfHeader.elfHeaderOffset ), SEEK_SET );
fread ( &elfHeader, sizeof ( Elf64_Ehdr ), 1, selfFile );

fseek ( elfFile, 0, SEEK_SET );
fwrite ( &elfHeader, sizeof ( Elf64_Ehdr ), 1, elfFile );

Section Headers

Elf64_Shdr elfSectionHeaders[100];

fseek ( selfFile, fix64 ( selfHeader.elfSectionHeadersOffset ), SEEK_SET );
fread ( elfSectionHeaders, sizeof ( Elf64_Shdr ), fix16 ( elfHeader.e_shnum ), selfFile );

fseek ( elfFile, fix64 ( elfHeader.e_shoff ), SEEK_SET );
fwrite ( elfSectionHeaders, sizeof ( Elf64_Shdr ), fix16 ( elfHeader.e_shnum ), elfFile );

Section Data

Notes:

  • Unknown, manually copying the data over works for now.
  • There should be a section data offset somewhere.

Program Headers

Elf64_Phdr elfProgramHeaders[100];

fseek ( selfFile, fix64 ( selfHeader.elfProgramHeadersOffset ), SEEK_SET );
fread ( elfProgramHeaders, sizeof ( Elf64_Phdr ), fix16 ( elfHeader.e_phnum ), selfFile );

fseek ( elfFile, fix64 ( elfHeader.e_phoff ), SEEK_SET );
fwrite ( elfProgramHeaders, sizeof ( Elf64_Phdr ), fix16 ( elfHeader.e_phnum ), elfFile );

Program Data

Notes:

  • Load the metadata information and decrypt the key and ivec entries using AES256CBC using erk and riv.
  • Load the metadata header and decrypt it using AES128CTR with the key and ivec entries from the metadata information.
  • Load sectionCount metadata section headers and decrypt them using AES128CTR with the key and ivec entries from the metadata information.
  • Load keyCount metadata keys and decrypt them using AES128CTR with the key and ivec entries from the metadata information.
  • For each metadata section:
    • In the SELF file, fseek to dataOffset and read in dataSize bytes.
    • Decrypt the data using AES128CTR with the key and ivec from the metadata keys specified by keyIndex and ivecIndex from the metadata section header.
    • Uncompress the data using zlib.
    • Write it to the ELF file as the program section specified by section Index in the metadata section header.

Meta Checksums

There are 3 checksums at the offset specified by meta_offset.

  • The first is the sha1 checksum of the entire self file.
  • The 2nd checksum is the inverse of the first checksum.
  • The 3rd checksum is the first checksum XORed with 0xAAAAAA..AAAAAB

The PSJailbreak payload ignores the actual checksums, but checks that the 3rd checksum is the 2nd checksum XORed with 0xAAAAAA..AAAAAB

Source: http://ps3wiki.lan.st/index.php?title=SELF_File_Format_and_Decryption