Difference between revisions of "CCI"
m (→NCSD header: flag for manual) |
|||
| Line 78: | Line 78: | ||
|- | |- | ||
| 0x320 | | 0x320 | ||
| − | | | + | | 8 |
| − | | | + | | Loader Title ID |
| + | |- | ||
| + | | 0x328 | ||
| + | | 8 | ||
| + | | Loader Title Version | ||
|} | |} | ||
| Line 85: | Line 89: | ||
CCI images may not include all three NCCH blocks. For example, Ghost Recon: Shadow Wars lacks the second NCCH. Entries at 0x130, 0x134 and 0x1A0 in its NCSD header are zero. | CCI images may not include all three NCCH blocks. For example, Ghost Recon: Shadow Wars lacks the second NCCH. Entries at 0x130, 0x134 and 0x1A0 in its NCSD header are zero. | ||
| + | |||
| + | = CXI Table Theory = | ||
| + | |||
| + | The 3 CXIs appear in some order. | ||
| + | |||
| + | if you take offset 0x120 and look at it as a table of {uint32 offset, uint32 length} it might be the CXI table | ||
| + | |||
| + | and at 0x190 starting the title_id table {uint64 title_id} of the same size as the table before. | ||
| + | |||
| + | Each CXI's information is on the same index on both tables... | ||
| + | |||
| + | In this method of reading CCIs can hold up to 13 CXIs. | ||
Revision as of 17:39, 19 December 2011
This document is about the format of CTR cart images (CCI), which is also the format of 3DS ROM dumps.
Overview
CCI files start with a NCSD header, followed by up to a maximum of 8 NCCH blocks according to spec. The first block usually starts at 0x4000. In most carts the first block contains game code/data, the second block contains the download play "child" and the third block contains potential system updates. The exact contents of NCCH blocks can be determined by looking at the flags.
The NCCH blocks are in the same format as CXI files.
NCSD header
| OFFSET | SIZE | DESCRIPTION |
|---|---|---|
| 0x000 | 0x100 | RSA-2048 signature of the NCSD header, using SHA-256 (needs to be confirmed) |
| 0x100 | 4 | Magic ID, always 'NCSD' |
| 0x104 | 4 | Size of the CCI image, in media units (1 media unit = 0x200 bytes) |
| 0x108 | 8 | Title/Program ID |
| 0x120 | 4 | Offset to the first NCCH in media units |
| 0x124 | 4 | Size of the first NCCH |
| 0x130 | 4 | Offset to the second NCCH |
| 0x134 | 4 | Size of the second NCCH |
| 0x158 | 4 | Offset to the third NCCH |
| 0x15C | 4 | Size of the third NCCH |
| 0x188 | 8 | NCCH Flags: byte[5]-byte[7] indicate content type ( system update, application, manual, ... ) size of media units ( 512*2^byte[6] ) and encryption. |
| 0x190 | 8 | Partition ID of the first NCCH |
| 0x1A0 | 8 | Partition ID of the second NCCH |
| 0x1C8 | 8 | Partition ID of the third NCCH |
| 0x200 | 4 | Always 0xFFFFFFFF |
| 0x300 | 4 | Used ROM size in bytes |
| 0x320 | 8 | Loader Title ID |
| 0x328 | 8 | Loader Title Version |
Parts of the first NCCH block's header are found around 0x1000 for whatever reason.
CCI images may not include all three NCCH blocks. For example, Ghost Recon: Shadow Wars lacks the second NCCH. Entries at 0x130, 0x134 and 0x1A0 in its NCSD header are zero.
CXI Table Theory
The 3 CXIs appear in some order.
if you take offset 0x120 and look at it as a table of {uint32 offset, uint32 length} it might be the CXI table
and at 0x190 starting the title_id table {uint64 title_id} of the same size as the table before.
Each CXI's information is on the same index on both tables...
In this method of reading CCIs can hold up to 13 CXIs.