NCA: Difference between revisions

| Magicnum "NCA3" ("NCA2", "NCA1" or "NCA0" for pre-1.0.0 NCAs)

| Distribution Type (0x00 = System NCA, 0x01 = Gamecard NCA)

| Content Type (0x00 = Program, 0x01 = Meta, 0x02 = Control, 0x03 = Manual, 0x04 = Data, 0x05 = PublicData)

| Old Key Generation (0x00 = [[1.0.0]], 0x01 = Unused, 0x02 = [[3.0.0]])

| Key Area Encryption Key Index (0x00 = Application, 0x01 = Ocean, 0x02 = System)

| Size of the entire NCA

| Title ID

| Content Index

| SDK AddOn Version (used in "FS_ACCESS: { sdk_version: {byte3}.{byte2}.{byte1}, ..." with byte0 set to 0 and compared with a required minimum value: 0x000B0000)

| Key Generation (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]], 0xFF = Invalid)

| Rights ID ([[Ticket]])

| 0x10*0x4(0x40)

| Table for each section (see below)

| 0x20*0x4(0x80)

| Table of SHA256 hashes (over each 0x200-byte [[#Section Header Block|Section Header Block]])

| 0x10*0x4(0x40)

| Key area

The header is 0x400-bytes, at NCA+0.

When the above '''Old Key Generation''' 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.

'''Key Generation''' 0x3 (with '''Old Key Generation''' 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.

 

'''Key Generation''' is always '''Master Key Version''' + 1, except for generations 0 and 1 which are both version 0.

* Pre-[[3.0.0]]: The '''Key Area Encryption Key Index''' field (0x207) is passed directly.

* [[3.0.0]]+: It's determined using the '''Key Area Encryption Key Index''' field (0x207) and the '''Old Key Generation''' 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 '''Old Key Generation''' 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.

== Section Table Entry ==

| Media Start Offset

| Media End Offset

| 0x4

| Unknown

 

 

= Section Header Block =

| Filesystem Type (0 = RomFS, 1 = PFS0)

| Hash Type (2 = PFS0, 3 = RomFS)

| Encryption Type (1 = None, 2 = AesCtrOld, 3 = AesCtr, 4 = AesCtrEx)

| Padding

| FS-specific superblock

| ?

| Optional BKTR header (can be used with any section, but only known to be used with game-updates RomFS)

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 total size is 0x200-bytes.

== PFS0 superblock ==

| SHA256 hash over the hash-table at section-start+0 with the below hash-table size

| Block size in bytes

| Must be 0x2

| 0x8

| Offset of hash-table (normally zero)

| 0x30

| Size of hash-table

| Actual byte-size of the PFS0 filesystem relative to the PFS0 header

== RomFS superblock ==

| IVFC header (basically the same as [[Savegames]] IVFC except with 2 more levels and +0x0C is non-zero, see below)

 

=== IVFC ===

{| class="wikitable"

! Start

! Length

| 0x00

| 4

| Magicnum "IVFC"

| 0x04

| 4

| Magic Number (0x20000)

| Level 1 size

| 4

| Level 1 block size (in log2)

| 0x28

| 8

| Level 2 offset

| 0x30

| 8

| Level 2 size

| 0x38

| 4

| Level 2 block size (in log2)

| 0x3C

| 4

| 0x48

| 8

| Level 3 size

| 0x50

| 4

| Level 3 block size (in log2)

| 0x54

| 4

| Reserved

| 0x58

| 8

| Level 4 offset

| 0x60

| 8

| Level 4 size

| 0x68

| 4

| Level 4 block size (in log2)

| 0x70

| 8

| Level 5 offset

| 0x78

| 8

| Level 5 size

| 0x80

| 4

| Level 5 block size (in log2)

| 0x84

| 4

| Reserved

| 0x88

| 8

| Level 6 offset

| 0x98

| 4

| Level 6 block size (in log2)

| 0x9C

| 4

| Reserved

| 0xA0

| 32

| Unknown, reserved?

| 0xC0

| 32

| Hash

{| class="wikitable"

! Start

! Length

| Offset

| Size

| Magicnum "BKTR"

| 0x14

| u32, must be <=1.

| ?

| 0x20

| 0x20

| Same as the above 0x20-bytes except with different data.

| 0x40

| 0x4?

| ?

| 0x44

| 0x4?

| ?

 

 

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}).

 

 

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

! Length

| 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:

 

{| class="wikitable"

! Start

! Length

| 0x0 || 0x4 || Padding/Unused?

| 0x4 || 0x4 || Number of Entries

| 0x8 || 0x8 || End offset for this Bucket

|-

Where relocation entries are as follows:

{| class="wikitable"

! Start

! Length

| 0x0 || 0x8 || Address in Patched RomFS

| 0x8 || 0x8 || Address in Source RomFS

| 0x10 || 0x4 || 1=Is from Patch RomFS, 0=Is from Base RomFS

 

{| class="wikitable"

! Start

! Length

| 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

 

{| class="wikitable"

! Start

! Length

| 0x0 || 0x4 || Padding/Unused?

| 0x4 || 0x4 || Number of Entries

| 0x8 || 0x8 || End offset for this Bucket

| 0x10 || 0x3FF0 || Subsection Entries

 

{| class="wikitable"

! Start

! Length

| 0x0 || 0x8 || Address in Patch RomFS

| 0x8 || 0x4 || Padding/Unused?

| 0xC  || 0x4 || Value for subsection AES-CTR

 

= Logo section =

= ExeFS section =

= Game-updates =

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.

| Magicnum "PFS0"

| Number of files

| Size of the string table

| Zero/Reserved

| File Entry Table

| String Table

| Raw File Data

 

| Offset of file in Data

| Size of file in Data

| Offset of filename in String Table

| Normally zero?