Difference between revisions of "NAX0"
(Encryption details) |
|||
Line 5: | Line 5: | ||
When a NAX0 file is recreated, the header and raw content in NAX0 are completely different except for the magicnum and size-field. This is the case when a title is redownloaded/reinstalled, and when "save/" files are recreated after manual deletion. | When a NAX0 file is recreated, the header and raw content in NAX0 are completely different except for the magicnum and size-field. This is the case when a title is redownloaded/reinstalled, and when "save/" files are recreated after manual deletion. | ||
− | [[Error_codes|Error]] 0x250E02 is returned by NCM when attempting to access a NcaId where the NAX0 header | + | [[Error_codes|Error]] 0x250E02 is returned by NCM when attempting to access a NcaId where the NAX0 header HMAC validation fails. |
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
Line 15: | Line 15: | ||
| 0x0 | | 0x0 | ||
| 0x20 | | 0x20 | ||
− | | | + | | Header HMAC |
|- | |- | ||
| 0x20 | | 0x20 | ||
Line 23: | Line 23: | ||
| 0x28 | | 0x28 | ||
| 0x20 | | 0x20 | ||
− | | | + | | Encrypted AES-XTS Keys |
|- | |- | ||
| 0x48 | | 0x48 | ||
− | | 0x8 | + | | 0x8 |
| Size of the file relative to offset 0x4000. | | Size of the file relative to offset 0x4000. | ||
+ | |- | ||
+ | | 0x50 | ||
+ | | 0x30 | ||
+ | | Padding | ||
|} | |} | ||
+ | |||
+ | = Encryption = | ||
+ | |||
+ | The actual content uses AES-XTS with the same non-standard tweak (endianness swap) as usual, and sector size 0x4000. | ||
+ | |||
+ | Key derivation is as follows: | ||
+ | |||
+ | First, FS retrieves the 16-byte console-unique seed that NS registered (data originates from the ns_systemseed:/ [[Flash_Filesystem#System_Savegames|system savegame]]). Next, FS calculates encryptedSeedKeys = <0x20 hardcoded keydata depending on if this NAX0 is a save or an NCA> XORed with the system seed, calculates kek = [[SPL_services#GenerateAesKek|GenerateAesKek]](<hardcoded keydata>, 0, 0), and then calculates decryptedSeedKeys by doing decryptedSeedKeys[i] = [[SPL_services#GenerateAesKey|GenerateAesKey]](kek, encryptedSeedKeys[i]); for both keys. | ||
+ | |||
+ | |||
+ | Once the decryptedSeedKeys are calculated, FS calculates naxSpecificKeys = hmac-sha256(key=decryptedSeedKeys[0], data=<NAX0 path, relative to /Nintendo/Contents>); (example path: '/registered/000000FF/cafebabecafebabecafebabecafebabe.nca'). Then, FS does the following decryptions in place: aes128_ecb_decrypt(key=naxSpecificKeys[0], data=Header + 0x28); aes128_ecb_decrypt(key=naxSpecificKeys[1], data=Header + 0x38); Finally, hmac-sha256(key=Header[0x20:0x60], data=decryptedSeedKeys[1]) is calculated, and compared using a constant-time memcmp to the hmac stored at Header + 0x0. If it matches, decryption proceeds using the two decrypted keys at Header + 0x28 as an AES-XTS keypair. |
Revision as of 23:27, 3 December 2017
This is the format on the files stored on SD, unknown if this is used elsewhere.
The data between this header and offset 0x4000 is unused/uninitialized it appears. The actual content which is encrypted, starts at offset 0x4000 with the size from the header.
When a NAX0 file is recreated, the header and raw content in NAX0 are completely different except for the magicnum and size-field. This is the case when a title is redownloaded/reinstalled, and when "save/" files are recreated after manual deletion.
Error 0x250E02 is returned by NCM when attempting to access a NcaId where the NAX0 header HMAC validation fails.
Offset | Size | Description |
---|---|---|
0x0 | 0x20 | Header HMAC |
0x20 | 0x8 | Magicnum "NAX0" |
0x28 | 0x20 | Encrypted AES-XTS Keys |
0x48 | 0x8 | Size of the file relative to offset 0x4000. |
0x50 | 0x30 | Padding |
Encryption
The actual content uses AES-XTS with the same non-standard tweak (endianness swap) as usual, and sector size 0x4000.
Key derivation is as follows:
First, FS retrieves the 16-byte console-unique seed that NS registered (data originates from the ns_systemseed:/ system savegame). Next, FS calculates encryptedSeedKeys = <0x20 hardcoded keydata depending on if this NAX0 is a save or an NCA> XORed with the system seed, calculates kek = GenerateAesKek(<hardcoded keydata>, 0, 0), and then calculates decryptedSeedKeys by doing decryptedSeedKeys[i] = GenerateAesKey(kek, encryptedSeedKeys[i]); for both keys.
Once the decryptedSeedKeys are calculated, FS calculates naxSpecificKeys = hmac-sha256(key=decryptedSeedKeys[0], data=<NAX0 path, relative to /Nintendo/Contents>); (example path: '/registered/000000FF/cafebabecafebabecafebabecafebabe.nca'). Then, FS does the following decryptions in place: aes128_ecb_decrypt(key=naxSpecificKeys[0], data=Header + 0x28); aes128_ecb_decrypt(key=naxSpecificKeys[1], data=Header + 0x38); Finally, hmac-sha256(key=Header[0x20:0x60], data=decryptedSeedKeys[1]) is calculated, and compared using a constant-time memcmp to the hmac stored at Header + 0x0. If it matches, decryption proceeds using the two decrypted keys at Header + 0x28 as an AES-XTS keypair.