SELF - SPRX: Difference between revisions
(still merging corrections needed (will do that later)) |
(end of merging - correction still needed (will do that later)) |
||
Line 117: | Line 117: | ||
} | } | ||
PROGRAMINFO_t; | PROGRAMINFO_t; | ||
Aligned to 0x10 bytes. | |||
{| class="wikitable" | |||
|- | |||
! 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 | |||
|} | |||
=== ELF Header === | === ELF Header === | ||
Line 143: | Line 164: | ||
} | } | ||
SEGMENTINFO_t; | SEGMENTINFO_t; | ||
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.) | |||
{| class="wikitable" | |||
|- | |||
! 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. | |||
|- | |||
|} | |||
Notes: | Notes: | ||
Line 330: | Line 374: | ||
**Uncompress the data using zlib. | **Uncompress the data using zlib. | ||
**Write it to the ELF file as the program section specified by section Index in the metadata section header. | **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 ''' | ''' Source: http://ps3wiki.lan.st/index.php?title=SELF_File_Format_and_Decryption ''' |
Revision as of 22:26, 3 October 2011
SELF stands for Signed Executable and Linkable Format.
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 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.
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.
File Format
Notes:
- Numbers are stored in big endian format.
SELF/SCE Header
typedef struct { uint32_t magic; // "SCE\0" uint32_t version; // always 2 uint16_t attribute; // 0x8000 - fself uint16_t category; uint32_t metadataInfoOffset; uint64_t fileOffset; uint64_t fileSize; uint64_t unknown06; uint64_t programInfoOffset; uint64_t elfHeaderOffset; uint64_t elfProgramHeadersOffset; uint64_t elfSectionHeadersOffset; uint64_t sInfoOffset; uint64_t versionInfoOffset; uint64_t controlInfoOffset; uint64_t controlInfoSize; uint32_t unknown15; } SELFHEADER_t;
field | offset | type | notes |
---|---|---|---|
Magic | 0x0 | u32 | Must be "SCE\0" |
version | 0x4 | u32 | This must be 2 or the Self loader will abort |
flags | 0x8 | u16 |
*0: retail type 0 *1: retail *2: retail type 1 *0x8000: devkit *4: unknown, games that require 3.42. *7: unknown, all games that require 3.50 have that flag. |
SCE header type | 0xA | u16 | 1 for SELF, 3 for update PKG |
meta_offset | 0xC | u32 | Offset to the checksums. Must be at least 20 bytes before the end of the header |
header size | 0x10 | u64 | This is the length of the header (including the fake elf headers)
|
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 |
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.
Program Info
typedef struct { uint64_t programAuthId; uint64_t unknown01; uint16_t programVersion[4]; uint64_t unknown03; } PROGRAMINFO_t;
Aligned to 0x10 bytes.
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 |
ELF Header
See Spec here: ELF Header
Notes:
- e_type: ET_PS3PRX=0xFFA4
- EI_OSABI: ELFOSABI_CELL_LV2=0x66
ELF Program Headers
See Spec here: ELF Program Headers
Segment Information
typedef struct { uint64_t dataOffset; uint64_t dataSize; uint32_t compressed; //1:NO, 2:YES uint32_t unknown03; uint32_t unknown04; uint32_t encrypted; //0:NA, 1:YES, 2:NO } SEGMENTINFO_t;
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.)
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. |
Notes:
- There is one Segment Information for each ELF Program Header.
Control Information
typedef struct { uint32_t unknown00; uint32_t unknown01; uint32_t unknown02; uint32_t unknown03; uint32_t controlFlags[8]; uint32_t unknown05; uint32_t unknown06; uint32_t unknown07; uint32_t unknown08; char digest[64]; uint32_t unknown10; uint32_t unknown11; } CONTROLINFO_t;
Metadata Information
typedef struct { uint8_t unknown00[32]; uint8_t key[32]; uint8_t ivec[32]; } METADATAINFO_t;
Notes:
- The key and ivec fields are encrypted using AES256CBC.
- This is not present if it is an FSELF.
Metadata Header
typedef struct { uint64_t signatureInputLength; uint32_t unknown02; uint32_t sectionCount; uint32_t keyCount; uint32_t signatureInfoSize; uint32_t unknown06; uint32_t unknown07; } METADATAHEADER_t;
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
typedef struct { uint64_t dataOffset; uint64_t dataSize; uint32_t unknown02; uint32_t programIndex; uint32_t unknown04; uint32_t sha1Index; uint32_t encrypted; //1:NO, 3:YES uint32_t keyIndex; uint32_t ivecIndex; uint32_t compressed; //1:NO, 2:YES } METADATASECTIONHEADER_t;
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.
Metadata Keys
typedef uint8_t METADATAKEY_t [16];
Notes:
- The metadata keys 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 Information
typedef struct { uint32_t unknown00; uint32_t signatureSize; uint64_t unknown02; uint64_t unknown03; uint64_t unknown04; uint64_t unknown05; uint32_t unknown06; uint32_t unknown07; } SIGNATUREINFO_t;
Notes:
- The signature information is located after the metadata keys in the SELF file.
- It is only present if the signatureInfoSize in the metadata header is not zero.
- It is decrypted using AES128CTR with the key and ivec entries from the metadata information.
Signature
typedef struct { uint8_t r[21]; uint8_t s[21]; uint8_t padding[6]; } SIGNATURE_t;
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.
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