- 3ds Simple Cia Converter Exheader Decryption Failed Download
- 3ds Simple Cia Converter Exheader Decryption Failed Version
- 3ds Simple Cia Converter Exheader Decryption Failed Windows 10
- 3ds Simple Cia Converter Exheader Decryption Failed Disk
3ds to CIA converter this tool. It's extremely simple as well as does not use Python or.NET Structure or any other programs and also scripts, just my very own code in a solitary exe file. Py2exe support for building a single.exe for Windows; Other small fixes; The 3dsconv.exe in this release includes all the necessary libraries and a Python interpreter, so it should be usable on 64-bit Windows without Python installed. It may not work on 32-bit without manually building the executable. Makecia is still required (on Windows, this can be in the same folder as 3dsconv.exe). CIA Decryptor (deep): Use this to fully decrypt all CIA files in the folder. This also processes the internal NCCH encryption. Deep decryption of a CIA file is otherwise known as cryptofixing. This also may need additional key files and / or seeddb.bin, see 'Support files' above. Tool to convert decrypted 3ds files to cia. Addeddate 2019-03-05 15:42:56 Identifier Decrypted3DSRomToCIA Scanner Internet Archive HTML5 Uploader 1.6.4.
Permalink Go to file- Copy path
| 3DS Simple CIA Converter by RikuKH3 |
| ----------------------------------- |
| After looking at how unnecessarily complicated current CIA converting methods are, I decided to write |
| this tool. It's very simple and doesn't use Python or .NET Framework or any other programs and scripts, |
| just my own code. |
| I decided to take slightly different approach to keep things simple and only use ExHeader XORpads. They are |
| 1MB each in size and multiple ROM files supported during 'ncchinfo.bin' creation, so you can make xorpads for a |
| bunch of games in one go. With version 4.0 I added ability to patch minimum required kernel version (FW Spoof) |
| and 'RegionFree', which requires *.exefs_norm.xorpad's. 'FW Spoof' function checks FW version game requires to |
| run and only applied if original value exceeds entered (2D02:FW8.0-8.1, 2E02:FW9.0-9.2, 3002:FW9.3, 3102:FW9.5, 3202:FW9.6-9.8). |
| 1) Put your 3DS games into 'roms' folder and press 'Create ncchinfo.bin file' button to create 'ncchinfo.bin' |
| from 3DS ROMs. |
| 2) Use rxTools along with created 'ncchinfo.bin' to generate ExHeader XORpads, put it in root of SD card, |
| launch rxTools and follow 'Decryption Options-->Generate Xorpads'. At the end of process you may see |
| 'Could not open SDinfo.bin!' message. It's okay, just ignore it. |
| 3) Put *.xorpad files you generated on 3DS from SD root into 'xorpads' folder, press 'Convert 3DS ROM to CIA' |
| button, select folder with *.3ds files and wait for program to finish. |
| Version 4.3, 2015-07-03 |
| ----------------------- |
| - Added zero-key encrypted ROM support, no xorpad required. |
| - Added error skip so program doesn't stop converting remain files. |
| - Added application Major version writing into TMD. |
| Version 4.0, 2015-06-28 |
| ----------------------- |
| - Added Download Play support. |
| - Added input 3DS ROM folder selection dialog. |
| - Added searching for *.3ds|*.3dz files in subfolders. |
| - Improved partition type detection. |
| - Improved 'FW Spoof' function. |
| - Set RegionFree to default without ability to disable it. |
| - Code cleanup and minor optimizations. |
- Copy lines
- Copy permalink
The following text tries to document the structure of the NCCH (Nintendo Content Container Header) container format. This format is used to store the content of any installed title.
3ds Simple Cia Converter Exheader Decryption Failed Download
- 1Overview
- 2Container File Format
- 2.4NCCH Flags
Overview[edit]
There are two known NCCH container specializations used on the 3DS, 'executable' and 'non-executable', officially known as CXI and CFA, respectively.
CXI[edit]
The CXI (CTR Executable Image) specialization of the NCCH container contains executable code, which runs on a single ARM11 core.
The CXI format is structured in the following order:
- first a NCCH header,
- followed by an extended header,
- followed by an access descriptor,
- followed by an optional plain binary region,
- followed by an optional executable filesystem (ExeFS) - (contains ARM11 code, Home menu icn/bnr and logo),
- and finally followed by an optional 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.
3ds Simple Cia Converter Exheader Decryption Failed Version
CFA[edit]
The CFA (CTR File Archive) specialization of the NCCH container is not executable, but is used in conjunction with CXI files, e.g. 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 System Data Archive titles and are found only in the NAND.
3ds Simple Cia Converter Exheader Decryption Failed Windows 10
CFA files are structured in the following order:
- first a NCCH header,
- followed by an optional executable filesystem (ExeFS) (same as in CXI, except no ARM11 code)
- followed by an optional read-only filesystem (RomFS)
Container File Format[edit]
Encryption[edit]
The extended header, the ExeFS, and the RomFS are encrypted using 128-bit AES CTR unless the NoCrypto flag is set in ncchflag[7]. There are different sets of encryption parameters in use, as over the time new system updates introduced more sophisticated means of encryption.
All encrypted regions are grouped into two categories, each of which uses one kind of encryption scheme:
- The 'menu info' group, including the extended header, the ExeFS header, and the files 'icon' and 'banner' in ExeFS, which are needed to display the game on the menu regardless whether system version supports the game, or whether the pre-downloaded eshop game is officially released.
- The 'content' group, including the rest files ('.code' and '.firm') in ExeFS, and the entire RomFS, which is needed for actually running the game, and which can be only decrypted on the supported system (and when the seed is officially released for eshop games).
The decryption key is generated using the AES Engine. The keyX and keyY for each group are set as follows:
- The 'menu info' group uses the primary key, always generated by keyX in the slot 0x2C (set by bootrom) and keyY from the first 0x10 bytes of the NCCH signature.
- The 'content' group uses the secondary key. The slot selection for keyX depends on ncchflag[3], as listed in the table below.
3ds Simple Cia Converter Exheader Decryption Failed Disk
| ncchflag[3] | FW Introduced | Old3DS | AES Keyslots | Notes |
|---|---|---|---|---|
| 0x00 | The initial version | Yes | 0x2C | This keyslot is initialized by bootrom. This is the same key as the primary key. |
| 0x01 | 7.0.0-X | Yes | 0x25 | This keyslot is initialized by the 6.0 gamecard savegame keyY init function during boot, using a different portion of the final hash (this keyslot is separate from the one used for the 6.0 save crypto). |
| 0x0A | 9.3.0-X | No | 0x18 | This keyslot is initialized by arm9loader on New3DS starting with 8.1.0-0_New3DS, but only 9.3.0-X and later know how to use it with ncchflag[3]. |
| 0x0B | 9.6.0-X | No | 0x1B | 9.6.0-X's arm9loader changed the contents of keyslots 0x19-0x1F; 9.6.0-X was the first time they were officially used, so this is not a breaking change (there is no content that would use the old versions of those keys). |
Besides all rules above, if ncchflag[7] bitmask 0x1 is set, and a fixed AES key instead is used for both groups. There are two fixed keys, one for titles which have the system category bit set (SystemFixedKey), and one for the rest ('zeros' key). These are debug keys, as they aren't nomally supported on retail systems.
The initial CTR for decryption each region is generated from the partition ID, as described below:
- if the version field (NCCH header + 0x112) is 0 or 2, the 16-byte CTR is [partition_id[7], partition_id[6], ..., partition_id[0], M, 0, ..., 0], where
- The 8-byte partition ID starts from the beginning in the reverse order. If the partition ID is viewed as a little-endian u64, and the CTR is viewed as big-endian u128, then this is to put the partition ID to the most significant bits of the CTR
- CTR[8] is set to a magic number M. For extended header, M = 1. For ExeFS, M = 2. For RomFS, M = 3.
- The rest 7 bytes (the least significant bits of big-endian CTR) are set to zero
- if the version field is 1, the 16-byte CTR is [partition_id[0], partition_id[1], ...,partition_id[7], 0, 0, 0, 0, T[0], T[1], T[2], T[3]], where
- The 8-byte partition ID starts from the beginning in the same order.
- Then four zeros follow.
- Then a number T in big-endian follows. This number is the offset of each encrypted region to the NCCH beginning. So for extended header, T = 0x200. For ExeFS/RomFS. T = 0x200 * ExeFS/RomFS offset in media units
Note that due to the key generation schemes described above, ExeFS can contain regions using different keys. Regardless of this, both regions shared the same initial CTR at the beginning of ExeFS. If one region doesn't start at the beginning of ExeFS, its actual CTR at its own beginning = ExeFS CTR + (region offset / AESBlockSize=16)
Format[edit]
Currently, only ExeFS:/.code can be compressed (with a LZ77 variant). A flag in the exheader determines if this is the case.
On retail for SD applications, exheader_systeminfoflags.flag bit1 must be set.
Retail CFAs use the default NCCH product code 'CTR-P-CTAP', while retail title/gamecard CXIs use NCCH product code 'CTR-X-XXXX'. This product code is the NCCH serial code. The region-locking info checked by home menu is stored in the icon.
All of the hashes stored in this NCCH header are over the cleartext data. The ExeFS/RomFS superblock starts at offset 0x0 in the ExeFS/RomFS, and the size is specified by the hash region fields. Nintendo's NCCH validation code seems to have the size of this region fixed to 0x200 bytes (for ExeFS at least).
As of 5.0.0-11 the application ExeFS:/logo can be loaded from the plaintext region between the access descriptor and the plain region, all applications built since 5.0.0-11 store the logo here. The size of this logo is always 0x2000-bytes.
The plain region mainly contains tags for each SDK library used when building the CXI. The version used for the 'FIRMWARE' tag is the kernel/FIRM version, this version can also be stored in the exheader 'kernel release version' ARM11 kernel descriptor field. As of 2.2.0-X the NATIVE_FIRM kernels check the CXI exheader 'kernel release version' field, if it is stored in the CXI exheader. If the kernel/FIRM version specified by this field is higher than the version of the running NATIVE_FIRM, the kernel will return error-code 0xD9001413.
NCCH Header[edit]
| 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 | When ncchflag[7] = 0x20 starting with FIRM 9.6.0-X, this is compared with the first output u32 from a SHA256 hash. The data used for that hash is 0x18-bytes: <0x10-long title-unique content lock seed> . This hash is only used for verification of the content lock seed, and is not the actual keyY. |
| 0x118 | 8 | Program ID |
| 0x120 | 0x10 | Reserved |
| 0x130 | 0x20 | Logo Region SHA-256 hash. (For applications built with SDK 5+) (Supported from firmware: 5.0.0-11) |
| 0x150 | 0x10 | Product code |
| 0x160 | 0x20 | Extended header SHA-256 hash (SHA256 of 2x Alignment Size, beginning at 0x0 of ExHeader) |
| 0x180 | 4 | Extended header size, in bytes |
| 0x184 | 4 | Reserved |
| 0x188 | 8 | Flags (See Below) |
| 0x190 | 4 | Plain region offset, in media units |
| 0x194 | 4 | Plain region size, in media units |
| 0x198 | 4 | Logo Region offset, in media units (For applications built with SDK 5+) (Supported from firmware: 5.0.0-11) |
| 0x19c | 4 | Logo Region size, in media units (For applications built with SDK 5+) (Supported from firmware: 5.0.0-11) |
| 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 SHA-256 hash - (SHA-256 hash, starting at 0x0 of the ExeFS over the number of media units specified in the ExeFS hash region size) |
| 0x1E0 | 0x20 | RomFS superblock SHA-256 hash - (SHA-256 hash, starting at 0x0 of the RomFS over the number of media units specified in the RomFS hash region size) |
Given offsets are based on the start of the file.
NCCH Flags[edit]
| INDEX | DESCRIPTION |
|---|---|
| 3 | Crypto Method: When this is non-zero, a NCCH crypto method using two keyslots is used(see above). |
| 4 | Content Platform: 1 = CTR, 2 = snake (New 3DS). |
| 5 | Content Type Bit-masks: Data = 0x1, Executable = 0x2, SystemUpdate = 0x4, Manual = 0x8, Child = (0x4|0x8), Trial = 0x10. When 'Data' is set, but not 'Executable', NCCH is a CFA. Otherwise when 'Executable' is set, NCCH is a CXI. |
| 6 | Content Unit Size i.e. u32 ContentUnitSize = 0x200*2^flags[6]; |
| 7 | Bit-masks: FixedCryptoKey = 0x1, NoMountRomFs = 0x2, NoCrypto = 0x4, using a new keyY generator = 0x20(starting with FIRM 9.6.0-X). |
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[edit]
Plain region example for Lego Starwars III[edit]
Example dependency list from the extended header[edit]
Tools[edit]
ctrtool - (CMD)(Windows/Linux) Parsing and decrypting (debug only) NCCH files
