https://www.3dbrew.org/w/api.php?action=feedcontributions&user=Vappy&feedformat=atom3dbrew - User contributions [en]2024-03-28T17:32:49ZUser contributionsMediaWiki 1.35.8https://www.3dbrew.org/w/index.php?title=NAND_Redirection&diff=15290NAND Redirection2016-01-14T12:06:21Z<p>Vappy: </p>
<hr />
<div>NAND redirection is an umbrella term for methods used to redirect [[Flash_Filesystem|NAND]] reads and writes from the actual system storage (in this context called sysNAND) to the SD card (or technically, any other data source). Among other things, this allows for accessing more recent (in some cases fully updated) system versions (installed on the redirection source) while keeping access to full-control exploits (through the old system installed on sysNAND).<br />
<br />
=== General Idea ===<br />
<br />
The SD filesystem, being a FAT32 partition, can be shrinked and relocated easily. As such, it is easy to make room on the SD card for a full NAND image. By not listing the NAND image partition in the SD card's Master Boot Record (the first 512 bytes of data on the device which is responsible for providing information on the contained filesystems), the NAND image does not interfere with regular SD card access. The actual redirection needs to be done through use of a [[FIRM|firmware]] modification depending on the location of the NAND image on the SD card. Two common approaches for this are known as EmuNAND and RedNAND, albeit these terms are sometimes also used as synonyms for the concept of NAND redirection in general.<br />
<br />
=== RedNAND ===<br />
<br />
RedNAND places the full NAND image at byte offset 512 on the SD card. The modified firmware hence needs to offset all NAND reads and writes by 512 bytes.<br />
<br />
=== EmuNAND ===<br />
<br />
Calling the NAND image size N, EmuNAND places bytes [512:N-1] of the NAND image at byte offset 512 on the SD card, and bytes [0:511] at byte offset N. The modified firmware needs to make sure that NAND reads/writes to the first 512 bytes are redirected properly, but leaves all other accesses unmodified.<br />
<br />
=== Restrictions on New 3DS ===<br />
<br />
If the sysNAND of a New 3DS console is below system version 9.6, it is not possible to have NAND redirection work with a redirected NAND of any system version since 9.6 without first [[3DS_System_Flaws#arm9loader|obtaining the relevant keys]]. This is because the [[AES|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers|OTP data]] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.</div>Vappyhttps://www.3dbrew.org/w/index.php?title=Title_metadata&diff=12847Title metadata2015-06-19T15:20:15Z<p>Vappy: </p>
<hr />
<div>[[Category:File formats]]<br />
'''Title metadata''' is a format used to store information about a title (installed title, DLC, etc.) and all its installed contents, including which contents they consist of and their SHA256 hashes.<br />
<br />
[https://bitbucket.org/trap15/3dshax Code is available] by trap15 to parse the available information from the 3DS format of TMDs.<br />
<br />
== Structure ==<br />
<br />
All the data in the file represented in Big Endian. <br />
<br />
{| class="wikitable"<br />
| align="center" style="background:#f0f0f0;"|'''Offset'''<br />
| align="center" style="background:#f0f0f0;"|'''Size'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
|-<br />
| 0x0||Y||Signature Data<br />
|-<br />
| Y ||0xC4||Header<br />
|-<br />
| 0xC4 + Y||0x24*64||Content Info Records.<br />
|-<br />
| 0x9C4 + Y||0x30*ContentCount||Content Chunk Records.<br />
|}<br />
<br />
Y denotes the total size of the "Signature Data" section and depends on the signature type.<br />
<br />
=== Signature Data ===<br />
The signature is of the header of the TMD.<br />
{| class="wikitable"<br />
| align="center" style="background:#f0f0f0;"|'''Offset'''<br />
| align="center" style="background:#f0f0f0;"|'''Size'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
|-<br />
| 0x0||0x4||Signature Type<br />
|-<br />
| 0x4 ||X||Signature<br />
|-<br />
| 0x4 + X|| ||Padding Aligning the signature data to 0x40 bytes<br />
|}<br />
<br />
==== Signature Type ====<br />
{{Signature Types}}<br />
The hash for the signature, is calculated over the header of the TMD<br />
<br />
=== Header ===<br />
<br />
{| class="wikitable"<br />
| align="center" style="background:#f0f0f0;"|'''Offset'''<br />
| align="center" style="background:#f0f0f0;"|'''Size'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
|-<br />
| 0x0||0x40||Signature Issuer<br />
|-<br />
| 0x40||0x1||Version<br />
|-<br />
| 0x41||0x1||ca_crl_version<br />
|-<br />
| 0x42||0x1||signer_crl_version <br />
|-<br />
| 0x43||0x1||Reserved<br />
|-<br />
| 0x44||0x8||System Version<br />
|-<br />
| 0x4C||0x8||Title ID<br />
|-<br />
| 0x54||0x4||Title Type<br />
|-<br />
| 0x58||0x2||Group ID<br />
|-<br />
| 0x5A||0x4||Save Data Size (Bytes) (Also SRL Public Save Data Size)<br />
|-<br />
| 0x5E||0x4||SRL Private Save Data Size (Bytes)<br />
|-<br />
| 0x62||0x4||Reserved<br />
|-<br />
| 0x66||0x1||SRL Flag<br />
|-<br />
| 0x67||0x31||Reserved<br />
|-<br />
| 0x98||0x4||Access Rights<br />
|-<br />
| 0x9C||0x2||Title Version<br />
|-<br />
| 0x9E||0x02||Content Count<br />
|-<br />
| 0xA0||0x2||Boot Content<br />
|-<br />
| 0xA2||0x2||Padding<br />
|-<br />
| 0xA4||0x20||SHA-256 Hash of the Content Info Records<br />
|}<br />
<br />
=== Content Info Records ===<br />
<br />
There are 64 of these records, usually only the first is used.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x00<br />
| 2<br />
| Content index offset<br />
|-<br />
| 0x02<br />
| 2<br />
| Content command count [k]<br />
|-<br />
| 0x04<br />
| 0x20<br />
| SHA-256 hash of the next k content records that have not been hashed yet<br />
|}<br />
<br />
=== Content chunk records ===<br />
There is one of these for each content contained in this title. (Determined by "Content Count" in the TMD Header).<br />
<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Content id<br />
|-<br />
| 0x04<br />
| 2<br />
| Content index<br />
|-<br />
| 0x06<br />
| 2<br />
| Content type<br />
|-<br />
| 0x08<br />
| 8<br />
| Content size<br />
|-<br />
| 0x10<br />
| 0x20<br />
| SHA-256 hash<br />
|}<br />
==== Content Index ====<br />
<br />
This indicates the content type:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index<br />
! Content Type<br />
|-<br />
| 0000<br />
| Main Content (.[[NCCH#CXI|CXI]] for 3DS executable content/.[[NCCH#CFA|CFA]] for 3DS Data Archives/.SRL for TWL content)<br />
|-<br />
| 0001<br />
| Home Menu Manual (.[[NCCH#CFA|CFA]])<br />
|-<br />
| 0002<br />
| DLP Child Container (.[[NCCH#CFA|CFA]])<br />
|}<br />
<br />
This does not apply to DLC.<br />
<br />
==== Content Type flags ====<br />
{| class="wikitable"<br />
|-<br />
! Flags<br />
! Description<br />
|-<br />
| 1<br />
| Encrypted<br />
|-<br />
| 2<br />
| Disc<br />
|-<br />
| 4<br />
| CFM (abbreviation for?)<br />
|-<br />
| 0x4000<br />
| Optional<br />
|-<br />
| 0x8000<br />
| Shared<br />
|}<br />
<br />
== Certificate Chain ==<br />
If the TMD file is obtained from Nintendo's CDN, then it will have two [[Certificates|certificates]] appended at the end of the file:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! CERTIFICATE<br />
! SIGNATURE TYPE<br />
! RETAIL CERT NAME<br />
! DEBUG CERT NAME<br />
! DESCRIPTION<br />
|-<br />
| TMD<br />
| RSA-2048<br />
| CP0000000b<br />
| CP0000000a<br />
| Used to verify the TMD signature<br />
|-<br />
| CA<br />
| RSA-4096<br />
| CA00000003<br />
| CA00000004<br />
| Used to verify the TMD Certificate<br />
|}<br />
<br />
The CA certificate is issued by 'Root', the public key for which is stored in NATIVE_FIRM.<br />
<br />
== Example code application ==<br />
<source lang="c"><br />
enum sig_type {<br />
RSA_2048_SHA256 = 0x00010004,<br />
RSA_4096_SHA256 = 0x00010003,<br />
RSA_2048_SHA1 = 0x00010001,<br />
RSA_4096_SHA1 = 0x00010000<br />
};<br />
<br />
// Sorry I removed the example struct because it is wrong.<br />
</source></div>Vappyhttps://www.3dbrew.org/w/index.php?title=Makerom&diff=10883Makerom2014-11-27T09:53:44Z<p>Vappy: Updating links</p>
<hr />
<div>{{Infobox homebrew<br />
| title = makerom<br />
| type = pc utility<br />
| author = [[User:3dsguy|3dsguy]]<br />
| download = https://anonfiles.com/file/865643f366d17771aa907d467f00826f<br />
| source = https://github.com/profi200/Project_CTR/tree/master/makerom<br />
| version = 0.13<br />
}}<br />
<br />
makerom is a tool which can be used to create [[NCCH]], [[NCSD|CCI]], and [[CIA]] files.<br />
<br />
== Format Overviews ==<br />
=== NCCH ===<br />
The native format storing code binaries and data archives for the 3DS is [[NCCH]]. [[NCCH]] files are comprised of:<br />
* code/exheader/plainregion (used for code execution) (plainregion just lists included SDK library add-ons)<br />
* icon (app title text, icon, homemenu settings, see [[SMDH|here]]<br />
* banner (cbmd + cwav, i.e. the upper screen banner/sound shown on the homemenu)<br />
* logo (the splash screen displayed after an application is launched from the homemenu)<br />
* romfs (read-only filesystem used to store resources)<br />
<br />
Typical uses for NCCH files include:<br />
* Executable image (code+exheader+icon+banner+logo+romfs)<br />
* e-Manual archive (accessed from homemenu) (romfs)<br />
* [[Download Play|DLP]] child CIA archive (accessed from application) (romfs)<br />
* Update Data archive (romfs)<br />
* Standalone data archive (romfs)<br />
* DLC index archive (icon+romfs)<br />
* DLC archive (romfs)<br />
<br />
=== CCI ===<br />
The native format for gamecard images is [[NCSD|CCI]] and is a NCCH container format. CCI files are limited to containing 8 NCCH files, and can contain NCCH files for applications titles only.<br />
==== NCCH configuration for CCI ====<br />
{| class="wikitable"<br />
|-<br />
! NCCH<br />
! Required<br />
! Index<br />
|-<br />
| Executable image<br />
| YES<br />
| 0<br />
|-<br />
| e-Manual archive<br />
| NO<br />
| 1<br />
|-<br />
| DLP child CIA archive<br />
| NO<br />
| 2<br />
|-<br />
| Update Data archive<br />
| NO<br />
| 7<br />
|}<br />
<br />
=== CIA ===<br />
The native format for packaging NCCH files for install is [[CIA]], which is also a NCCH container format. CIA files are limited to containing 65535 NCCH files and can be used to contain NCCH files for any title type. CIA files also contain data used by the 3DS for general title management and DRM. Installing custom CIA files on a 3DS which also uses eShop/SysUpdates is unwise as conflicts will likely occur.<br />
<br />
==== NCCH configurations for CIA ====<br />
Applications (Application/DlpChild/Demo/Patch/SystemApplication):<br />
{| class="wikitable"<br />
|-<br />
! NCCH<br />
! Required<br />
! Index<br />
|-<br />
| Executable image<br />
| YES<br />
| 0<br />
|-<br />
| e-Manual archive<br />
| NO<br />
| 1<br />
|-<br />
| DLP child CIA archive<br />
| NO<br />
| 2<br />
|}<br />
<br />
System Applet/Module:<br />
{| class="wikitable"<br />
|-<br />
! NCCH<br />
! Required<br />
! Index<br />
|-<br />
| Executable image<br />
| YES<br />
| 0<br />
|}<br />
<br />
System Data Archives:<br />
{| class="wikitable"<br />
|-<br />
! NCCH<br />
! Required<br />
! Index<br />
|-<br />
| Data archive<br />
| YES<br />
| 0<br />
|}<br />
<br />
DLC:<br />
<br />
The number of DLC data archives in DLC varies for each DLC.<br />
{| class="wikitable"<br />
|-<br />
! NCCH<br />
! Required<br />
! Index<br />
|-<br />
| DLC index archive<br />
| YES<br />
| 0<br />
|-<br />
| DLC data archive<br />
| YES<br />
| Varies<br />
|}<br />
<br />
== Using Makerom ==<br />
<br />
=== Command line ===<br />
Since CCI and CIA are NCCH containers, makerom was built so CXIs could be built stand alone or straight into a container format. It is also possible rebuild CXIs from an ELF file. As a result there are many combinations which can be used; for simplicity, specific functions will be explained by breaking them up into argument groups:<br />
<br />
'''Creating CXIs from scratch:'''<br />
-elf <elf path> -rsf <rsf path> [-icon <[[SMDH|icon]] path> -banner <banner path>]<br />
<br />
'''Rebuilding CXIs:'''<br />
-code <decompressed exefs .code> -exheader <exheader from original CXI> -rsf <rsf path> [-icon <[[SMDH|icon]] path> -banner <banner path> -romfs <cleartext romfs binary>]<br />
<br />
'''Creating CFAs:'''<br />
-f cfa -rsf <rsf path> [-icon <[[SMDH|icon]] path> -romfs <romfs binary>]<br />
<br />
'''Creating CCIs:'''<br />
-f cci [-content <path>:<index> ...]<br />
<br />
'''Creating CIAs:'''<br />
-f cia [-content <path>:<index>:<id> ...]<br />
<br />
'''Using Desc presets:'''<br />
-desc <app type>:<firm version><br />
<br />
* 'app type' can be SDApp / ECApp / Demo / DlpChild<br />
* 'firm version' is the target kernel version minor for the intended 3DS system.<br />
<br />
'''Examples:'''<br />
Create a CCI, using a manual CFA, and a desc preset:<br />
makerom -f cci -elf homebrew.elf -rsf app.rsf -desc sdapp:33 -icon homebrew.icn -banner homebrew.bnr -content manual.cfa:1 -o homebrew.cci<br />
<br />
Create a CIA using an already built application CXI and manual CFA:<br />
makerom -f cia -content homebrew.cxi:0:0 -content manual.cfa:1:1 -o homebrew.cia<br />
<br />
Rebuild a CXI:<br />
makerom -code code.bin -exheader exheader.bin -icon icon.bin -banner banner.bin -romfs romfs.bin -rsf app.rsf -desc sdapp:33 -o rebuild.cxi<br />
<br />
<br />
=== Creating RSF files ===<br />
Inspired by Nintendo's format for their makerom, a yaml configuration file is required for creating NCCH files. CIA/CCI can be created without using a RSF file, but default settings will be used.<br />
<br />
For CXI, RSF files can be used to specify permissions, and access control settings. Makerom can use default settings by use of the "-desc" option, which removes the requirement for specifying them in the RSF file.<br />
<br />
Sample RSF to be used with "-desc": [https://gist.githubusercontent.com/3DSGuy/83e12e0ae3dcccb9827f/raw/sample0.rsf download]<br />
<br />
Sample RSF to be used without "-desc": [https://gist.githubusercontent.com/3DSGuy/83e12e0ae3dcccb9827f/raw/sample1.rsf download]<br />
<br />
=== Creating ELF files ===<br />
DevKitARM used in conjunction with [https://github.com/smealum/ctrulib ctrulib] can create ELF files compatible with makerom, provided they are linked with [https://gist.github.com/yellows8/6da7984a80a825b10294 this linker script], and striped.<br />
<br />
ELF files that are created using the official SDK are also supported by makerom. <br />
<br />
== Compiling Source ==<br />
For Windows a MinGW/MSYS build setup is required. <br />
<br />
For Linux, gcc/g++/make must be installed.<br />
<br />
All additional libraries used by makerom (polarssl/libyaml) are included in the source, and are linked statically.<br />
<br />
== Issues ==<br />
<br />
* RomFS hasn't been completely implemented (but valid pre-built RomFS can be used as substitute)</div>Vappyhttps://www.3dbrew.org/w/index.php?title=CIA&diff=10625CIA2014-11-11T05:51:29Z<p>Vappy: </p>
<hr />
<div>[[Category:File formats]]<br />
== Overview ==<br />
CIA stands for '''C'''TR '''I'''mportable '''A'''rchive. This format allows the installation titles to the 3DS. CIA files and titles on [[Title list|Nintendo's CDN]] contain identical data. As a consequence, valid CIA files can be generated from CDN content. This also means CIA files can contain anything that titles on Nintendo's CDN can contain. <br />
<br />
Under normal circumstances CIA files are used where downloading a title is impractical or not possible. Such as distributing a [[Download Play]] child, or installing forced Gamecard updates. Those CIA(s) are stored by the titles in question, in an auxiliary [[NCCH#CFA|CFA]] file.<br />
<br />
Development Units, are capable of manually installing CIA files via the [[3DS Development Unit Software#Dev Menu|Dev Menu]].<br />
<br />
== Format ==<br />
<br />
This is the current version of the CIA format, it was finalised in late 2010. (Older versions of the CIA format can be viewed on the [[Talk:CIA|Talk]] page)<br />
<br />
The CIA format has a similar structure to the [http://wiibrew.org/wiki/Wad WAD format].<br />
<br />
The file is represented in little-endian.<br />
<br />
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).<br />
<br />
=== CIA Header ===<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! START<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x00<br />
| 0x04 <br />
| Archive Header Size (Usually = 0x2020 bytes)<br />
|-<br />
| 0x04<br />
| 0x02<br />
| Type<br />
|-<br />
| 0x06<br />
| 0x02<br />
| Version<br />
|- <br />
| 0x08 <br />
| 0x04<br />
| Certificate chain size <br />
|-<br />
| 0x0C <br />
| 0x04<br />
| [[Ticket]] size<br />
|-<br />
| 0x10 <br />
| 0x04<br />
| [[TMD]] file size<br />
|-<br />
| 0x14 <br />
| 0x04<br />
| Meta size (0 if no Meta data is present)<br />
|-<br />
| 0x18 <br />
| 0x08<br />
| Content size<br />
|-<br />
| 0x20<br />
| 0x2000<br />
| Content Index<br />
|}<br />
<br />
The order of the sections in the CIA file:<br />
* certificate chain<br />
* Ticket<br />
* TMD file data<br />
* APP file data<br />
* Meta file data (Not a necessary component) <br />
<br />
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.<br />
<br />
=== Certificate Chain ===<br />
<br />
There are three [[Certificates|certificates]] in this chain:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! CERTIFICATE<br />
! SIGNATURE TYPE<br />
! RETAIL CERT NAME<br />
! DEBUG CERT NAME<br />
! DESCRIPTION<br />
|-<br />
| CA<br />
| RSA-4096<br />
| CA00000003<br />
| CA00000004<br />
| Used to verify the Ticket/TMD Certificates<br />
|-<br />
| Ticket<br />
| RSA-2048<br />
| XS0000000c<br />
| XS00000009<br />
| Used to verify the Ticket signature<br />
|-<br />
| TMD<br />
| RSA-2048<br />
| CP0000000b<br />
| CP0000000a<br />
| Used to verify the TMD signature<br />
|}<br />
<br />
The CA certificate is issued by 'Root', the public key for which is stored in NATIVE_FIRM.<br />
<br />
=== Meta ===<br />
<br />
The structure of this data is as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! START<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x00<br />
| 0x180<br />
| Title ID dependency list - Taken from the application's [[NCCH#Extended Header|ExHeader]]<br />
|-<br />
| 0x180<br />
| 0x180<br />
| Reserved<br />
|-<br />
| 0x300<br />
| 0x4<br />
| Core Version<br />
|-<br />
| 0x304<br />
| 0xFC<br />
| Reserved<br />
|-<br />
| 0x400<br />
| 0x36C0<br />
| [[SMDH|Icon Data]](.ICN) - Taken from the application's [[ExeFS]]<br />
|}<br />
<br />
Obviously this section is not present in TWL CIA files, or any other CIA file which does not contain a [[NCCH#CXI|CXI]].<br />
<br />
== Tools ==<br />
<br />
* [https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - Reading/Extraction of CIA files. This can only decrypt the title-key for development CIAs, since retail CIAs use the [[AES]] hardware key-scrambler for the common-key keyslot.<br />
<br />
* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cia make_cia] - Generating CIA files. Requires CommonKey and ticket/TMD RSA-2048 private exponents.<br />
<br />
* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cdn_cia make_cdn_cia] - (CMD)(Windows/Linux) Generates CIA files from CDN Content <br />
<br />
== Title Key Encryption ==<br />
<br />
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.<br />
Each Title Key is encrypted with AES-CBC to get the encrypted Title Key.<br />
<br />
To encrypt an unencrypted title key, you need:<br />
<br />
* Common key (as byte array)<br />
* Title ID (as ulong)<br />
* (and of course the unencrypted title key you want to encrypt) (as byte array)<br />
<br />
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().<br />
If the converted bytes (title ID) are in Little Endian, reverse those bytes. (in C# it would be Array.Reverse(byte_array_from_bitconverter))<br />
This process makes the Title Key encryption IV.<br />
<br />
Next, after you've gotten your Title Key's IV, you can start your cryptography transformation. Using AESManaged, where:<br />
<br />
Key = Common Key<br />
<br />
IV = the byte array found in the conversion process above<br />
<br />
Mode = CipherMode.CBC<br />
<br />
Create the encryptor (AesManaged.CreateEncryptor(key, iv)) where the key and IV are both the same as above.<br />
<br />
Then, create a CryptoStream and a MemoryStream. The Crypto stream should start with the arguments (memorystream, aes_transform_from_above, CryptoStreamMode.Write).<br />
<br />
Write to the CryptoStream where buffer=unencrypted_titlekey, offset=0, and count=the length of the unencrypted title key.<br />
<br />
Use FlushFinalBlock() on the CryptoStream.<br />
<br />
Finally, then, the encrypted title key will be available from your memory <br />
stream. (to output the calculated encrypted title key as a byte array, you can use memorystream.ToArray(), for example)<br />
<br />
Example function: (C#)<br />
<br />
<pre><br />
public static byte[] EncryptMyTitleKey(byte[] commonKey, byte[] titleKey, ulong titleId)<br />
{<br />
// Make encryption IV<br />
byte[] titleidasbytes = new byte[0x10];<br />
for (int i = 0; i < 0x10; i++)<br />
{<br />
titleidasbytes[i] = 0;<br />
}<br />
byte[] bitBytes = BitConverter.GetBytes(titleId);<br />
if (BitConverter.IsLittleEndian)<br />
{<br />
Array.Reverse(bitBytes);<br />
}<br />
bitBytes.CopyTo(titleidasbytes, 0);<br />
// Encrypt<br />
ICryptoTransform transform = new AesManaged { Key = commonKey, IV = titleidasbytes, Mode = CipherMode.CBC }.CreateEncryptor(commonKey, titleidasbytes);<br />
MemoryStream memstream = new MemoryStream();<br />
CryptoStream cryptostream = new CryptoStream(memstream, transform, CryptoStreamMode.Write);<br />
cryptostream.Write(titleKey, 0, titleKey.Length);<br />
cryptostream.FlushFinalBlock();<br />
return memstream.ToArray();<br />
}<br />
</pre></div>Vappyhttps://www.3dbrew.org/w/index.php?title=CIA&diff=10567CIA2014-11-10T07:07:42Z<p>Vappy: fixed a couple of links under tools</p>
<hr />
<div>[[Category:File formats]]<br />
== Overview ==<br />
CIA stands for '''C'''TR '''I'''mportable '''A'''rchive. This format allows the installation titles to the 3DS. CIA files and titles on [[Title list|Nintendo's CDN]] contain identical data. As a consequence, valid CIA files can be generated from CDN content. This also means CIA files can contain anything that titles on Nintendo's CDN can contain. <br />
<br />
Under normal circumstances CIA files are used where downloading a title is impractical or not possible. Such as distributing a [[Download Play]] child, or installing forced Gamecard updates. Those CIA(s) are stored by the titles in question, in an auxiliary [[NCCH#CFA|CFA]] file.<br />
<br />
Development Units, are capable of manually installing CIA files via the [[3DS Development Unit Software#Dev Menu|Dev Menu]].<br />
<br />
== Format ==<br />
<br />
This is the current version of the CIA format, it was finalised in late 2010. (Older versions of the CIA format can be viewed on the [[Talk:CIA|Talk]] page)<br />
<br />
The CIA format has a similar structure to the [http://wiibrew.org/wiki/Wad WAD format].<br />
<br />
The file is represented in little-endian.<br />
<br />
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).<br />
<br />
=== CIA Header ===<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! START<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x00<br />
| 0x04 <br />
| Archive Header Size (Usually = 0x2020 bytes)<br />
|-<br />
| 0x04<br />
| 0x02<br />
| Type<br />
|-<br />
| 0x06<br />
| 0x02<br />
| Version<br />
|- <br />
| 0x08 <br />
| 0x04<br />
| Certificate chain size <br />
|-<br />
| 0x0C <br />
| 0x04<br />
| [[Ticket]] size<br />
|-<br />
| 0x10 <br />
| 0x04<br />
| [[TMD]] file size<br />
|-<br />
| 0x14 <br />
| 0x04<br />
| Meta size (0 if no Meta data is present)<br />
|-<br />
| 0x18 <br />
| 0x08<br />
| Content size<br />
|-<br />
| 0x20<br />
| 0x2000<br />
| Content Index<br />
|}<br />
<br />
The order of the sections in the CIA file:<br />
* certificate chain<br />
* Ticket<br />
* TMD file data<br />
* APP file data<br />
* Meta file data (Not a necessary component) <br />
<br />
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.<br />
<br />
=== Certificate Chain ===<br />
<br />
There are three [[Certificates|certificates]] in this chain:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! CERTIFICATE<br />
! SIGNATURE TYPE<br />
! RETAIL CERT NAME<br />
! DEBUG CERT NAME<br />
! DESCRIPTION<br />
|-<br />
| CA<br />
| RSA-4096<br />
| CA00000003<br />
| CA00000004<br />
| Used to verify the Ticket/TMD Certificates<br />
|-<br />
| Ticket<br />
| RSA-2048<br />
| XS0000000c<br />
| XS00000009<br />
| Used to verify the Ticket signature<br />
|-<br />
| TMD<br />
| RSA-2048<br />
| CP0000000b<br />
| CP0000000a<br />
| Used to verify the TMD signature<br />
|}<br />
<br />
The CA certificate is issued by 'Root', the public key for which is stored in NATIVE_FIRM.<br />
<br />
=== Meta ===<br />
<br />
The structure of this data is as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! START<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x00<br />
| 0x180<br />
| Title ID dependency list - Taken from the application's [[NCCH#Extended Header|ExHeader]]<br />
|-<br />
| 0x180<br />
| 0x180<br />
| Reserved<br />
|-<br />
| 0x300<br />
| 0x4<br />
| Core Version<br />
|-<br />
| 0x304<br />
| 0xFC<br />
| Reserved<br />
|-<br />
| 0x400<br />
| 0x36C0<br />
| [[SMDH|Icon Data]](.ICN) - Taken from the application's [[ExeFS]]<br />
|}<br />
<br />
Obviously this section is not present in TWL CIA files, or any other CIA file which does not contain a [[NCCH#CXI|CXI]].<br />
<br />
== Tools ==<br />
<br />
* [https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - Reading/Extraction of CIA files. This can only decrypt the title-key for development CIAs, since retail CIAs use the [[AES]] hardware key-scrambler for the common-key keyslot.<br />
<br />
* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cia make_cia] - Generating CIA files. Requires CommonKey and ticket/TMD RSA-2048 private exponents. (link broken at the moment)<br />
<br />
* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cdn_cia make_cdn_cia] - (CMD)(Windows/Linux) Generates CIA files from CDN Content (link broken at the moment)<br />
<br />
<br />
If you have updated links or a local copy of either of the broken repositories, please edit this page or contact us. Thanks.<br />
<br />
== Title Key Encryption ==<br />
<br />
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.<br />
Each Title Key is encrypted with AES-CBC to get the encrypted Title Key.<br />
<br />
To encrypt an unencrypted title key, you need:<br />
<br />
* Common key (as byte array)<br />
* Title ID (as ulong)<br />
* (and of course the unencrypted title key you want to encrypt) (as byte array)<br />
<br />
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().<br />
If the converted bytes (title ID) are in Little Endian, reverse those bytes. (in C# it would be Array.Reverse(byte_array_from_bitconverter))<br />
This process makes the Title Key encryption IV.<br />
<br />
Next, after you've gotten your Title Key's IV, you can start your cryptography transformation. Using AESManaged, where:<br />
<br />
Key = Common Key<br />
<br />
IV = the byte array found in the conversion process above<br />
<br />
Mode = CipherMode.CBC<br />
<br />
Create the encryptor (AesManaged.CreateEncryptor(key, iv)) where the key and IV are both the same as above.<br />
<br />
Then, create a CryptoStream and a MemoryStream. The Crypto stream should start with the arguments (memorystream, aes_transform_from_above, CryptoStreamMode.Write).<br />
<br />
Write to the CryptoStream where buffer=unencrypted_titlekey, offset=0, and count=the length of the unencrypted title key.<br />
<br />
Use FlushFinalBlock() on the CryptoStream.<br />
<br />
Finally, then, the encrypted title key will be available from your memory <br />
stream. (to output the calculated encrypted title key as a byte array, you can use memorystream.ToArray(), for example)<br />
<br />
Example function: (C#)<br />
<br />
<pre><br />
public static byte[] EncryptMyTitleKey(byte[] commonKey, byte[] titleKey, ulong titleId)<br />
{<br />
// Make encryption IV<br />
byte[] titleidasbytes = new byte[0x10];<br />
for (int i = 0; i < 0x10; i++)<br />
{<br />
titleidasbytes[i] = 0;<br />
}<br />
byte[] bitBytes = BitConverter.GetBytes(titleId);<br />
if (BitConverter.IsLittleEndian)<br />
{<br />
Array.Reverse(bitBytes);<br />
}<br />
bitBytes.CopyTo(titleidasbytes, 0);<br />
// Encrypt<br />
ICryptoTransform transform = new AesManaged { Key = commonKey, IV = titleidasbytes, Mode = CipherMode.CBC }.CreateEncryptor(commonKey, titleidasbytes);<br />
MemoryStream memstream = new MemoryStream();<br />
CryptoStream cryptostream = new CryptoStream(memstream, transform, CryptoStreamMode.Write);<br />
cryptostream.Write(titleKey, 0, titleKey.Length);<br />
cryptostream.FlushFinalBlock();<br />
return memstream.ToArray();<br />
}<br />
</pre></div>Vappy