CXI - Revision history

3dsguy: Redirected page to NCCH#CXI

2012-07-18T15:59:46Z

Redirected page to NCCH#CXI

← Older revision		Revision as of 19:59, 18 July 2012
Line 1:		Line 1:
			#REDIRECT [[NCCH#CXI]]
	[[Category:File formats]]		[[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.

Neimod at 08:13, 29 June 2012

2012-06-29T06:13:03Z

← Older revision		Revision as of 10:13, 29 June 2012
Line 3:		Line 3:

	== Overview ==		== Overview ==
	The ~~NCCH (~~CXI) format is ~~like~~ a ~~multipurpose~~ container. Generally ~~a NCCH file~~ will contain ~~the~~ 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 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.

	~~Executable NCCH files are~~ structured in the following order:		The CXI format is structured in the following order:
	* first a NCCH header,		* first a NCCH header,
	* followed by an extended header,		* followed by an extended header,
Line 12:		Line 12:
	* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).		* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).

	There are NCCH ~~files~~ which are not executable, but are used in conjunction with ~~executable~~ 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)		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:		Non-Executable NCCH files are structured in the following order:

3dsguy at 01:01, 29 June 2012

2012-06-28T23:01:02Z

← Older revision		Revision as of 03:01, 29 June 2012
Line 12:		Line 12:
	* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).		* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).

	There are NCCH files which are not executable, but are used in conjunction with executable NCCH files. For instance the DLP Child Container and the Home Menu App Manual. (There is a system update ~~CXI~~ 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)		There are NCCH files which are not executable, but are used in conjunction with executable 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:		Non-Executable NCCH files are structured in the following order:

3dsguy at 01:00, 29 June 2012

2012-06-28T23:00:10Z

3dsguy at 14:21, 24 June 2012

2012-06-24T12:21:10Z

← Older revision		Revision as of 16:21, 24 June 2012
Line 10:		Line 10:
	* followed by a plain binary region,		* followed by a plain binary region,
	* followed by an embedded executable filesystem ([[ExeFS]]) - (contains ARM11 code, Home menu icn/bnr and logo),		* 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) - (Used for external file storage).		* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).

	There are CXI files which are not executable, but are used in conjunction with executable CXI files. For instance the DLP Child Container and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application CXI, 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 CXI)		There are CXI files which are not executable, but are used in conjunction with executable CXI files. For instance the DLP Child Container and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application CXI, 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 CXI)
Line 16:		Line 16:
	Non-Executable CXI files are structured in the following order:		Non-Executable CXI files are structured in the following order:
	* first a NCCH header,		* first a NCCH header,
	* followed by a read-only filesystem (RomFS)		* followed by a read-only filesystem ([[RomFS]])

	Non-Executable CXI file examples(Includes Decrypted RomFS):		Non-Executable CXI file examples(Includes Decrypted [[RomFS]]):

	[http://depositfiles.com/files/d8ej64571 DLPChildContainer]		[http://depositfiles.com/files/d8ej64571 DLPChildContainer]

3dsguy at 07:26, 24 June 2012

2012-06-24T05:26:15Z

← Older revision		Revision as of 09:26, 24 June 2012
Line 12:		Line 12:
	* and finally followed by a read-only filesystem (RomFS) - (Used for external file storage).		* and finally followed by a read-only filesystem (RomFS) - (Used for external file storage).

	There are CXI files which are not executable, but are used in conjunction with executable CXI files. For instance the DLP Child Container ~~CXI~~ and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application CXI, 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 CXI)		There are CXI files which are not executable, but are used in conjunction with executable CXI files. For instance the DLP Child Container and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application CXI, 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 CXI)

	Non-Executable CXI files are structured in the following order:		Non-Executable CXI files are structured in the following order:

3dsguy: fixed bad wording, sorry :/

2012-06-23T20:37:47Z

fixed bad wording, sorry :/

← Older revision		Revision as of 00:37, 24 June 2012
Line 12:		Line 12:
	* and finally followed by a read-only filesystem (RomFS) - (Used for external file storage).		* and finally followed by a read-only filesystem (RomFS) - (Used for external file storage).

	There are CXI files which are not executable, but are used in conjunction with executable CXI files. For instance the DLP Child CXI and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application CXI, 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 CXI)		There are CXI files which are not executable, but are used in conjunction with executable CXI files. For instance the DLP Child Container CXI and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application CXI, 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 CXI)

	Non-Executable CXI files are structured in the following order:		Non-Executable CXI files are structured in the following order:
Line 20:		Line 20:
	Non-Executable CXI file examples(Includes Decrypted RomFS):		Non-Executable CXI file examples(Includes Decrypted RomFS):

	[http://depositfiles.com/files/d8ej64571 ~~DLPChild~~]		[http://depositfiles.com/files/d8ej64571 DLPChildContainer]
	[http://depositfiles.com/files/en9g37b0j Manual]		[http://depositfiles.com/files/en9g37b0j Manual]

3dsguy at 05:06, 22 June 2012

2012-06-22T03:06:41Z

← Older revision		Revision as of 07:06, 22 June 2012
Line 2:		Line 2:
	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 ===		== 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.		The CXI format is like a multipurpose container. Generally a CXI file will contain the 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]].~~		Executable CXI files are structured in the following order:
			* first a NCCH header,
	~~More specifically, the CXI file format is~~ structured in the following order:
	* 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 CXI files which are not executable, but are used in conjunction with executable CXI files. For instance the DLP Child CXI and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application CXI, 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 CXI)

			Non-Executable CXI files are structured in the following order:
			* first a NCCH header,
			* followed by a read-only filesystem (RomFS)

			Non-Executable CXI file examples(Includes Decrypted RomFS):

			[http://depositfiles.com/files/d8ej64571 DLPChild]
			[http://depositfiles.com/files/en9g37b0j Manual]

	The extended header contains additional information regarding access control.		The extended header contains additional information regarding access control.
Line 21:		Line 30:
	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. System titles expect a fixed system key.

	=== NCCH Header ===		== NCCH Header ==
	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
	\|-		\|-
Line 141:		Line 150:
	\|}		\|}

	==== NCCH header example for Lego Starwars III ====		=== NCCH header example for Lego Starwars III ===
	Signature: 720FF8F83F2A1E998322A026D1434165		Signature: 720FF8F83F2A1E998322A026D1434165
	ED19642ABC1CB2722135AA202BEAD60A		ED19642ABC1CB2722135AA202BEAD60A
Line 184:		Line 193:
	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 ====		=== 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
Line 203:		Line 212:
	A tool for parsing this format is available [http://github.com/3dshax/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 ====		=== 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
Line 228:		Line 237:
	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 ====		=== Extended Header ===

	'''NOTE: AFTER DECRYPTION'''		'''NOTE: AFTER DECRYPTION'''

3dsguy at 09:35, 8 June 2012

2012-06-08T07:35:28Z

← Older revision		Revision as of 11:35, 8 June 2012
Line 5:		Line 5:
	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.		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.

	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 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]].

	More specifically, the CXI file format is structured in the following order:		More specifically, the CXI file format is structured in the following order:
Line 11:		Line 11:
	* 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]]),
	* and finally followed by a read-only filesystem (RomFS).		* and finally followed by a read-only filesystem (RomFS).

Line 17:		Line 17:
	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 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. System titles expect a fixed system key.
Line 242:		Line 242:
	\| Memory type (00 = Base, 01 = Application, 02 = System)		\| Memory type (00 = Base, 01 = Application, 02 = System)
	\|}		\|}

	~~==== ExeFS filesystem ====~~

	* .code Contains the code binary, which can be optionally reverse-LZSS compressed via an exheader flag.
	* [[logo]] Contains distribution licensing Binary data. (Types: Nintendo, Licensed, Published, or Distributed) Additionally it could have no license (type None). System applications and applets that interact with the Home Menu are typically set to type 'none' as they don't display that information.
	* [[File Formats\|banner]] Contains the banner which homemenu uses for this CXI.
	* [[SMDH\|icon]] Contains the icon which homemenu displays for this CXI.

Xcution at 05:54, 30 April 2012

2012-04-30T03:54:45Z

@@ Line 227: / Line 227: @@
 F0 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 02 . .............
 A00 5B 53 44 4B 2B 4E 49 4E 54 45 4E 44 4F 3A 43 54 [SDK+NINTENDO:CT
 ==== ExeFS filesystem ====

← Older revision		Revision as of 03:00, 29 June 2012
Line 3:		Line 3:

	== Overview ==		== Overview ==
	The CXI format is like a multipurpose container. Generally a ~~CXI~~ file will contain the 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 NCCH (CXI) format is like a multipurpose container. Generally a NCCH file will contain the 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.

	Executable ~~CXI~~ files are structured in the following order:		Executable NCCH files are structured in the following order:
	* first a NCCH header,		* first a NCCH header,
	* followed by an extended header,		* followed by an extended header,
Line 12:		Line 12:
	* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).		* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).

	There are ~~CXI~~ files which are not executable, but are used in conjunction with executable ~~CXI~~ files. For instance the DLP Child Container and the Home Menu App Manual. (There is a system update CXI which follows this format, but is used by the 3DS rather than the Application ~~CXI~~, 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 ~~CXI~~)		There are NCCH files which are not executable, but are used in conjunction with executable NCCH files. For instance the DLP Child Container and the Home Menu App Manual. (There is a system update CXI 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 ~~CXI~~ files are structured in the following order:		Non-Executable NCCH files are structured in the following order:
	* first a NCCH header,		* first a NCCH header,
	* followed by a read-only filesystem ([[RomFS]])		* followed by a read-only filesystem ([[RomFS]])

	Non-Executable ~~CXI~~ file examples(Includes Decrypted [[RomFS]]):		Non-Executable NCCH file examples(Includes Decrypted [[RomFS]]):

	[http://depositfiles.com/files/d8ej64571 DLPChildContainer]		[http://depositfiles.com/files/d8ej64571 DLPChildContainer]