A little homebrew test I just compiled...and it succeeded!

I'm actually not sure why the icon (upper left of bottom screen) appeared like that. That's not my program's icon...but who cares because the message succeeded in delivery!

2012-10-14T22:42:14Z

Xcution: /* NCCH Header */

[[Category:File formats]]
The following text tries to document the structure of the NCCH container format.

== Overview ==
There are two known NCCH container specialisations used on the 3DS, "executable" and "non-executable", officially known as CXI and CFA respectively.

== CXI ==

The CXI (CTR Executable Image) specialisation of the NCCH container, contains 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 structured in the following order:
* first a NCCH header,
* followed by an extended header,
* followed by a plain binary region,
* followed by an embedded executable filesystem ([[ExeFS]]) - (contains ARM11 code, Home menu [[SMDH|icn]]/bnr and [[Logo|logo]]),
* and finally followed by a read-only filesystem ([[RomFS]]) - (Used for external file storage).

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.

== CFA ==

The CFA (CTR File Archive) specialisation of the NCCH container, is not executable, but are used in conjunction with CXI files. For instance the DLP Child Container and the Electronic 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 CFA files which exist alone in a title, but these are just [[Title list|System Data Archive]] titles and are found only on the NAND.

CFA 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/n476if4gj DLPChild Container]
[http://depositfiles.com/files/gnrihkeec Electronic Manual]

== NCCH Specs ==

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. Retail SD card CXIs must have the [[ExeFS|ExeFS:/.code]] compressed. Development units use a fixed system key for system titles. On retail part of the input [[AES]] engine key is unique per NCCH, the AES engine internally generates the final-normal key.

Retail CFAs use NCCH product code "CTR-P-CTAP", while retail title/gamecard CXIs use NCCH product code "CTR-P-XXXX". This product code is the NCCH [[Serials|serial code]]. <del>This CXI product code is likely used for region-locking.</del> There is a value set in the banner used for region-locking.

=== NCCH Header ===
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 0x100
| RSA-2048 signature of the NCCH header, using SHA-256.
|-
| 0x100
| 4
| Magic ID, always 'NCCH'
|-
| 0x104
| 4
| Content size, in media units (1 media unit = 0x200 bytes)
|-
| 0x108
| 8
| Partition ID
|-
| 0x110
| 2
| Maker code
|-
| 0x112
| 2
| Version
|-
| 0x114
| 4
| Reserved
|-
| 0x118
| 8
| Program ID
|-
| 0x120
| 1
| Temp flag
|-
| 0x121
| 0x2F
| Reserved
|-
| 0x150
| 0x10
| Product code
|-
| 0x160
| 0x20
| Extended header hash. SHA256Managed() over first 0x400 bytes of UNENCRYPTED ExHeader.
|-
| 0x180
| 4
| Extended header size
|-
| 0x184
| 4
| Reserved
|-
| 0x188
| 8
| Flags: byte[5]-byte[7] indicate content type ( system update, application, manual, ... ) size of media unit ( 512*2^byte[6] ) and encryption.
|-
| 0x190
| 4
| Plain region offset, in media units
|-
| 0x194
| 4
| Plain region size, in media units
|-
| 0x198
| 8
| Reserved
|-
| 0x1A0
| 4
| ExeFS offset, in media units
|-
| 0x1A4
| 4
| ExeFS size, in media units
|-
| 0x1A8
| 4
| ExeFS hash region size, in media units
|-
| 0x1AC
| 4
| Reserved
|-
| 0x1B0
| 4
| RomFS offset, in media units
|-
| 0x1B4
| 4
| RomFS size, in media units
|-
| 0x1B8
| 4
| RomFS hash region size, in media units
|-
| 0x1BC
| 4
| Reserved
|-
| 0x1C0
| 0x20
| ExeFS superblock hash. SHA256Managed() over first 0x200 bytes of UNENCRYPTED ExeFS.
|-
| 0x1E0
| 0x20
| RomFS superblock hash. SHA256Managed() over first 0x200 bytes of UNENCRYPTED RomFS.
|}

=== NCCH Flags ===
{| class="wikitable" border="1"
|-
! INDEX
! DESCRIPTION
|-
| 5
| 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.

==== NCCH header example for Lego Starwars III ====
Signature: 720FF8F83F2A1E998322A026D1434165
ED19642ABC1CB2722135AA202BEAD60A
80BCD21C768C597B8268FEF2C64EA710
4C9BA5E12CFFBD1D0C619F4EF7B42CA7
DD8482CB4EB26720AD66CDA57ABCBCFB
D63268A6E2896A59B3B744E39E45B88A
ABB4C0980ACC6210818DCE6DAC838A10
95D0F66B352474D4B3DA4B333F49912D
29AF7EA58BC8C890B18C70B7D540A9FB
EBE24A5312055617D3353B28C3EB1D17
61021BEFF6AD22C384835B40BD44DFAD
981F6350F9458B17BCB5F768C92ABC93
2BCE9888855A8998F4CDE40C9543514A
C57B84EB75A680E7C742632614620D1D
A253284DF3DC01091EB3800C36FD62EE
BA15340F1FD498FAB67C0302E9CDA397
Magic: NCCH
Content size: 0x1cfef400
Partition id: 0004000000038c00
Maker code: 3436 ("46")
Version: 0002
Program id: 0004000000038c00
Temp flag: 00
Product code: CTR-P-ALGP
Extended header hash: 0C27E3C1DE7B2AE2D3114F32A4EEBF46
9AFD0CF352C11D4984C2A9F1D2144C63
Extended header size: 00000400
Flags: 0000030100000000
Plain region offset: 0x00004a00
Plain region size: 0x00000200
ExeFS offset: 0x00004c00
ExeFS size: 0x00143800
ExeFS hash region size: 0x00000200
RomFS offset: 0x00148400
RomFS size: 0x1ceab000
RomFS hash region size: 0x00000200
ExeFS Superblock Hash: 130C042615F647C4C63225EA9E67F8A2
7B15246B88FBC7A927257B84977B787B
RomFS Superblock Hash: A65BEE1060BB6A6821BBCEC600035B7E
64FB6EACA7F0960CFB1F5A37087728F7
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]
0004a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30 R_SDK-0_14_23_20
0004a20: 30 5f 6e 6f 6e 65 5d 00 5b 53 44 4b 2b 4e 49 4e 0_none].[SDK+NIN [SDK+NINTENDO:Firmware-02_27]
0004a30: 54 45 4e 44 4f 3a 46 69 72 6d 77 61 72 65 2d 30 TENDO:Firmware-0
0004a40: 32 5f 32 37 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 2_27].[SDK+Mobic [SDK+Mobiclip:Deblocker_1_0_2]
0004a50: 6c 69 70 3a 44 65 62 6c 6f 63 6b 65 72 5f 31 5f lip:Deblocker_1_
0004a60: 30 5f 32 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 6c 0_2].[SDK+Mobicl [SDK+Mobiclip:ImaAdpcmDec_1_0_0]
0004a70: 69 70 3a 49 6d 61 41 64 70 63 6d 44 65 63 5f 31 ip:ImaAdpcmDec_1
0004a80: 5f 30 5f 30 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 _0_0].[SDK+Mobic [SDK+Mobiclip:MobiclipDec_1_0_1]
0004a90: 6c 69 70 3a 4d 6f 62 69 63 6c 69 70 44 65 63 5f lip:MobiclipDec_
0004aa0: 31 5f 30 5f 31 5d 00 5b 53 44 4b 2b 4d 6f 62 69 1_0_1].[SDK+Mobi [SDK+Mobiclip:MoflexDemuxer_1_0_2]
0004ab0: 63 6c 69 70 3a 4d 6f 66 6c 65 78 44 65 6d 75 78 clip:MoflexDemux
0004ac0: 65 72 5f 31 5f 30 5f 32 5d 00 00 00 00 00 00 00 er_1_0_2].......
0004ad0: 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/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.
00860 24 68 6F 73 74 69 6F 30 24 68 6F 73 74 69 6F 31 $hostio0$hostio1
00870 61 63 3A 75 00 00 00 00 62 6F 73 73 3A 55 00 00 ac:u....boss:U..
00880 63 61 6D 3A 75 00 00 00 63 65 63 64 3A 75 00 00 cam:u...cecd:u..
00890 63 66 67 3A 75 00 00 00 64 6C 70 3A 46 4B 43 4C cfg:u...dlp:FKCL
008A0 64 6C 70 3A 53 52 56 52 64 73 70 3A 3A 44 53 50 dlp:SRVRdsp::DSP
008B0 66 72 64 3A 75 00 00 00 66 73 3A 55 53 45 52 00 frd:u...fs: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...
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...
00900 70 78 69 3A 64 65 76 00 73 6F 63 3A 55 00 00 00 pxi:dev.soc:U...
00910 73 73 6C 3A 43 00 00 00 79 32 72 3A 75 00 00 00 ssl:C...y2r:u...
00920 69 72 3A 55 53 45 52 00 6C 64 72 3A 72 6F 00 00 ir:USER.ldr:ro..
00930 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00940 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00960 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
... ...
009D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
009E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
009F0 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 02 . .............

=== Extended Header ===

'''NOTE: AFTER DECRYPTION'''

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x399
| 1
| Memory type (00 = Base, 01 = Application, 02 = System)
|}

CIA

2012-10-06T23:40:36Z

Xcution:

[[Category:File formats]]
=== Overview ===
CIA stands for '''C'''TR '''I'''mportable '''A'''rchive. This format allows the installation titles to the 3DS. CIA files can compile [[NCCH]] files for installation to either the SDMC or CTR NAND. CIA files can also compile .SRL files (format for DS(i) executable images) for installation to the TWL NAND of the 3DS.

An example .CIA can be downloaded [http://depositfiles.com/files/t93cpkb2g here] Credit: [[User:Jl12|Jl12]]. It includes a .cia file, the result of installation, some screenshots. Also I've decrypted/extracted everything, for those people who can't be bothered using ctrtool ;)

[[Download Play]] utilises the CIA format when transferring titles.(This is also the only known retail implementation of the CIA format)

Development Units, are capable of manually installing CIA files via the [[3DS Development Unit Software#Dev Menu|Dev Menu]]

=== Format ===
The CIA format has a similar structure to the [http://wiibrew.org/wiki/Wad WAD format].

The file is represented in little-endian.

The data is aligned in 64 byte blocks (if a content ends at the middle of the block, the next content will begin from a new block).

The CIA format is capable of containing more then one NCCH in the APP data, the TMD specifies the size of each NCCH contained in the APP data. Generally it will only contain additional NCCH files (.[[NCCH#CFA|CFA]] format, such as the Manual and DLP Child) related to the main executable NCCH (.[[NCCH#CXI|CXI]] format). The CIA format could be interpreted as an installable variant of the [[NCSD|CCI]] format.

== CIA Header ==

This is a 32 bytes long header (8 x uint32).

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x04
| Archive Header Size (=0x2020 bytes) (Starts with 0x80 @ offset 0x0020)
|-
| 0x04
| 0x02
| Type
|-
| 0x06
| 0x02
| Version
|-
| 0x08
| 0x04
| Certificate chain size
|-
| 0x0C
| 0x04
| Ticket size
|-
| 0x10
| 0x04
| [[TMD]] file size
|-
| 0x14
| 0x04
| Meta size (0 if no Meta data is present)
|-
| 0x18
| 0x04
| APP file size
|-
| 0x1C
| 0x04
| 0x80000000
|}

The order of the sections in the CIA file:
* certificate chain
* Ticket
* TMD file data
* APP file data
* Meta file data

The APP data (NCCH/SRL) is encrypted, using 128-bit AES-CBC. The encryption uses the decrypted titlekey of the ticket, and the titleid padded with zeros as the IV. To get the decrypted titlekey, the titlekey stored in the ticket must be decrypted using 128-bit AES-CBC with the 3DS common key, and the same IV as mentioned previously.

== Meta ==

The structure of this data is as follows:

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x180
| Title ID dependency list - From the application's ExHeader
|-
| 0x180
| 0x280
| Reserved/Unused
|-
| 0x400
| 0x36C0
| [[SMDH|Icon Data]](.ICN) - From the application's [[ExeFS]]
|}

Obviously this section is not present in TWL CIA files.

== Title Key Encryption ==

The unencrypted Title Key is used to encrypt the data in a CIA. The encrypted Title Key of a CIA can be found at offset 0x1BF in a CIA's Ticket.
Each Title Key is encrypted with AES-CBC to get the encrypted Title Key.

To encrypt an unencrypted title key, you need:

* Common key (as byte array)
* Title ID (as ulong)
* (and of course the unencrypted title key you want to encrypt) (as byte array)

The title key encryption process starts by converting the ulong (Title ID) into a byte array using by retrieving the bytes of the Title ID using BitConverter.GetBytes().
If the converted bytes (title ID) are in Little Endian, reverse those bytes. (in C# it would be Array.Reverse(byte_array_from_bitconverter))
This process makes the Title Key encryption IV.

Next, after you've gotten your Title Key's IV, you can start your cryptography transformation. Using AESManaged, where:

Key = Common Key

IV = the byte array found in the conversion process above

Mode = CipherMode.CBC

Create the encryptor (AesManaged.CreateEncryptor(key, iv)) where the key and IV are both the same as above.

Then, create a CryptoStream and a MemoryStream. The Crypto stream should start with the arguments (memorystream, aes_transform_from_above, CryptoStreamMode.Write).

Write to the CryptoStream where buffer=unencrypted_titlekey, offset=0, and count=the length of the unencrypted title key.

Use FlushFinalBlock() on the CryptoStream.

Finally, then, the encrypted title key will be available from your memory
stream. (to output the calculated encrypted title key as a byte array, you can use memorystream.ToArray(), for example)

Example function: (C#)

<pre>
public static byte[] EncryptMyTitleKey(byte[] commonKey, byte[] titleKey, ulong titleId)
{
// Make encryption IV
byte[] titleidasbytes = new byte[0x10];
for (int i = 0; i < 0x10; i++)
{
titleidasbytes[i] = 0;
}
byte[] bitBytes = BitConverter.GetBytes(titleId);
if (BitConverter.IsLittleEndian)
{
Array.Reverse(bitBytes);
}
bitBytes.CopyTo(titleidasbytes, 0);
// Encrypt
ICryptoTransform transform = new AesManaged { Key = commonKey, IV = titleidasbytes, Mode = CipherMode.CBC }.CreateEncryptor(commonKey, titleidasbytes);
MemoryStream memstream = new MemoryStream();
CryptoStream cryptostream = new CryptoStream(memstream, transform, CryptoStreamMode.Write);
cryptostream.Write(titleKey, 0, titleKey.Length);
cryptostream.FlushFinalBlock();
return memstream.ToArray();
}
</pre>