839
edits
Changes
Jump to navigation
Jump to search
Line 5:
Line 5: − + Line 11:
Line 11: − + Line 17:
Line 17: − + Line 242:
Line 242: − − ==== 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.
no edit summary
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:
* 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).
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.
| Memory type (00 = Base, 01 = Application, 02 = System)
| Memory type (00 = Base, 01 = Application, 02 = System)
|}
|}