SELF - SPRX: Difference between revisions
CelesteBlue (talk | contribs) |
CelesteBlue (talk | contribs) No edit summary |
||
Line 6: | Line 6: | ||
= Introduction = | = Introduction = | ||
It consists of a CF header with an extended header followed by the encapsulated ELF file. ELF sections can be compressed using gzip. SELFs are encrypted and signed, unlike fSELFs. ELF sections are encrypted using | It consists of a CF header with an extended header followed by the encapsulated ELF file. ELF sections can be compressed using gzip. SELFs are encrypted and signed, unlike fSELFs. ELF sections are encrypted using AES128 and signed using ECDSA160 or RSA2048 + HMAC-SHA1 or HMAC-SHA256. SELF file has a specific header called Extended header where it stores all the parameters for this program. | ||
*Extended Header | *Extended Header | ||
Line 12: | Line 12: | ||
*Encryption Root Header | *Encryption Root Header | ||
Encryption Root Header is itself encrypted under AES256CBC. It contains key and ivec to further decrypt the Certification data using | Encryption Root Header is itself encrypted under AES256CBC. It contains key and ivec to further decrypt the Certification data using AES128(CBC or CTR). | ||
*Certification data | *Certification data | ||
The Certification Header, | The Certification Header, Certification Body and Certification Footer are encrypted under this AES128 layer and are decrypted with the key above. | ||
*Certification Header | *Certification Header | ||
Certification Header contains the info required to authenticate the Certification. The signature is ECDSA160 of the SHA1 | Certification Header contains the info required to authenticate the Certification. The Certification Footer signature is ECDSA160 of the SHA1 digest of the SELF file starting at offset 0x0 and ending at offset footer_offset, or RSA2048 ?of the same data?. | ||
*Data Sections | *Data Sections | ||
The data sections can be encrypted | The data sections can be encrypted and/or compressed. SHA1/HMAC-SHA1/HMAC-SHA256 is used to ensure that they have not been modified. | ||
= Cryptography = | = Cryptography = | ||
Line 31: | Line 31: | ||
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>. | 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 key and iv to decrypt the rest of the Certification data using <abbr title="AESCTR - Advanced Encryption Standard - Counter Mode"> | Then the result is used as key and iv to decrypt the rest of the Certification data using <abbr title="AESCTR - Advanced Encryption Standard - Counter Mode">AES128CTR</abbr> (PS3) or AES128CBC (PSVita). Finally the decrypted Certification data contains the key and iv for each data sections which are still decrypted following the Segment Certification Header information. This security model is based on the fact that the Certification Root Header 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 AES128 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, <abbr title="HMAC-SHA1 - Hash-based Message Authentication Code - Secure Hash Algorithm 1">HMAC-SHA1</abbr> of the data sections and <abbr title="ECDSA - Elliptic Curve Digital Signature Algorithm"> | 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> or HMAC-SHA256 of the data sections and <abbr title="ECDSA - Elliptic Curve Digital Signature Algorithm">ECDSA160</abbr> or RSA2048 for the signature of the header and the Certification data. | ||
== Short references == | == Short references == | ||
Line 572: | Line 572: | ||
Temp name was Metadata Information. Official name is encryption_root_header. | Temp name was Metadata Information. Official name is encryption_root_header. | ||
This is not present in fSELF. | This is not present in fCF (fSELF, fSPP, etc...). | ||
The key and ivec fields are encrypted using AES256CBC. | |||
=== Struct === | === Struct === | ||
Line 586: | Line 588: | ||
=== Comments === | === Comments === | ||
== Certification Header == | == Certification Header == | ||
Line 594: | Line 593: | ||
Temp name was Metadata Header. Official name is certification_header. | Temp name was Metadata Header. Official name is certification_header. | ||
It is only present if the Encryption Root Header is present. | |||
It is decrypted using AES128 with the key and ivec entries from the Encryption Root Header. | |||
It is located after the Encryption Root Header in the SELF file. | |||
=== Struct === | === Struct === | ||
Line 602: | Line 603: | ||
<source lang="C"> | <source lang="C"> | ||
typedef struct { | typedef struct { | ||
uint64_t | uint64_t footer_offset; | ||
uint32_t signature_type; // 1 = ECDSA160, 5 = RSA2048 | uint32_t signature_type; // 1 = ECDSA160, 5 = RSA2048 | ||
uint32_t | uint32_t segment_count; | ||
uint32_t blocks_count; // was keyCount | uint32_t blocks_count; // was keyCount | ||
uint32_t optional_header_size; | uint32_t optional_header_size; | ||
Line 613: | Line 614: | ||
=== Comments === | === Comments === | ||
== Certification Body == | |||
* | |||
*It is decrypted with the key and ivec entries from the Encryption Root Header. | |||
=== Segment Certification Header === | |||
Temp name was Metadata Section Header. Official name is segment_certification_header. | |||
It is only present if the Certification Header is present. | |||
The number of sections is indicated by the segment_count entry in the Certification Header. | |||
The Segment Certification Headers are located after the Certification Header in the SELF file. | The Segment Certification Headers are located after the Certification Header in the SELF file. | ||
=== Struct === | ==== Struct ==== | ||
<source lang="C"> | <source lang="C"> | ||
Line 641: | Line 645: | ||
</source> | </source> | ||
=== Comments === | ==== Comments ==== | ||
Notes: | Notes: | ||
*Segment data is decrypted using enc_algorithm with the key and ivec from the Segment Certification specified by key_idx and iv_idx. | *Segment data is decrypted using enc_algorithm with the key and ivec from the Segment Certification specified by key_idx and iv_idx. | ||
*The segment_offset of the Segment Certification Header matches in general the offset from the Segment Extended Header. | *The segment_offset of the Segment Certification Header matches in general the offset from the Segment Extended Header. | ||
== Segment Certification == | === Segment Certification === | ||
Temp name was Metadata Keys, Section Hash. Official name might be Segment Certification. | Temp name was Metadata Keys, Section Hash. Official name might be Segment Certification. | ||
Line 654: | Line 657: | ||
The number of Segment Certifications is indicated by the segment_count entry in the Certification Header. | The number of Segment Certifications is indicated by the segment_count entry in the Certification Header. | ||
The Segment | The Segment Certifications are located after the Segment Certification Headers in the SELF file. | ||
=== Struct === | ==== Struct ==== | ||
<source lang="C"> | <source lang="C"> | ||
Line 675: | Line 678: | ||
</source> | </source> | ||
=== Comments === | ==== Comments ==== | ||
Notes: | Notes: | ||
*The HMAC-SHA1 is calculated on the decrypted data and before the decompression. | *The HMAC-SHA1 is calculated on the decrypted data and before the decompression. | ||
== Optional Header Table == | === Optional Header Table === | ||
Temp name was Signature Info, Capabilities Info. Official name is optional_header_table. | Temp name was Signature Info, Capabilities Info. Official name is optional_header_table. | ||
Line 689: | Line 691: | ||
It is only present if optional_header_size in the Certification Header is not zero. | It is only present if optional_header_size in the Certification Header is not zero. | ||
=== Struct === | ==== Struct ==== | ||
<source lang="C"> | <source lang="C"> | ||
Line 715: | Line 717: | ||
=== Comments === | === Comments === | ||
* Type 1 contains encrypted_capability. See [[Capability Flags]]. | * Type 1 contains encrypted_capability. See [[Capability Flags]]. | ||
== Certification | == Certification Footer == | ||
Temp name was Signature. | |||
It is located at the Certification Header footer_offset in the SELF file. | |||
It is decrypted with the key and ivec entries from the Encryption Root Header. | |||
It can be ECDSA160 or RSA2048, according to the Certification Header. | It can be ECDSA160 or RSA2048, according to the Certification Header. | ||
Line 736: | Line 741: | ||
uint8_t rsa[0x100]; | uint8_t rsa[0x100]; | ||
} RSA2048; | } RSA2048; | ||
} __attribute__((packed)) | } __attribute__((packed)) certification_footer; | ||
</source> | </source> | ||
=== Comments === | === Comments === | ||
* footer_offset 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 for signature. | |||
* | |||
= Extraction = | = Extraction = | ||
Line 786: | Line 790: | ||
Notes: | Notes: | ||
*Load the Encryption Root Header and decrypt the key and ivec entries using AES256CBC with erk and riv from OS. | *Load the Encryption Root Header and decrypt the key and ivec entries using AES256CBC with erk and riv from OS. | ||
*Load the Certification Header and decrypt it using AES128CTR with the key and ivec entries from the Encryption Root Header. | *Load the Certification Header and decrypt it using AES128CTR/CBC with the key and ivec entries from the Encryption Root Header. | ||
*Load the | *Load the Segment Certification Headers and decrypt them using AES128CTR/CBC with the key and ivec entries from the Encryption Root Header. | ||
*Load the | *Load the Segment Certifications and decrypt them using AES128CTR/CBC with the key and ivec entries from the Encryption Root Header. | ||
*For each Segment Certification: | *For each Segment Certification: | ||
**In the SELF file, fseek to data_offset and read in data_size bytes. | **In the SELF file, fseek to data_offset and read in data_size bytes. | ||
**Decrypt the data using | **Decrypt the data using the algorithm, key and ivec from the Segment Certification specified by keyIndex and ivecIndex in the Segment Certification Header. | ||
**Uncompress the data using | **Uncompress the data using the algorithm specified in the Segment Certification Header. | ||
**Write | **Write the output data to the ELF file as the program section specified by program_idx in the Segment Certification Header. | ||
{{File Formats}}<noinclude>[[Category:Main]]</noinclude> | {{File Formats}}<noinclude>[[Category:Main]]</noinclude> |
Revision as of 12:31, 26 December 2019
SELF stands for Signed Executable and Linkable Format. SPRX stands for Signed Playstation Relocatable eXecutable. They are the format used by the executables on the PS3 and PSVita.
Introduction
It consists of a CF header with an extended header followed by the encapsulated ELF file. ELF sections can be compressed using gzip. SELFs are encrypted and signed, unlike fSELFs. ELF sections are encrypted using AES128 and signed using ECDSA160 or RSA2048 + HMAC-SHA1 or HMAC-SHA256. SELF file has a specific header called Extended header where it stores all the parameters for this program.
- Extended Header
It consists of information regarding the structure and offsets of the SELF. The first part is in plaintext until you reach Encryption Root Header.
- Encryption Root Header
Encryption Root Header is itself encrypted under AES256CBC. It contains key and ivec to further decrypt the Certification data using AES128(CBC or CTR).
- Certification data
The Certification Header, Certification Body and Certification Footer are encrypted under this AES128 layer and are decrypted with the key above.
- Certification Header
Certification Header contains the info required to authenticate the Certification. The Certification Footer signature is ECDSA160 of the SHA1 digest of the SELF file starting at offset 0x0 and ending at offset footer_offset, or RSA2048 ?of the same data?.
- Data Sections
The data sections can be encrypted and/or compressed. SHA1/HMAC-SHA1/HMAC-SHA256 is used to ensure that they have not been modified.
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 key and iv to decrypt the rest of the Certification data using AES128CTR (PS3) or AES128CBC (PSVita). Finally the decrypted Certification data contains the key and iv for each data sections which are still decrypted following the Segment Certification Header information. This security model is based on the fact that the Certification Root Header 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 AES128 key or iv.
Loaders are also involved with inflating the binaries using zlib.
The SELF authenticity is based on other independent steps, HMAC-SHA1 or HMAC-SHA256 of the data sections and ECDSA160 or RSA2048 for the signature of the header and the Certification data.
Short references
More indepth Online course about encryption in generic (also AES/ECDSA): Lecture Notes on Computer and Network Security by Avinash Kak
fSELF
fSELF stands for fake signed ELF. It is the format ouput by developer SDK. As it name suggests, it is not signed nor encrypted. If it was, that would imply SDK embeds private keys to sign it and keys to encrypt it.
A fSELF has Attribute set to 0x8000. ?always?
A fSELF has usually less rights than a System SELF. The OS recognizes a fSELF by looking at its program-authority-id.
To document more...
Location
PS3
Files with extensions: eboot.bin, .self, .sprx.
See also SELFs inside ELFs.
PSVita
Files with extensions: eboot.bin, .self, .suprx, .skprx.
File Format
Notes:
- Warning: PS3 uses big endian, PSVita uses little endian.
- Encapsulated ELF header fields are useless (only the EI_CLASS EI_DATA and EI_VERSION fields are checked).
PS3 early type 3 SELFs
SDK 0.60: No sce version and digest SDK 0.8X: No sce version, with 0x30 digest SDK 0.9X: With sce version and 0x40 digest (scetool produces this type)
Special SELFs
Warhawk public beta release 012
Oldest official game SELF (not NPDRM !!!) I have found for now: 2007-06-08.
- https://web.archive.org/web/*/http://download-prod.online.scea.com/medius-patch/warhawk-pubeta/warhawk//*
- https://web.archive.org/web/20070711084313/http://download-prod.online.scea.com/medius-patch/warhawk-*pubeta/warhawk/20070608_r012/NPUA80093_113_release.self
- https://web.archive.org/web/20070711084217/http://download-prod.online.scea.com/medius-patch/warhawk-pubeta/warhawk/20070608_r012/NPUA80093_113_PARAM.sfo
- https://web.archive.org/web/20070621155928/http://download-prod.online.scea.com/medius-patch/warhawk-pubeta/warhawk/20070608_r012/NPUA80093.cfg
Extended Header
Extended Header offsets are relative to Certified File start.
Struct
typedef struct { // Size is 0x50 bytes
uint64_t ext_hdr_version;
uint64_t program_identification_hdr_offset;
uint64_t ehdr_offset;
uint64_t phdr_offset;
uint64_t shdr_offset;
uint64_t segment_ext_hdr_offset;
uint64_t version_hdr_offset;
uint64_t supplemental_hdr_offset;
uint64_t supplemental_hdr_size;
uint64_t padding;
} __attribute__((packed)) ext_hdr;
Table
field | offset | type | notes |
---|---|---|---|
Extended Header version | 0x0 | u64 | 3 for PS3, 4 for PSVita |
Program Identification Header offset | 0x8 | u64 | Offset to Program Identification Header. |
ELF Header offset | 0x10 | u64 | Offset to ELF header. |
Program Header offset | 0x18 | u64 | Offset to ELF Program Header. |
Section Header offset | 0x20 | u64 | Offset to ELF Section Header. |
Segment Extended Header offset | 0x28 | u64 | Offset to Segment Extended Header. |
Version Header offset | 0x30 | u64 | Offset to Version Header. |
Supplemental Header offset | 0x38 | u64 | Offset to Supplemental Header. |
Supplemental Header size | 0x40 | u64 | Size of Supplemental Header. |
Padding | 0x48 | u64 |
Comments
The real ELF data is located after the extended header (see header size). It is encrypted, unless attribute is 0x8000. unfself works by cutting the SCE header from the (fake)SELF and if needed decompressing sections.
Program Identification Header
Temp name was App Info. Official name is Program Identification Header.
Struct
typedef struct {
uint64_t program_authority_id;
uint32_t program_vender_id;
uint32_t program_type;
uint64_t program_sceversion;
uint64_t padding;
} __attribute__((packed)) program_identification_header;
Table
field | offset | type | notes | example |
---|---|---|---|---|
program_authority_id | 0x00 | u64 | See Program Authority Id | ex: 21 00 00 10 1C CA 01 30 |
program_vender_id | 0x08 | u32 | See Program Vender Id | ex: 00 00 00 00 |
program_type | 0x0C | u32 | See Program Type | ex: 08 00 00 00 |
program_sceversion | 0x10 | u64 | ?SDK version or app version? version ex: 01.02 is translated by make_fself.exe to 02 01 00 00 | ex: 0x0000036000000000 (3.600.011), 0x0000009450000000 (0.945.040) |
padding | 0x18 | u64 | Padding | 00 00 00 00 00 00 00 00 |
Comments
Aligned to 0x10 bytes.
ELF Header
Struct
PS3
typedef struct {
uint8_t e_ident[16]; /* ELF identification */
uint16_t e_type; /* object file type */
uint16_t e_machine; /* machine type */
uint32_t e_version; /* object file version */
uint64_t e_entry; /* entry point address */
uint64_t e_phoff; /* program header offset */
uint64_t e_shoff; /* section header offset */
uint32_t e_flags; /* processor-specific flags */
uint16_t e_ehsize; /* ELF header size */
uint16_t e_phentsize; /* size of program header entry */
uint16_t e_phnum; /* number of program header entries */
uint16_t e_shentsize; /* size of section header entry */
uint16_t e_shnum; /* number of section header entries */
uint16_t e_shstrndx; /* section name string table index */
} __attribute__((packed)) ELF;
See also specifications: ELF Header ELF-64 Object File Format
PSVita
typedef struct {
uint8_t e_ident[16]; /* ELF identification */
uint16_t e_type; /* object file type */
uint16_t e_machine; /* machine type */
uint32_t e_version; /* object file version */
uint32_t e_entry; /* entry point address */
uint32_t e_phoff; /* program header offset */
uint32_t e_shoff; /* section header offset */
uint32_t e_flags; /* processor-specific flags */
uint16_t e_ehsize; /* ELF header size */
uint16_t e_phentsize; /* size of program header entry */
uint16_t e_phnum; /* number of program header entries */
uint16_t e_shentsize; /* size of section header entry */
uint16_t e_shnum; /* number of section header entries */
uint16_t e_shstrndx; /* section name string table index */
} __attribute__((packed)) ELF;
Name of the variable | Offset | Size | Notes |
---|---|---|---|
e_ident[0..3] | 0 | 4 | Magic. |
e_ident[4] | 4 | 1 | Class Type. Must be [ELFCLASS32 = 0x01]. |
e_ident[5] | 5 | 1 | Data Type. Must be [ELFDATA2LSB = 0x01]. |
e_ident[6] | 6 | 1 | File version. Must be 1. |
e_ident[7...15] | 7 | 9 | unused |
e_type | 0x10 | 2 | See SCE-specific e_type. |
e_machine | 0x12 | 2 | Must be [EM_ARM = 0x0028]. |
e_version | 0x14 | 4 | Must be 0x1. |
e_entry | 0x18 | 4 | Address to jump to in order to start program (warning: not always set). |
e_phoff | 0x1C | 4 | Boundary checked, but unused (already given by SELF header). ?and for fSELF? |
e_shoff | 0x20 | 4 | unused |
e_flags | 0x24 | 4 | unused |
e_ehsize | 0x28 | 2 | Must be sizeof(Elf32_Ehdr) = 0x0034. |
e_phentsize | 0x2A | 2 | Must be sizeof(Elf32_Phdr) = 0x0020. |
e_phnum | 0x2C | 2 | Count of Program Header in this ELF. |
e_shentsize | 0x2E | 2 | unused |
e_shnum | 0x30 | 2 | unused |
e_shstrndx | 0x32 | 2 | unused |
See also specifications: yifanlu specs
SCE specific ELF types (e_type)
/* SCE-specific definitions for e_type: */
#define ET_SCE_EXEC 0xFE00 /* SCE Executable */
#define ET_SCE_RELEXEC 0xFE04 /* SCE Relocatable Executable */
#define ET_SCE_STUBLIB 0xFE0C /* SCE SDK Stubs */
#define ET_SCE_DYNAMIC 0xFE18 /* ? */
#define ET_SCE_IOPRELEXEC 0xFF80 /* SCE IOP Relocatable Executable */
#define ET_SCE_IOPRELEXEC2 0xFF81 /* SCE IOP Relocatable Executable Version 2 */
#define ET_SCE_EERELEXEC 0xFF90 /* SCE EE Relocatable Executable */
#define ET_SCE_EERELEXEC2 0xFF91 /* SCE EE Relocatable Executable Version 2 */
#define ET_SCE_PSPRELEXEC 0xFFA0 /* SCE PSP Relocatable Executable */
#define ET_SCE_PPURELEXEC 0xFFA4 /* SCE PPU Relocatable Executable */
#define ET_SCE_ARMRELEXEC 0xFFA5 /* ?SCE ARM Relocatable Executable (PSVita FW <=0.931) */
#define ET_SCE_PSPOVERLAY 0xFFA8 /* ? */
OS ABI identification
#define ELFOSABI_CELL_LV2 102 /* CELL LV2 */
ELF Program Segment Header
Struct
PS3
typedef struct
{
Elf64_Word p_type; /* Segment type */
Elf64_Word p_flags; /* Segment flags */
Elf64_Off p_offset; /* Segment file offset */
Elf64_Addr p_vaddr; /* Segment virtual address */
Elf64_Addr p_paddr; /* Segment physical address */
Elf64_Xword p_filesz; /* Segment size in file */
Elf64_Xword p_memsz; /* Segment size in memory */
Elf64_Xword p_align; /* Segment alignment */
} Elf64_Phdr;
PSVita
typedef struct
{
Elf32_Word p_type; /* Segment type */
Elf32_Off p_offset; /* Segment file offset */
Elf32_Addr p_vaddr; /* Segment virtual address */
Elf32_Addr p_paddr; /* Segment physical address */
Elf32_Word p_filesz; /* Segment size in file */
Elf32_Word p_memsz; /* Segment size in memory */
Elf32_Word p_flags; /* Segment flags */
Elf32_Word p_align; /* Segment alignment */
} Elf32_Phdr;
See Spec here: ELF Program Segment Header
SCE specific segment types (p_type)
*PT_SCE_IOPMOD = 0x70000080
*PT_SCE_EEMOD = 0x70000090
*PT_SCE_PSPREL = 0x700000A0
*PT_SCE_PPURELA = 0x700000A4
*PT_SCE_SEGSYM = 0x700000A8
SCE specific segment flags (p_flags)
*PF_SPU_X = 0x00100000
*PF_SPU_W = 0x00200000
*PF_SPU_R = 0x00400000
*PF_RSX_X = 0x01000000
*PF_RSX_W = 0x02000000
*PF_RSX_R = 0x04000000
ELF Section Header
Struct
typedef struct {
uint32_t sh_name; /* section name */
uint32_t sh_type; /* section type */
uint64_t sh_flags; /* section attributes */
uint64_t sh_addr; /* virtual address in memory */
uint64_t sh_offset; /* offset in file */
uint64_t sh_size; /* size of section */
uint32_t sh_link; /* link to other section */
uint32_t sh_info; /* miscellaneous information */
uint64_t sh_addralign; /* address alignment boundary */
uint64_t sh_entsize; /* size of entries, if section has table */
} __attribute__((packed)) ELF_SHDR;
Comments
Processor specific section types (sh_type):
- SHT_SCE_IOPMOD = 0x70000080
- SHT_SCE_EEMOD = 0x70000090
- SHT_SCE_PSPREL = 0x700000a0
- SHT_SCE_PPURELA = 0x700000a4
Segment Extended Header
Temp name was SELF Section Info. Official name is segment_ext_header.
A table which maps each phdr entry to the actual offset/size within the encrypted CF. Indeed, because sections can be compressed, they might not match the values listed within the ELF phdr/shdr.
There is one of these entries for each ELF phdr (ELF Program Segment Header) entry in the ELF file so that the console knows where to decrypt the data from (because it might also be compressed).
Struct
typedef struct {
uint64_t offset;
uint64_t size;
uint32_t compression;
uint32_t unknown;
uint64_t encryption;
} __attribute__((packed)) segment_ext_header;
Table
field | offset | type | notes |
---|---|---|---|
Offset | 0x00 | u64 | Offset to data |
Size | 0x08 | u64 | Size of data |
Compression | 0x10 | u32 | 1 = uncompressed, 2 = compressed |
Unknown | 0x14 | u32 | Always 0, as far as I know. |
Encryption | 0x18 | u64 | 1 = encrypted, 2 = unencrypted |
PS3 OS uses the following structure to handle that data:
typedef struct {
void *data;
uint64_t size;
uint64_t offset;
} segment_ext_header;
Version Header
It contains some version information, including an offset to the .sceversion section of the encrypted ELF.
Struct
typedef struct {
uint32_t subheader_type; // 1 - sceversion
uint32_t present; // 0 = false, 1 = true
uint32_t size; // usually 0x10
uint32_t unknown4;
} __attribute__((packed)) version_header;
Data Struct
typedef struct {
uint16 unknown_1;
uint16 unknown_2; // 0x1
uint32 unknown_3;
uint32 unknown_4; // ?Number of sections?
uint32 unknown_5;
////
uint64 offset; // Data offset
uint64 size; // Data size
//// <- these are supposed to be sections
} SCE_VERSION_DATA_30;
Comments
Supplemental Header Table
Temp name was Control Information. Official name is supplemental_header_table.
Struct
typedef struct {
uint32_t type; // 1=PS3 plaintext_capability; 2=PS3 ELF digest; 3=PS3 NPDRM, 4=PSVita ELF digest; 5=PSVita NPDRM; 6=PSVita boot param; 7=PSVita shared secret
uint32_t size;
uint64_t next; // 1 if another Supplemental Header element follows else 0
union {
// type 1, 0x30 bytes
struct { // 0x20 bytes of data
plaintext_capability_t plaintext_capability;
} PS3_plaintext_capability_header;
// type 2, 0x40 bytes
struct { // 0x30 bytes of data
uint8_t constant[0x14]; // same for every PSVita/PS3 SELF, hardcoded in make_fself.exe: 627CB1808AB938E32C8C091708726A579E2586E4
uint8_t elf_digest[0x14]; // SHA-1. Hash F2C552BF716ED24759CBE8A0A9A6DB9965F3811C is blackisted by appldr
uint64_t required_system_version; // filled on Sony auth server, contains decimal PS3_SYSTEM_VER value from PARAM.SFO
} PS3_elf_digest_header_40;
// type 2, 0x30 bytes
struct { // 0x20 bytes of data
uint8_t constant_or_elf_digest[0x14];
uint8_t padding[0xC];
} PS3_elf_digest_header_30;
// type 3, 0x90 bytes
struct { // 0x80 bytes of data
uint32_t magic; // 4E 50 44 00 ("NPD.")
uint32_t license_version;
uint32_t drm_type; // [[License Types|license_type]]
uint32_t app_type; // [[App Types|app_type]]
uint8_t content_id[0x30];
uint8_t digest[0x10]; // SHA-1 hash of debug self/sprx created with make_fself_npdrm
uint8_t inv_digest[0x10]; // hash_cid_fname
uint8_t xor_digest[0x10]; // hash_cid
uint8_t padding[0x10];
} PS3_npdrm_header;
// type 4, 0x50 bytes
struct { // 0x40 bytes of data
uint8_t constant[0x14]; // same for every PSVita/PS3 SELF, hardcoded in make_fself.exe: 627CB1808AB938E32C8C091708726A579E2586E4
uint8_t elf_digest[0x20]; // SHA-256 of source ELF file.
uint8_t padding[8];
uint32_t min_required_fw; // ex: 0x363 for 3.63
} PSVita_elf_digest_header;
// type 5, 0x110 bytes
struct { // 0x80 bytes of data
uint32_t magic; // 7F 44 52 4D (".DRM")
uint32_t finalized_flag; // ex: 80 00 00 01
uint32_t drm_type; // [[License Types|license_type]] ex: 2 local, 0xD free with license
uint32_t padding;
uint8_t content_id[0x30];
uint8_t digest[0x10]; // ?sha-1 hash of debug self/sprx created using make_fself_npdrm?
uint8_t padding_78[0x78];
uint8_t hash_signature[0x38]; // unknown hash/signature
} PSVita_npdrm_header;
// type 6, 0x110 bytes
struct { // 0x100 bytes of data
uint32_t is_used; // 0=false, 1=true
uint8_t boot_param[0x9C]; // ex: starting with 02 00 00 00
} PSVita_boot_param_header;
// type 7, 0x50 bytes
struct { // 0x40 bytes of data
uint8_t shared_secret_0[0x10]; // ex: 0x7E7FD126A7B9614940607EE1BF9DDF5E or full of zeroes
uint8_t shared_secret_1[0x10]; // ex: full of zeroes
uint8_t shared_secret_2[0x10]; // ex: full of zeroes
uint8_t shared_secret_3[0x10]; // ex: full of zeroes
} PSVita_shared_secret_header;
};
} __attribute__((packed)) supplemental_header;
Table
Comments
There are 3 digests in ps3_npdrm_header:
- digest is the sha1 checksum of the entire SELF file.
- inv_digest is the inverse of digest.
- xor_digest is digest 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.
Notes:
- See Capability_Flags.
- PS3 loader uses supplemental_header_table to handle some data:
typedef struct {
plaintext_capability_t plaintext_capability; /* Plaintext Capability */
uint8[0x14] elf_digest; /* sha1 hash of the ELF file */
uint32_t unknown_0; /* seems to be padding */
uint64_t required_system_vesion; /* PS3_SYSTEM_VER, decimal format */
} supplemental_header_table;
Encryption Root Header
Temp name was Metadata Information. Official name is encryption_root_header.
This is not present in fCF (fSELF, fSPP, etc...).
The key and ivec fields are encrypted using AES256CBC.
Struct
typedef struct {
uint8_t key[16];
uint8_t key_pad[16];
uint8_t iv[16];
uint8_t iv_pad[16];
} __attribute__((packed)) encryption_root_header;
Comments
Certification Header
Temp name was Metadata Header. Official name is certification_header.
It is only present if the Encryption Root Header is present.
It is decrypted using AES128 with the key and ivec entries from the Encryption Root Header.
It is located after the Encryption Root Header in the SELF file.
Struct
typedef struct {
uint64_t footer_offset;
uint32_t signature_type; // 1 = ECDSA160, 5 = RSA2048
uint32_t segment_count;
uint32_t blocks_count; // was keyCount
uint32_t optional_header_size;
uint64_t unknown06;
} __attribute__((packed)) certification_header;
Comments
Certification Body
- It is decrypted with the key and ivec entries from the Encryption Root Header.
Segment Certification Header
Temp name was Metadata Section Header. Official name is segment_certification_header.
It is only present if the Certification Header is present.
The number of sections is indicated by the segment_count entry in the Certification Header.
The Segment Certification Headers are located after the Certification Header in the SELF file.
Struct
typedef struct {
uint64_t segment_offset;
uint64_t segment_size;
uint32_t segment_type; // 1 = shdr, 2 = phdr, 3 = sceversion
uint32_t program_idx; // 0,1,2,3,etc for phdr, always 3 for shdrs, sceversion shdr number for sceversion
uint32_t hash_algorithm; // ?1 = none?, 2 = sha1_hmac, 3 = sha1, 6 = sha256_hmac
uint32_t hash_idx;
uint32_t enc_algorithm; // 1 = none, 2 = aes128cbccfb, 3 = aes128ctr
uint32_t key_idx; // -1 when enc_algorithm = none
uint32_t iv_idx; // -1 when enc_algorithm = none
uint32_t comp_algorithm; // 1 = none, 2 = zlib
} __attribute__((packed)) segment_certification_header;
Comments
Notes:
- Segment data is decrypted using enc_algorithm with the key and ivec from the Segment Certification specified by key_idx and iv_idx.
- The segment_offset of the Segment Certification Header matches in general the offset from the Segment Extended Header.
Segment Certification
Temp name was Metadata Keys, Section Hash. Official name might be Segment Certification.
The number of Segment Certifications is indicated by the segment_count entry in the Certification Header.
The Segment Certifications are located after the Segment Certification Headers in the SELF file.
Struct
typedef struct {
union { // size is 0x40 bytes
uint8_t digest[0x20]; // hmac_sha1
uint8_t hmac_key[0x20];
} hash_type2;
union { // size is 0x60 bytes
uint8_t unk0[0x20]; // certinly hmax_sha256
uint8_t unk1[0x40]; // certainly hmac_key
} hash_type6;
union { // size is 0x20 bytes
uint8_t key[0x10];
uint8_t iv[0x10];
} encryption_params; // present for type 2 and 3
} __attribute__((packed)) segment_certification;
Comments
Notes:
- The HMAC-SHA1 is calculated on the decrypted data and before the decompression.
Optional Header Table
Temp name was Signature Info, Capabilities Info. Official name is optional_header_table.
The Optional Header Table is located after the Section Hash in the SELF file.
It is only present if optional_header_size in the Certification Header is not zero.
Struct
typedef struct {
uint32_t type; // 1=capability_header, 2=individual_seed_header, 3=attribute_header
uint32_t size;
uint64_t next; // 1 if another optional_header structure follows else 0
union {
// type 1
struct { // 0x20 bytes of data
uint8_t capability[0x20];
} capability_header;
// type 2
struct { // 0x100 bytes of data
uint8_t individual_seed[0x100];
} individual_seed_header;
// type 3
struct { // 0x20 bytes of data
uint8_t attribute[0x20];
} attribute_header;
};
} __attribute__((packed)) optional_header;
Comments
- Type 1 contains encrypted_capability. See Capability Flags.
Temp name was Signature.
It is located at the Certification Header footer_offset in the SELF file.
It is decrypted with the key and ivec entries from the Encryption Root Header.
It can be ECDSA160 or RSA2048, according to the Certification Header.
Struct
typedef struct {
union {
uint8_t r[21];
uint8_t s[21];
uint8_t padding[6];
} ECDSA160;
union {
uint8_t rsa[0x100];
} RSA2048;
} __attribute__((packed)) certification_footer;
Comments
- footer_offset 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 for signature.
Extraction
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 Encryption Root Header and decrypt the key and ivec entries using AES256CBC with erk and riv from OS.
- Load the Certification Header and decrypt it using AES128CTR/CBC with the key and ivec entries from the Encryption Root Header.
- Load the Segment Certification Headers and decrypt them using AES128CTR/CBC with the key and ivec entries from the Encryption Root Header.
- Load the Segment Certifications and decrypt them using AES128CTR/CBC with the key and ivec entries from the Encryption Root Header.
- For each Segment Certification:
- In the SELF file, fseek to data_offset and read in data_size bytes.
- Decrypt the data using the algorithm, key and ivec from the Segment Certification specified by keyIndex and ivecIndex in the Segment Certification Header.
- Uncompress the data using the algorithm specified in the Segment Certification Header.
- Write the output data to the ELF file as the program section specified by program_idx in the Segment Certification Header.
|