NCCH: Difference between revisions

No edit summary
Line 36: Line 36:
The extended header, the [[ExeFS]] and the RomFS are encrypted using 128-bit AES CTR.  
The extended header, the [[ExeFS]] and the RomFS are encrypted using 128-bit AES CTR.  


By default encrypted regions are compressed with an LZ77 variant, then encrypted. The spec allows for both unencrypted and uncompressed regions to exist. System titles expect a fixed system key.
By default encrypted regions are compressed with an LZ77 variant, then encrypted. The spec allows for both unencrypted and uncompressed regions to exist. Retail SD card CXIs must have the [[ExeFS|ExeFS:/.code]] compressed. Development units use a fixed system key for system titles, a separate key is used on retail.


=== NCCH Header ===
=== NCCH Header ===
Line 167: Line 167:
|  When the low 2-bits are 0x1, the NCCH is a CFA. Otherwise, it's a CXI.
|  When the low 2-bits are 0x1, the NCCH is a CFA. Otherwise, it's a CXI.
|}
|}
CXIs NCCH header signature is verified using the RSA public key stored in the accessdesc,(which follows the exheader) while CFAs NCCH header is verified with a fixed RSA public key. Type 0x1 is CFA, type 0x2 is system CXI, and type 0x3 is application CXI.
CXIs NCCH header signature is verified using the RSA public key stored in the accessdesc,(which follows the exheader) while CFAs NCCH header is verified with a fixed RSA public key.


==== NCCH header example for Lego Starwars III ====
==== NCCH header example for Lego Starwars III ====