Nintendo Switch Brew - User contributions [en]

System Version Title

2018-03-15T05:14:42Z

Missile: /* Retail Firmware Updates */ , 4.0.0 and 5.0.0

The FS for the system-version title(TID 0100000000000809) contains "/file":

{| class=wikitable
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Major
|-
| 0x1
| 0x1
| Minor
|-
| 0x2
| 0x1
| Micro
|-
| 0x3
| 0x1
| Unknown/Build?
|-
| 0x4
| 0x1
| Revision Number
|-
| 0x5
| 0x3
| Normally all-zero. Padding?
|-
| 0x8
| 0x20
| Platform string ("NX" with zeros afterwards)
|-
| 0x28
| 0x40
| Hex ASCII string. 0x28-bytes(not including NUL-terminator) normally with zeros afterwards. The value of this string differs from [[2.0.0]] and [[2.1.0]].
|-
| 0x68
| 0x18
| System-version in string form with zeros afterwards. For example: "2.1.0". This is what is displayed in System settings.
|-
| 0x80
| 0x80
| ASCII string with zeros / padding afterwards. For example: "NintendoSDK Firmware for NX 2.0.0-15"
|}

== Known Versions ==
=== Retail Firmware Updates ===
{| class=wikitable
! Firmware
! Version String
! Hex ASCII String
|-
| 1.0.0
| NintendoSDK Firmware for NX 1.0.0-15
| 84b8da475a02261c456e6472b403b31416480165
|-
| 2.0.0
| NintendoSDK Firmware for NX 2.0.0-15
| 25233e518f580062b41f45fae7ce56bff261094a
|-
| 2.1.0
| NintendoSDK Firmware for NX 2.1.0-0
| e548f82b0aaff5fd18cfd80e7b9bd9808eeb7c99
|-
| 2.2.0
| NintendoSDK Firmware for NX 2.2.0-1
| c83b637205048e61e73c870f21271cc3c6364396
|-
| 2.3.0
| NintendoSDK Firmware for NX 2.3.0-0
| 3ed3bbc8885b6362f4f244dcecd2b430fa27310e
|-
| 3.0.0
| NintendoSDK Firmware for NX 3.0.0-10.0
| 7fbde2b0bba4d14107bf836e4643043d9f6c8e47
|-
| 3.0.1
| NintendoSDK Firmware for NX 3.0.1-0.0
| a3363e086791370ed89dca69c697b4a8bc443d66
|-
| 3.0.2
| NintendoSDK Firmware for NX 3.0.2-0.0
| 56bc7f71d0e13179ccb6543bbb33d7f537859e49
|-
| 4.0.0
| NintendoSDK Firmware for NX 4.0.0-4.0
| 875be0f6edc29b23938b7aea50764421b9f217e5
|-
| 4.0.1
| NintendoSDK Firmware for NX 4.0.1-0.0
| 826588c45cecab1672c46f5de87d83ea6008d583
|-
| 4.1.0
| NintendoSDK Firmware for NX 4.1.0-0.0
| 314f9468b704e84e1ffed449dfa6108ba4be221d
|-
| 5.0.0
| NintendoSDK Firmware for NX 5.0.0-3.0
| 66790aa646927601523df36a6750205cd944b3de
|}

=== Other ===
{| class=wikitable
! Firmware
! Version String
! Hex ASCII String
! Note
|-
| 2.0.0-2
| NintendoSDK Firmware for NX 2.0.0-2
| 665fafc03935d12eebba8060a135516b021ccbaa
| Revision of [[Factory Setup|factory firmware]].
|-
| 2.0.0-13
| NintendoSDK Firmware for NX 2.0.0-13
| 60b5fa391b0055f50fec362d29ac18395f387412
| Revision of [[Factory Setup|factory firmware]].
|-
| 3.0.0
| NintendoSDK Firmware for NX 3.0.0-10.0
| 83480e96a810a6c7cd3a8fb58dfb5b53961ac781
| Revision of [[Factory Setup|factory firmware]].
|-
|}

Flash Filesystem

2017-07-28T18:58:25Z

Missile: add a summary, also rpmb is definitely not used at all

= NAND structure =
The Switch's eMMC storage features a large user area, two smaller boot partitions, and a replay-protected memory block which is unused (no authentication key is programmed).

== Boot Partitions ==

'''Boot Partition 0 (0 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x004000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x008000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x00C000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x100000
| 0x40000
| Title 0100000000000819 "package1"
|-
| 0x140000
| 0x40000
| Title 0100000000000819 "package1" (Backup)
|-
| 0x180000
| 0x4000
| Keyblob area
|-
| 0x184000
| 0x20
| Unknown pseudorandom data, often changes on reboot. All zero on 1.0.
|-
| 0x184020
| 0x8?
| Increments on every boot until hitting a certain number? Bottom 10 bits (0x3FF) are always zero. All zero on 1.0.
|}

'''Boot Partition 1 (1 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x40000
| Title 010000000000081A "package1"
|-
| 0x040000
| 0x40000
| Title 010000000000081A "package1" (Backup)
|-
| 0x080000
| 0x40000
|
|-
| 0x0C0000
| 0x40000
|
|}

=== Keyblob ===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Keyblob AES-CMAC over the remaining 0xA0-bytes (Checked with a mem-diff function which is safe against timing attacks, calls the general panic() func on failure)
|-
| 0x10
| 0x10
| Keyblob AES CTR
|-
| 0x20
| 0x90
| Keyblob encrypted payload
|-
| 0xB0
| 0x150
| Unused, all-zero.
|}

Decrypted Keydata format:

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x80
| Array of master static key encryption keys
|-
| 0x80
| 0x10
| [[Package1|Stage 2]] key
|}

Starting at 0x180000 is an array of 0x200-byte entries, for a total of 32 keyblobs. Each one is unique compared to the others. They are all console unique.

The 0xB0-byte keyblob is installed to the "customer data" section in BCTs (BCT+0x450).

BCT offset 0x2330 is the field controlling which keyblob gets used. NS uses this to inject the appropriate keyblob on system update. [[Boot]] also uses this index for repairing corrupt sectors.

With [ [[3.0.0]] + ] index 2 is used instead of index 1.

The Tegra 210 BCT format can be found in nvidia's cbootimage [https://github.com/thierryreding/tegra-avp/blob/35f467996e532357db54894c975acab93293d219/include/avp/tegra210/bct.h#L521]

== User Partitions ==
{| class="wikitable" border="1"
|-
! Partition name
! Offset
! Size
! [[Filesystem_services|Bis]] Partition ID
! Description
|-
| N/A
| 0x0
|
| 20
| GPT header, Bis-storage also allows raw access to the entire NAND eMMC sectors starting at sector0.
|-
| PRODINFO
| 0x00004400
| 0x003FBC00
| 27
| "CAL0" raw partition containing set:cal data.
|-
| PRODINFOF
| 0x00400000
| 0x00400000
| 28
| FAT12 filesystem, additional calibration.
|-
| BCPKG2-1-Normal-Main
| 0x00800000
| 0x00800000
| 21
| For all these packages, data starts at offset 0x4000 and is not console-unique. This is installed from "package2" in firmware package A (0100000000000819) by default. With the exFAT update installed, this is switched to firmware package C (010000000000081B). The data stored here matches the raw /nx/package2 file stored in the 81[9AB] data archives -- there is no additional encryption.
|-
| BCPKG2-2-Normal-Sub
| 0x01000000
| 0x00800000
| 22
| Identical to BCPKG2-1-Normal-Main, probably used as a backup partition.
|-
| BCPKG2-3-SafeMode-Main
| 0x01800000
| 0x00800000
| 23
| This is installed from "package2" in firmware package B (010000000000081A).
|-
| BCPKG2-4-SafeMode-Sub
| 0x02000000
| 0x00800000
| 24
| Identical to BCPKG2-3-SafeMode-Main.
|-
| BCPKG2-5-Repair-Main
| 0x02800000
| 0x00800000
| 25
| Installed at the factory.
|-
| BCPKG2-6-Repair-Sub
| 0x03000000
| 0x00800000
| 26
| Identical to BCPKG2-5-Repair-Main.
|-
| SAFE
| 0x03800000
| 0x04000000
| 29
| FAT32 filesystem.
|-
| SYSTEM
| 0x07800000
| 0xA0000000
| 31 (and 32?)
| FAT32 filesystem.
|-
| USER
| 0xA7800000
| 0x680000000
| 30
| FAT32 filesystem.
|-
|
| 0x747BFFE00
| 0x200
|
| This is the backup GPT header specified by the main GPT header. This is also the last sector readable with Bis-storage paritionID 20.
|}

If the client process lacks the relevant permission for any of the above partition IDs, error 0x2EE202 is returned.

[[NCA]]s stored in NAND are raw, identical to the data readable with [[Content_Manager_services#ReadEntryRaw]].

The filenames for saveimages is just "<lower-case hex u64 saveID>". SYSTEM-partition saveIDs are specified by [[Filesystem_services|FS]] commands, while USER-partition saveIDs are determined by FS-module internally. The high u32 of the saveID is normally either 0x00000000 or 0x80000000.

=== PRODINFOF ===
PRODINFOF
├── Certifications
│ └── WirelessCertification.png
└── ptd
├── DeviceIdWithEmsBit.dat
├── Ecid.dat
├── prodCode.dat
└── log
├── Process_asm1.log
├── Process_board1.log
├── TestFlagLine.log
├── TestFlagQc.log
├── AGING
│ └── Sequence.log
├── BOARD_TEST
│ └── Sequence.log
├── BOARD_WIRELESS
│ └── Sequence.log
├── FINAL_CHECK
│ └── Sequence.log
├── LCD_AND_KEY
│ └── Sequence.log
└── USB_AND_HP
└── Sequence.log

==== DeviceIdWithEmsBit.dat ====
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the [[Settings_services|DeviceCert]].

=== SYSTEM ===
SYSTEM
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
└── saveMeta
└── ... (empty?)

The saves stored under this partition are only for system-titles / etc.

=== USER ===
USER
├── PRF2SAFE.RCV
├── Album (Same layout as [[SD_Filesystem|SD]])
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
├── saveMeta
│ └── ...
└── temp

The saves for all non-system applications, regardless of where the application is located(storageID), is stored here. Each user account which has savedata has a separate saveimage. Save-common for an application is presumably a separate saveimage too. Every saveimage here is ''only'' for applications.

=== SAFE ===
SAFE
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]] (nothing installed?)
│ └── placehld
│ └── ... [[NCA]]
└── [[Savegames|save]]
├── 8000000000000000
└── 8000000000000120

On a v2.1 system with MountBis, the only thing under here is "PRF2SAFE.RCV".

= System Savegames =

This is a listing of known System Savedata and what titles they correspond to.

{| class="wikitable" border="1"
! SaveID || Owner || Notes
|-
| 0x80000000000000d1 || erpt || Contains "/journal" report listing + actual crash reports ("/%08x-%04x-%04x-%02x%02x-%04x%08x"), which are serialized via [http://msgpack.org/ MsgPack].
|}

Cryptosystem

2017-07-27T00:08:28Z

Missile: oops, both keys are needed of course

Like the 3DS, the Switch relies on a number of cryptographic keys to prevent unauthorized persons from dumping and analyzing its software and assets. This page will focus on the "symmetric" cryptography involved in the Switch's cryptosystem.

== BootROM ==

The Switch's BootROM does no symmetric cryptographic operations. However, it sets up two keys in the hardware security engine's keyslots: the SBK (Secure Boot Key) in keyslot 0xE and the SSK (Secure Storage Key) in keyslot 0xF. Reads from both of these keyslots are disabled by the bootROM. The material used to generate these keys is stored in special fuses that have their access disabled by the bootROM.

The SBK is common to all consoles while the SSK is console unique. The SSK is not used on retail devices.
== Falcon coprocessor ==

The falcon processor (TSEC) stores a special console-unique key (that will be referred to as the "device keyblob seed generation key") in fuses that only microcode authenticated by NVidia has access to.

== Bootloader stage 0 ==

=== Key generation ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Cleared by
! Per-console
|-
| 0xB
| Pk11DecryptionKey
| [[Package1]]
| [[Package1]]
| No
|-
| 0xC
| MasterKey
| [[Package1]]
| Forever
| No
|-
| 0xD
| ConsoleKey
| [[Package1]]
| Forever
| Yes
|-
| 0xE
| SecureBootKey
| Bootrom
| [[Package1]]
| No
|-
| 0xF
| SecureStorageKey
| Bootrom
| [[Package1]]
| Yes
|}

Bootloader stage 0 generates three keys. Keyslot 0xB is cleared after it is used to decrypt the stage 2 bootloader; only keyslots 0xC and 0xD will be transferred to stage 2. Additionally, keyslots 0xC and 0xD are set read-only after they are generated. The SBK and the SSK are also cleared after use (although the SSK isn't used at all, except on dev units).

The master static key is generated by decrypting the master static seed (a constant stored in bootloader .data) with the master static key encryption key. The master static seed used varies depending on whether the console is a retail unit or a dev unit.
Both the master static key encryption key and the stage 2 key are stored in a keyblob. The keyblob format is described [[Flash_Filesystem#Keyblob|here]].

The 32 blobs are stored in the eMMC. Only one at a time is loaded, it is controlled by the bootloader version field in the BCT (at +0x2330).

Although the keydata is presumably common to all consoles, each keyblob is console-unique, because the key used to encrypt it is at the factory is console unique. Each keyblob has its own encryption key, with keyblob key N generated by decrypting keyblob key seed N with the SBK, and keyblob key seed N generated by decrypting keyblob N's seed constant with the device keyblob seed generation key obtained from the Falcon. Keyblob key 1 is special: In addition to being used to decrypt keyblob 1, it is also used to generate the master device key by decrypting a constant block.

The key used to verify a keyblob's MAC is not the keyblob key but a key derived from it; this is likely part of an attempt to mitigate side-channel attacks as the MAC is an alterable part of the keyblob.

The bootloader only stores the seed constants for the keyblob loaded by the current revision and for keyblob 1 (So that the master device key can be generated).

This mechanism provides several advantages. If the stage 2 bootloader is compromised, stage 1 can just use another master static key in the keyblob. If stage 1 itself is glitched or exploited in such a way the keyblob is dumped, Nintendo just has to change the loaded keyblob: the vulnerable bootloader won't be able to decrypt the new keyblob, as the keyblob key it knows is different from the one needed. Even if somehow an exploit or glitch allowed one to be able to use the SBK to generate keyblob keys, the seed constants for future keyblobs are unknown (and will be until Nintendo releases new bootloaders that use them), and so the exploit or glitch would have to be re-done on each new bootloader revision (if it's not patched).

Dumping the fuses and TSEC key of any single system would effectively bypass all of the above security mechanisms.

The key-derivation is described [[Package1#Key_generation|here]].

==== Table of used keyblobs ====

{| class="wikitable" border="1"
|-
! System version
! Used keyblob
! Used master static key encryption key in keyblob
|-
| 1.0.0-2.3.0
| 1
| 1
|-
| 3.0.0
| 2
| 1
|}

== Bootloader stage 1 ==

It is currently unknown what key generation the stage 2 bootloader does.

== Secure Monitor ==

The secure monitor performs some runtime cryptographic operations. See [[SMC]] for what operations it provides.

Cryptosystem

2017-07-27T00:07:07Z

Missile: nintendo and nvidia don't know what a microscope is :P

Like the 3DS, the Switch relies on a number of cryptographic keys to prevent unauthorized persons from dumping and analyzing its software and assets. This page will focus on the "symmetric" cryptography involved in the Switch's cryptosystem.

== BootROM ==

The Switch's BootROM does no symmetric cryptographic operations. However, it sets up two keys in the hardware security engine's keyslots: the SBK (Secure Boot Key) in keyslot 0xE and the SSK (Secure Storage Key) in keyslot 0xF. Reads from both of these keyslots are disabled by the bootROM. The material used to generate these keys is stored in special fuses that have their access disabled by the bootROM.

The SBK is common to all consoles while the SSK is console unique. The SSK is not used on retail devices.
== Falcon coprocessor ==

The falcon processor (TSEC) stores a special console-unique key (that will be referred to as the "device keyblob seed generation key") in fuses that only microcode authenticated by NVidia has access to.

== Bootloader stage 0 ==

=== Key generation ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Cleared by
! Per-console
|-
| 0xB
| Pk11DecryptionKey
| [[Package1]]
| [[Package1]]
| No
|-
| 0xC
| MasterKey
| [[Package1]]
| Forever
| No
|-
| 0xD
| ConsoleKey
| [[Package1]]
| Forever
| Yes
|-
| 0xE
| SecureBootKey
| Bootrom
| [[Package1]]
| No
|-
| 0xF
| SecureStorageKey
| Bootrom
| [[Package1]]
| Yes
|}

Bootloader stage 0 generates three keys. Keyslot 0xB is cleared after it is used to decrypt the stage 2 bootloader; only keyslots 0xC and 0xD will be transferred to stage 2. Additionally, keyslots 0xC and 0xD are set read-only after they are generated. The SBK and the SSK are also cleared after use (although the SSK isn't used at all, except on dev units).

The master static key is generated by decrypting the master static seed (a constant stored in bootloader .data) with the master static key encryption key. The master static seed used varies depending on whether the console is a retail unit or a dev unit.
Both the master static key encryption key and the stage 2 key are stored in a keyblob. The keyblob format is described [[Flash_Filesystem#Keyblob|here]].

The 32 blobs are stored in the eMMC. Only one at a time is loaded, it is controlled by the bootloader version field in the BCT (at +0x2330).

Although the keydata is presumably common to all consoles, each keyblob is console-unique, because the key used to encrypt it is at the factory is console unique. Each keyblob has its own encryption key, with keyblob key N generated by decrypting keyblob key seed N with the SBK, and keyblob key seed N generated by decrypting keyblob N's seed constant with the device keyblob seed generation key obtained from the Falcon. Keyblob key 1 is special: In addition to being used to decrypt keyblob 1, it is also used to generate the master device key by decrypting a constant block.

The key used to verify a keyblob's MAC is not the keyblob key but a key derived from it; this is likely part of an attempt to mitigate side-channel attacks as the MAC is an alterable part of the keyblob.

The bootloader only stores the seed constants for the keyblob loaded by the current revision and for keyblob 1 (So that the master device key can be generated).

This mechanism provides several advantages. If the stage 2 bootloader is compromised, stage 1 can just use another master static key in the keyblob. If stage 1 itself is glitched or exploited in such a way the keyblob is dumped, Nintendo just has to change the loaded keyblob: the vulnerable bootloader won't be able to decrypt the new keyblob, as the keyblob key it knows is different from the one needed. Even if somehow an exploit or glitch allowed one to be able to use the SBK to generate keyblob keys, the seed constants for future keyblobs are unknown (and will be until Nintendo releases new bootloaders that use them), and so the exploit or glitch would have to be re-done on each new bootloader revision (if it's not patched).

Dumping the fuses of any single system would effectively bypass all of the above security mechanisms.

The key-derivation is described [[Package1#Key_generation|here]].

==== Table of used keyblobs ====

{| class="wikitable" border="1"
|-
! System version
! Used keyblob
! Used master static key encryption key in keyblob
|-
| 1.0.0-2.3.0
| 1
| 1
|-
| 3.0.0
| 2
| 1
|}

== Bootloader stage 1 ==

It is currently unknown what key generation the stage 2 bootloader does.

== Secure Monitor ==

The secure monitor performs some runtime cryptographic operations. See [[SMC]] for what operations it provides.

Package1

2017-07-26T23:50:57Z

Missile: clarify and clean up grammar in downgrade check section

The Nintendo Switch's bootloader (called "package1") is the first custom piece of code running on the Switch. It is loaded in the IRAM and launched by the Tegra X1 bootROM according to the BCT. It runs on the boot processor, an ARM7TDMI called "BPMP" by NVidia (Boot and Power Management Processor).
It is split into two parts, one that is in plaintext, one that is encrypted. The bootROM does not perform any symmetric cryptographic operations on the bootloader it loads.

== Stage 1 ==

The first stage of the bootloader is the plaintext part of the bootloader. It has four goals: to power on devices, to look for incoherencies, to generate keys, and to decrypt and launch the second stage.
The stage 1 bootloader's authors knew that the code was in plaintext, and thus took extra care to try to protect the bootloader from side-channel attacks.

=== Execution flow ===

==== Startup ====

After setting up the stack and branching to main, stage 1 poisons all the exception vectors to point at the panic function.
It then clears the (empty) bss and calls the functions in the (empty) init array.

==== Main ====

* Registers are setup
* A device (?) is powered on
* Flags are set on the clock-reset registers
* [3.0.0+] The security engine address is setup
* [3.0.0+] Bit30 of offset 0x800 of the security engine is checked: if set, panic.
* The SKU info is checked. If it doesn't match 0x83, panic.
* Fuse coherency is checked, potentially panicking.
* The copy of the BCT left by the bootROM is checked. If the version field doesn't match the expected version field, panic.
* Anti-downgrade fuses are checked, potentially panicking.
* [1.0.0-2.3.0] Fuse programming is disabled until next reboot.
* The memory controller is powered on and setup to allow GPU DMA to the IRAM. This will be needed to interact with the Falcon and with the security engine.
* [1.0.0-2.3.0] The security engine address is setup
* [1.0.0-2.3.0] Bit30 of offset 0x800 of the security engine is checked: if set, panic.
* Key generation is performed. If the unit type is equal to 0 (non-retail) AND if some fuse is clear, the secondary method will be used. Else, the main method will be used.
* Stage 2 is decrypted with keyslot 0xB. Keyslot 0xB is cleared, and the second stage's header validity is checked. If any of this fails, panic.
* The entrypoint of stage 2 is computed.
* The stack is pivoted to a secondary stack, the main stack and the key area are cleared, and stage 1 jumps to stage 2's entrypoint.

==== Fuse coherency ====

Unit type is computed from data from a fuse. It must be either 0 (non-retail) or 1 (retail). If it's neither, 2 will be returned by the function, and the check will call panic.

==== Downgrade check ====

The bootloader verifies a lockdown fuse counter to prevent downgrading. A 32-bit lockdown value at fuse offset 0x1E4 is checked. If too many fuses are burned the bootloader will panic. If too few are burned, the bootloader will program the expected number of bits and force a reset. The expected lockdown value differs between unit type 0 (non-retail) and unit type 1 (retail).

{| class="wikitable" border="1"
|-
! System version
! Expected number of burnt fuses (retail)
! Expected number of burnt fuses (non-retail)
|-
| 1.0.0
| 1
| 0
|-
| 2.0.0-2.3.0
| 2
| 0
|-
| 3.0.0
| 3
| 1
|}

==== Panic ====

The panic function does the following things:
* It clears the stack
* It disables(?) and clears the security engine
* It disables fuse programming
* It clears the key area
* It clears the data for stage 2
* It signals over the debug interface that a panic occurred until the Switch is reset.

=== Key generation ===
For more detail on the Switch's Cryptosystem, please see [[Cryptosystem|this page]].

In all cases, at the end of the key generation function three keys are generated: the stage 2 key (stored in keyslot 0xB), the master static key (stored in keyslot 0xC), and the master device key (stored in keyslot 0xD).
The two keys initialized by the bootROM (the SBK, stored in keyslot 0xE, and the SSK, stored in keyslot 0xF) are cleared immediately after the bootloader is finished using them.
Keyslots 0xC and 0xD are marked unreadable. Keyslot 0xB is not, but is is cleared by stage 1 after stage 2's decryption anyway.

==== Main method ====

This method is called when the unit type is equal to 1 (retail) OR when unit type is equal to 0 and some fuse is set.

The master static seed selected depends on whether the unit type is zero and whether the last byte of the bootloader's RSA modulus is 0x4F.

* Falcon microcode is loaded, the device keyblob seed generation key is obtained from the Falcon.
* The device keyblob seed generation key is stored in keyslot 0xD.
* [3.0.0+] keyblob key seed 1 is generated by decrypting the keyblob seed constant 1 with the device keyblob seed generation key
* [3.0.0+] keyblob key 1 is generated by decrypting keyblob key seed 1 with the SBK. The result is directly stored in keyslot 0xA without leaving the crypto engine.
* keyblob key seed N is generated by decrypting the keyblob seed constant N with the device keyblob seed generation key
* keyblob key N is generated by decrypting keyblob key seed N with the SBK. The result is directly stored in keyslot 0xD without leaving the crypto engine.
* The SBK and the SSK are cleared.
* The constant MAC key generator block is decrypted with keyblob key N to generate keyblob MAC key N. The result is directly stored in keyslot 0xB without leaving the crypto engine.
* With keyblob MAC key N, AES CMAC is performed over the keyblob.
* With a comparison function which is safe against timing attacks, the CMAC is compared with the stored CMAC. If they differ, panic is called.
* The keyblob data is decrypted with AES-CTR, using the keyblob key N and the stored CTR.
* The stage 2 decryption key (the ninth key in the blob) is loaded in keyslot 0xB.
* The master static key encryption key. is loaded in keyslot 0xC.
* The decrypted keyblob data is erased.
* The master static key is generated by decrypting the master static seed with the master static key encryption key. The result is directly stored in keyslot 0xC without leaving the crypto engine.
* [1.0.0-2.3.0] The master device key is generated by decrypting a constant block with keyslot 0xD (which contains keyblob N's key 1). The result is directly stored in keyslot 0xD without leaving the crypto engine.
* [3.0.0+] The master device key is generated by decrypting a constant block with keyslot 0xA (which contains keyblob 1's key 1). The result is directly stored in keyslot 0xD without leaving the crypto engine.
* [3.0.0+] Keyslot 0xA is cleared.

==== Secondary method ====

The secondary method (which is never launched on retail units) is very simple.
First a master static seed is selected (depending on whether the bootloader's RSA modulus ends with 0x11).
Then, a constant block is decrypted by the SBK. The result is the stage 2 key and will be stored in keyslot 0xB.
A constant block will be decrypted by the SBK and temporarily stored in keyslot 0xC. Another constant block will be decrypted by the SSK and temporarily stored in keyslot 0xD.
Both the SBK and the SSK are cleared.
The master static seed is decrypted with keyslot 0xC and stored in keyslot 0xC.
A constant block is decrypted with keyslot 0xD and stored in keyslot 0xD.

== Stage 2 (package1.1) ==

The second stage of the bootloader is the encrypted part of the bootloader. It is much bigger than stage 1, but what it does is currently unknown due to its being encrypted.

=== Header format ===

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| Magic "PK11"
|-
| 0x4
| 4
| Size of section 3
|-
| 0x8
| 8
| Unknown
|-
| 0x10
| 4
| Size of section 2
|-
| 0x14
| 4
| Entrypoint of section 2
|-
| 0x18
| 4
| Size of section 1
|-
| 0x1C
| 4
| Entrypoint of section 1?
|}

Entrypoints are relative to the section.
Stage 1 jumps to the entrypoint of section 2.

Package1

2017-07-26T23:34:58Z

Missile: LDV > expected just immediately panics

The Nintendo Switch's bootloader (called "package1") is the first custom piece of code running on the Switch. It is loaded in the IRAM and launched by the Tegra X1 bootROM according to the BCT. It runs on the boot processor, an ARM7TDMI called "BPMP" by NVidia (Boot and Power Management Processor).
It is split into two parts, one that is in plaintext, one that is encrypted. The bootROM does not perform any symmetric cryptographic operations on the bootloader it loads.

== Stage 1 ==

The first stage of the bootloader is the plaintext part of the bootloader. It has four goals: to power on devices, to look for incoherencies, to generate keys, and to decrypt and launch the second stage.
The stage 1 bootloader's authors knew that the code was in plaintext, and thus took extra care to try to protect the bootloader from side-channel attacks.

=== Execution flow ===

==== Startup ====

After setting up the stack and branching to main, stage 1 poisons all the exception vectors to point at the panic function.
It then clears the (empty) bss and calls the functions in the (empty) init array.

==== Main ====

* Registers are setup
* A device (?) is powered on
* Flags are set on the clock-reset registers
* [3.0.0+] The security engine address is setup
* [3.0.0+] Bit30 of offset 0x800 of the security engine is checked: if set, panic.
* The SKU info is checked. If it doesn't match 0x83, panic.
* Fuse coherency is checked, potentially panicking.
* The copy of the BCT left by the bootROM is checked. If the version field doesn't match the expected version field, panic.
* Anti-downgrade fuses are checked, potentially panicking.
* [1.0.0-2.3.0] Fuse programming is disabled until next reboot.
* The memory controller is powered on and setup to allow GPU DMA to the IRAM. This will be needed to interact with the Falcon and with the security engine.
* [1.0.0-2.3.0] The security engine address is setup
* [1.0.0-2.3.0] Bit30 of offset 0x800 of the security engine is checked: if set, panic.
* Key generation is performed. If the unit type is equal to 0 (non-retail) AND if some fuse is clear, the secondary method will be used. Else, the main method will be used.
* Stage 2 is decrypted with keyslot 0xB. Keyslot 0xB is cleared, and the second stage's header validity is checked. If any of this fails, panic.
* The entrypoint of stage 2 is computed.
* The stack is pivoted to a secondary stack, the main stack and the key area are cleared, and stage 1 jumps to stage 2's entrypoint.

==== Fuse coherency ====

Unit type is computed from data from a fuse. It must be either 0 (non-retail) or 1 (retail). If it's neither, 2 will be returned by the function, and the check will call panic.

==== Downgrade check ====

The bootloader will check if someone attempted to downgrade it. A fuse array will be checked, if too many fuses are burnt the bootloader will panic. If too little are set, the bootloader will program the expected bitmap and force a reset. The fuse array and the expected number of burnt fuses is different on unit type 0 (non-retail) and unit type 1 (retail).

{| class="wikitable" border="1"
|-
! System version
! Expected number of burnt fuses (retail)
! Expected number of burnt fuses (non-retail)
|-
| 1.0.0
| 1
| 0
|-
| 2.0.0-2.3.0
| 2
| 0
|-
| 3.0.0
| 3
| 1
|}

==== Panic ====

The panic function does the following things:
* It clears the stack
* It disables(?) and clears the security engine
* It disables fuse programming
* It clears the key area
* It clears the data for stage 2
* It signals over the debug interface that a panic occurred until the Switch is reset.

=== Key generation ===
For more detail on the Switch's Cryptosystem, please see [[Cryptosystem|this page]].

In all cases, at the end of the key generation function three keys are generated: the stage 2 key (stored in keyslot 0xB), the master static key (stored in keyslot 0xC), and the master device key (stored in keyslot 0xD).
The two keys initialized by the bootROM (the SBK, stored in keyslot 0xE, and the SSK, stored in keyslot 0xF) are cleared immediately after the bootloader is finished using them.
Keyslots 0xC and 0xD are marked unreadable. Keyslot 0xB is not, but is is cleared by stage 1 after stage 2's decryption anyway.

==== Main method ====

This method is called when the unit type is equal to 1 (retail) OR when unit type is equal to 0 and some fuse is set.

The master static seed selected depends on whether the unit type is zero and whether the last byte of the bootloader's RSA modulus is 0x4F.

* Falcon microcode is loaded, the device keyblob seed generation key is obtained from the Falcon.
* The device keyblob seed generation key is stored in keyslot 0xD.
* [3.0.0+] keyblob key seed 1 is generated by decrypting the keyblob seed constant 1 with the device keyblob seed generation key
* [3.0.0+] keyblob key 1 is generated by decrypting keyblob key seed 1 with the SBK. The result is directly stored in keyslot 0xA without leaving the crypto engine.
* keyblob key seed N is generated by decrypting the keyblob seed constant N with the device keyblob seed generation key
* keyblob key N is generated by decrypting keyblob key seed N with the SBK. The result is directly stored in keyslot 0xD without leaving the crypto engine.
* The SBK and the SSK are cleared.
* The constant MAC key generator block is decrypted with keyblob key N to generate keyblob MAC key N. The result is directly stored in keyslot 0xB without leaving the crypto engine.
* With keyblob MAC key N, AES CMAC is performed over the keyblob.
* With a comparison function which is safe against timing attacks, the CMAC is compared with the stored CMAC. If they differ, panic is called.
* The keyblob data is decrypted with AES-CTR, using the keyblob key N and the stored CTR.
* The stage 2 decryption key (the ninth key in the blob) is loaded in keyslot 0xB.
* The master static key encryption key. is loaded in keyslot 0xC.
* The decrypted keyblob data is erased.
* The master static key is generated by decrypting the master static seed with the master static key encryption key. The result is directly stored in keyslot 0xC without leaving the crypto engine.
* [1.0.0-2.3.0] The master device key is generated by decrypting a constant block with keyslot 0xD (which contains keyblob N's key 1). The result is directly stored in keyslot 0xD without leaving the crypto engine.
* [3.0.0+] The master device key is generated by decrypting a constant block with keyslot 0xA (which contains keyblob 1's key 1). The result is directly stored in keyslot 0xD without leaving the crypto engine.
* [3.0.0+] Keyslot 0xA is cleared.

==== Secondary method ====

The secondary method (which is never launched on retail units) is very simple.
First a master static seed is selected (depending on whether the bootloader's RSA modulus ends with 0x11).
Then, a constant block is decrypted by the SBK. The result is the stage 2 key and will be stored in keyslot 0xB.
A constant block will be decrypted by the SBK and temporarily stored in keyslot 0xC. Another constant block will be decrypted by the SSK and temporarily stored in keyslot 0xD.
Both the SBK and the SSK are cleared.
The master static seed is decrypted with keyslot 0xC and stored in keyslot 0xC.
A constant block is decrypted with keyslot 0xD and stored in keyslot 0xD.

== Stage 2 (package1.1) ==

The second stage of the bootloader is the encrypted part of the bootloader. It is much bigger than stage 1, but what it does is currently unknown due to its being encrypted.

=== Header format ===

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| Magic "PK11"
|-
| 0x4
| 4
| Size of section 3
|-
| 0x8
| 8
| Unknown
|-
| 0x10
| 4
| Size of section 2
|-
| 0x14
| 4
| Entrypoint of section 2
|-
| 0x18
| 4
| Size of section 1
|-
| 0x1C
| 4
| Entrypoint of section 1?
|}

Entrypoints are relative to the section.
Stage 1 jumps to the entrypoint of section 2.

Flash Filesystem

2017-07-19T01:54:34Z

Missile: beats me

= NAND structure =

== Boot Partitions ==

'''Boot Partition 0 (0 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x004000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x008000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x00C000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x100000
| 0x40000
| Title 0100000000000819 "package1"
|-
| 0x140000
| 0x40000
| Title 0100000000000819 "package1" (Backup)
|-
| 0x180000
| 0x4000
| Keyblob area
|-
| 0x184000
| 0x20
| Unknown pseudorandom data, often changes on reboot. All zero on 1.0.
|-
| 0x184020
| 0x8?
| Increments on every boot until hitting a certain number? Bottom 10 bits (0x3FF) are always zero. All zero on 1.0.
|}

'''Boot Partition 1 (1 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x40000
| Title 010000000000081A "package1"
|-
| 0x040000
| 0x40000
| Title 010000000000081A "package1" (Backup)
|-
| 0x080000
| 0x40000
|
|-
| 0x0C0000
| 0x40000
|
|}

=== Keyblob ===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Keyblob AES-CMAC over the remaining 0xA0-bytes (Checked with a mem-diff function which is safe against timing attacks, calls the general panic() func on failure)
|-
| 0x10
| 0x10
| Keyblob AES CTR
|-
| 0x20
| 0x90
| Keyblob encrypted payload
|-
| 0xB0
| 0x150
| Unused, all-zero.
|}

Starting at 0x180000 is an array of 0x200-byte entries, for a total of 32 keyblobs. Each one is unique compared to the others. They are all console unique.

The 0xB0-byte keyblob is installed to the "customer data" section in BCTs (BCT+0x450).

BCT offset 0x2330 is the field controlling which keyblob gets used. NS uses this to inject the appropriate keyblob on system update. [[Boot]] also uses this index for repairing corrupt sectors.

With [ [[3.0.0]] + ] index 2 is used instead of index 1.

The Tegra 210 BCT format can be found in nvidia's cbootimage [https://github.com/thierryreding/tegra-avp/blob/35f467996e532357db54894c975acab93293d219/include/avp/tegra210/bct.h#L521]

== User Partitions ==
{| class="wikitable" border="1"
|-
! Partition name
! Offset
! Size
! [[Filesystem_services|Bis]] Partition ID
! Description
|-
| N/A
| 0x0
|
| 20
| GPT header, Bis-storage also allows raw access to the entire NAND eMMC sectors starting at sector0.
|-
| PRODINFO
| 0x00004400
| 0x003FBC00
| 27
| "CAL0" raw partition containing set:cal data.
|-
| PRODINFOF
| 0x00400000
| 0x00400000
| 28
| FAT12 filesystem, additional calibration.
|-
| BCPKG2-1-Normal-Main
| 0x00800000
| 0x00800000
| 21
| For all these packages, data starts at offset 0x4000 and is not console-unique. This is installed from "package2" in firmware package A (0100000000000819) by default. With the exFAT update installed, this is switched to firmware package C (010000000000081B). The data stored here matches the raw /nx/package2 file stored in the 81[9AB] data archives -- there is no additional encryption.
|-
| BCPKG2-2-Normal-Sub
| 0x01000000
| 0x00800000
| 22
| Identical to BCPKG2-1-Normal-Main, probably used as a backup partition.
|-
| BCPKG2-3-SafeMode-Main
| 0x01800000
| 0x00800000
| 23
| This is installed from "package2" in firmware package B (010000000000081A).
|-
| BCPKG2-4-SafeMode-Sub
| 0x02000000
| 0x00800000
| 24
| Identical to BCPKG2-3-SafeMode-Main.
|-
| BCPKG2-5-Repair-Main
| 0x02800000
| 0x00800000
| 25
| Installed at the factory.
|-
| BCPKG2-6-Repair-Sub
| 0x03000000
| 0x00800000
| 26
| Identical to BCPKG2-5-Repair-Main.
|-
| SAFE
| 0x03800000
| 0x04000000
| 29
| FAT32 filesystem.
|-
| SYSTEM
| 0x07800000
| 0xA0000000
| 31 (and 32?)
| FAT32 filesystem.
|-
| USER
| 0xA7800000
| 0x680000000
| 30
| FAT32 filesystem.
|-
|
| 0x747BFFE00
| 0x200
|
| This is the backup GPT header specified by the main GPT header. This is also the last sector readable with Bis-storage paritionID 20.
|}

If the client process lacks the relevant permission for any of the above partition IDs, error 0x2EE202 is returned.

[[NCA]]s stored in NAND are raw, identical to the data readable with [[Content_Manager_services#ReadEntryRaw]].

The filenames for saveimages is just "<lower-case hex u64 saveID>". SYSTEM-partition saveIDs are specified by [[Filesystem_services|FS]] commands, while USER-partition saveIDs are determined by FS-module internally. The high u32 of the saveID is normally either 0x00000000 or 0x80000000.

=== PRODINFOF ===
PRODINFOF
├── Certifications
│ └── WirelessCertification.png
└── ptd
├── DeviceIdWithEmsBit.dat
├── Ecid.dat
├── prodCode.dat
└── log
├── Process_asm1.log
├── Process_board1.log
├── TestFlagLine.log
├── TestFlagQc.log
├── AGING
│ └── Sequence.log
├── BOARD_TEST
│ └── Sequence.log
├── BOARD_WIRELESS
│ └── Sequence.log
├── FINAL_CHECK
│ └── Sequence.log
├── LCD_AND_KEY
│ └── Sequence.log
└── USB_AND_HP
└── Sequence.log

==== DeviceIdWithEmsBit.dat ====
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the [[Settings_services|DeviceCert]].

=== SYSTEM ===
SYSTEM
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
└── saveMeta
└── ... (empty?)

The saves stored under this partition are only for system-titles / etc.

=== USER ===
USER
├── PRF2SAFE.RCV
├── Album (Same layout as [[SD_Filesystem|SD]])
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
├── saveMeta
│ └── ...
└── temp

The saves for all non-system applications, regardless of where the application is located(storageID), is stored here. Each user account which has savedata has a separate saveimage. Save-common for an application is presumably a separate saveimage too. Every saveimage here is ''only'' for applications.

=== SAFE ===
SAFE
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]] (nothing installed?)
│ └── placehld
│ └── ... [[NCA]]
└── [[Savegames|save]]
├── 8000000000000000
└── 8000000000000120

On a v2.1 system with MountBis, the only thing under here is "PRF2SAFE.RCV".

= System Savegames =

This is a listing of known System Savedata and what titles they correspond to.

{| class="wikitable" border="1"
! SaveID || Owner || Notes
|-
| 0x80000000000000d1 || erpt || Contains "/journal" report listing + actual crash reports ("/%08x-%04x-%04x-%02x%02x-%04x%08x"), which are serialized via [http://msgpack.org/ MsgPack].
|}

Flash Filesystem

2017-07-18T22:43:05Z

Missile: 0x184000 analysis - feel free to break this out into its own section if it's cluttery or more is discovered

= NAND structure =

== Boot Partitions ==

'''Boot Partition 0 (0 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x004000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x008000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x00C000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x100000
| 0x40000
| Title 0100000000000819 "package1"
|-
| 0x140000
| 0x40000
| Title 0100000000000819 "package1" (Backup)
|-
| 0x180000
| 0x4000
| Keyblob area
|-
| 0x184000
| 0x20
| Unknown pseudorandom data, changes every boot. All zero on 1.0.
|-
| 0x184020
| 0x8?
| Increments on every boot. Bottom 10 bits (0x3FF) are always zero. All zero on 1.0.
|}

'''Boot Partition 1 (1 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x40000
| Title 010000000000081A "package1"
|-
| 0x040000
| 0x40000
| Title 010000000000081A "package1" (Backup)
|-
| 0x080000
| 0x40000
|
|-
| 0x0C0000
| 0x40000
|
|}

=== Keyblob ===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Keyblob AES-CMAC over the remaining 0xA0-bytes (Checked with a mem-diff function which is safe against timing attacks, calls the general panic() func on failure)
|-
| 0x10
| 0x10
| Keyblob AES CTR
|-
| 0x20
| 0x90
| Keyblob encrypted payload
|-
| 0xB0
| 0x150
| Unused, all-zero.
|}

Starting at 0x180000 is an array of 0x200-byte entries, for a total of 32 keyblobs. Each one is unique compared to the others. They are all console unique.

The 0xB0-byte keyblob is installed to the "customer data" section in BCTs (BCT+0x450).

BCT offset 0x2330 is the field controlling which keyblob gets used. NS uses this to inject the appropriate keyblob on system update. [[Boot]] also uses this index for repairing corrupt sectors.

With [ [[3.0.0]] + ] index 2 is used instead of index 1.

The Tegra 210 BCT format can be found in nvidia's cbootimage [https://github.com/thierryreding/tegra-avp/blob/35f467996e532357db54894c975acab93293d219/include/avp/tegra210/bct.h#L521]

== User Partitions ==
{| class="wikitable" border="1"
|-
! Partition name
! Offset
! Size
! [[Filesystem_services|Bis]] Partition ID
! Description
|-
| N/A
| 0x0
|
| 20
| GPT header, Bis-storage also allows raw access to the entire NAND eMMC sectors starting at sector0.
|-
| PRODINFO
| 0x00004400
| 0x003FBC00
| 27
| "CAL0" raw partition containing set:cal data.
|-
| PRODINFOF
| 0x00400000
| 0x00400000
| 28
| FAT12 filesystem, additional calibration.
|-
| BCPKG2-1-Normal-Main
| 0x00800000
| 0x00800000
| 21
| For all these packages, data starts at offset 0x4000 and is not console-unique. This is installed from "package2" in firmware package A (0100000000000819) by default. With the exFAT update installed, this is switched to firmware package C (010000000000081B). The data stored here matches the raw /nx/package2 file stored in the 81[9AB] data archives -- there is no additional encryption.
|-
| BCPKG2-2-Normal-Sub
| 0x01000000
| 0x00800000
| 22
| Identical to BCPKG2-1-Normal-Main, probably used as a backup partition.
|-
| BCPKG2-3-SafeMode-Main
| 0x01800000
| 0x00800000
| 23
| This is installed from "package2" in firmware package B (010000000000081A).
|-
| BCPKG2-4-SafeMode-Sub
| 0x02000000
| 0x00800000
| 24
| Identical to BCPKG2-3-SafeMode-Main.
|-
| BCPKG2-5-Repair-Main
| 0x02800000
| 0x00800000
| 25
| Installed at the factory.
|-
| BCPKG2-6-Repair-Sub
| 0x03000000
| 0x00800000
| 26
| Identical to BCPKG2-5-Repair-Main.
|-
| SAFE
| 0x03800000
| 0x04000000
| 29
| FAT32 filesystem.
|-
| SYSTEM
| 0x07800000
| 0xA0000000
| 31 (and 32?)
| FAT32 filesystem.
|-
| USER
| 0xA7800000
| 0x680000000
| 30
| FAT32 filesystem.
|-
|
| 0x747BFFE00
| 0x200
|
| This is the backup GPT header specified by the main GPT header. This is also the last sector readable with Bis-storage paritionID 20.
|}

If the client process lacks the relevant permission for any of the above partition IDs, error 0x2EE202 is returned.

[[NCA]]s stored in NAND are raw, identical to the data readable with [[Content_Manager_services#ReadEntryRaw]].

The filenames for saveimages is just "<lower-case hex u64 saveID>". SYSTEM-partition saveIDs are specified by [[Filesystem_services|FS]] commands, while USER-partition saveIDs are determined by FS-module internally. The high u32 of the saveID is normally either 0x00000000 or 0x80000000.

=== PRODINFOF ===
PRODINFOF
├── Certifications
│ └── WirelessCertification.png
└── ptd
├── DeviceIdWithEmsBit.dat
├── Ecid.dat
├── prodCode.dat
└── log
├── Process_asm1.log
├── Process_board1.log
├── TestFlagLine.log
├── TestFlagQc.log
├── AGING
│ └── Sequence.log
├── BOARD_TEST
│ └── Sequence.log
├── BOARD_WIRELESS
│ └── Sequence.log
├── FINAL_CHECK
│ └── Sequence.log
├── LCD_AND_KEY
│ └── Sequence.log
└── USB_AND_HP
└── Sequence.log

==== DeviceIdWithEmsBit.dat ====
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the [[Settings_services|DeviceCert]].

=== SYSTEM ===
SYSTEM
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
└── saveMeta
└── ... (empty?)

The saves stored under this partition are only for system-titles / etc.

=== USER ===
USER
├── PRF2SAFE.RCV
├── Album (Same layout as [[SD_Filesystem|SD]])
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
├── saveMeta
│ └── ...
└── temp

The saves for all non-system applications, regardless of where the application is located(storageID), is stored here. Each user account which has savedata has a separate saveimage. Save-common for an application is presumably a separate saveimage too. Every saveimage here is ''only'' for applications.

=== SAFE ===
SAFE
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]] (nothing installed?)
│ └── placehld
│ └── ... [[NCA]]
└── [[Savegames|save]]
├── 8000000000000000
└── 8000000000000120

On a v2.1 system with MountBis, the only thing under here is "PRF2SAFE.RCV".

= System Savegames =

This is a listing of known System Savedata and what titles they correspond to.

{| class="wikitable" border="1"
! SaveID || Owner || Notes
|-
| 0x80000000000000d1 || erpt || Contains "/journal" report listing + actual crash reports ("/%08x-%04x-%04x-%02x%02x-%04x%08x"), which are serialized via [http://msgpack.org/ MsgPack].
|}

Flash Filesystem

2017-07-18T22:11:31Z

Missile: clarify the intention of cmac check function, this is actually identical to a fix deployed on xbox360 cb

= NAND structure =

== Boot Partitions ==

'''Boot Partition 0 (0 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x004000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x008000
| 0x4000
| Title 0100000000000819 BCT
|-
| 0x00C000
| 0x4000
| Title 010000000000081A BCT
|-
| 0x100000
| 0x40000
| Title 0100000000000819 "package1"
|-
| 0x140000
| 0x40000
| Title 0100000000000819 "package1" (Backup)
|-
| 0x180000
| 0x4000
| Keyblob area
|-
| 0x184000
|
| Unknown, 0x20-bytes hash (updated when bcpkg-2-1 updates) + one u64? (may be incremented on bcpkg update) All zero on 1.0.
|}

'''Boot Partition 1 (1 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
| 0x40000
| Title 010000000000081A "package1"
|-
| 0x040000
| 0x40000
| Title 010000000000081A "package1" (Backup)
|-
| 0x080000
| 0x40000
|
|-
| 0x0C0000
| 0x40000
|
|}

=== Keyblob ===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Keyblob AES-CMAC over the remaining 0xA0-bytes (Checked with a mem-diff function which is safe against timing attacks, calls the general panic() func on failure)
|-
| 0x10
| 0x10
| Keyblob AES CTR
|-
| 0x20
| 0x90
| Keyblob encrypted payload
|-
| 0xB0
| 0x150
| Unused, all-zero.
|}

Starting at 0x180000 is an array of 0x200-byte entries, for a total of 32 keyblobs. Each one is unique compared to the others. They are all console unique.

The 0xB0-byte keyblob is installed to the "customer data" section in BCTs (BCT+0x450).

BCT offset 0x2330 is the field controlling which keyblob gets used. NS uses this to inject the appropriate keyblob on system update. [[Boot]] also uses this index for repairing corrupt sectors.

With [ [[3.0.0]] + ] index 2 is used instead of index 1.

The Tegra 210 BCT format can be found in nvidia's cbootimage [https://github.com/thierryreding/tegra-avp/blob/35f467996e532357db54894c975acab93293d219/include/avp/tegra210/bct.h#L521]

== User Partitions ==
{| class="wikitable" border="1"
|-
! Partition name
! Offset
! Size
! [[Filesystem_services|Bis]] Partition ID
! Description
|-
| N/A
| 0x0
|
| 20
| GPT header, Bis-storage also allows raw access to the entire NAND eMMC sectors starting at sector0.
|-
| PRODINFO
| 0x00004400
| 0x003FBC00
| 27
| "CAL0" raw partition containing set:cal data.
|-
| PRODINFOF
| 0x00400000
| 0x00400000
| 28
| FAT12 filesystem, additional calibration.
|-
| BCPKG2-1-Normal-Main
| 0x00800000
| 0x00800000
| 21
| For all these packages, data starts at offset 0x4000 and is not console-unique. This is installed from "package2" in firmware package A (0100000000000819) by default. With the exFAT update installed, this is switched to firmware package C (010000000000081B). The data stored here matches the raw /nx/package2 file stored in the 81[9AB] data archives -- there is no additional encryption.
|-
| BCPKG2-2-Normal-Sub
| 0x01000000
| 0x00800000
| 22
| Identical to BCPKG2-1-Normal-Main, probably used as a backup partition.
|-
| BCPKG2-3-SafeMode-Main
| 0x01800000
| 0x00800000
| 23
| This is installed from "package2" in firmware package B (010000000000081A).
|-
| BCPKG2-4-SafeMode-Sub
| 0x02000000
| 0x00800000
| 24
| Identical to BCPKG2-3-SafeMode-Main.
|-
| BCPKG2-5-Repair-Main
| 0x02800000
| 0x00800000
| 25
| Installed at the factory.
|-
| BCPKG2-6-Repair-Sub
| 0x03000000
| 0x00800000
| 26
| Identical to BCPKG2-5-Repair-Main.
|-
| SAFE
| 0x03800000
| 0x04000000
| 29
| FAT32 filesystem.
|-
| SYSTEM
| 0x07800000
| 0xA0000000
| 31 (and 32?)
| FAT32 filesystem.
|-
| USER
| 0xA7800000
| 0x680000000
| 30
| FAT32 filesystem.
|-
|
| 0x747BFFE00
| 0x200
|
| This is the backup GPT header specified by the main GPT header. This is also the last sector readable with Bis-storage paritionID 20.
|}

If the client process lacks the relevant permission for any of the above partition IDs, error 0x2EE202 is returned.

[[NCA]]s stored in NAND are raw, identical to the data readable with [[Content_Manager_services#ReadEntryRaw]].

The filenames for saveimages is just "<lower-case hex u64 saveID>". SYSTEM-partition saveIDs are specified by [[Filesystem_services|FS]] commands, while USER-partition saveIDs are determined by FS-module internally. The high u32 of the saveID is normally either 0x00000000 or 0x80000000.

=== PRODINFOF ===
PRODINFOF
├── Certifications
│ └── WirelessCertification.png
└── ptd
├── DeviceIdWithEmsBit.dat
├── Ecid.dat
├── prodCode.dat
└── log
├── Process_asm1.log
├── Process_board1.log
├── TestFlagLine.log
├── TestFlagQc.log
├── AGING
│ └── Sequence.log
├── BOARD_TEST
│ └── Sequence.log
├── BOARD_WIRELESS
│ └── Sequence.log
├── FINAL_CHECK
│ └── Sequence.log
├── LCD_AND_KEY
│ └── Sequence.log
└── USB_AND_HP
└── Sequence.log

==== DeviceIdWithEmsBit.dat ====
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the [[Settings_services|DeviceCert]].

=== SYSTEM ===
SYSTEM
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
└── saveMeta
└── ... (empty?)

The saves stored under this partition are only for system-titles / etc.

=== USER ===
USER
├── PRF2SAFE.RCV
├── Album (Same layout as [[SD_Filesystem|SD]])
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
├── saveMeta
│ └── ...
└── temp

The saves for all non-system applications, regardless of where the application is located(storageID), is stored here. Each user account which has savedata has a separate saveimage. Save-common for an application is presumably a separate saveimage too. Every saveimage here is ''only'' for applications.

=== SAFE ===
SAFE
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]] (nothing installed?)
│ └── placehld
│ └── ... [[NCA]]
└── [[Savegames|save]]
├── 8000000000000000
└── 8000000000000120

On a v2.1 system with MountBis, the only thing under here is "PRF2SAFE.RCV".

= System Savegames =

This is a listing of known System Savedata and what titles they correspond to.

{| class="wikitable" border="1"
! SaveID || Owner || Notes
|-
| 0x80000000000000d1 || erpt || Contains "/journal" report listing + actual crash reports ("/%08x-%04x-%04x-%02x%02x-%04x%08x"), which are serialized via [http://msgpack.org/ MsgPack].
|}

Services API

2017-07-12T19:06:57Z

Missile: capsrv internal service names

Services are system processes running in the background which wait for incoming requests. When a process wants to communicate with a service, it first needs to get a handle to the named service, and then it can communicate with the service via inter-process communication (each service has a name up to 8 characters).

Handles for services are retrieved from the service manager port, "sm:". Manager service "sm:m" also exists. Services are an abstraction of ports, they operate the same way except regular ports can have their handles retrieved directly from a SVC.

= sm: =
{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#Initialize]]
|-
| 1 || [[#GetService]]
|-
| 2 || [[#RegisterService]]
|-
| 3 || [[#UnregisterService]]
|}

== Initialize ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x8000000A
|-
| 2 || 0x00000001
|- style="border-top: double"
| 0-1 || Pid
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000000
|-
| 2 || Always 0.
|}

== GetService ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x0000000A
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000001
|-
| 2 || Service name, zero padded and casted to u64.
|}

== RegisterService ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x0000000C
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000002
|-
| 2 || Service name, zero padded and casted to u64.
|-
| 3 || Max sessions? 32-bit integer.
|-
| 4 || Unknown bool
|}

== UnregisterService ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x0000000A
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000003
|-
| 2 || Service name, zero padded and casted to u64.
|}

= sm:m =
This service is presumably equivalent to 3DS "srv:pm".

= Service List =
{| class="wikitable" border="1"
|-
! Service names
! scope="col" width="200" | Description
! scope="col" width="200" | Notes
|-
| acc:u0, acc:u1, acc:aa, acc:su
| [[Account services]]
| u0: System, u1: User, su: Admin, aa: Baas
|-
| ahid:cd, ahid:hdr, hid, hid:dbg, hid:sys, (htc?), irs, irs:sys, xcd:sys
| [[HID services]]
|
|-
| appletAE, appletOE, idle:sys, omm, spsm
| Applet services, [[OMM services]]
|
|-
| aoc:u, mii:u, mii:e, ns:am, ns:su, ns:dev, pl:u, ovln:rcv, ovln:snd, pdm:ntfy, pdm:qry
| [[NS Services]]
| am: Application Manager, su: System Update
|-
| apm, apm:p, apm:sys, fgm, fgm:0, fgm:9, (fgm:dbg?)
| [[APM services]]
|
|-
| arp:r, arp:w, bgtc:t, bgtc:sc
| Glue services
| r: Reader, w: Writer
|-
| audin:a, audin:d, audin:u, audout:a, audout:d, audout:u, audren:a, audren:d, audren:u, audrec:a, audrec:d, audrec:u, audctl, codecctl, hwopus
| Audio services
|
|-
| <nowiki>bcat:a, bcat:u, bcat:m, bcat:s, news:a, news:c, news:m, news:p, news:v, prepo:u, prepo:s, prepo:m, prepo:a</nowiki>
| [[BCAT services]]
|
|-
| bpc, bpc:r, pcv, pcv:imm, time:u, time:a, time:s
| [[BPC services]]
|
|-
| bsd:u, bsd:s, bsdcfg, ethc:c, ethc:i, nsd:u, nsd:a, sfdnsres
| [[Sockets services]], [[NSD services]]
|
|-
| btdrv
| Bluetooth Driver services
|
|-
| btm, btm:dbg, btm:sys
| Battery services
|
|-
| caps:a, caps:c
| Capture services
| a: AlbumAccessor, c: AlbumControl
|-
| caps:sc, caps:ss, mm:u, vi:m, vi:s, vi:u, cec-mgr
| [[Display services]]
|
|-
| csrng
| [[Secure RNG services]]
|
|-
| dispdrv
| Nvnflinger services
|
|-
| erpt:c, erpt:r
| Error Report services
|
|-
| es
| ETicket services
|
|-
| fan, psm, tc, ts
| PTM services
|
|-
| fatal:u, fatal:p
| Fatal Error services
| u: User, p: Privileged
|-
| friend:u, friend:v, friend:m, friend:s, friend:a
| Friend services
|
|-
| fsp-srv, fsp-ldr, fsp-pr
| [[Filesystem services]]
| srv: Main, ldr: Loader, pr: Program Registry
|-
| gpio, i2c, i2c:pcv, pinmux, pwm, uart
| [[Bus services]]
|
|-
| lbl
| [[Backlight services]]
|
|-
| ldn:m, ldn:s, ldn:u
| [[Local Network Monitor services]]
|
|-
| ldr:pm, ldr:ro, ldr:shel, ldr:dmnt
| [[Loader services]]
|
|-
| lm
| Log services
|
|-
| lr, ncm, ncm:v
| [[Location Resolver services]]
|
|-
| nfc:am, nfc:mf:u, nfc:user, nfc:sys
| NFC services
|
|-
| nifm:u, nifm:a, nifm:s
| [[Network Interface services]]
|
|-
| nim, nim:shp, ntc
| [[NIM services]]
| shp: eShop
|-
| npns:u, npns:s
| NPNS services
|
|-
| nvdrv:a, nvdrv:s, nvdrv:t, nvdrv, nvdrvdbg, nvgem:c, nvgem:cd, nvmemp
| [[NV services]]
|
|-
| pcie
| [[PCIe services]]
|
|-
| pctl, pctl:a, pctl:s, pctl:r
| Parental Control services
|
|-
| pm:bm, pm:info, pm:shell
| [[Process Manager services]]
|
|-
| psc:c, psc:m
| PSC services
|
|-
| set, set:fd, set:cal, set:sys
| [[Settings services]]
| cal: calibration, sys: System Settings
|-
| ssl
| [[SSL services]]
|
|-
| spl:
| [[SPL services]]
|
|-
| usb:ds, usb:hs, usb:pd, usb:pd:c, usb:pm
| USB services
|
|-
| wlan:inf, wlan:lcl, wlan:lg, wlan:lga, wlan:sg, wlan:soc
| WLAN services
|
|}

[[Category:Services]]

Flash Filesystem

2017-07-11T12:17:54Z

Missile: fun fact: failing this CMAC check will blow fuses

= NAND structure =

== Boot Partitions ==

'''Boot Partition 0 (0 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
|
| Title 0100000000000819 BCT
|-
| 0x004000
|
| Title 010000000000081A BCT
|-
| 0x008000
|
| Title 0100000000000819 BCT
|-
| 0x00C000
|
| Title 010000000000081A BCT
|-
| 0x100000
|
| Title 0100000000000819 "package1"
|-
| 0x140000
|
| Title 0100000000000819 "package1" (Backup)
|-
| 0x180000
| 0x4000
| Keyblob area
|-
| 0x184000
|
| Unknown, 0x20-bytes hash (updated when bcpkg-2-1 updates) + one u64? (may be incremented on bcpkg update) All zero on 1.0.
|}

'''Boot Partition 1 (1 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
|
| Title 010000000000081A "package1"
|-
| 0x040000
|
| Title 010000000000081A "package1" (Backup)
|}

=== Keyblob ===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Keyblob AES-CMAC
|-
| 0x10
| 0x10
| Keyblob AES IV
|-
| 0x20
| 0x90
| Keyblob encrypted payload
|-
| 0xB0
| 0x150
| Unused, all-zero.
|}

The data at 0x180000 is an array of 0x200-byte entries, with a total of 32 entries. Therefore, there's 32 different keyblobs are stored here. The raw data for each one is unique compared to the others.

The 0xB0-byte keyblob is installed to the console-unique "customer data" section in BCTs(BCT+0x450), which is what gets used during system boot.

Which keyblob is loaded from here during install is presumably somewhere in BCT? <v3.0 use index0, v3.0 uses index1. Hence, the installed keyblob was changed with v3.0.

== User Partitions ==
{| class="wikitable" border="1"
|-
! Partition name
! Offset
! Size
! [[Filesystem_services|Bis]] Partition ID
! Description
|-
| N/A
| 0x0
|
| 20
| GPT header, Bis-storage also allows raw access to the entire NAND eMMC sectors starting at sector0.
|-
| PRODINFO
| 0x00004400
| 0x003FBC00
| 27
| "CAL0" raw partition containing set:cal data.
|-
| PRODINFOF
| 0x00400000
| 0x00400000
| 28
| FAT12 filesystem, additional calibration.
|-
| BCPKG2-1-Normal-Main
| 0x00800000
| 0x00800000
| 21
| For all these packages, data starts at offset 0x4000 and is not console-unique. This is installed from "package2" in firmware package A (0100000000000819) by default. With the exFAT update installed, this is switched to firmware package C (010000000000081B).
|-
| BCPKG2-2-Normal-Sub
| 0x01000000
| 0x00800000
| 22
| Identical to BCPKG2-1-Normal-Main, probably used as a backup partition.
|-
| BCPKG2-3-SafeMode-Main
| 0x01800000
| 0x00800000
| 23
| This is installed from "package2" in firmware package B (010000000000081A).
|-
| BCPKG2-4-SafeMode-Sub
| 0x02000000
| 0x00800000
| 24
| Identical to BCPKG2-3-SafeMode-Main.
|-
| BCPKG2-5-Repair-Main
| 0x02800000
| 0x00800000
| 25
| Installed at the factory.
|-
| BCPKG2-6-Repair-Sub
| 0x03000000
| 0x00800000
| 26
| Identical to BCPKG2-5-Repair-Main.
|-
| SAFE
| 0x03800000
| 0x04000000
| 29
| FAT32 filesystem.
|-
| SYSTEM
| 0x07800000
| 0xA0000000
| 31 (and 32?)
| FAT32 filesystem.
|-
| USER
| 0xA7800000
| 0x680000000
| 30
| FAT32 filesystem.
|-
|
| 0x747BFFE00
| 0x200
|
| This is the backup GPT header specified by the main GPT header. This is also the last sector readable with Bis-storage paritionID 20.
|}

If the client process lacks the relevant permission for any of the above partition IDs, error 0x2EE202 is returned.

[[NCA]]s stored in NAND are raw, identical to the data readable with [[Content_Manager_services#ReadEntryRaw]].

The filenames for saveimages is just "<lower-case hex u64 saveID>". SYSTEM-partition saveIDs are specified by [[Filesystem_services|FS]] commands, while USER-partition saveIDs are determined by FS-module internally. The high u32 of the saveID is normally either 0x00000000 or 0x80000000.

=== PRODINFOF ===
PRODINFOF
├── Certifications
│ └── WirelessCertification.png
└── ptd
├── DeviceIdWithEmsBit.dat
├── Ecid.dat
├── prodCode.dat
└── log
├── Process_asm1.log
├── Process_board1.log
├── TestFlagLine.log
├── TestFlagQc.log
├── AGING
│ └── Sequence.log
├── BOARD_TEST
│ └── Sequence.log
├── BOARD_WIRELESS
│ └── Sequence.log
├── FINAL_CHECK
│ └── Sequence.log
├── LCD_AND_KEY
│ └── Sequence.log
└── USB_AND_HP
└── Sequence.log

==== DeviceIdWithEmsBit.dat ====
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the [[Settings_services|DeviceCert]].

=== SYSTEM ===
SYSTEM
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
└── saveMeta
└── ... (empty?)

The saves stored under this partition are only for system-titles / etc.

=== USER ===
USER
├── PRF2SAFE.RCV
├── Album (Same layout as [[SD_Filesystem|SD]])
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
├── saveMeta
│ └── ...
└── temp

The saves for all non-system applications, regardless of where the application is located(storageID), is stored here. Each user account which has savedata has a separate saveimage. Save-common for an application is presumably a separate saveimage too. Every saveimage here is ''only'' for applications.

=== SAFE ===
SAFE
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]] (nothing installed?)
│ └── placehld
│ └── ... [[NCA]]
└── [[Savegames|save]]
├── 8000000000000000
└── 8000000000000120

On a v2.1 system with MountBis, the only thing under here is "PRF2SAFE.RCV".

PPC services

2017-07-11T10:45:37Z

Missile: add settings (performance_mode_policy is neat)

APM is utilized for setting system performance profiles; including clocks for CPU, GPU, and memory.

== apm ==
{| class="wikitable" border="1"
|-
! Cmd || Name || Notes
|-
| 0 || [[#ISession|GetISession]] ||
|-
| 1 || GetPerformanceMode ||
|}

== apm:p ==
{| class="wikitable" border="1"
|-
! Cmd || Name || Notes
|-
| 0 || [[#ISession|GetISession]] || Same as apm ISession - but more privileged?
|-
| 1 || ? ||
|}

== apm:sys ==
Internally known as ISystemManager

== ISession ==
{| class="wikitable" border="1"
|-
! Cmd || Name || Notes
|-
| 0 || SetPerformanceConfiguration || Takes u32 PerformanceMode
|-
| 1 || GetPerformanceConfiguration || Takes u32 PerformanceMode, u32 PerformanceConfiguration
|}

=== PerformanceMode ===
{| class="wikitable" border="1"
|-
! Value || Name
|-
| 0 || Handheld
|-
| 1 || Docked
|}

=== PerformanceConfiguration ===
{| class="wikitable" border="1"
|-
! Value || CPU clock || GPU clock || Memory clock
|-
| 0x00010000 || 1020 || 384 || 1600
|-
| 0x00010001 || 1020 || 768 || 1600
|-
| 0x00010002 || 1224 || 691.2 || 1600
|-
| 0x00020000 || 1020 || 230.4 || 1600
|-
| 0x00020001 || 1020 || 307.2 || 1600
|-
| 0x00020002 || 1224|| 230.4 || 1600
|-
| 0x00020003 || 1020 || 307 || 1331.2
|-
| 0x00020004 || 1020 || 384 || 1331.2
|-
| 0x00020005 || 1020 || 307.2 || 1065.6
|-
| 0x00020006 || 1020 || 384 || 1065.6
|-
| 0x92220007 || 1020 || 460.8 || 1600
|-
| 0x92220008 || 1020 || 460.8 || 1331.2
|}
Clocks are all in MHz.

Configurations 0x10001 and 0x20000 are only available while docked. Configurations 0x10002 and 0x20002 do not seem to be available at all (dependent on apm settings?).

== Settings ==
{| class="wikitable" border="1"
|-
! Key || Size || Notes
|-
| battery_draining_enabled|| 1 || ?
|-
| performance_mode_policy|| strlen || "auto": use boost mode when docked. "normal": never use boost mode. "boost": always use boost mode (devkit only).
|-
| sdev_cpu_overclock_enabled || 1 || Not used as of 3.0. May have been used to allow access to 1224MHz CPU mode?
|-
| sdev_throttling_additional_delay_us || 4 || ?
|-
| sdev_throttling_additional_delay_enabled || 1 || ?
|-
| throttling_for_smpd_enabled || 1 || Not used as of 3.0.
|-
| throttling_for_undock_enabled || 1 || Not used as of 3.0.
|}

[[Category:Services]]

PPC services

2017-07-11T08:08:48Z

Missile: /* PerformanceConfiguration */

PPC services

2017-07-11T07:41:47Z

Missile: add cpu/gpu/ram clocks for all profiles :3c

PPC services

2017-07-11T07:20:08Z

Missile: apm:p info, and rearrange sections

PPC services

2017-07-11T05:58:05Z

Missile: whoops

PPC services

2017-07-08T20:43:37Z

Missile: /* PerformanceConfiguration */

Services API

2017-07-08T20:37:19Z

Missile: /* Service List */

Services are system processes running in the background which wait for incoming requests. When a process wants to communicate with a service, it first needs to get a handle to the named service, and then it can communicate with the service via inter-process communication (each service has a name up to 8 characters).

Handles for services are retrieved from the service manager port, "sm:". Manager service "sm:m" also exists. Services are an abstraction of ports, they operate the same way except regular ports can have their handles retrieved directly from a SVC.

= sm: =
{| class="wikitable" border="1"
|-
! Cmd || Name
|-
| 0 || [[#Initialize]]
|-
| 1 || [[#GetService]]
|-
| 2 || [[#RegisterService]]
|-
| 3 || [[#UnregisterService]]
|}

== Initialize ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x8000000A
|-
| 2 || 0x00000001
|- style="border-top: double"
| 0-1 || Pid
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000000
|-
| 2 || Always 0.
|}

== GetService ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x0000000A
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000001
|-
| 2 || Service name, zero padded and casted to u64.
|}

== RegisterService ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x0000000C
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000002
|-
| 2 || Service name, zero padded and casted to u64.
|-
| 3 || Max sessions? 32-bit integer.
|-
| 4 || Unknown bool
|}

== UnregisterService ==
{| class="wikitable" border="1"
|-
! Word || Value
|-
| 0 || 0x00000004
|-
| 1 || 0x0000000A
|- style="border-top: double"
| 0 || "SFCI"
|-
| 1 || 0x00000003
|-
| 2 || Service name, zero padded and casted to u64.
|}

= sm:m =
This service is presumably equivalent to 3DS "srv:pm".

= Service List =
{| class="wikitable" border="1"
|-
! Service names
! scope="col" width="200" | Description
! scope="col" width="200" | Notes
|-
| acc:u0, acc:u1, acc:aa, acc:su
| [[Account services]]
| u1: User, su: Admin
|-
| ahid:cd, ahid:hdr, hid, hid:dbg, hid:sys, (htc?), irs, irs:sys, xcd:sys
| [[HID services]]
|
|-
| appletAE, appletOE, idle:sys, omm, spsm
| Applet services, [[OMM services]]
|
|-
| aoc:u, mii:u, mii:e, ns:am, ns:su, ns:dev, pl:u, ovln:rcv, ovln:snd, pdm:ntfy, pdm:qry
| [[NS Services]]
| am: Application Manager, su: System Update
|-
| apm, apm:p, apm:sys, fgm, fgm:0, fgm:9, (fgm:dbg?)
| [[APM services]]
|
|-
| arp:r, arp:w, bgtc:t, bgtc:sc
|
| r: Reader, w: Writer
|-
| audin:a, audin:d, audin:u, audout:a, audout:d, audout:u, audren:a, audren:d, audren:u, audrec:a, audrec:d, audrec:u, audctl, codecctl, hwopus
| Audio services
|
|-
| <nowiki>bcat:a, bcat:u, bcat:m, bcat:s, news:a, news:c, news:m, news:p, news:v, prepo:u, prepo:s, prepo:m, prepo:a</nowiki>
| [[BCAT services]]
|
|-
| bpc, bpc:r, pcv, pcv:imm, time:u, time:a, time:s
| [[BPC services]]
|
|-
| bsd:u, bsd:s, bsdcfg, ethc:c, ethc:i, nsd:u, nsd:a, sfdnsres
| [[Sockets services]], [[NSD services]]
|
|-
| btdrv
| Bluetooth Driver services?
|
|-
| btm, btm:dbg, btm:sys
| Battery services?
|
|-
| caps:a, caps:c
| Capture services
| a: Album, ss: Screenshot
|-
| caps:sc, caps:ss, mm:u, vi:m, vi:s, vi:u
| [[Display services]]
|
|-
| cec-mgr
|
|
|-
| csrng
| [[Secure RNG services]]
|
|-
| dispdrv
|
|
|-
| erpt:c, erpt:r
| Error Report services
|
|-
| es
| ETicket services?
|
|-
| fan, psm, tc, ts
|
|
|-
| fatal:u, fatal:p
| Fatal Error services
| u: User, p: Privileged?
|-
| friend:u, friend:v, friend:m, friend:s, friend:a
| Friend services
|
|-
| fsp-srv, fsp-ldr, fsp-pr
| [[Filesystem services]]
| srv: Main, ldr: Loader, pr: Program Registry
|-
| gpio, i2c, i2c:pcv, pinmux, pwm, uart
| [[Bus services]]
|
|-
| lbl
| [[Backlight services]]
|
|-
| ldn:m, ldn:s, ldn:u
| [[Local Network Monitor services]]
|
|-
| ldr:pm, ldr:ro, ldr:shel, ldr:dmnt
| [[Loader services]]
|
|-
| lm
| Log services
|
|-
| lr, ncm, ncm:v
| [[Location Resolver services]]
|
|-
| nfc:am, nfc:mf:u, nfc:user, nfc:sys
| NFC services
|
|-
| nifm:u, nifm:a, nifm:s
| [[Network Interface services]]
|
|-
| nim, nim:shp, ntc
| [[NIM services]]
| shp: eShop
|-
| npns:u, npns:s
| ?
|
|-
| nvdrv:a, nvdrv:s, nvdrv:t, nvdrv, nvdrvdbg, nvgem:c, nvgem:cd, nvmemp
| [[NV services]]
|
|-
| pcie
| [[PCIe services]]
|
|-
| pctl, pctl:a, pctl:s, pctl:r
| Parental Control services
|
|-
| pm:bm, pm:info, pm:shell
| [[Process Manager services]]
|
|-
| psc:c, psc:m
| ?
|
|-
| set, set:fd, set:cal, set:sys
| [[Settings services]]
| cal: calibration, sys: System Settings
|-
| ssl
| [[SSL services]]
|
|-
| spl:
| [[SPL services]]
|
|-
| usb:ds, usb:hs, usb:pd, usb:pd:c, usb:pm
| USB services
|
|-
| wlan:inf, wlan:lcl, wlan:lg, wlan:lga, wlan:sg, wlan:soc
| WLAN services
|
|}

[[Category:Services]]

PPC services

2017-07-08T20:35:59Z

Missile: Created page with "APM is utilized for setting system performance profiles; including clocks for CPU, GPU, and memory. == apm == {| class="wikitable" border="1" |- ! Cmd || Name || Notes |- | 0..."

Flash Filesystem

2017-07-06T17:04:43Z

Missile: u64 could also reflect bcpkg size? - this was observed to be larger after 3.0->3.0exfat update

= NAND structure =

== Boot Partitions ==

'''Boot Partition 0 (0 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
|
| Title 0100000000000819 BCT
|-
| 0x004000
|
| Title 010000000000081A BCT
|-
| 0x008000
|
| Title 0100000000000819 BCT
|-
| 0x00C000
|
| Title 010000000000081A BCT
|-
| 0x100000
|
| Title 0100000000000819 "package1"
|-
| 0x140000
|
| Title 0100000000000819 "package1" (Backup)
|-
| 0x180000
|
| Keyblob area, the first 0xB0 is identical to the console-unique "customer data" section in BCTs
|-
| 0x184000
|
| Unknown, 0x20-bytes hash (updated when bcpkg-2-1 updates) + one u64? (may be incremented on bcpkg update) All zero on 1.0.
|}

'''Boot Partition 1 (1 of 1)'''
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000000
|
| Title 010000000000081A "package1"
|-
| 0x040000
|
| Title 010000000000081A "package1" (Backup)
|}

== User Partitions ==
{| class="wikitable" border="1"
|-
! Partition name
! Offset
! Size
! [[Filesystem_services|Bis]] Partition ID
! Description
|-
| N/A
| 0x0
|
| 20
| GPT header, Bis-storage also allows raw access to the entire NAND eMMC sectors starting at sector0.
|-
| PRODINFO
| 0x00004400
| 0x003FBC00
| 27
| "CAL0" raw partition containing set:cal data.
|-
| PRODINFOF
| 0x00400000
| 0x00400000
| 28
| FAT12 filesystem, additional calibration.
|-
| BCPKG2-1-Normal-Main
| 0x00800000
| 0x00800000
| 21
| For all these packages, data starts at offset 0x4000 and is not console-unique. This is installed from "package2" in firmware package A (0100000000000819) by default. With the exFAT update installed, this is switched to firmware package C (010000000000081B).
|-
| BCPKG2-2-Normal-Sub
| 0x01000000
| 0x00800000
| 22
| Identical to BCPKG2-1-Normal-Main, probably used as a backup partition.
|-
| BCPKG2-3-SafeMode-Main
| 0x01800000
| 0x00800000
| 23
| This is installed from "package2" in firmware package B (010000000000081A).
|-
| BCPKG2-4-SafeMode-Sub
| 0x02000000
| 0x00800000
| 24
| Identical to BCPKG2-3-SafeMode-Main.
|-
| BCPKG2-5-Repair-Main
| 0x02800000
| 0x00800000
| 25
| Installed at the factory.
|-
| BCPKG2-6-Repair-Sub
| 0x03000000
| 0x00800000
| 26
| Identical to BCPKG2-5-Repair-Main.
|-
| SAFE
| 0x03800000
| 0x04000000
| 29
| FAT32 filesystem.
|-
| SYSTEM
| 0x07800000
| 0xA0000000
| 31 (and 32?)
| FAT32 filesystem.
|-
| USER
| 0xA7800000
| 0x680000000
| 30
| FAT32 filesystem.
|-
|
| 0x747BFFE00
| 0x200
|
| This is the backup GPT header specified by the main GPT header. This is also the last sector readable with Bis-storage paritionID 20.
|}

If the client process lacks the relevant permission for any of the above partition IDs, error 0x2EE202 is returned.

[[NCA]]s stored in NAND are raw, identical to the data readable with [[Content_Manager_services#ReadEntryRaw]].

The filenames for saveimages is just "<lower-case hex u64 saveID>". saveIDs aren't related to the titleID, or at least not for USER-partition saves. The high u32 of the saveID is normally either 0x00000000 or 0x80000000.

=== PRODINFOF ===
PRODINFOF
├── Certifications
│ └── WirelessCertification.png
└── ptd
├── DeviceIdWithEmsBit.dat
├── Ecid.dat
├── prodCode.dat
└── log
├── Process_asm1.log
├── Process_board1.log
├── TestFlagLine.log
├── TestFlagQc.log
├── AGING
│ └── Sequence.log
├── BOARD_TEST
│ └── Sequence.log
├── BOARD_WIRELESS
│ └── Sequence.log
├── FINAL_CHECK
│ └── Sequence.log
├── LCD_AND_KEY
│ └── Sequence.log
└── USB_AND_HP
└── Sequence.log

==== DeviceIdWithEmsBit.dat ====
Contains a 0x10-byte uppercase hex string, identical to the DeviceId in the [[Settings_services|DeviceCert]].

=== SYSTEM ===
SYSTEM
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
└── saveMeta
└── ... (empty?)

The saves stored under this partition are only for system-titles / etc.

=== USER ===
USER
├── PRF2SAFE.RCV
├── Album (Same layout as [[SD_Filesystem|SD]])
├── Contents
│ ├── registered
│ │ └── ... [[NCA]]
│ └── placehld
│ └── ... [[NCA]]
├── [[Savegames|save]]
│ └── ...
└── saveMeta
└── ...

The saves for all non-system applications, regardless of where the application is located(storageID), is stored here. Each user account which has savedata has a separate saveimage. Save-common for an application is presumably a separate saveimage too. Every saveimage here is ''only'' for applications.

=== SAFE ===
SAFE
├── PRF2SAFE.RCV
├── Contents
│ ├── registered
│ │ └── ... [[NCA]] (nothing installed?)
│ └── placehld
│ └── ... [[NCA]]
└── [[Savegames|save]]
├── 8000000000000000
└── 8000000000000120

On a v2.1 system with MountBis, the only thing under here is "PRF2SAFE.RCV".

Internet Browser

2017-07-05T13:54:03Z

Missile: 3.0 user agent

Nintendo Switch does not have a normal Internet Browser for user usage. However, there is multiple browser applets. It is the [https://web.archive.org/web/20170304075230/https://gl.access-company.com/news_event/archives/2017/170303/ NetFront NX] browser, which is based on Webkit.

When linking the Nintendo Account with Facebook, the Facebook Auth website will open, offering a search box that can be used to browse the Internet ("LoginApplet"). Alternatively, it can be accessed with [https://gbatemp.net/threads/web-browser-kind-of-on-the-switch.463094/ custom DNS settings] which simulate a Wi-Fi login page ("WifiWebAuthApplet" for captive-portal).

== Known User Agent Strings ==
{| class='wikitable'
! System Version
! UA String
|-
| [[2.0.0]]
| Mozilla/5.0 (Nintendo Switch; <appletname>) AppleWebKit/601.6 (KHTML, like Gecko) NF/4.0.0.5.9 NintendoBrowser/5.1.0.13341
|-
| [[2.1.0]]-[[2.3.0]]
| Mozilla/5.0 (Nintendo Switch; <appletname>) AppleWebKit/601.6 (KHTML, like Gecko) NF/4.0.0.5.10 NintendoBrowser/5.1.0.13343
|-
| [[3.0.0]]
| Mozilla/5.0 (Nintendo Switch; <appletname>) AppleWebKit/601.6 (KHTML, like Gecko) NF/4.0.0.6.9 NintendoBrowser/5.1.0.14936
|}

The UA is generated with: "Mozilla/5.0 (Nintendo Switch; <appletname>) AppleWebKit/<webkitver> (KHTML, like Gecko) NF/<nfver0>.<nfver1>.<nfver2> NintendoBrowser/5.<ninver0>.<ninver1>.<ninver2>"

== Browser Applets ==
{| class='wikitable'
! appletname (From UA)
! Usage
! Invalid TLS cert handling
! Uses whitelist
! Title ID
! Notes
|-
| WebApplet
| General web-applet for use by applications(online manuals, ...).
| Displays an error dialog without an option to ignore it.
| Yes
| 010000000000100A
|
|-
| ShopN
| Actual eShop client
| Just displays an error-code.
| Yes
| 010000000000100B
|
|-
| WebApplet
| Offline HTML display
|
|
| 010000000000100F
|
|-
| LoginApplet
| Nintendo Account linking
| Just displays an error-code.
| Yes
| 0100000000001010
|
|-
| ShareApplet
| Posting screenshots to social media, and (optionally) linking social media accounts
| Just displays an error-code.
| Yes
| 0100000000001010
|
|-
| LobbyApplet
| Related to online-multiplayer lobbies
| Just displays an error-code.
| Yes
| 0100000000001010
|
|-
| WifiWebAuthApplet
| Captive-portal
| Displays an error dialog with an option to ignore it.
| No
| 0100000000001011
|
|}

When whitelisting is enabled, you can only load page domains included in the whitelist, otherwise an error is displayed. This only applies to page navigation. Videos via the <video> tag are not affected, likewise with network requests with JS.

No known applets can directly access the SD card via mounting it. This includes ShareApplet (which posts screenshots from SD to social media).

== OSS ==
The NROs for the OSS are stored under a separate [[Title_list|title]]. All of the web-applets use the same OSS NROs via this title.

String from v2.0 in oss_wkc.nro: "libcurl/7.50.1".

== Video Playback ==
WifiWebAuthApplet does not fully support playing videos. It will [[Error_codes|assert]] with normal videos. The assert triggers before it even starts MP4 parsing?(For example, selecting a video from a video-tag will assert even though it doesn't send any network request for it) However, in some cases with certain MP4s using vulns it will display an error dialog instead.

With v3.0 WifiWebAuthApplet video-playback was disabled, it now throws the following error when attempting to play a video: "Support Code: 2809-1212" "This feature is not available." On past system-versions it would just trigger a fatal-error(see above). Video-playback which already worked fine under whitelisted-applet, still works fine on v3.0.

== Trusted RootCAs ==
While the rootCA(s) for Let's Encrypt isn't included, Let's Encrypt is indirectly trusted via "Digital Signature Trust Co.". This seems to be only(?) the case for WifiWebAuthApplet, hence non-WifiWebAuthApplet seems to have a different set of trusted rootCAs.

== WifiWebAuthApplet ==
When doing a connection-test in system-settings, it will detect that the captive-portal is required and display an error for it when the response for "http://conntest.nintendowifi.net/" doesn't include the "X-Organization: Nintendo" HTTP header. The web-applet will not load until something else attempts a conntest, for example when launching eShop and prior to LoginApplet launching. The initial page loaded by this applet is the above conntest URL.

This is only available starting with [[2.0.0]].

==Whitelisted Applets==
The v2.1 main-codebin page-aligned .text size is 0x1000-bytes larger than ShopN.

The file at "data:/whitelist/WhitelistLns.txt" for LoginApplet/ShareApplet/LobbyApplet, which doesn't exist in WifiWebAuthApplet, contains the following:

<nowiki>^https://([0-9A-Za-z\-]+\.)*nintendo\.net(/|$)
^https?://([0-9A-Za-z\-]+\.)*nintendo\.(co\.jp|com|eu|co\.uk|es|pt|ch|at|de|nl|be|ch|ru|fr|it|co\.za|co\.kr|tw|com\.hk|com\.au|ca|co\.nz)(/|$)
^https?://([0-9A-Za-z\-]+\.)*nintendo-europe\.com(/|$)
^https?://([0-9A-Za-z\-]+\.)*nintendoservicecentre\.co\.uk(/|$)
^https?://([0-9A-Za-z\-]+\.)*google\.(com|ad|ae|com\.af|com\.ag|com\.ai|al|am|co\.ao|com\.ar|as|at|com\.au|az|ba|com\.bd|be|bf|bg|com\.bh|bi|bj|com\.bn|com\.bo|com\.br|bs|bt|co\.bw|by|com\.bz|ca|cd|cf|cg|ch|ci|co\.ck|cl|cm|cn|com\.co|co\.cr|com\.cu|cv|com\.cy|cz|de|dj|dk|dm|com\.do|dz|com\.ec|ee|com\.eg|es|com\.et|fi|com\.fj|fm|fr|ga|ge|gg|com\.gh|com\.gi|gl|gm|gp|gr|com\.gt|gy|com\.hk|hn|hr|ht|hu|co\.id|ie|co\.il|im|co\.in|iq|is|it|je|com\.jm|jo|co\.jp|co\.ke|com\.kh|ki|kg|co\.kr|com\.kw|kz|la|com\.lb|li|lk|co\.ls|lt|lu|lv|com\.ly|co\.ma|md|me|mg|mk|ml|com\.mm|mn|ms|com\.mt|mu|mv|mw|com\.mx|com\.my|co\.mz|com\.na|com\.nf|com\.ng|com\.ni|ne|nl|no|com\.np|nr|nu|co\.nz|com\.om|com\.pa|com\.pe|com\.pg|com\.ph|com\.pk|pl|pn|com\.pr|ps|pt|com\.py|com\.qa|ro|ru|rw|com\.sa|com\.sb|sc|se|com\.sg|sh|si|sk|com\.sl|sn|so|sm|sr|st|com\.sv|td|tg|co\.th|com\.tj|tk|tl|tm|tn|to|com\.tr|tt|com\.tw|co\.tz|com\.ua|co\.ug|co\.uk|com\.uy|co\.uz|com\.vc|co\.ve|vg|co\.vi|com\.vn|vu|ws|rs|co\.za|co\.zm|co\.zw|cat)(/|$)
^https://([0-9A-Za-z\-]+\.)*facebook\.com(/|$)
^https://([0-9A-Za-z\-]+\.)*twitter\.com(/|$)</nowiki>

===ShareApplet===
The initial page loaded by this applet depends on a flag. <nowiki>non-val1: "https://web-lp1.share.srv.nintendo.net/" val1: "https://web-lp1.share.srv.nintendo.net/settings/"</nowiki>

The server will return a HTTP 302 redirect to <nowiki>"https://nintendo.com/"</nowiki> when the specified User-Agent isn't the one for ShareApplet.

===LobbyApplet===
The initial page loaded by this applet is: <nowiki>"https://web-lp1.znc.srv.nintendo.net/lobby/"</nowiki>.

The content of the above URL refers to "rooms", "NxView_Img_Google_Play_Icon", etc.

And also:
Your room has been created.

You can invite friends to the room via
the Nintendo Switch Online Lounge app.

== ShopN ==
The initial page loaded by ShopN seems to be the following: <nowiki>"https://bugyo.hac.lp1.eshop.nintendo.net/ashigaru/"</nowiki>.

The file at "data:/whitelist/WhitelistEc.txt", which doesn't exist in WifiWebAuthApplet, contains the following:

<nowiki>^https://([0-9A-Za-z\-]+\.)*eshop\.nintendo\.net($|/)
^https?://([0-9A-Za-z\-]+\.)*nintendo\.(co\.jp|com|de)($|/)</nowiki>

== WebApplet ==
===010000000000100A===
The initial page loaded by this applet is specified by the title which launched this applet. Plain HTTP is allowed.

The files under "data:/" are identical to WifiWebAuthApplet except that the content of each file differs.

This applet uses a whitelist, but it doesn't come from "data:/" like whitelisted-applet.

=== Offline Applet ===
Minus TIDs, the [[NPDM]] is the same as 010000000000100A except 010000000000100A has access to more/other services.

== Service/FS Access ==
All browser applets have access to the following services: acc:u1, appletAE, audin:u, audren:u, audout:u, bsd:u, fatal:u, fsp-srv, hid, hid:sys, irs, ldn:m, ldr:ro, lm, erpt:c, nifm:s, ns:am, nsd:u, nvdrv:a, mm:u, pl:u, prepo:s, set, set:sys, sfdnsres, ssl, time:u, vi:s

LoginApplet/ShareApplet/LobbyApplet have access to the above + caps:a.

ShopN has access to the above + nim:shp.

Unlike the applets listed above, WebApplet TID 010000000000100A has access to the [[Filesystem_services|FS]] MountContent* commands. This is so that it can load the whitelist from "/accessible-urls/accessible-urls.txt" in the mounted FS, from [[NCA]]-type4 where titleID={application which launched this applet}.

== Heap ==

The size used for [[SVC|svcSetHeapSize]] by the web-applets is 0x15600000. Under ShopN, the largest size that can be passed to this without an error being returned, is 0x1B400000.

== Versions ==

=== [[2.0.0]] ===

"shareddata:/buildinfo/buildinfo.dat" content:
r:13341
p:NX64
v:Release
d:2017-02-13 22:57
n:0.5.9

=== [[2.1.0]] ===
See [[Switch_Userland_Flaws|here]] for vuln-related changes.

The WebKit NRO was updated. For the WebKit NRO, the page-aligned size for the R-X, R--, and RW- pages are the same as v2.0.
* The actual code in the NRO starts differing starting at offset 0xE780. In v2.0 the offset following the last code instruction is text_lastpage+0x3F8(text_end-0xC08), while for v2.1 it's text_lastpage+0xE60(text_end-0x1A0). Compared to the previous version, there's a val0 u32(padding) inserted where the code for the import stubs begin, near the end of .text. Relative to that end offset going backwards, .text differs starting at v2.0 textbase+0xD56530 / v2.1 textbase+0xD56F94.
* The R-- section was updated. Besides the large table(?) which was updated(nothing was added/removed there), the strings containing "D:/for_cruiser/release_182/nx/webkit/" were updated: "182" was changed to "189". 0x10-bytes at offset 0x57292C were removed. 0x8-bytes were inserted at offset 0x14B2B5C in the v2.1 section. 0x8-bytes were inserted at offset 0x14B5C10 in the v2.1 section. ...
* The RW- section was updated, mainly for different addrs. Nothing was added/removed. Most(?)/all(?) main-codebin func import-addrs relative to main-codebin-base are the same as v2.0.

Main-codebin region(titleID 010000000000100B):
* rtld is same as before basically, minus addrs. Likewise for the "nnSdkEmpty" binary following the main-codebin.
* Various byte values were changed in the main .text.
* In the main R-- section:
** The length of a string used with the user-agent changed, due to being changed from "{...}.9" to "{...}.10".
** The version in the following string was changed from "1.2.2" to "1.2.3": "FS_ACCESS: { sdk_versio n: 1.2.3, spec: NX }"
** The datetime strings following "b/23876444" was changed from "Feb 10 2017" "02:24:47" to "Mar 9 201 7" "21:41:27".
** A 0x10-byte block prior to SDK library tag strings was updated. The version in those strings was changed from "1_2_2" to "1_2_3".
* The main RW- section appears to be basically the same minus addrs.

All of the other NROs were updated in FS with only the following changes:
* The R-X section is identical to the previous version except for the 0x10-byte block in the NRO header.
* The R-- section only had version values in "/release_{ver}/" strings updated, see the for_cruiser path mentioned for WebKit NRO above. The only other change was that a 0x10-byte block following a "GNU" string was updated.

==== FS ====
The content of "blacklist:/" and "oceanShared:/" haven't changed. Only the content of "shareddata:/" and "data:/" changed.

===== "shareddata:/" =====
The following files were updated here(nothing added/removed):

* /buildinfo/buildinfo.dat
* /dll/cairo_wkc.nro
* /dll/libfont.nro
* /dll/oss_wkc.nro
* /dll/peer_wkc.nro
* /dll/webkit_wkc.nro

That is, every .nro under the above directory was updated.

"shareddata:/buildinfo/buildinfo.dat" content:
r:13343
p::NX64
v:Release
d:2017-03-14 21:08
n:0.5.10

===== "data:/" =====
The following files were updated here(nothing added/removed):

* /.nrr/netfront.nrr
* /buildinfo/buildinfo.dat

Flash Filesystem

2017-07-02T18:04:33Z

Missile: /* Boot Partitions */

Flash Filesystem

2017-07-02T17:58:55Z

Missile: the byte at 0x184024 is often set to 0x01 or 0x03, but not on all systems?

Flash Filesystem

2017-07-02T17:54:52Z

Missile: /* Boot Partitions */

Flash Filesystem

2017-07-02T17:49:37Z

Missile: /* User Partitions */