Difference between revisions of "NCA"

From Nintendo Switch Brew
Jump to navigation Jump to search
(note nca2 diff)
 
(39 intermediate revisions by 12 users not shown)
Line 1: Line 1:
 +
NCA means «Nintendo Content Archive».
 +
 
The entire raw NCAs are encrypted.
 
The entire raw NCAs are encrypted.
  
 
The only known area which is not encrypted in the raw NCA is the logo section, when the NCA includes that section. Everything else documented on this page is for the plaintext version of that data.
 
The only known area which is not encrypted in the raw NCA is the logo section, when the NCA includes that section. Everything else documented on this page is for the plaintext version of that data.
  
−
=Encryption=
+
= Encryption =
 
The first 0xC00 bytes are encrypted with AES-XTS with sector size 0x200 with a non-standard "tweak" (endianness is reversed, see [https://gist.github.com/SciresM/fe8a631d13c069bd66e9c656ab5b3f7f here]), this encrypted data is an 0x400 NCA header + an 0x200 header for each section in the section table.
 
The first 0xC00 bytes are encrypted with AES-XTS with sector size 0x200 with a non-standard "tweak" (endianness is reversed, see [https://gist.github.com/SciresM/fe8a631d13c069bd66e9c656ab5b3f7f here]), this encrypted data is an 0x400 NCA header + an 0x200 header for each section in the section table.
  
 
For pre-1.0.0 "NCA2" NCAs, the first 0x400 byte are encrypted the same way as in NCA3. However, each section header is individually encrypted as though it were sector 0, instead of the appropriate sector as in NCA3.
 
For pre-1.0.0 "NCA2" NCAs, the first 0x400 byte are encrypted the same way as in NCA3. However, each section header is individually encrypted as though it were sector 0, instead of the appropriate sector as in NCA3.
  
−
=Header=
+
= Header =
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 17: Line 19:
 
| 0x0
 
| 0x0
 
| 0x100
 
| 0x100
−
| RSA-2048 signature over the 0x200-bytes starting at offset 0x200 using fixed key.
+
| RSA-2048 signature over the header (data from 0x200 to 0x400) using a fixed key
 
|-
 
|-
 
| 0x100
 
| 0x100
 
| 0x100
 
| 0x100
−
| RSA-2048 signature over the 0x200-bytes starting at offset 0x200 using key from [[NPDM]], or zeroes if not a program.
+
| RSA-2048 signature over the header (data from 0x200 to 0x400) using a key from [[NPDM]] (or zeroes if not a program)
 
|-
 
|-
 
| 0x200
 
| 0x200
 
| 0x4
 
| 0x4
−
| Magicnum (Normally "NCA3", "NCA2" for some pre-1.0.0 NCAs)
+
| Magic "NCA3" ("NCA2", "NCA1" or "NCA0" for pre-1.0.0 NCAs)
 
|-
 
|-
 
| 0x204
 
| 0x204
 
| 0x1
 
| 0x1
−
| 0 for system NCAs. 1 for a NCA from gamecard.
+
| DistributionType (0x00 = Download, 0x01 = GameCard)
 
|-
 
|-
 
| 0x205
 
| 0x205
 
| 0x1
 
| 0x1
−
| Content Type (0=Program, 1=Meta, 2=Control, 3=Manual, 4=Data)
+
| ContentType (0x00 = Program, 0x01 = Meta, 0x02 = Control, 0x03 = Manual, 0x04 = Data, 0x05 = PublicData)
 
|-
 
|-
 
| 0x206
 
| 0x206
 
| 0x1
 
| 0x1
−
| Crypto Type. Only used stating with [[3.0.0]]. Normally 0. 2 = Crypto supported starting with [[3.0.0]].
+
| KeyGenerationOld (0x00 = [[1.0.0]], 0x01 = Unused, 0x02 = [[3.0.0]])
 
|-
 
|-
 
| 0x207
 
| 0x207
 
| 0x1
 
| 0x1
−
| Key index, must be 0-2.
+
| KeyAreaEncryptionKeyIndex (0x00 = Application, 0x01 = Ocean, 0x02 = System)
 
|-
 
|-
 
| 0x208
 
| 0x208
 
| 0x8
 
| 0x8
−
| Size of the entire NCA.
+
| ContentSize
 
|-
 
|-
 
| 0x210
 
| 0x210
 
| 0x8
 
| 0x8
−
| titleID
+
| ProgramId
 +
|-
 +
| 0x218
 +
| 0x4
 +
| ContentIndex
 
|-
 
|-
 
| 0x21C
 
| 0x21C
 
| 0x4
 
| 0x4
−
| sdk_version. byte0 is normally 0? Compared with a required minimum-value(0x000B0000). Matches this string from codebin: "FS_ACCESS: { sdk_version: {byte3}.{byte2}.{byte1}, ...".
+
| SdkAddonVersion (used in "FS_ACCESS: { sdk_version: {byte3}.{byte2}.{byte1}, ..." with byte0 set to 0 and compared with a required minimum value: 0x000B0000)
 
|-
 
|-
 
| 0x220
 
| 0x220
 
| 0x1
 
| 0x1
−
| Crypto-Type2. 0x3 = Crypto supported starting with [[3.0.1]]. 0x4 = Crypto supported starting with [[4.0.0]].
+
| KeyGeneration (0x03 = [[3.0.1]], 0x04 = [[4.0.0]], 0x05 = [[5.0.0]], 0x06 = [[6.0.0]], 0x07 = [[6.2.0]], 0x08 = [[7.0.0]], 0x09 = [[8.1.0]], 0x0A = [[9.0.0]], 0x0B = [[9.1.0]], 0x0C = [[12.1.0]], 0x0D = [[13.0.0]], 0x0E = [[14.0.0]], 0x0F = [[15.0.0]], 0x10 = [[16.0.0]], 0x11 = [[17.0.0]], 0x12 = [[18.0.0]], 0x13 = [[19.0.0]], 0xFF = Invalid)
 +
|-
 +
| 0x221
 +
| 0x1
 +
| [9.0.0+] SignatureKeyGeneration
 +
|-
 +
| 0x222
 +
| 0xE
 +
| Reserved
 
|-
 
|-
 
| 0x230
 
| 0x230
 
| 0x10
 
| 0x10
−
| Rights ID ([[Ticket]])
+
| RightsId
 
|-
 
|-
 
| 0x240
 
| 0x240
−
| 0x10*0x4(0x40)
+
| 0x10 * 4
−
| Table for each section, see below.
+
| Array of [[#FsEntry|FsEntry]]
 
|-
 
|-
 
| 0x280
 
| 0x280
−
| 0x20*0x4(0x80)
+
| 0x20 * 4
−
| Table of SHA256 hashes, over each 0x200-byte Section Header Block.
+
| Array of SHA256 hashes (over each [[#FsHeader|FsHeader]])
 
|-
 
|-
 
| 0x300
 
| 0x300
−
| 0x10*0x4(0x40)
+
| 0x10 * 4
−
| Key area
+
| EncryptedKeyArea
 
|}
 
|}
  
 +
When the above '''KeyGenerationOld''' field is 0x2 on >= v3.0, different {crypto/keydata} is used for the sections' data. With system content, this is used with every ncatype except ncatype0. The only other exception is {data-content} for the firm titles: this is required in order for older-system-versions to install it.
  
−
The header is 0x400-bytes, at NCA+0.
+
'''KeyGeneration''' 0x3 (with '''KeyGenerationOld''' set to 0x2) is used for all [[3.0.1]] sysmodules and the [[System_Version_Title]]. With [[3.0.2]], all updated titles use the crypto from [[3.0.1]] for non-ncatype0, except for firm {data-content}. In some cases various game content uses the above newer crypto as well.
−
 
 
−
When the above "Crypto Type" field is 0x2 on >=v3.0, different {crypto/keydata} is used for the sections' data. With system content, this is used with every ncatype except ncatype0. The only other exception is {data-content} for the firm titles: this is required in order for older-system-versions to install it.
 
−
 
 
−
Crypto-Type2 0x3(with the above crypto-type value) is used for all [[3.0.1]] sysmodules and the [[System_Version_Title]].
 
−
 
 
−
With [[3.0.2]], all updated titles use the crypto from [[3.0.1]] for non-ncatype0, except for firm {data-content}.
 
  
−
Note: in some cases various game content uses the above newer crypto as well.
+
'''KeyGeneration''' is always '''MasterKeyVersion''' + 1, except for generations 0 and 1 which are both version 0.
  
 
The keyindex passed to <key-generation-related code> is determined as follows:
 
The keyindex passed to <key-generation-related code> is determined as follows:
−
* Pre-[[3.0.0]]: The ncahdr keyindex field(0x207) is passed directly.
+
* Pre-[[3.0.0]]: The '''KeyAreaEncryptionKeyIndex''' field (0x207) is passed directly.
−
* [[3.0.0]]+: It's determined using ncahdr keyindex(0x207) and "Crypto Type"(0x206). The latter field must be 0-2. In each ncahdr_keyindex block, it executes "if(ncahdr_x206>=3)<panic>", but that won't trigger due to the earlier check. The end result is basically the same as pre-[[3.0.0]], except when ncahdr_x206 == 0x2, final_index is new_base_index+ncahdr_keyindex. Actual implementation loads index from u32_array[ncahdr_crypto_type], where the address of u32_array is different for each ncahdr_keyindex.
+
* [[3.0.0]]+: It's determined using the '''KeyAreaEncryptionKeyIndex''' field (0x207) and the '''KeyGenerationOld''' field (0x206). The latter field must be 0, 1 or 2. In each ncahdr_keyindex block, it executes "if(ncahdr_x206>=3)<panic>", but that won't trigger due to the earlier check. The end result is basically the same as pre-[[3.0.0]], except when ncahdr_x206 == 0x2, final_index is new_base_index+ncahdr_keyindex. Actual implementation loads index from u32_array[ncahdr_crypto_type], where the address of u32_array is different for each ncahdr_keyindex.
−
* [[3.0.1]]+: The dedicated range check for ncahdr_x206("Crypto Type") was removed, since the updated code no longer needs it. The output from a function masked with 0xFF is now used instead of ncahdr_x206(ncahdr_crypto_type). The range check for that field was changed from {ncahdr_x206 check with panic described above}, to "if(index>=4)final_index=10;"(skips accessing the array and uses 10 directly). The arrays were updated with an additional entry: final_index=v301_base_index+ncahdr_keyindex.
+
* [[3.0.1]]+: The dedicated range check for the '''KeyGenerationOld''' field (0x206) was removed, since the updated code no longer needs it. The output from a function masked with 0xFF is now used instead of ncahdr_x206. The range check for that field was changed from {ncahdr_x206 check with panic described above}, to "if(index>=4)final_index=10;"(skips accessing the array and uses 10 directly). The arrays were updated with an additional entry: final_index=v301_base_index+ncahdr_keyindex.
 
** The keydata for the above index10 is not(?) known to be initialized.
 
** The keydata for the above index10 is not(?) known to be initialized.
 
** The new function called by the code described above does:
 
** The new function called by the code described above does:
 
** <code>if(ncahdr_x206 < ncahdr_x220){ret = ncahdr_x220; } else { ret = ncahdr_x206; } return ret;</code>
 
** <code>if(ncahdr_x206 < ncahdr_x220){ret = ncahdr_x220; } else { ret = ncahdr_x206; } return ret;</code>
  
−
==Section Table Entry==
+
== FsEntry ==
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 104: Line 113:
 
| 0x0
 
| 0x0
 
| 0x4
 
| 0x4
−
| Media offset
+
| StartOffset (in blocks which are 0x200 bytes)
 
|-
 
|-
 
| 0x4
 
| 0x4
 
| 0x4
 
| 0x4
−
| Media end-offset
+
| EndOffset (in blocks which are 0x200 bytes)
 
|-
 
|-
 
| 0x8
 
| 0x8
−
| 0x4
+
| 0x8
−
| Unknown
+
| Reserved
−
|-
 
−
| 0xC
 
−
| 0x4
 
−
| Unknown
 
 
|}
 
|}
  
−
Entry size is 0x10-bytes.
+
= FsHeader =
−
 
 
−
Media offset is absoluteoffset/{mediasize}, where mediasize is hard-coded to 0x200.
 
−
 
 
−
=Section Header Block=
 
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 131: Line 132:
 
|-
 
|-
 
| 0x0
 
| 0x0
−
| 0x1
+
| 0x2
−
| ?
+
| Version (always 2)
−
|-
 
−
|-
 
−
| 0x1
 
−
| 0x1
 
−
| ?
 
 
|-
 
|-
 
| 0x2
 
| 0x2
 
| 0x1
 
| 0x1
−
| ?
+
| FsType (0 = RomFS, 1 = PartitionFS)
 
|-
 
|-
 
| 0x3
 
| 0x3
 
| 0x1
 
| 0x1
−
| Filesystem type. 0x2 = PFS0, 0x3 = RomFS, everything else is invalid.
+
| HashType (0 = Auto, 1 = None, 2 = HierarchicalSha256Hash, 3 = HierarchicalIntegrityHash, [14.0.0+] 4 = AutoSha3, [14.0.0+] 5 = HierarchicalSha3256Hash, [14.0.0+] 6 = HierarchicalIntegritySha3Hash)
 
|-
 
|-
 
| 0x4
 
| 0x4
 
| 0x1
 
| 0x1
−
| Crypto type. 0 and >4 are invalid. 1 = none(plaintext from raw NCA). 2 = other crypto. 3 = regular crypto. 4 = unknown.
+
| EncryptionType (0 = Auto, 1 = None, 2 = AesXts, 3 = AesCtr, 4 = AesCtrEx, [14.0.0+] 5 = AesCtrSkipLayerHash, [14.0.0+] 6 = AesCtrExSkipLayerHash)
 
|-
 
|-
 
| 0x5
 
| 0x5
 
| 0x1
 
| 0x1
−
| Padding?
+
| [14.0.0+] MetaDataHashType (0 = None, 1 = HierarchicalIntegrity)
 +
|-
 +
| 0x6
 +
| 0x2
 +
| Reserved
 
|-
 
|-
 
| 0x8
 
| 0x8
−
|  
+
| 0xF8
−
| FS-specific superblock.
+
| [[#HashData|HashData]]
 
|-
 
|-
 
| 0x100
 
| 0x100
−
| ?
+
| 0x40
−
| Optional BKTR header. Can be used with any section, but only known to be used with game-updates RomFS.
+
| [[#PatchInfo|PatchInfo]] (only used with game updates RomFs)
 +
|-
 +
| 0x140
 +
| 0x4
 +
| Generation
 +
|-
 +
| 0x144
 +
| 0x4
 +
| SecureValue
 +
|-
 +
| 0x148
 +
| 0x30
 +
| [[#SparseInfo|SparseInfo]] (only used in sections with sparse storage)
 +
|-
 +
| 0x178
 +
| 0x28
 +
| [12.0.0+] [[#CompressionInfo|CompressionInfo]]
 +
|-
 +
| 0x1A0
 +
| 0x30
 +
| [14.0.0+] [[#MetaDataHashDataInfo|MetaDataHashDataInfo]]
 +
|-
 +
| 0x1D0
 +
| 0x30
 +
| Reserved
 
|}
 
|}
  
−
The Section Header Block for each section is at absoluteoffset+0x400+(sectionid*0x200), where sectionid corresponds to the index used with the entry/hash tables.
+
The FsHeader for each section is at absoluteoffset+0x400+(sectionid*0x200), where sectionid corresponds to the index used with the entry/hash tables.
  
−
The total size is 0x200-bytes.
+
== HashData ==
 +
This contains information specific to the hash type in use.
  
−
==PFS0 superblock==
+
=== HierarchicalSha256Data ===
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 175: Line 200:
 
! Description
 
! Description
 
|-
 
|-
−
| 0x8
+
| 0x0
 
| 0x20
 
| 0x20
−
| SHA256 hash over the hash-table at section-start+0 with the below hash-table size.
+
| MasterHash (SHA256 hash over the hash-table at section-start+0 with the below hash-table size)
 
|-
 
|-
−
| 0x28
+
| 0x20
 
| 0x4
 
| 0x4
−
| Block size in bytes.
+
| BlockSize
 
|-
 
|-
−
| 0x2C
+
| 0x24
 
| 0x4
 
| 0x4
−
| Must be 0x2.
+
| LayerCount (always 2)
−
|-
 
−
| 0x30
 
−
| 0x8
 
−
| Offset of hash-table. Normally zero?
 
−
|-
 
−
| 0x38
 
−
| 0x8
 
−
| Size of hash-table.
 
−
|-
 
−
| 0x40
 
−
| 0x8
 
−
| Offset relative to section-start where the PFS0 header is located.
 
−
|-
 
−
| 0x48
 
−
| 0x8
 
−
| Actual byte-size of the PFS0 filesystem relative to the PFS0 header.
 
 
|-
 
|-
 +
| 0x28
 
| 0x50
 
| 0x50
−
| 0xF4
+
| [[#Region|LayerRegions]] (one region for the hash-table and another for PFS0 filesystem)
−
| Normally zeros.
 
 
|-
 
|-
−
| 0x144
+
| 0x78
−
| ?
+
| 0x80
−
| 0x1?
+
| Reserved
−
|-
 
−
| 0x148
 
−
| 0xB8
 
−
| Normally zeros.
 
 
|}
 
|}
  
−
This documents the structure of Section Header Block +0 for PFS0.
+
==== Region ====
−
 
 
−
==RomFS superblock==
 
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 225: Line 228:
 
! Description
 
! Description
 
|-
 
|-
 +
| 0x0
 
| 0x8
 
| 0x8
−
| 0xE0
+
| Offset
−
| IVFC header. Basically the same as [[Savegames]] IVFC except with 2 more levels and +0x0C is non-zero, see below.
+
|-
 +
| 0x8
 +
| 0x8
 +
| Size
 
|}
 
|}
  
−
This documents the structure of Section Header Block +0 for RomFS.
+
=== IntegrityMetaInfo ===
−
 
+
{| class="wikitable" border="1"
−
=== IVFC ===
 
−
{| class="wikitable"
 
 
|-
 
|-
−
! Start
+
! Offset
−
! Length
+
! Size
 
! Description
 
! Description
 
|-
 
|-
−
| 0x00
+
| 0x0
−
| 4
+
| 0x4
 
| Magic ("IVFC")
 
| Magic ("IVFC")
 
|-
 
|-
−
| 0x04
+
| 0x4
−
| 4
+
| 0x4
−
| Magic Number (0x20000)
+
| Version
 
|-
 
|-
−
| 0x08
+
| 0x8
−
| 4
+
| 0x4
−
| Master hash size?
+
| MasterHashSize
 
|-
 
|-
−
| 0x0C
+
| 0xC
−
| 4
+
| 0xB4
−
| Usually 7? Unknown, could be related to total number of levels maybe?
+
| [[#InfoLevelHash|InfoLevelHash]]
 
|-
 
|-
−
| 0x10
+
| 0xC0
−
| 8
+
| 0x20
−
| Level 1 offset
+
| MasterHash
 
|-
 
|-
 +
| 0xE0
 
| 0x18
 
| 0x18
−
| 8
+
| Reserved
−
| Level 1 size
+
|}
 +
 
 +
==== InfoLevelHash ====
 +
{| class="wikitable" border="1"
 
|-
 
|-
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 0x4
 +
| MaxLayers
 +
|-
 +
| 0x4
 +
| 0x90
 +
| [[#HierarchicalIntegrityVerificationLevelInformation|Levels]]
 +
|-
 +
| 0x94
 
| 0x20
 
| 0x20
−
| 4
+
| SignatureSalt
−
| Level 1 block size, in log2
+
|}
 +
 
 +
===== HierarchicalIntegrityVerificationLevelInformation =====
 +
{| class="wikitable" border="1"
 
|-
 
|-
−
| 0x24
+
! Offset
−
| 4
+
! Size
−
| Reserved
+
! Description
 
|-
 
|-
−
| 0x28
+
| 0x0
−
| 8
+
| 0x8
−
| Level 2 offset
+
| LogicalOffset
 
|-
 
|-
−
| 0x30
+
| 0x8
−
| 8
+
| 0x8
−
| Level 2 size
+
| HashDataSize
 
|-
 
|-
−
| 0x38
+
| 0x10
−
| 4
+
| 0x4
−
| Level 2 block size, in log2.
+
| BlockSize (in log2)
 
|-
 
|-
−
| 0x3C
+
| 0x14
−
| 4
+
| 0x4
 
| Reserved
 
| Reserved
 +
|}
 +
 +
== PatchInfo ==
 +
{| class="wikitable" border="1"
 
|-
 
|-
−
| 0x40
+
! Offset
−
| 8
+
! Size
−
| Level 3 offset
+
! Description
 
|-
 
|-
−
| 0x48
+
| 0x0
−
| 8
+
| 0x8
−
| Level 3 size
+
| IndirectOffset
 
|-
 
|-
−
| 0x50
+
| 0x8
−
| 4
+
| 0x8
−
| Level 3 block size, in log2.
+
| IndirectSize
 
|-
 
|-
−
| 0x54
+
| 0x10
−
| 4
+
| 0x10
−
| Reserved
+
| [[#BucketTreeHeader|IndirectHeader]]
 
|-
 
|-
−
| 0x58
+
| 0x20
−
| 8
+
| 0x8
−
| Level 4 offset
+
| AesCtrExOffset
 
|-
 
|-
−
| 0x60
+
| 0x28
−
| 8
+
| 0x8
−
| Level 4 size
+
| AesCtrExSize
 
|-
 
|-
−
| 0x68
+
| 0x30
−
| 4
+
| 0x10
−
| Level 4 block size, in log2.
+
| [[#BucketTreeHeader|AesCtrExHeader]]
 +
|}
 +
 
 +
The above byte-offsets are relative to the start of the section-data.
 +
 
 +
The two sections specified by the two BKTR entries are usually(?) at the very end of the section data(section_endoffset-{size of BKTR sections}).
 +
 
 +
=== RomFs Patching ===
 +
The [[#PatchInfo|PatchInfo]] section enables combining data from an update NCA with the RomFs from a base NCA to create a single patched RomFS image.  
 +
 
 +
The first BKTR entry describes how to map regions of the two RomFs images to create the patched RomFs. It has the following format:
 +
{| class="wikitable" border="1"
 
|-
 
|-
−
| 0x6C
+
! Offset
−
| 4
+
! Size
−
| Reserved
+
! Description
 
|-
 
|-
−
| 0x70
+
| 0x0
−
| 8
+
| 0x4
−
| Level 5 offset
+
| Padding/Unused?
 
|-
 
|-
−
| 0x78
+
| 0x4
−
| 8
+
| 0x4
−
| Level 5 size
+
| Number of Buckets
 
|-
 
|-
−
| 0x80
+
| 0x8
−
| 4
+
| 0x8
−
| Level 5 block size, in log2.
+
| Total Size of the Virtual RomFS Image
 
|-
 
|-
−
| 0x84
+
| 0x10
−
| 4
+
| 0x3FF0
−
| Reserved
+
| Base Virtual Offset for each Bucket (u64s, padded with 0s until end)
 
|-
 
|-
−
| 0x88
+
| 0x4000
−
| 8
+
| 0x4000*X
−
| Level 6 offset
+
| Relocation Buckets
 +
|}
 +
 
 +
Where relocation buckets are as follows:
 +
{| class="wikitable" border="1"
 
|-
 
|-
−
| 0x90
+
! Offset
−
| 8
+
! Size
−
| Level 6 size
+
! Description
 
|-
 
|-
−
| 0x98
+
| 0x0
−
| 4
+
| 0x4
−
| Level 6 block size, in log2.
+
| Padding/Unused?
 
|-
 
|-
−
| 0x9C
+
| 0x4
−
| 4
+
| 0x4
−
| Reserved
+
| Number of Entries
 
|-
 
|-
−
| 0xA0
+
| 0x8
−
| 32
+
| 0x8
−
| Unknown, reserved?
+
| End offset for this Bucket
 
|-
 
|-
−
| 0xC0
+
| 0x10
−
| 32
+
| 0x3FF0
−
| Hash
+
| Relocation Entries
 
|}
 
|}
  
−
== BKTR ==
+
Where relocation entries are as follows:
−
{| class="wikitable"
+
{| class="wikitable" border="1"
 
|-
 
|-
−
! Start
+
! Offset
−
! Length
+
! Size
 
! Description
 
! Description
 
|-
 
|-
 
| 0x0
 
| 0x0
 
| 0x8
 
| 0x8
−
| Offset
+
| Address in Patched RomFs
−
|-
 
 
|-
 
|-
 
| 0x8
 
| 0x8
 
| 0x8
 
| 0x8
−
| Size
+
| Address in Source RomFs
 
|-
 
|-
 
| 0x10
 
| 0x10
 
| 0x4
 
| 0x4
−
| "BKTR"
+
| 1=Is from Patch RomFS, 0=Is from Base RomFS
 +
|}
 +
 
 +
The second BKTR entry describes the subsections within the Patch RomFs. It has the following format:
 +
{| class="wikitable" border="1"
 
|-
 
|-
−
| 0x14
+
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 
| 0x4
 
| 0x4
−
| u32, must be <=1.
+
| Padding/Unused?
 
|-
 
|-
−
| 0x18
 
 
| 0x4
 
| 0x4
−
| s32, must be >=1.
+
| 0x4
 +
| Number of Buckets
 +
|-
 +
| 0x8
 +
| 0x8
 +
| Total Size of the Physical Patch Image
 +
|-
 +
| 0x10
 +
| 0x3FF0
 +
| Base Physical Offset for each Bucket (u64s, padded with 0s until end)
 +
|-
 +
| 0x4000
 +
| 0x4000*X
 +
| Subsection Buckets
 +
|}
 +
 
 +
Where subsection buckets are as follows:
 +
{| class="wikitable" border="1"
 +
|-
 +
! Offset
 +
! Size
 +
! Description
 
|-
 
|-
−
| 0x1C
+
| 0x0
 
| 0x4
 
| 0x4
−
| ?
+
| Padding/Unused?
 
|-
 
|-
−
| 0x20
+
| 0x4
−
| 0x20
+
| 0x4
−
| Same as the above 0x20-bytes except with different data.
+
| Number of Entries
 
|-
 
|-
−
| 0x40
+
| 0x8
−
| 0x4?
+
| 0x8
−
| ?
+
| End offset for this Bucket
 
|-
 
|-
−
| 0x44
+
| 0x10
−
| 0x4?
+
| 0x3FF0
−
| ?
+
| Subsection Entries
 
|}
 
|}
  
−
Using this header is enabled when offset 0x8 in this header is non-zero.
+
Where subsection entries are as follows:
 +
{| class="wikitable" border="1"
 +
|-
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 0x8
 +
| Address in Patch RomFs
 +
|-
 +
| 0x8
 +
| 0x4
 +
| Padding/Unused?
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Value for subsection AES-CTR
 +
|}
  
−
The above byte-offsets are relative to the start of the section-data.
+
Official code assumes the relocation entries are sorted, and performs a binary search when determining where to read from. Each subsection in the Patch RomFs has its CTR calculated separately from the others based on the value in its entry (the BKTR entries use normal crypto). Thus decrypting a Patch RomFS requires decrypting and parsing the BKTR entries before anything else.
  
−
The two sections specified by the two BKTR entries are usually(?) at the very end of the section data(section_endoffset-{size of BKTR sections}).
+
== SparseInfo ==
−
 
+
{| class="wikitable" border="1"
−
===RomFS Patching===
 
−
 
 
−
The BKTR section enables combining data from an update NCA with the RomFS from a base NCA to create a single patched RomFS image.
 
−
 
 
−
The first BKTR entry describes how to map regions of the two RomFS images to create the patched RomFS. It has the following format:
 
−
 
 
−
{| class="wikitable"
 
 
|-
 
|-
−
! Start
+
! Offset
−
! Length
+
! Size
 
! Description
 
! Description
 
|-
 
|-
 
| 0x0
 
| 0x0
−
| 0x4004
+
| 0x8
−
| Padding/Unused?
+
| TableOffset
 +
|-
 +
| 0x8
 +
| 0x8
 +
| TableSize
 
|-
 
|-
−
| 0x4004 || 0x4 || Number of Entries
+
| 0x10
 +
| 0x10
 +
| [[#BucketTreeHeader|TableHeader]]
 
|-
 
|-
−
| 0x4008 || 0x8 || Patched RomFS Size
+
| 0x20
 +
| 0x8
 +
| PhysicalOffset
 
|-
 
|-
−
| 0x4010 || 0x14*X || Relocation Entries
+
| 0x28
 +
| 0x2
 +
| Generation
 +
|-
 +
| 0x2A
 +
| 0x6
 +
| Reserved
 
|}
 
|}
  
−
Where relocation entries are as follows:
+
== CompressionInfo ==
−
 
+
{| class="wikitable" border="1"
−
{| class="wikitable"
 
 
|-
 
|-
−
! Start
+
! Offset
−
! Length
+
! Size
 
! Description
 
! Description
 
|-
 
|-
−
| 0x0 || 0x8 || Address in Patched RomFS
+
| 0x0
 +
| 0x8
 +
| TableOffset
 
|-
 
|-
−
| 0x8 || 0x8 || Address in Source RomFS
+
| 0x8
 +
| 0x8
 +
| TableSize
 +
|-
 +
| 0x10
 +
| 0x10
 +
| [[#BucketTreeHeader|TableHeader]]
 
|-
 
|-
−
| 0x10  || 0x4 || 1=Is from Patch RomFS, 0=Is from Base RomFS
+
| 0x20
 +
| 0x8
 +
| Reserved
 
|}
 
|}
  
−
The second BKTR entry describes the subsections within the Patch RomFS. It has the following format:
+
== BucketTreeHeader ==
−
 
+
{| class="wikitable" border="1"
−
{| class="wikitable"
 
 
|-
 
|-
−
! Start
+
! Offset
−
! Length
+
! Size
 
! Description
 
! Description
 
|-
 
|-
 
| 0x0
 
| 0x0
−
| 0x4004
+
| 0x4
−
| Padding/Unused?
+
| Magic ("BKTR")
 
|-
 
|-
−
| 0x4004 || 0x4 || Number of Entries
+
| 0x4
 +
| 0x4
 +
| Version
 
|-
 
|-
−
| 0x4008 || 0x8 || Patch RomFS Size - BKTR entries
+
| 0x8
 +
| 0x4
 +
| EntryCount
 
|-
 
|-
−
| 0x4010 || 0x10*X || Subsection Entries
+
| 0xC
 +
| 0x4
 +
| Reserved
 
|}
 
|}
  
−
Where subsection entries are as follows:
+
== MetaDataHashDataInfo ==
−
 
+
{| class="wikitable" border="1"
−
{| class="wikitable"
 
 
|-
 
|-
−
! Start
+
! Offset
−
! Length
+
! Size
 
! Description
 
! Description
 
|-
 
|-
−
| 0x0 || 0x8 || Address in Patch RomFS
+
| 0x0
 +
| 0x8
 +
| TableOffset
 
|-
 
|-
−
| 0x8 || 0x4 || Padding/Unused?
+
| 0x8
 +
| 0x8
 +
| TableSize
 
|-
 
|-
−
| 0xC  || 0x4 || Value for subsection AES-CTR
+
| 0x10
 +
| 0x20
 +
| TableHash
 
|}
 
|}
  
−
Official code assumes the relocation entries are sorted, and performs a binary search when determining where to read from. Each subsection in the Patch RomFS has its CTR calculated separately from the others based on the value in its entry (the BKTR entries use normal crypto). Thus decrypting a Patch RomFS requires decrypting and parsing the BKTR entries before anything else.
+
= Logo Section =
 +
This is a PFS0.
  
−
=Logo section=
+
See [[NCA_Content_FS|here]] for the mounted-FS logo contents.
−
This is a PFS0. See [[NCA_Content_FS|here]] for the mounted-FS logo contents.
 
  
−
=ExeFS section =
+
= ExeFS Section =
 
This is a PFS0.
 
This is a PFS0.
  
 
See [[ExeFS|here]] for mounted-FS ExeFS contents.
 
See [[ExeFS|here]] for mounted-FS ExeFS contents.
  
−
=Game-updates=
+
= Game Updates =
 
The section-data for ncatype1 RomFS section(section1) uses section-crypto-type 0x4.
 
The section-data for ncatype1 RomFS section(section1) uses section-crypto-type 0x4.
  
−
Game-updates also contain multiple ncatype6 content, which contain "section0_pfs0/fragment". Some of these are just NCAs, unknown for the rest(presumably NCAs with additional crypto?). The first ncatype6 content fragment file has a NDV0 header, with the NCA starting at offset 0x44.
+
Game updates also contain multiple ncatype6 content, which contain "section0_pfs0/fragment". Some of these are just NCAs, unknown for the rest(presumably NCAs with additional crypto?). The first ncatype6 content fragment file has a NDV0 header, with the NCA starting at offset 0x44.
  
−
=PFS0=
+
= PFS0 =
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 532: Line 647:
 
| 0x0
 
| 0x0
 
| 0x4
 
| 0x4
−
| "PFS0" Magic
+
| Magic ("PFS0")
 
|-
 
|-
 
| 0x4
 
| 0x4
 
| 0x4
 
| 0x4
−
| Number of files
+
| EntryCount
 
|-
 
|-
 
| 0x8
 
| 0x8
 
| 0x4
 
| 0x4
−
| Size of the string table
+
| StringTableSize
 
|-
 
|-
 
| 0xC
 
| 0xC
 
| 0x4
 
| 0x4
−
| Zero/Reserved
+
| Reserved
 
|-
 
|-
 
| 0x10
 
| 0x10
 
| X
 
| X
−
| File Entry Table
+
| [[#PartitionEntry|PartitionEntryTable]]
 
|-
 
|-
 
| 0x10 + X
 
| 0x10 + X
 
| Y
 
| Y
−
| String Table
+
| StringTable
 
|-
 
|-
 
| 0x10 + X + Y
 
| 0x10 + X + Y
 
| Z
 
| Z
−
| Raw File Data
+
| FileData
 
|}
 
|}
  
−
Where File Entry Table consists of Number of Files FileEntries:
+
== PartitionEntry ==
−
 
 
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 569: Line 683:
 
| 0x0
 
| 0x0
 
| 0x8
 
| 0x8
−
| Offset of file in Data
+
| Offset
 
|-
 
|-
 
| 0x8
 
| 0x8
 
| 0x8
 
| 0x8
−
| Size of file in Data
+
| Size
 
|-
 
|-
 
| 0x10
 
| 0x10
 
| 0x4
 
| 0x4
−
| Offset of filename in String Table
+
| StringOffset
 
|-
 
|-
 
| 0x14
 
| 0x14
 
| 0x4
 
| 0x4
−
| Normally zero?
+
| Reserved
 
|}
 
|}

Latest revision as of 00:06, 8 October 2024

NCA means «Nintendo Content Archive».

The entire raw NCAs are encrypted.

The only known area which is not encrypted in the raw NCA is the logo section, when the NCA includes that section. Everything else documented on this page is for the plaintext version of that data.

Encryption

The first 0xC00 bytes are encrypted with AES-XTS with sector size 0x200 with a non-standard "tweak" (endianness is reversed, see here), this encrypted data is an 0x400 NCA header + an 0x200 header for each section in the section table.

For pre-1.0.0 "NCA2" NCAs, the first 0x400 byte are encrypted the same way as in NCA3. However, each section header is individually encrypted as though it were sector 0, instead of the appropriate sector as in NCA3.

Header

Offset Size Description
0x0 0x100 RSA-2048 signature over the header (data from 0x200 to 0x400) using a fixed key
0x100 0x100 RSA-2048 signature over the header (data from 0x200 to 0x400) using a key from NPDM (or zeroes if not a program)
0x200 0x4 Magic "NCA3" ("NCA2", "NCA1" or "NCA0" for pre-1.0.0 NCAs)
0x204 0x1 DistributionType (0x00 = Download, 0x01 = GameCard)
0x205 0x1 ContentType (0x00 = Program, 0x01 = Meta, 0x02 = Control, 0x03 = Manual, 0x04 = Data, 0x05 = PublicData)
0x206 0x1 KeyGenerationOld (0x00 = 1.0.0, 0x01 = Unused, 0x02 = 3.0.0)
0x207 0x1 KeyAreaEncryptionKeyIndex (0x00 = Application, 0x01 = Ocean, 0x02 = System)
0x208 0x8 ContentSize
0x210 0x8 ProgramId
0x218 0x4 ContentIndex
0x21C 0x4 SdkAddonVersion (used in "FS_ACCESS: { sdk_version: {byte3}.{byte2}.{byte1}, ..." with byte0 set to 0 and compared with a required minimum value: 0x000B0000)
0x220 0x1 KeyGeneration (0x03 = 3.0.1, 0x04 = 4.0.0, 0x05 = 5.0.0, 0x06 = 6.0.0, 0x07 = 6.2.0, 0x08 = 7.0.0, 0x09 = 8.1.0, 0x0A = 9.0.0, 0x0B = 9.1.0, 0x0C = 12.1.0, 0x0D = 13.0.0, 0x0E = 14.0.0, 0x0F = 15.0.0, 0x10 = 16.0.0, 0x11 = 17.0.0, 0x12 = 18.0.0, 0x13 = 19.0.0, 0xFF = Invalid)
0x221 0x1 [9.0.0+] SignatureKeyGeneration
0x222 0xE Reserved
0x230 0x10 RightsId
0x240 0x10 * 4 Array of FsEntry
0x280 0x20 * 4 Array of SHA256 hashes (over each FsHeader)
0x300 0x10 * 4 EncryptedKeyArea

When the above KeyGenerationOld field is 0x2 on >= v3.0, different {crypto/keydata} is used for the sections' data. With system content, this is used with every ncatype except ncatype0. The only other exception is {data-content} for the firm titles: this is required in order for older-system-versions to install it.

KeyGeneration 0x3 (with KeyGenerationOld set to 0x2) is used for all 3.0.1 sysmodules and the System_Version_Title. With 3.0.2, all updated titles use the crypto from 3.0.1 for non-ncatype0, except for firm {data-content}. In some cases various game content uses the above newer crypto as well.

KeyGeneration is always MasterKeyVersion + 1, except for generations 0 and 1 which are both version 0.

The keyindex passed to <key-generation-related code> is determined as follows:

  • Pre-3.0.0: The KeyAreaEncryptionKeyIndex field (0x207) is passed directly.
  • 3.0.0+: It's determined using the KeyAreaEncryptionKeyIndex field (0x207) and the KeyGenerationOld field (0x206). The latter field must be 0, 1 or 2. In each ncahdr_keyindex block, it executes "if(ncahdr_x206>=3)<panic>", but that won't trigger due to the earlier check. The end result is basically the same as pre-3.0.0, except when ncahdr_x206 == 0x2, final_index is new_base_index+ncahdr_keyindex. Actual implementation loads index from u32_array[ncahdr_crypto_type], where the address of u32_array is different for each ncahdr_keyindex.
  • 3.0.1+: The dedicated range check for the KeyGenerationOld field (0x206) was removed, since the updated code no longer needs it. The output from a function masked with 0xFF is now used instead of ncahdr_x206. The range check for that field was changed from {ncahdr_x206 check with panic described above}, to "if(index>=4)final_index=10;"(skips accessing the array and uses 10 directly). The arrays were updated with an additional entry: final_index=v301_base_index+ncahdr_keyindex.
    • The keydata for the above index10 is not(?) known to be initialized.
    • The new function called by the code described above does:
    • if(ncahdr_x206 < ncahdr_x220){ret = ncahdr_x220; } else { ret = ncahdr_x206; } return ret;

FsEntry

Offset Size Description
0x0 0x4 StartOffset (in blocks which are 0x200 bytes)
0x4 0x4 EndOffset (in blocks which are 0x200 bytes)
0x8 0x8 Reserved

FsHeader

Offset Size Description
0x0 0x2 Version (always 2)
0x2 0x1 FsType (0 = RomFS, 1 = PartitionFS)
0x3 0x1 HashType (0 = Auto, 1 = None, 2 = HierarchicalSha256Hash, 3 = HierarchicalIntegrityHash, [14.0.0+] 4 = AutoSha3, [14.0.0+] 5 = HierarchicalSha3256Hash, [14.0.0+] 6 = HierarchicalIntegritySha3Hash)
0x4 0x1 EncryptionType (0 = Auto, 1 = None, 2 = AesXts, 3 = AesCtr, 4 = AesCtrEx, [14.0.0+] 5 = AesCtrSkipLayerHash, [14.0.0+] 6 = AesCtrExSkipLayerHash)
0x5 0x1 [14.0.0+] MetaDataHashType (0 = None, 1 = HierarchicalIntegrity)
0x6 0x2 Reserved
0x8 0xF8 HashData
0x100 0x40 PatchInfo (only used with game updates RomFs)
0x140 0x4 Generation
0x144 0x4 SecureValue
0x148 0x30 SparseInfo (only used in sections with sparse storage)
0x178 0x28 [12.0.0+] CompressionInfo
0x1A0 0x30 [14.0.0+] MetaDataHashDataInfo
0x1D0 0x30 Reserved

The FsHeader for each section is at absoluteoffset+0x400+(sectionid*0x200), where sectionid corresponds to the index used with the entry/hash tables.

HashData

This contains information specific to the hash type in use.

HierarchicalSha256Data

Offset Size Description
0x0 0x20 MasterHash (SHA256 hash over the hash-table at section-start+0 with the below hash-table size)
0x20 0x4 BlockSize
0x24 0x4 LayerCount (always 2)
0x28 0x50 LayerRegions (one region for the hash-table and another for PFS0 filesystem)
0x78 0x80 Reserved

Region

Offset Size Description
0x0 0x8 Offset
0x8 0x8 Size

IntegrityMetaInfo

Offset Size Description
0x0 0x4 Magic ("IVFC")
0x4 0x4 Version
0x8 0x4 MasterHashSize
0xC 0xB4 InfoLevelHash
0xC0 0x20 MasterHash
0xE0 0x18 Reserved

InfoLevelHash

Offset Size Description
0x0 0x4 MaxLayers
0x4 0x90 Levels
0x94 0x20 SignatureSalt
HierarchicalIntegrityVerificationLevelInformation
Offset Size Description
0x0 0x8 LogicalOffset
0x8 0x8 HashDataSize
0x10 0x4 BlockSize (in log2)
0x14 0x4 Reserved

PatchInfo

Offset Size Description
0x0 0x8 IndirectOffset
0x8 0x8 IndirectSize
0x10 0x10 IndirectHeader
0x20 0x8 AesCtrExOffset
0x28 0x8 AesCtrExSize
0x30 0x10 AesCtrExHeader

The above byte-offsets are relative to the start of the section-data.

The two sections specified by the two BKTR entries are usually(?) at the very end of the section data(section_endoffset-{size of BKTR sections}).

RomFs Patching

The PatchInfo section enables combining data from an update NCA with the RomFs from a base NCA to create a single patched RomFS image.

The first BKTR entry describes how to map regions of the two RomFs images to create the patched RomFs. It has the following format:

Offset Size Description
0x0 0x4 Padding/Unused?
0x4 0x4 Number of Buckets
0x8 0x8 Total Size of the Virtual RomFS Image
0x10 0x3FF0 Base Virtual Offset for each Bucket (u64s, padded with 0s until end)
0x4000 0x4000*X Relocation Buckets

Where relocation buckets are as follows:

Offset Size Description
0x0 0x4 Padding/Unused?
0x4 0x4 Number of Entries
0x8 0x8 End offset for this Bucket
0x10 0x3FF0 Relocation Entries

Where relocation entries are as follows:

Offset Size Description
0x0 0x8 Address in Patched RomFs
0x8 0x8 Address in Source RomFs
0x10 0x4 1=Is from Patch RomFS, 0=Is from Base RomFS

The second BKTR entry describes the subsections within the Patch RomFs. It has the following format:

Offset Size Description
0x0 0x4 Padding/Unused?
0x4 0x4 Number of Buckets
0x8 0x8 Total Size of the Physical Patch Image
0x10 0x3FF0 Base Physical Offset for each Bucket (u64s, padded with 0s until end)
0x4000 0x4000*X Subsection Buckets

Where subsection buckets are as follows:

Offset Size Description
0x0 0x4 Padding/Unused?
0x4 0x4 Number of Entries
0x8 0x8 End offset for this Bucket
0x10 0x3FF0 Subsection Entries

Where subsection entries are as follows:

Offset Size Description
0x0 0x8 Address in Patch RomFs
0x8 0x4 Padding/Unused?
0xC 0x4 Value for subsection AES-CTR

Official code assumes the relocation entries are sorted, and performs a binary search when determining where to read from. Each subsection in the Patch RomFs has its CTR calculated separately from the others based on the value in its entry (the BKTR entries use normal crypto). Thus decrypting a Patch RomFS requires decrypting and parsing the BKTR entries before anything else.

SparseInfo

Offset Size Description
0x0 0x8 TableOffset
0x8 0x8 TableSize
0x10 0x10 TableHeader
0x20 0x8 PhysicalOffset
0x28 0x2 Generation
0x2A 0x6 Reserved

CompressionInfo

Offset Size Description
0x0 0x8 TableOffset
0x8 0x8 TableSize
0x10 0x10 TableHeader
0x20 0x8 Reserved

BucketTreeHeader

Offset Size Description
0x0 0x4 Magic ("BKTR")
0x4 0x4 Version
0x8 0x4 EntryCount
0xC 0x4 Reserved

MetaDataHashDataInfo

Offset Size Description
0x0 0x8 TableOffset
0x8 0x8 TableSize
0x10 0x20 TableHash

Logo Section

This is a PFS0.

See here for the mounted-FS logo contents.

ExeFS Section

This is a PFS0.

See here for mounted-FS ExeFS contents.

Game Updates

The section-data for ncatype1 RomFS section(section1) uses section-crypto-type 0x4.

Game updates also contain multiple ncatype6 content, which contain "section0_pfs0/fragment". Some of these are just NCAs, unknown for the rest(presumably NCAs with additional crypto?). The first ncatype6 content fragment file has a NDV0 header, with the NCA starting at offset 0x44.

PFS0

Offset Size Description
{Hash-table offset from superblock} {Hash-table size from superblock} Table of SHA256 hashes.
{Hash-table <offset+size> from superblock} Zeros for alignment to {alignment size}.
{PFS0 offset from superblock} {PFS0 size from superblock} The actual PFS0.

This is the FS which has magicnum "PFS0" at header+0. This is very similar to HFS0. A tool for extracting this FS is available here.

The hash table is hashes for every {Block size from superblock} starting at the PFS0 header. The size used for the last hash is {PFS0 filesystem size from superblock} - offset_relativeto_header.

See also the PFS0 superblock above.

Offset Size Description
0x0 0x4 Magic ("PFS0")
0x4 0x4 EntryCount
0x8 0x4 StringTableSize
0xC 0x4 Reserved
0x10 X PartitionEntryTable
0x10 + X Y StringTable
0x10 + X + Y Z FileData

PartitionEntry

Offset Size Description
0x0 0x8 Offset
0x8 0x8 Size
0x10 0x4 StringOffset
0x14 0x4 Reserved
Retrieved from "https://switchbrew.org/w/index.php?title=NCA&oldid=12926"