Extended Header

This page documents the format of the NCCH Extended Header, or exheader for short.

The exheader has two sections:

• The actual exheader data, containing System Control Info (SCI) and Access Control Info (ACI);
• A signed copy of NCCH HDR public key, and exheader ACI. This version of the ACI is used as limitation to the actual ACI.

All values are little endian unless otherwise specified.

See also: 🔗 1

The AccessDesc signature covers the NCCH HDR public key and second ACI. The AccessDesc public key is initialised by the boot ROM.

When loading the exheader, Process9 compares the exheader data with the data in the AccessDesc (note that not everything is compared here). When these don’t match, an error is returned. The Process9 code handling this validation was updated with v6.0; the only change in this function seems to be the check for the “Ideal processor” field.

Most of these fields are used in LOADER:LoadProcess.

In the exheader data, the ideal processor field is a bit-index, while in the AccessDesc the ideal processor field is a bitmask. When the bit specified by the exheader field is not set in the AccessDesc field, an error is returned.

if((1 << exheaderval) & accessdescval == 0) return error

During a FIRM-launch when a TitleInfo structure was specified, the field at offset 0x400 in the FIRM-launch parameters is set to the SystemMode of the specified title, however in some cases other values are written there. With 8.0.0-18 NS will now check the output of PTMSYSM command 0x040A0000, when the output is non-zero and a certain NS state field is value-zero, the following is executed otherwise this is skipped. With that check passed on 8.0.0-18, NS will then check (Flag2 & 0xF). When that is value2, the output value (used for the FIRM-launcher parameter field mentioned above) is set to value7. Otherwise, when that value is non-zero, the output value is set to 6.

In order for the exheader to have any of the above new bits set, the AccessDesc must have the corresponding bit set, otherwise the invalid-exheader error is returned.

Homebrew which runs under a title which has the above cpuspeed flag set, runs much faster on New3DS. It’s unknown how exactly the system handles these flags.

When launching titles / perhaps other things with APT, NS uses PTMSYSM:ConfigureNew3DSCPU with data which originally came from these flags; NS does this regardless of what the running 3DS system is. However, due to a bug(?) in NS the value sent to that command is always either 0x0 or 0x3. When calculating that value, the code only ever uses the cpuspeed field, not the cache field: code to actually load and check the value of the cache field appears to be missing.

When in Legacy mode, the actual memory layout is the same as in New3DS Prod, except the available application memory as reported to the application is reduced to the Old3DS size.

The exheader value for the New3DS system mode value must be ≤ to the AccessDesc value, otherwise the invalid-exheader error is returned.

Used in FSReg:Register.

File System Access Info:

When Bit1 is set, the “Extdata ID” and “Storage Accessable Unique IDs” regions are used to store a total of 6 “Accessible Save IDs”. Introduced in 6.0.0.

This is the list of services which the process is allowed to access, this is registered with the services manager. Each service listed in the exheader must be listed in the AccessDesc, otherwise the invalid exheader error is returned. The order of the services for exheader/AccessDesc doesn’t matter. The AccessDesc can list services which are not in the exheader, but normally the service-access-control data for exheader/AccessDesc are exactly the same.

This list is submitted to SRVPM:RegisterProcess.

The kernel capability descriptors are passed to svcCreateProcess.

There are different descriptor types, determined by the number of leading ones in the binary value representation of bits 20-31. The different types are laid out as follows:

Descriptors: