839
edits
Changes
Jump to navigation
Jump to search
mLine 1:
Line 1: + + − === Overview ===+ − A CXI file contains the 'application' program code, which runs on a single ARM11 core. It can communicate through SVC calls with the other ARM11 core running the 'system' program code. For reasons of clarity, the ARM11 cores will sometimes be called the 'appcore' and 'syscore' respectively.+ − + − + − More specifically, the CXI file format is structured in the following order: − − + − + + + + + + + + + + + + − + − + − === NCCH Header ===+ Line 85:
Line 96: − + Line 133:
Line 144: − + Line 140:
Line 151: − ==== NCCH header example for Lego Starwars III ====+ Line 183:
Line 194: − ==== Plain region example for Lego Starwars III ====+ Line 200:
Line 211: − + − − ==== Example dependency list from the extended header ==== + Line 213:
Line 223: − + Line 227:
Line 237: + + + + + + + + + + + + + + +
Redirected page to NCCH#CXI
#REDIRECT [[NCCH#CXI]]
[[Category:File formats]]
The following text tries to document the structure of the CTR Executable Image (CXI) format.
The following text tries to document the structure of the CTR Executable Image (CXI) format.
== Overview ==
The CXI format is a specialization of an NCCH container. Generally the CXI will contain executable code, which runs on a single ARM11 core. It can communicate through SVC calls with the other ARM11 core running the 'system' program code. For reasons of clarity, the ARM11 cores will sometimes be called the 'appcore' and 'syscore' respectively.
The CXI file format contains application ARM11 code, the menu icon, the menu 3D model, and an embedded read-only (ROM) filesystem for external filestorage. In fact, the application ARM11 code, menu icon, and menu 3D model are embedded into its own filesystem too, called the ExeFS.
The CXI format is structured in the following order:
* first a NCCH header,
* first an NCCH header,
* followed by an extended header,
* followed by an extended header,
* followed by a plain binary region,
* followed by a plain binary region,
* followed by an embedded executable filesystem (ExeFS),
* followed by an embedded executable filesystem ([[ExeFS]]) - (contains ARM11 code, Home menu icn/bnr and logo),
* and finally followed by a read-only filesystem (RomFS).
* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).
There are specializations of NCCH containers which are not executable, but are used in conjunction with CXI NCCH files. For instance the DLP Child Container and the Home Menu App Manual. (There is a system update NCCH which follows this format, but is used by the 3DS rather than the Application NCCH, and only works when embedded in the [[CCI]] format because the nVer is kept in the header of retail [[CCI]] files instead of the application NCCH)
Non-Executable NCCH files are structured in the following order:
* first a NCCH header,
* followed by a read-only filesystem ([[RomFS]])
Non-Executable NCCH file examples(Includes Decrypted [[RomFS]]):
[http://depositfiles.com/files/d8ej64571 DLPChildContainer]
[http://depositfiles.com/files/en9g37b0j Manual]
The extended header contains additional information regarding access control.
The extended header contains additional information regarding access control.
The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.
The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.
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 a 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. System titles expect a fixed system key.
== NCCH Header ==
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
| 0x188
| 0x188
| 8
| 8
| Flags: byte[5]-byte[7] indicate content type ( system update, application, ... ) size of media unit ( 512*2^byte[6] ) and encryption.
| Flags: byte[5]-byte[7] indicate content type ( system update, application, manual, ... ) size of media unit ( 512*2^byte[6] ) and encryption.
|-
|-
| 0x190
| 0x190
| 0x1C0
| 0x1C0
| 0x20
| 0x20
| ExeFS superblock hash
| ExeFS superblock hash, over the cleartext ExeFS
|-
|-
| 0x1E0
| 0x1E0
|}
|}
=== NCCH header example for Lego Starwars III ===
Signature: 720FF8F83F2A1E998322A026D1434165
Signature: 720FF8F83F2A1E998322A026D1434165
ED19642ABC1CB2722135AA202BEAD60A
ED19642ABC1CB2722135AA202BEAD60A
Note: Offsets and sizes in media units have been converted to byte sizes.
Note: Offsets and sizes in media units have been converted to byte sizes.
=== Plain region example for Lego Starwars III ===
0004a00: 5b 53 44 4b 2b 4e 49 4e 54 45 4e 44 4f 3a 43 54 [SDK+NINTENDO:CT [SDK+NINTENDO:CTR_SDK-0_14_23_200_none]
0004a00: 5b 53 44 4b 2b 4e 49 4e 54 45 4e 44 4f 3a 43 54 [SDK+NINTENDO:CT [SDK+NINTENDO:CTR_SDK-0_14_23_200_none]
0004a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30 R_SDK-0_14_23_20
0004a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30 R_SDK-0_14_23_20
0004ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0004ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
A tool for parsing this format is available [http://github.com/neimod/ctr/tree/master/ctrtool here]
A tool for parsing this format is available [http://github.com/3dshax/ctr/tree/master/ctrtool here]
=== Example dependency list from the extended header ===
00850 41 50 54 3A 55 00 00 00 24 68 69 6F 46 49 4F 00 APT:U...$hioFIO.
00850 41 50 54 3A 55 00 00 00 24 68 69 6F 46 49 4F 00 APT:U...$hioFIO.
00860 24 68 6F 73 74 69 6F 30 24 68 6F 73 74 69 6F 31 $hostio0$hostio1
00860 24 68 6F 73 74 69 6F 30 24 68 6F 73 74 69 6F 31 $hostio0$hostio1
008C0 67 73 70 3A 3A 47 70 75 68 69 64 3A 55 53 45 52 gsp::Gpuhid:USER
008C0 67 73 70 3A 3A 47 70 75 68 69 64 3A 55 53 45 52 gsp::Gpuhid:USER
008D0 68 74 74 70 3A 43 00 00 6D 69 63 3A 75 00 00 00 http:C..mic:u...
008D0 68 74 74 70 3A 43 00 00 6D 69 63 3A 75 00 00 00 http:C..mic:u...
008E0 6E 64 6D 3A 75 00 00 00 6E 65 77 73 3A 75 00 00 ndm:u...news:u..
008E0 6E 64 6D 3A 75 00 00 00 6E 65 77 73 3A 75 00 00 ndm:u...<nowiki>news:u..</nowiki>
008F0 6E 77 6D 3A 3A 55 44 53 70 74 6D 3A 75 00 00 00 nwm::UDSptm:u...
008F0 6E 77 6D 3A 3A 55 44 53 70 74 6D 3A 75 00 00 00 nwm::UDSptm:u...
00900 70 78 69 3A 64 65 76 00 73 6F 63 3A 55 00 00 00 pxi:dev.soc:U...
00900 70 78 69 3A 64 65 76 00 73 6F 63 3A 55 00 00 00 pxi:dev.soc:U...
009F0 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 02 . .............
009F0 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 02 . .............
00A00 5B 53 44 4B 2B 4E 49 4E 54 45 4E 44 4F 3A 43 54 [SDK+NINTENDO:CT
00A00 5B 53 44 4B 2B 4E 49 4E 54 45 4E 44 4F 3A 43 54 [SDK+NINTENDO:CT
=== Extended Header ===
'''NOTE: AFTER DECRYPTION'''
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x399
| 1
| Memory type (00 = Base, 01 = Application, 02 = System)
|}