SELF

SELF files are a wrapper around encrypted ELF files. The encrypted header contains keys to decrypt each encrypted ELF program, which are decrypted and loaded individually. Because of this, a copy of the ELF headers and ELF program headers are stored in plain text next to the SCE header.

Authority ID
8 Bytes long. Located at offset 0x80 in SELF header.

sceAppMgrConvertVs0UserDrivePath checks the AuthId to limit mount points.

only used by SceWebCore eboot.bin (NPXS10017 / NPXS10037 on 1.69-3.01, replaced later by SceWebKit).

seen used by SceWebCore can access  and.

seen used by PSM can access  and.

Relocations
Relocations are stored within the PT_SCE_RELA segment.

Relocation entry format can be one of 10 types which is determined by the first 4 bits.

Encryption
SELF, PRX and Update Packages are all encrypted using the exact same algorithm, while SELF are hashed and signed (signature is RSA based), this section only focuses on the encryption layer itself.


 * Step 1

The first step uses a static key and IV contained within a relevant Secure Module; for example update package keys are located in update_service_sm.self while kernel prx keys are located in kprx_auth_sm.self (or, for secure module themselves as well as kernel_boot_loader.self, inside secure_kernel.enp).

The initial step decrypts the first 0x40 bytes of the self metadata using AES256CBC, this results into the key and IV used in step 2


 * Step 2

The second step uses the key and iv decrypted from the first 0x40 bytes of the metadata to decrypt the rest of the metadata using AES128CBC.


 * Step 3

The SELF metadata is typically stored in this format (below is the metadata example for a 4 sections self): Update packages metadata follows the same principles but is slightly different (different MAGIC/Header)

Following the same principles, an update package metadata would look like this:


 * Step 4

The last step uses the keys and ivs extracted from the metadata to decrypt their respective sections using AES128CTR.