SLSK

Location
SLSK files can be found in SLB2 as personalized and in SPKGs as non-personalized.

Footer
The last 0x340 bytes of each SLSK are not personalized and not used in any way.

Secret debug mode
Before the SLSK is loaded, there is a check for some secret mode. Note these two ports are used in regular syscon SPI-like communications. However, usually these two pins are used as part of the SPI-like protocol for signaling. But the bootrom does not use the SPI registers at all. It uses some registers that are never seen outside of the bootrom. Even though it is logically separate from the SPI ports, it could be physically connected to the same pins although this is unconfirmed. Note that when the secret handshake passes and we are in secret mode, the MBR is read from the gamecard instead (with gamecard auth not enabled, so a regular SD card would work). Additionally, the personalization removal is done using keyslot 0x207 instead of 0x206 (see below) although it is not currently known if 0x207 is per-console. All the HMAC and signature checks are still performed, so this secret mode cannot be used to run unsigned code. However, Glitching would still work when in the secret debug mode.

See also: Ernie_Firmware.

Personalization Removal
First, personalization layer is removed. It uses AES-128-CBC with a derived key and decrypts data at Metadata offset (0xE0 on FW 0.940-3.73, 0xD0 on FW 0.931) for size of (body_size + 0xC0 (Metadata) + 0x20 (HMAC) + 0x100 (Header Signature)).

There are two possible paths to derive the key used to remove personalization. Normally, the key is derived using keyslot 0x206. There is however an alternative path, triggered in secret debug mode, when instead keyslot 0x207 is used and with a different seed.

Once personalization is removed, the source keyslots are locked down. Keyslots 0x9, 0x206, 0x207 are locked down completely (leaving only 0xA0 protection). However, keyslot 0x8 allows encryption, leaving Update Manager SM add personalization layer during firmware update without having to derive the keys itself.

HMAC and RSA verification
A key is derived from keyslot 0x344 and put into keyslot 0x20. This key is then immediately used to calculate HMAC-SHA256 over SLSK header excluding the SLSK Header Signature (usually 0x00 to 0x1C0 or to 0x1B0).

2 bytes are read from keyring slot 0x603. This is the bitmask of allowed RSA public keys (0xFFFF on 1.692). If the bitmask is zero, a hardcoded RSA modulus is used. Otherwise, it checks SLSK Signature Public Key Revision against the mask and if it is allowed, it gets the RSA modulus from keyring RSA storage starting at keyslot 0x700.

After calculating RSA powmod, it checks the padding over the SLSK Signature and compares previously calculated HMAC-SHA256 against the contents.

Finally, it protects keyslots 0x700 to 0x77F to disable reading out the modulus.

Metadata decryption and encrypted body verification
Using keyslot (0x208+enc_key_revision) and the SLSK Metadata first seed (0x20 bytes), the SLSK Body decryption key is derived and put into keyslot 0xA. Then, 5 more keys are derived in the same way, using SLSK Metadata seeds. These 5 keys are put into keyslots 0xB, 0xC, 0xD, 0xE and 0xF.

Once done, keyslots 0x208, 0x209, 0x20A, 0x20B, 0x20C, 0x20D (all possible keys bound to SLSK Encryption Key Revisions) are protected.

SLSK HMAC is decrypted using keyslot 0xA. This is HMAC-SHA256 of the encrypted Body segment. HMAC-SHA256 is calculated over the encrypted Body segment using keyslot 0x20, then keyslot 0x20 is protected. Finally, the calculated HMAC over the encrypted Body is compared to the HMAC decrypted from the SLSK header.

Protecting the keys
Some keys are protected, depending on the bit flags buffer that we call Static key revoke block. However, on FW 3.68 SLSK, Static key revoke block is all zeroes so no keys should be protected by this function (?).

Body decryption
Body is decrypted using keyslot 0xA as key and a hardcoded IV. Then, the key is protected. The decrypted Body is the executable code segment.

One could guess that at this step, SHA256 of the decrypted Body is calculated and compared to the SLSK Header SHA256, but Team Molecule has not confirmed this theory, like in Prototype DEM-3000H First Loader showcased by Yifan Lu where the SHA256 integrity check is not present.

Remainder area clearing
The remainder (0x1C000 - body_size) after the decrypted body is cleared with DMAC. DMAC registers are also cleared.