Nintendo Switch Brew - User contributions [en]

Cryptosystem

2018-11-25T13:20:23Z

Motezazer: Keyblobs are dead

== BootROM ==
The bootrom initializes two keyslots in the hardware engine:

* the SBK (Secure Boot Key) in keyslot 14
* the SSK (Secure Storage Key) in keyslot 15.

Reads from both of these keyslots are disabled by the bootROM.
The SBK is stored in [[Fuses#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY]], which are locked to read out only FFs after the bootrom finishes.

SBK is '''unique''' per console, and not shared among consoles as originally believed.

The SSK is derived on boot via the SBK, the 32-bit console-unique "Device Key", and hardware information stored in fuses.

Pseudocode for the derivation is as follows:
void generateSSK() {
char keyBuffer[0x10]; // Used to store keydata
uint hwInfoBuffer[4]; // Used to store info about hardware from fuses
uint deviceKey = getDeviceKey(); // Reads 32-bit device key from FUSE_PRIVATE_KEY4.
for (int i = 0; i < 4; i++) { // Keybuffer = deviceKey || deviceKey || deviceKey || deviceKey
((uint *)keyBuffer)[i] = deviceKey;
}

encryptWithSBK(keyBuffer); // keyBuffer = AES-ECB(SBK, deviceKey || {...})

// Set up Hardware info buffer
uint vendor_code = *((uint *)0x7000FA00) & 0x0000000F; // FUSE_VENDOR_CODE
uint fab_code = *((uint *)0x7000FA04) & 0x0000003F; // FUSE_FAB_CODE
uint lot_code_0 = *((uint *)0x7000FA08) & 0xFFFFFFFF; // FUSE_LOT_CODE_0
uint lot_code_1 = *((uint *)0x7000FA0C) & 0x0FFFFFFF; // FUSE_LOT_CODE_1
uint wafer_id = *((uint *)0x7000FA10) & 0x0000003F; // FUSE_WAFER_ID
uint x_coord = *((uint *)0x7000FA14) & 0x000001FF; // FUSE_X_COORDINATE
uint y_coord = *((uint *)0x7000FA18) & 0x000001FF; // FUSE_Y_COORDINATE
uint unk_hw_fuse = *((uint *)0x7000FA20) & 0x0000003F; // Unknown cached fuse.

// HARDWARE_INFO_BUFFER = unk_hw_fuse || Y_COORD || X_COORD || WAFER_ID || LOT_CODE || FAB_CODE || VENDOR_ID
hwInfoBuffer[0] = (lot_code_1 << 30) | (wafer_id << 24) | (x_coord << 15) | (y_coord << 6) | unk_hw_fuse;
hwInfoBuffer[1] = (lot_code_0 << 26) | (lot_code_1 >> 2);
hwInfoBuffer[2] = (fab_code << 26) | (lot_code_0 >> 6);
hwInfoBuffer[3] = vendor_code;

for (int i = 0; i < 0x10; i++) { // keyBuffer = XOR(AES-ECB(SBK, deviceKey || {...}), HARDWARE_INFO_BUFFER)
keyBuffer[i] ^= ((char *)hwInfoBuffer)[i];
}

encryptWithSBK(keyBuffer); // keyBuffer = AES-ECB(SBK, XOR(AES-ECB(SBK, deviceKey || {...}), HARDWARE_INFO_BUFFER))

setKeyslot(KEYSLOT_SSK, keyBuffer); // SSK = keyBuffer.
}

== Falcon coprocessor ==
The falcon processor (TSEC) generates a special console-unique key (that will be referred to as the "tsec key").

This is presumably using data stored in fuses that only microcode authenticated by NVidia has access to.

== Package1ldr ==

=== Key table during package1ldr ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 11
| Package1Key
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes
|-
| 14
| SecureBootKey
| Bootrom
| Yes
| No
|-
| 15
| SecureStorageKey
| Bootrom
| Yes
| No
|}

=== [1.0.0-3.0.2] Key table after package1ldr ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 13
| PerConsoleKey
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|}

=== [4.0.0]+ Key table after package1ldr (Secure Monitor boot) ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 13
| PerConsoleKeyForFirmwareSpecificPerConsoleKeyGen
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|-
| 14
| StaticKeyForFirmwareSpecificPerConsoleKeyGen
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 15
| PerConsoleKey
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|}

=== [4.0.0]+ Key table after package1ldr (Secure Monitor runtime) ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 13
| FirmwareSpecificPerConsoleKey
| Secure Monitor init
| Yes
| Yes, on security updates
|-
| 15
| PerConsoleKey
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|}

=== [6.2.0]+ Key table after package1ldr/TSEC Payload (Secure Monitor boot) ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| TsecKey
| [[TSEC#Payload|Package1ldr TSEC Firmware]]
| Yes
| No
|-
| 13
| TsecRootKey
| [[TSEC#Payload|Package1ldr TSEC Firmware]]
| No
| Unknown
|-
| 14
| SecureBootKey
| Bootrom
| Yes
| No
|-
| 15
| SecureStorageKey
| Bootrom
| Yes
| No
|}

=== Key generation ===
Note: aes_unwrap(wrapped_key, wrap_key) is just another name for a single AES-128 block decryption.

If bit0 of 0x7000FB94 is clear, it will initialize keys like this (probably used for internal development units only):
// Final keys:
package1_key /* slot11 */ = aes_unwrap(f5b1eadb.., sbk)
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x11 ? simpleseed_dev0 : simpleseed_dev1, aes_unwrap(5ff9c2d9.., sbk))
per_console_key /* slot13 */ = aes_unwrap(4f025f0e..., aes_unwrap(6e4a9592.., ssk))

[4.0.0+] Above method was removed.

Normal key generation looks like this on 1.0.0/2.0.0:

keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x4f ? normalseed_dev : normalseed_retail, keyblob+0x20)
per_console_key /* slot13 */ = aes_unwrap(4f025f0e.., keyblob_key)

.. and on 3.0.0, they moved keyslots around a little to generate the same per-console key as 1.0.0:

old_keyblob_key /* slot10 */ = aes_unwrap(aes_unwrap(df206f59.., tsec_key /* slot13 */), sbk /* slot14 */)
keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x4f ? normalseed_dev : normalseed_retail, keyblob+0x20)
per_console_key /* slot13 */ = aes_unwrap(4f025f0e.., old_keyblob_key)

.. and on 4.0.0 it was further moved around:

keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(normalseed_retail, keyblob+0x20)
new_master_key /* slot14 */ = aes_unwrap(2dc1f48d.., keyblob+0x20)
new_per_console_key /* slot13 */ = aes_unwrap(0c9109db.., old_keyblob_key)
per_console_key /* slot15 */ = aes_unwrap(4f025f0e.., old_keyblob_key)

.. and on 6.2.0, they moved key generation out of package1ldr, and into the Secure Monitor's boot section:

clear_keyslots_other_than_12_13_and_14()

old_keyblob_key /* slot15 */ = aes_unwrap(aes_unwrap(df206f59.., tsec_key /* slot12 */), sbk /* slot14 */)
/* Previously, master_kek was stored at keyblob+0x20) */
master_kek /* slot13 */ = aes_unwrap(374b7729.. /* probably firmware specific */, tsec_root_key /* slot13 */)

clear_keyslot(12)

// Final keys:
new_master_key /* slot12 */ = aes_unwrap(2dc1f48d.., master_kek)
master_key /* slot13 */ = aes_unwrap(normalseed_retail, master_kek)
new_per_console_key /* slot14 */ = aes_unwrap(0c9109db.., old_keyblob_key)
per_console_key /* slot15 */ = aes_unwrap(4f025f0e.., old_keyblob_key)

SBK and SSK keyslots are cleared after keys have been generated.

See table above for which keys are console unique.

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 hardcoded constants for the keyblob used in the current revision. Nintendo are withholding all the future hardcoded constants.

This means that if you have an attack on the bootloader, you need to re-preform it every time they move to a new keyblob.

Dumping the SBK and TSEC key of any single system should be enough to derive all key material on the system, prior to 6.2.0.

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

==== Keyblob ====
There are 32 keyblobs written to NAND at factory, with each keyblob encrypted with a console-unique key derived from the console's SBK, the console's tsec key, and a constant specific to each keyblob.

Despite being encrypted with console unique keys, though, the decrypted keyblob contents are shared for all consoles.

==== Seeds ====
normalseed_retail = d8a2410a...

[1.0.0] wrapped_keyblob_key = df206f59...
[1.0.0] simpleseed_dev0 = aff11423...
[1.0.0] simpleseed_dev1 = 5e177ee1...
[1.0.0] normalseed_dev = 0542a0fd...

[3.0.0] wrapped_keyblob_key = 0c25615d...
[3.0.0] simpleseed_dev0 = de00216a...
[3.0.0] simpleseed_dev1 = 2db7c0a1...
[3.0.0] normalseed_dev = 678c5a03...

[3.0.1] wrapped_keyblob_key = 337685ee...
[3.0.1] simpleseed_dev0 = e045f5ba...
[3.0.1] simpleseed_dev1 = 84d92e0d...
[3.0.1] normalseed_dev = cd88155b...

[4.0.0] wrapped_keyblob_key = 2d1f4880...

==== 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
|-
| 3.0.1-3.0.2
| 3
| 1
|-
| 4.0.0-4.1.0
| 4
| 1
|-
| 5.0.0-5.1.0
| 5
| 1
|-
| 6.0.0-6.1.0
| 6
| 1
|}

Starting from 6.2.0, key generation no longer uses keyblobs.

== Secure Monitor Init ==
On all versions, the key to decrypt [[Package2]] is generated by decrypting a constant seed with the master key. The key is erased after use.

Additionally, starting from 4.0.0, the Secure Monitor init will decrypt another constant seed successively with a special per console key and a special static key passed by package1loader, to generate the firmware specific per-console key. The operation will erase these special keys passed by package1loader.

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

Switch System Flaws

2018-04-23T20:39:31Z

Motezazer: Fun stuff part two

System Flaws are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of known and public Switch System Flaws.

=List of Switch System Flaws=

== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| GMMU DMA attack
| The Switch's GPU includes a separate MMU (GMMU) that is allowed to bypass the system's IOMMU (SMMU). By accessing the GPU's MMIO region and manipulating the page table entries in the GMMU, an attacker can read/write any portion of the DRAM (except memory carveouts).

[5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out.
| None
| HAC-001
| Summer 2017
| December 28, 2017
| [[User:hexkyz|hexkyz]], [[User:SciresM|SciresM]] and [[User:qlutoo|qlutoo]]
|-
| Weak Security Engine context validation
| The Tegra X1 supports a "deep sleep" feature, where everything but DRAM and the PMC registers lose their content (and the SoC loses power). Upon awaking, the bootrom re-executes, restoring system state. Among these stored states is the Security Engine's saved state, which uses AES-128-CBC with a random key and all-zeroes IV. However, the bootrom doesn't perform a MAC on this data, and only validates the last block. This allows one to control most of security engine's state upon wakeup, if one has a way to modify the encrypted state buffer.

With a way to modify the encrypted state buffer, one can thus dump keys from "write-only" keyslots, etc.

This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot.
| None
| HAC-001
| December 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Security Engine keyslots vulnerable to partial overwrite attack
|
The Tegra X1 security engine supports writing keyslot data to the engine with syntax as follows:

SECURITY_ENGINE->AES_KEYTABLE_ADDR = (keyslot << 4) | (dword_index_in_keyslot);

SECURITY_ENGINE->AES_KEYTABLE_DATA = readle32(key, dword_index_in_keyslot * 4);

However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256.
| None
| HAC-001
| Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
|}

== System software ==

=== Stage 1 Bootloader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced.
The BPMP doesn't have an active MPU and the bus won't data abort on an invalid address, so no exception will be entered: it'll end up overwriting some exception vectors with NULL before halting.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Some exception vectors overwritten with NULL, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.

This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.

This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.

Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
|}

=== TrustZone ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.

However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| Mostly useless. Maybe some oob-write into unused (and thus useless) memory if running smcGetRandomBytesForKernel and smcGetRandomBytesForUser at the same time.
| [[2.0.0]]
| [[2.0.0]]
| December 2017 (Probably earlier by others)
| January 18, 2018
| [[User:SciresM|SciresM]], probably others.
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.

This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Missed BPMP Exception Vector Writes
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).

With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.

This was fixed in [[4.0.0]] by writing to the correct registers.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| [[4.0.0]]
| [[4.0.0]]
| January, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others, independently.
|-
|}

=== Kernel ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Syscall Infoleaks
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
| Nothing really.
| 2.0.0
| 2.0.0
|
|
| ?
|-
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| If there is a page fault when fetching handles from the userspace array, it cleans up by dereferencing all objects despite having only loaded first N. Allows the attacker to make arbitrary decrefs on any kernel synchronization object, and thus can be used to get UAF. Haven't actually been tried on real HW though, but should work (tm).
| Kernel code execution
| 2.0.0
| 2.0.0
|
| 24 April
| [[User:qlutoo|qlutoo]]
|-
| GetLastThreadInfo UAF
| GetLastThreadInfo syscall gets last-scheduled-KThread pointer from KScheduler object. This pointer is not reference counted, and can be pointing to a freed KThread.
| Nothing. There is a theoretical race that might leak from a KThread from a different process, but it's impossible to trigger practically.
| Unfixed
|
| 15 October
| 17 October
| [[User:qlutoo|qlutoo]]
|-
| Bad irq_id check in CreateInterruptEvent
| CreateInterruptEvent syscall is designed to work only for irq_id >= 32. All irq_ids < 32 are "per-core" and reserved for kernel use (watchdog/scheduling/core communications).
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
| You can register irq's in the Core3Irqs table, and thus register per-core irqs for core3, that are normally reserved for kernel. Useless.
| 2.0.0
| 2.0.0
| ~October
| 17 October
| [[User:qlutoo|qlutoo]]
|-
| Kernel .text mapped executable in usermode
| Prior to [[3.0.2]] the kernel .text was [[Memory_layout|mapped]] in usermode as executable. This can be used for usermode ROP for bypassing ASLR, but SVCs/IPC are not usable by running kernel .text in usermode.
| Executing kernel .text in usermode
| [[3.0.2]]
| [[3.0.2]]
|
| 34c3 (December 28, 2017)
| [[User:qlutoo|qlutoo]]
|-
| Memory Controller not properly secured
| The Switch OS originally had the memory controller not set to be accessible only by the secure-world, which was problematic because insecure access can compromise the kernel.

This was fixed partially in [[2.0.0]] by blacklisting the memory controller from being mapped by user-processes, and was fixed entirely in [[4.0.0]] by making the memory controller TZ-only and making all kernel accesses go through [[SMC|smcReadWriteRegister]].
| With some way to access the memory controller MMIO, arbitrary kernel code execution.
| [[4.0.0]]
| [[4.0.0]]
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
|}

=== FIRM-package System Modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Service access control bypass (sm:h, smhax, probably other names)
| Prior to [[3.0.1]], the ''service manager'' (sm) built-in system module treats a user as though it has full permissions if the user creates a new "sm:" port session but bypasses [[Services_API#Initialize|initialization]]. This is due to the other sm commands skipping the service ACL check for Pids <= 7 (i.e. all kernel bundled modules) and that skipping the initialization command leaves the Pid field uninitialized.
In [[3.0.1]], sm returns error code 0x415 if [[Services_API#Initialize|Initialize]] has not been called yet.
| Acquiring, registering, and unregistering arbitrary services
| [[3.0.1]]
| [[3.0.1]]
| May 2017
| August 17, 2017
| Everyone
|-
| Overly permissive SPL service
| The concept behind the switch's [[SMC|Secure Monitor]] is that all cryptographic keydata is located in userspace, but stored as "access keys" encrypted with "keks" that never leave TrustZone. The [[SPL services|spl]] ("security processor liaison"?) service serves as an interface between the rest of the system and the secure monitor. Prior to [[4.0.0]], spl exposed only a single service "spl:", which provided all TrustZone wrapper functions to all sysmodules with access to it. Thus anyone with access to the spl: service (via smhax or by pwning a sysmodule with access) could do crypto with any access keys they knew.

This was fixed in [[4.0.0]] by splitting spl: into spl:, spl:mig, spl:ssl, spl:es, and spl:fs.
| Arbitrary spl: crypto with any access keys one knows. For example, one could use the SSL module's access keys to decrypt their console's SSL certificate private key without having to pwn the SSL sysmodule.
| [[4.0.0]]
| [[4.0.0]]
| Summer 2017 (after smhax was discovered).
| December 23, 2017
| Everyone
|-
| Single session services not really single session
| Several "critical" services (like fsp-ldr, fsp-pr, sm:m, etc) are meant to only ever hold a single session with a specific sysmodule. However, when a sysmodule dies, all its service session handles are released -- and thus killing the holder of a single session handle would allow one (via sm:hax etc) to get access to that service.

This was fixed in [[4.0.0]] by adding a semaphore to these critical single-session services, so that even if one gets access to them an error code will be returned when attempting to use any of their commands.
| With some way to access these services and kill their session holders (like expLDR): dumping sysmodule code, arbitrary service access, elevated filesystem permissions, etc.
| [[4.0.0]]
| [[4.0.0]]
| May/June 2017 (basically immediately after smhax was discovered)
| December 30, 2017
| Everyone
|-
|-
| nspwn
| fsp-ldr command 0 "MountCode" takes in a Content Path (retrieved from NCM by Loader), and returns an IFileSystem for the resulting ExeFS. These content paths, are normally NCAs, but MountCode also supports a number of other formats, including ".nsp" -- which is just a PFS0.

When a path ending in ".nsp" is parsed by MountCode, the PFS0 is treated as a raw ExeFS. Because there is no NCA header, the ACID signatures are not validated -- and because there are no other signatures in a PFS0, this results in no signature checking happening at all.

The actual .nsp handling is eventually done by {content mounting function} called by MountCode and other FS commands.

Thus, by placing an ExeFS (NSOs + "main.npdm") and setting one's desired title ID to "@Sdcard:/some_title.nsp" or "@User:/some_title.nsp" etc one can launch arbitrary unsigned code, with arbitrary unsigned NPDMs.
| With access to "lr": Arbitrary code execution with full system privileges.
| [[5.0.0]]
| [[5.0.0]]
| Late 2017
| April 23, 2018
| Everyone
|-
|}

=== System Modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Out-of-bounds array read for [[BCAT_Content_Container]] secret-data index
| The [[BCAT_Content_Container]] secret-data index is not validated at all. This is handled before the RSA-signature(?) is ever used. Since the field is an u8, a total of 0x800-bytes relative to the array start can be accessed.
This is not useful since the string loaded from this array is only involved with key-generation.
|
| Unknown
| [[2.0.0]]
| August 4, 2017
| August 6, 2017
| [[User: shinyquagsire23|Shiny Quagsire]], [[User:Yellows8|yellows8]] (independently)
|-
| OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names)
| Prior to [[3.0.0]], pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In [[3.0.0]], sending out of range indexes causes error code 0x60A to be returned.
| Dumping full NS .text, .rodata and .data, infoleak, etc
| [[3.0.0]]
| [[3.0.0]]
| April 2017
| On exploit's fix in [[3.0.0]]
| [[User:qlutoo|qlutoo]], Reswitched team (independently)
|-
| Unchecked domain ID in common IPC code
| Prior to [[2.0.0]], object IDs in [[IPC_Marshalling#Domain_message|domain messages]] are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages.
|
| 2.0.0
| 2.0.0
| ~July 2017
| 20 July 2017‎
| [[User:hthh|hthh]]
|-
| expLDR (sysmodule handle table exhaustion)
| Most sysmodules share common template code to handle IPC control messages. The command DuplicateSession (type 5 command 2)'s template code will abort() if it fails to duplicate a session's handle for the requester. Because many sysmodules have limited handle table size (smaller than the browser/other entrypoints), repeatedly requesting to duplicate one's session will cause the sysmodule to run out of handle table space and abort, causing the service to release all its handles cleanly.
| Sysmodule crashes. Most usefully, crashing ldr allows access to fsp-ldr and crashing pm allows access to fsp-pr. Useless after [[4.0.0]], which mitigated a number of single-session service access issues.
| Unfixed
| 4.1.0
| 24 June 2017
| 8 March 2018
| [[User:daeken|daeken]]
|}

Switch System Flaws

2018-04-23T20:33:04Z

Motezazer: Fun stuff

System Flaws are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of known and public Switch System Flaws.

=List of Switch System Flaws=

== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| GMMU DMA attack
| The Switch's GPU includes a separate MMU (GMMU) that is allowed to bypass the system's IOMMU (SMMU). By accessing the GPU's MMIO region and manipulating the page table entries in the GMMU, an attacker can read/write any portion of the DRAM (except memory carveouts).

[5.0.0+] Works around this hardware flaw by using memory pool partitioning. You can no longer escalate into sysmodules with GPU DMA because all their memory is allocated using heap that's carved out.
| None
| HAC-001
| Summer 2017
| December 28, 2017
| [[User:hexkyz|hexkyz]], [[User:SciresM|SciresM]] and [[User:qlutoo|qlutoo]]
|-
| Weak Security Engine context validation
| The Tegra X1 supports a "deep sleep" feature, where everything but DRAM and the PMC registers lose their content (and the SoC loses power). Upon awaking, the bootrom re-executes, restoring system state. Among these stored states is the Security Engine's saved state, which uses AES-128-CBC with a random key and all-zeroes IV. However, the bootrom doesn't perform a MAC on this data, and only validates the last block. This allows one to control most of security engine's state upon wakeup, if one has a way to modify the encrypted state buffer.

With a way to modify the encrypted state buffer, one can thus dump keys from "write-only" keyslots, etc.

This also bypasses the SBK protection of the bootROM: indeed, at warmboot, bootROM will always clear keyslot 0xE to prevent malicious code from saving the SBK. Moving the SBK to another keyslot in the saved context renders this protection moot.
| None
| HAC-001
| December 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Security Engine keyslots vulnerable to partial overwrite attack
|
The Tegra X1 security engine supports writing keyslot data to the engine with syntax as follows:

SECURITY_ENGINE->AES_KEYTABLE_ADDR = (keyslot << 4) | (dword_index_in_keyslot);

SECURITY_ENGINE->AES_KEYTABLE_DATA = readle32(key, dword_index_in_keyslot * 4);

However, the Security Engine flushes writes to the internal key tables immediately when AES_KEYTABLE_DATA is written -- this allows one to overwrite a single dword of a key at a time, and thus brute force the contents of keyslots in time (2^32 * 8) = 2^35 instead of 2^256.
| None
| HAC-001
| Theorized Summer 2017 due to suggestive syntax, confirmed April 9, 2018
| April 9, 2018
| [[User:SciresM|SciresM]], almost surely others (independently).
|}

== System software ==

=== Stage 1 Bootloader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced. This would cause a data abort, causing the bootloader to clear the stack and then try to clear the security engine...dereferencing NULL again, over and over in a loop.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Infinite clear-the-stack-then-data-abort loop very early in boot, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.

This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.

This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.

Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
|}

=== TrustZone ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.

However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| Mostly useless. Maybe some oob-write into unused (and thus useless) memory if running smcGetRandomBytesForKernel and smcGetRandomBytesForUser at the same time.
| [[2.0.0]]
| [[2.0.0]]
| December 2017 (Probably earlier by others)
| January 18, 2018
| [[User:SciresM|SciresM]], probably others.
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.

This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
| Missed BPMP Exception Vector Writes
| Starting in [[2.0.0]], the BPMP is asleep at runtime, and is turned on by TrustZone during [[SMC|smcCpuSuspend]] in order to initiate the deep sleep process. When it does so, it is held in RESET, and TrustZone attempts to write to the BPMP exception vectors at 0x6000F200 to register EVP_RESET = lp0_entry_fw_crt0, and all other EVPs to a function that simply reboots. However, while they successfully write EVP_RESET, they miss all the other vectors, accidentally writing to the 0x6000F004-0x6000F020 region instead of the 0x6000F204-0x6000F220 region they want to write to. This results in all the exception vectors for the BPMP other than RESET being "undefined" (attacker controlled).

With some way of causing an exception vector to be taken at the right time, this would give pre-sleep code execution (and thus arbitrary TrustZone code execution, via the security engine flaw). However, none of the abort vectors are really triggerable, and interrupts are disabled for the BPMP when it is taken out of reset. Thus, this is useless in practice.

This was fixed in [[4.0.0]] by writing to the correct registers.
| Theoretically: Arbitrary TrustZone code execution. In practice: Useless.
| [[4.0.0]]
| [[4.0.0]]
| January, 2018
| February 23, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]], [[User:Naehrwert|naehrwert]], [[User:Hexkyz|hexkyz]], probably others, independently.
|-
|}

=== Kernel ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Syscall Infoleaks
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
| Nothing really.
| 2.0.0
| 2.0.0
|
|
| ?
|-
| svcWaitSynchronization/svcReplyAndReceive bad cleanup on error
| If there is a page fault when fetching handles from the userspace array, it cleans up by dereferencing all objects despite having only loaded first N. Allows the attacker to make arbitrary decrefs on any kernel synchronization object, and thus can be used to get UAF. Haven't actually been tried on real HW though, but should work (tm).
| Kernel code execution
| 2.0.0
| 2.0.0
|
| 24 April
| [[User:qlutoo|qlutoo]]
|-
| GetLastThreadInfo UAF
| GetLastThreadInfo syscall gets last-scheduled-KThread pointer from KScheduler object. This pointer is not reference counted, and can be pointing to a freed KThread.
| Nothing. There is a theoretical race that might leak from a KThread from a different process, but it's impossible to trigger practically.
| Unfixed
|
| 15 October
| 17 October
| [[User:qlutoo|qlutoo]]
|-
| Bad irq_id check in CreateInterruptEvent
| CreateInterruptEvent syscall is designed to work only for irq_id >= 32. All irq_ids < 32 are "per-core" and reserved for kernel use (watchdog/scheduling/core communications).
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
| You can register irq's in the Core3Irqs table, and thus register per-core irqs for core3, that are normally reserved for kernel. Useless.
| 2.0.0
| 2.0.0
| ~October
| 17 October
| [[User:qlutoo|qlutoo]]
|-
| Kernel .text mapped executable in usermode
| Prior to [[3.0.2]] the kernel .text was [[Memory_layout|mapped]] in usermode as executable. This can be used for usermode ROP for bypassing ASLR, but SVCs/IPC are not usable by running kernel .text in usermode.
| Executing kernel .text in usermode
| [[3.0.2]]
| [[3.0.2]]
|
| 34c3 (December 28, 2017)
| [[User:qlutoo|qlutoo]]
|-
| Memory Controller not properly secured
| The Switch OS originally had the memory controller not set to be accessible only by the secure-world, which was problematic because insecure access can compromise the kernel.

This was fixed partially in [[2.0.0]] by blacklisting the memory controller from being mapped by user-processes, and was fixed entirely in [[4.0.0]] by making the memory controller TZ-only and making all kernel accesses go through [[SMC|smcReadWriteRegister]].
| With some way to access the memory controller MMIO, arbitrary kernel code execution.
| [[4.0.0]]
| [[4.0.0]]
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
|}

=== FIRM-package System Modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Service access control bypass (sm:h, smhax, probably other names)
| Prior to [[3.0.1]], the ''service manager'' (sm) built-in system module treats a user as though it has full permissions if the user creates a new "sm:" port session but bypasses [[Services_API#Initialize|initialization]]. This is due to the other sm commands skipping the service ACL check for Pids <= 7 (i.e. all kernel bundled modules) and that skipping the initialization command leaves the Pid field uninitialized.
In [[3.0.1]], sm returns error code 0x415 if [[Services_API#Initialize|Initialize]] has not been called yet.
| Acquiring, registering, and unregistering arbitrary services
| [[3.0.1]]
| [[3.0.1]]
| May 2017
| August 17, 2017
| Everyone
|-
| Overly permissive SPL service
| The concept behind the switch's [[SMC|Secure Monitor]] is that all cryptographic keydata is located in userspace, but stored as "access keys" encrypted with "keks" that never leave TrustZone. The [[SPL services|spl]] ("security processor liaison"?) service serves as an interface between the rest of the system and the secure monitor. Prior to [[4.0.0]], spl exposed only a single service "spl:", which provided all TrustZone wrapper functions to all sysmodules with access to it. Thus anyone with access to the spl: service (via smhax or by pwning a sysmodule with access) could do crypto with any access keys they knew.

This was fixed in [[4.0.0]] by splitting spl: into spl:, spl:mig, spl:ssl, spl:es, and spl:fs.
| Arbitrary spl: crypto with any access keys one knows. For example, one could use the SSL module's access keys to decrypt their console's SSL certificate private key without having to pwn the SSL sysmodule.
| [[4.0.0]]
| [[4.0.0]]
| Summer 2017 (after smhax was discovered).
| December 23, 2017
| Everyone
|-
| Single session services not really single session
| Several "critical" services (like fsp-ldr, fsp-pr, sm:m, etc) are meant to only ever hold a single session with a specific sysmodule. However, when a sysmodule dies, all its service session handles are released -- and thus killing the holder of a single session handle would allow one (via sm:hax etc) to get access to that service.

This was fixed in [[4.0.0]] by adding a semaphore to these critical single-session services, so that even if one gets access to them an error code will be returned when attempting to use any of their commands.
| With some way to access these services and kill their session holders (like expLDR): dumping sysmodule code, arbitrary service access, elevated filesystem permissions, etc.
| [[4.0.0]]
| [[4.0.0]]
| May/June 2017 (basically immediately after smhax was discovered)
| December 30, 2017
| Everyone
|-
|-
| nspwn
| fsp-ldr command 0 "MountCode" takes in a Content Path (retrieved from NCM by Loader), and returns an IFileSystem for the resulting ExeFS. These content paths, are normally NCAs, but MountCode also supports a number of other formats, including ".nsp" -- which is just a PFS0.

When a path ending in ".nsp" is parsed by MountCode, the PFS0 is treated as a raw ExeFS. Because there is no NCA header, the ACID signatures are not validated -- and because there are no other signatures in a PFS0, this results in no signature checking happening at all.

The actual .nsp handling is eventually done by {content mounting function} called by MountCode and other FS commands.

Thus, by placing an ExeFS (NSOs + "main.npdm") and setting one's desired title ID to "@Sdcard:/some_title.nsp" or "@User:/some_title.nsp" etc one can launch arbitrary unsigned code, with arbitrary unsigned NPDMs.
| With access to "lr": Arbitrary code execution with full system privileges.
| [[5.0.0]]
| [[5.0.0]]
| Late 2017
| April 23, 2018
| Everyone
|-
|}

=== System Modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Out-of-bounds array read for [[BCAT_Content_Container]] secret-data index
| The [[BCAT_Content_Container]] secret-data index is not validated at all. This is handled before the RSA-signature(?) is ever used. Since the field is an u8, a total of 0x800-bytes relative to the array start can be accessed.
This is not useful since the string loaded from this array is only involved with key-generation.
|
| Unknown
| [[2.0.0]]
| August 4, 2017
| August 6, 2017
| [[User: shinyquagsire23|Shiny Quagsire]], [[User:Yellows8|yellows8]] (independently)
|-
| OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names)
| Prior to [[3.0.0]], pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In [[3.0.0]], sending out of range indexes causes error code 0x60A to be returned.
| Dumping full NS .text, .rodata and .data, infoleak, etc
| [[3.0.0]]
| [[3.0.0]]
| April 2017
| On exploit's fix in [[3.0.0]]
| [[User:qlutoo|qlutoo]], Reswitched team (independently)
|-
| Unchecked domain ID in common IPC code
| Prior to [[2.0.0]], object IDs in [[IPC_Marshalling#Domain_message|domain messages]] are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages.
|
| 2.0.0
| 2.0.0
| ~July 2017
| 20 July 2017‎
| [[User:hthh|hthh]]
|-
| expLDR (sysmodule handle table exhaustion)
| Most sysmodules share common template code to handle IPC control messages. The command DuplicateSession (type 5 command 2)'s template code will abort() if it fails to duplicate a session's handle for the requester. Because many sysmodules have limited handle table size (smaller than the browser/other entrypoints), repeatedly requesting to duplicate one's session will cause the sysmodule to run out of handle table space and abort, causing the service to release all its handles cleanly.
| Sysmodule crashes. Most usefully, crashing ldr allows access to fsp-ldr and crashing pm allows access to fsp-pr. Useless after [[4.0.0]], which mitigated a number of single-session service access issues.
| Unfixed
| 4.1.0
| 24 June 2017
| 8 March 2018
| [[User:daeken|daeken]]
|}

Gamecard

2018-03-24T21:42:36Z

Motezazer:

For the Gamecard partitions that can be [[Filesystem_services|mounted]], see [[Gamecard_Partition|here]].

For the format of the Gamecard image, see [[Gamecard_Format|here]].

= Gamecard controller =

The gamecard controller (a separate chip on the gamecard reader board) is responsible for communicating with the Gamecard.
[[Filesystem_services|FS]], to access the gamecard data, will communicate with the gamecard controller. At each boot, firmware blobs (with a fixed size of 0x7800 bytes) are sent by FS to the gamecard controller.

The gamecard controller firmware is encrypted, signed and follows the format below.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| RSA-PKCS#1 signature
|-
| 0x100
| 0x4
| Magic ("LAFW")
|-
| 0x104
| 0x4
| Unknown (0xFF000000, 0xFFFF0000 or 0xFFFFFF00)
|-
| 0x108
| 0x4
|
|-
| 0x10C
| 0x4
|
|-
| 0x110
| 0x4
| Version (0, 1 or 3)
|-
| 0x114
| 0x4
| Unknown (0x80000000)
|-
| 0x118
| 0x4
| Data size
|-
| 0x11C
| 0x4
|
|-
| 0x120
| 0x10
| Data hash
|-
| 0x130
| 0x10
| Placeholder string ("IDIDIDIDIDIDIDID")
|-
| 0x140
| 0x40
| Empty
|-
| 0x180
| 0x7680
| Encrypted data
|}

= Hardware =
{| style="float:right; margin-left: 0px;"
|-
| [[File:ZeldaFront.jpg|200px|thumb|right|A Switch game cartridge, frontside]]
| [[File:ZeldaBack.jpg|200px|thumb|right|A Switch game cartridge, backside]]
|-
| [[File:CartridgeFront.jpeg|200px|thumb|right|Close-up of frontside PCB]]
|rowspan="2"|[[File:CartridgeBack.jpeg|200px|thumb|right|Close-up of backside PCB]]
|-
|[[File:CartridgeFrontBare.jpeg|200px|thumb|right|Close-up of stripped frontside PCB]]
|
|-
|}

== Pinout ==
[[File:Gamecard-pinout.png|400px]]

{| class="wikitable"
! Pin
! Name
! Direction
! Description
|-
| 0
| IRQ?
| Output
| Always wired to GND inside game cartridge; Possibly used for interrupt signaling
|-
| 1
| RCLK
| Output
| Return clock; Game cartridge sends back CLK signal delayed by a few ns
|-
| 2
| CLK
| Input
| Clock, 25MHz
|-
| 3
| CS
| Input
| Chip select; Switch pulls this LOW during a transfer
|-
| 4
| DAT0
| Inout
| Data bus pin 0
|-
| 5
| DAT1
| Inout
| Data bus pin 1
|-
| 6
| VCC 3.3v
| Input
|
|-
| 7
| DAT2
| Inout
| Data bus pin 2
|-
| 8
| DAT3
| Inout
| Data bus pin 3
|-
| 9
| VCC 1.8v
| Input
|
|-
| 10
| DAT4
| Inout
| Data bus pin 4
|-
| 11
| DAT5
| Inout
| Data bus pin 5
|-
| 12
| DAT6
| Inout
| Data bus pin 6
|-
| 13
| DAT7
| Inout
| Data bus pin 7
|-
| 14
| GND
|
|
|-
| 15
| RST
| Input
| Reset, active LOW.
|-
|}

All IO use 1.8V for logic HIGH and 0V for logic LOW.

== Protocol ==
Switch game cartridges use a simple (but Nintendo proprietery) SPI-like bus with 8-bit width (DAT7..0). It is very similar to the bus interface of 3DS game cartridges, except with very different commands.

The Switch host starts a transfer by first pulling CS low, followed by clocking a byte each clock cycle. The bus data will always be ready before the rising edge of the CLK signal, so that it can be captured on the rising edge.
After command bytes are written to the bus, the direction of the bus implicitly changes and the game cartridge responds. The Switch host keeps clocking while the game cartridge responds.
After the transfer is ended, the CS line is pulled high again.

Commands are 16 bytes long, and followed immediately by a 4-byte CRC-32 over the command bytes. After this, the Switch stops driving the data bus, and the bus will be 'floating'. Due to the pull-ups on the bus, it will slowly converge to logic HIGH state. The Switch will clock 2 cycles to allow the bus to settle a direction change. The Switch host will then clock another cycle and if the game cartridge didn't receive the CRC OK, it will respond with "01". Otherwise it will respond with "00" and pull DAT0 low on the next cycle to signal it is busy. The Switch host will then keep clocking until the cartridge is ready.

When the game cartridge is ready to send the actual data response, it will pull the DAT0 pin high for 2 cycles to let the Switch host know. After this, the game cartridge will send the actual data response bytes.

The actual response bytes are also followed immediately by a 4-byte CRC-32 over the actual data response bytes.

== Commands ==
A typical boot up sequence of a game cartridge (in this case, the game "1,2 Switch") looks like this:

{| class="wikitable"
! Command
! Size
! Description
|-
| <code>5B000000000000010000000000000000</code>
| 0x200
| Read sector 0, contains "HEAD" blob
|-
| <code>5B000000000000010000000000000000</code>
| 0x200
| Read sector 0, contains "HEAD" blob
|-
| <code>56000000000000000000000000000000</code>
| 0x4
| Read card id "AE F8 01 21"
|-
| <code>28000000000000000000000000000000</code>
| 0x4
| Read ??? "02 00 00 00"
|-
| <code>A5000000000000000000000000000000</code>
| 0x4
| Read ??? "00 00 00 00"
|-
| <code>56000000000000000000000000000000</code>
| 0x4
| Read card id "AE F8 01 21"
|-
| <code>28000000000000000000000000000000</code>
| 0x4
| Read ??? "02 00 00 00"
|-
| <code>5B000000380000010000000000000000</code>
| 0x200
| Read sector 0x38, contains "CERT" blob
|-
| <code>E2000000000000000000000000000000</code>
| 0x4
| Read ??? "01 00 00 00"
|-
| <code>E0000000000000000000000000000000</code>
| 0x200
| Read crypto-challenge header
|-
| <code>200838A25A344F818ABB6456694D4E8D</code>
| 0
| Enter crypto mode1 with HOST-RANDOM "0838A25A344F818ABB6456694D4E8D"
|-
| <code>7EE41FDF12C01C157CC899910673A0CF</code>
| 0x40
| Encrypted crypto mode1 command, reads CART-RANDOM
|-
| <code>263C8230EC15FAE3CE79365BD850F4BD</code>
| 0x0
| Encrypted mode1 command, enters crypto mode2 with (HOST-RANDOM, CART-RANDOM)
|-
| <code>B6FDA6F37FFA29E18831D0B217DFBDBE</code>
| 0x4
| Encrypted mode2 command, possibly read card id?
|-
| <code>7B97F7DF07240AA9870E1C974336FA8A</code>
| 0x4
| Encrypted mode2 command
|-
|}

The meaning of some these commands are currently unknown.

== Observations ==
* The "update" and "normal" partitions can be dumped using the plaintext 5B commands
* The "secure" partition can only be read from encrypted mode.

== Encryption ==
After a few initial plaintext commands, the Switch instructs the game cartridge to enter into encrypted mode. From that point on, commands and responses are sent encrypted over the bus. The encryption algorithm used is currently unknown.

There appear to be 2 kinds of crypto mode.

Crypto mode1 is initiated solely by the HOST-RANDOM as random session seed. In that mode, the Switch host requests for the game cartridge random seed, and then sends a command to enter crypto mode2.

Crypto mode2 takes into account the CART-RANDOM seed generated by the cartridge, and possibly the previous HOST-RANDOM.
The game cartridge will always send a different CART-RANDOM even if the exact same command sequence is replayed and thus with this scheme replay attacks are not possible.

== Manufacturers ==
;Macronix (MX)
: Uses package: LGA
: Uses card id: 0xC2
;OKI Semiconductor
: Uses package: TSOP-48
: Uses card id: 0xAE
;SanDisk?
: Uses package: ??
: Uses card id: 0x45 ?

Cryptosystem

2018-03-12T23:39:19Z

Motezazer: New update + clarifications

== BootROM ==
The bootrom initializes two keyslots in the hardware engine:

* the SBK (Secure Boot Key) in keyslot 14
* the SSK (Secure Storage Key) in keyslot 15.

Reads from both of these keyslots are disabled by the bootROM.
The SBK is stored in [[Fuses#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY]], which are locked to read out only FFs after the bootrom finishes.

SBK is '''unique''' per console, and not shared among consoles as originally believed.

The SSK is derived on boot via the SBK, the 32-bit console-unique "Device Key", and hardware information stored in fuses.

Pseudocode for the derivation is as follows:
void generateSSK() {
char keyBuffer[0x10]; // Used to store keydata
uint hwInfoBuffer[4]; // Used to store info about hardware from fuses
uint deviceKey = getDeviceKey(); // Reads 32-bit device key from FUSE_PRIVATE_KEY4.
for (int i = 0; i < 4; i++) { // Keybuffer = deviceKey || deviceKey || deviceKey || deviceKey
((uint *)keyBuffer)[i] = deviceKey;
}

encryptWithSBK(keyBuffer); // keyBuffer = AES-ECB(SBK, deviceKey || {...})

// Set up Hardware info buffer
uint vendor_code = *((uint *)0x7000FA00) & 0x0000000F; // FUSE_VENDOR_CODE
uint fab_code = *((uint *)0x7000FA04) & 0x0000003F; // FUSE_FAB_CODE
uint lot_code_0 = *((uint *)0x7000FA08) & 0xFFFFFFFF; // FUSE_LOT_CODE_0
uint lot_code_1 = *((uint *)0x7000FA0C) & 0x0FFFFFFF; // FUSE_LOT_CODE_1
uint wafer_id = *((uint *)0x7000FA10) & 0x0000003F; // FUSE_WAFER_ID
uint x_coord = *((uint *)0x7000FA14) & 0x000001FF; // FUSE_X_COORDINATE
uint y_coord = *((uint *)0x7000FA18) & 0x000001FF; // FUSE_Y_COORDINATE
uint unk_hw_fuse = *((uint *)0x7000FA20) & 0x0000003F; // Unknown cached fuse.

// HARDWARE_INFO_BUFFER = unk_hw_fuse || Y_COORD || X_COORD || WAFER_ID || LOT_CODE || FAB_CODE || VENDOR_ID
hwInfoBuffer[0] = (lot_code_1 << 30) | (wafer_id << 24) | (x_coord << 15) | (y_coord << 6) | unk_hw_fuse;
hwInfoBuffer[1] = (lot_code_0 << 26) | (lot_code_1 >> 2);
hwInfoBuffer[2] = (fab_code << 26) | (lot_code_0 >> 6);
hwInfoBuffer[3] = vendor_code;

for (int i = 0; i < 0x10; i++) { // keyBuffer = XOR(AES-ECB(SBK, deviceKey || {...}), HARDWARE_INFO_BUFFER)
keyBuffer[i] ^= ((char *)hwInfoBuffer)[i];
}

encryptWithSBK(keyBuffer); // keyBuffer = AES-ECB(SBK, XOR(AES-ECB(SBK, deviceKey || {...}), HARDWARE_INFO_BUFFER))

setKeyslot(KEYSLOT_SSK, keyBuffer); // SSK = keyBuffer.
}

== Falcon coprocessor ==
The falcon processor (TSEC) generates a special console-unique key (that will be referred to as the "tsec key").

This is presumably using data stored in fuses that only microcode authenticated by NVidia has access to.

== Package1ldr ==

=== Key table during package1ldr ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 11
| Package1Key
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes
|-
| 14
| SecureBootKey
| Bootrom
| Yes
| No
|-
| 15
| SecureStorageKey
| Bootrom
| Yes
| No
|}

=== [1.0.0-3.0.2] Key table after package1ldr ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 13
| PerConsoleKey
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|}

=== [4.0.0]+ Key table after package1ldr (Secure Monitor boot) ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 13
| PerConsoleKeyForFirmwareSpecificPerConsoleKeyGen
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|-
| 14
| StaticKeyForFirmwareSpecificPerConsoleKeyGen
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 15
| PerConsoleKey
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|}

=== [4.0.0]+ Key table after package1ldr (Secure Monitor runtime) ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1#Package1ldr|Package1ldr]]
| No
| Yes, on security updates
|-
| 13
| FirmwareSpecificPerConsoleKey
| Secure Monitor init
| Yes
| Yes, on security updates
|-
| 15
| PerConsoleKey
| [[Package1#Package1ldr|Package1ldr]]
| Yes
| No
|}

=== Key generation ===
Note: aes_unwrap(wrapped_key, wrap_key) is just another name for a single AES-128 block decryption.

If bit0 of 0x7000FB94 is clear, it will initialize keys like this (probably used for internal development units only):
// Final keys:
package1_key /* slot11 */ = aes_unwrap(f5b1eadb.., sbk)
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x11 ? simpleseed_dev0 : simpleseed_dev1, aes_unwrap(5ff9c2d9.., sbk))
per_console_key /* slot13 */ = aes_unwrap(4f025f0e..., aes_unwrap(6e4a9592.., ssk))

[4.0.0+] Above method was removed.

Normal key generation looks like this on 1.0.0/2.0.0:

keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x4f ? normalseed_dev : normalseed_retail, keyblob+0x20)
per_console_key /* slot13 */ = aes_unwrap(4f025f0e.., keyblob_key)

.. and on 3.0.0, they moved keyslots around a little to generate the same per-console key as 1.0.0:

old_keyblob_key /* slot10 */ = aes_unwrap(aes_unwrap(df206f59.., tsec_key /* slot13 */), sbk /* slot14 */)
keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x4f ? normalseed_dev : normalseed_retail, keyblob+0x20)
per_console_key /* slot13 */ = aes_unwrap(4f025f0e.., old_keyblob_key)

.. and on 4.0.0 it was further moved around:

old_keyblob_key /* slot15 */ = aes_unwrap(aes_unwrap(df206f59.., tsec_key /* slot13 */), sbk /* slot14 */)
keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(normalseed_retail, keyblob+0x20)
new_master_key /* slot14 */ = aes_unwrap(2dc1f48d.., keyblob+0x20)
new_per_console_key /* slot13 */ = aes_unwrap(0c9109db.., old_keyblob_key)
per_console_key /* slot15 */ = aes_unwrap(4f025f0e.., old_keyblob_key)

SBK and SSK keyslots are cleared after keys have been generated.

See table above for which keys are console unique.

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 hardcoded constants for the keyblob used in the current revision. Nintendo are withholding all the future hardcoded constants.

This means that if you have an attack on the bootloader, you need to re-preform it every time they move to a new keyblob.

Dumping the SBK and TSEC key of any single system should be enough to derive all key material on the system.

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

==== Keyblob ====
There are 32 keyblobs written to NAND at factory, with each keyblob encrypted with a console-unique key derived from the console's SBK, the console's tsec key, and a constant specific to each keyblob.

Despite being encrypted with console unique keys, though, the decrypted keyblob contents are shared for all consoles.

==== Seeds ====
normalseed_retail = d8a2410a...

[1.0.0] wrapped_keyblob_key = df206f59...
[1.0.0] simpleseed_dev0 = aff11423...
[1.0.0] simpleseed_dev1 = 5e177ee1...
[1.0.0] normalseed_dev = 0542a0fd...

[3.0.0] wrapped_keyblob_key = 0c25615d...
[3.0.0] simpleseed_dev0 = de00216a...
[3.0.0] simpleseed_dev1 = 2db7c0a1...
[3.0.0] normalseed_dev = 678c5a03...

[3.0.1] wrapped_keyblob_key = 337685ee...
[3.0.1] simpleseed_dev0 = e045f5ba...
[3.0.1] simpleseed_dev1 = 84d92e0d...
[3.0.1] normalseed_dev = cd88155b...

[4.0.0] wrapped_keyblob_key = 2d1f4880...

==== 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
|-
| 3.0.1-3.0.2
| 3
| 1
|-
| 4.0.0-4.1.0
| 4
| 1
|-
| 5.0.0
| 5
| 1
|}

== Secure Monitor Init ==
On all versions, the key to decrypt [[Package2]] is generated by decrypting a constant seed with the master key. The key is erased after use.

Additionally, starting from 4.0.0, the Secure Monitor init will decrypt another constant seed successively with a special per console key and a special static key passed by package1loader, to generate the firmware specific per-console key. The operation will erase these special keys passed by package1loader.

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

Fuses

2018-03-12T23:35:42Z

Motezazer: New update

The Nintendo Switch makes use of Tegra's fuse driver for a number of operations. This driver is mapped to physical address 0x7000F800 with a total size of 0x400 bytes and exposes several registers for fuse programming.

Registers from 0x7000F800 to 0x7000F800 + 0xFF can be used to directly program the hardware fuse array, while registers from 0x7000F800 + 0x100 (FUSE_CHIP_REG_START_OFFSET) to 0x7000F800 + 0x3FC (FUSE_CHIP_REG_END_OFFSET) represent cached values read from certain fuses.

== Registers ==
Below is a list of fuse driver registers used by the Switch's bootloaders.

=== Driver registers ===
{| class="wikitable" border="1"
! Name
! Address
|-
| [[#FUSE_CTRL|FUSE_CTRL]]
| 0x7000F800
|-
| [[#FUSE_REG_ADDR|FUSE_REG_ADDR]]
| 0x7000F804
|-
| [[#FUSE_REG_READ|FUSE_REG_READ]]
| 0x7000F808
|-
| [[#FUSE_REG_WRITE|FUSE_REG_WRITE]]
| 0x7000F80C
|-
| FUSE_TIME_RD1
| 0x7000F810
|-
| FUSE_TIME_RD2
| 0x7000F814
|-
| FUSE_TIME_PGM1
| 0x7000F818
|-
| [[#FUSE_TIME_PGM2|FUSE_TIME_PGM2]]
| 0x7000F81C
|-
| FUSE_PRIV2INTFC
| 0x7000F820
|-
| FUSE_FUSEBYPASS
| 0x7000F824
|-
| FUSE_PRIVATEKEYDISABLE
| 0x7000F828
|-
| [[#FUSE_DIS_PGM|FUSE_DIS_PGM]]
| 0x7000F82C
|-
| [[#FUSE_WRITE_ACCESS|FUSE_WRITE_ACCESS]]
| 0x7000F830
|-
| FUSE_PWR_GOOD_SW
| 0x7000F834
|-
|}

==== FUSE_CTRL ====
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| Fuse command (1 = FUSE_READ; 2 = FUSE_WRITE; 3 = FUSE_SENSE)
|-
| 26
| Fuse power down mode flag (FUSE_CTRL_PD)
|-
|}

Before fuse reading/writing the power down mode must be disabled.
FUSE_SENSE mode flushes programmed values into the [[Fuses#Cache_registers|cache registers]].

==== FUSE_REG_ADDR ====
This register takes the address of the fuse to be read/written/sensed.

==== FUSE_REG_READ ====
This register receives the value read from the fuse.

==== FUSE_REG_WRITE ====
This register takes the value to be written to the fuse.

==== FUSE_TIME_PGM2 ====
This register takes the fuse programming pulse (0xC0 == 19200 kHz).

==== FUSE_DIS_PGM ====
If set to 0x01, this register disables fuse programming.

==== FUSE_WRITE_ACCESS ====
If set to 0x01, this register disables software writes to the fuse driver registers.

=== Cache registers ===
{| class="wikitable" border="1"
! Name
! Address
|-
| FUSE_PRODUCTION_MODE
| 0x7000F900
|-
| [[#FUSE_SKU_INFO|FUSE_SKU_INFO]]
| 0x7000F910
|-
| FUSE_CPU_SPEEDO_0
| 0x7000F914
|-
| FUSE_CPU_IDDQ
| 0x7000F918
|-
| FUSE_FT_REV
| 0x7000F928
|-
| FUSE_CPU_SPEEDO_1
| 0x7000F92C
|-
| FUSE_CPU_SPEEDO_2
| 0x7000F930
|-
| FUSE_SOC_SPEEDO_0
| 0x7000F934
|-
| [[#FUSE_SOC_SPEEDO_1|FUSE_SOC_SPEEDO_1]]
| 0x7000F938
|-
| FUSE_SOC_SPEEDO_2
| 0x7000F93C
|-
| FUSE_SOC_IDDQ
| 0x7000F940
|-
| [[#FUSE_FA|FUSE_FA]]
| 0x7000F948
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY0]]
| 0x7000F964
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY1]]
| 0x7000F968
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY2]]
| 0x7000F96C
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY3]]
| 0x7000F970
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY4]]
| 0x7000F974
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY5]]
| 0x7000F978
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY6]]
| 0x7000F97C
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY7]]
| 0x7000F980
|-
| FUSE_TSENSOR_1
| 0x7000F984
|-
| FUSE_TSENSOR_2
| 0x7000F988
|-
| FUSE_CP_REV
| 0x7000F990
|-
| FUSE_TSENSOR_0
| 0x7000F998
|-
| FUSE_FIRST_BOOTROM_PATCH_SIZE_REG
| 0x7000F99C
|-
| FUSE_SECURITY_MODE
| 0x7000F9A0
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY0]]
| 0x7000F9A4
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY1]]
| 0x7000F9A8
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY2]]
| 0x7000F9AC
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY3]]
| 0x7000F9B0
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY4]]
| 0x7000F9B4
|-
| [[#FUSE_RESERVED_SW|FUSE_RESERVED_SW]]
| 0x7000F9C0
|-
| FUSE_VP8_ENABLE
| 0x7000F9C4
|-
| FUSE_RESERVED_ODM0
| 0x7000F9C8
|-
| FUSE_RESERVED_ODM1
| 0x7000F9CC
|-
| FUSE_RESERVED_ODM2
| 0x7000F9D0
|-
| FUSE_RESERVED_ODM3
| 0x7000F9D4
|-
| [[#FUSE_RESERVED_ODM4|FUSE_RESERVED_ODM4]]
| 0x7000F9D8
|-
| FUSE_RESERVED_ODM5
| 0x7000F9DC
|-
| [[#FUSE_RESERVED_ODM6|FUSE_RESERVED_ODM6]]
| 0x7000F9E0
|-
| [[#FUSE_RESERVED_ODM7|FUSE_RESERVED_ODM7]]
| 0x7000F9E4
|-
| FUSE_SKU_USB_CALIB
| 0x7000F9F0
|-
| FUSE_SKU_DIRECT_CONFIG
| 0x7000F9F4
|-
| FUSE_VENDOR_CODE
| 0x7000FA00
|-
| FUSE_FAB_CODE
| 0x7000FA04
|-
| FUSE_LOT_CODE_0
| 0x7000FA08
|-
| FUSE_LOT_CODE_1
| 0x7000FA0C
|-
| FUSE_WAFER_ID
| 0x7000FA10
|-
| FUSE_X_COORDINATE
| 0x7000FA14
|-
| FUSE_Y_COORDINATE
| 0x7000FA18
|-
| FUSE_SATA_CALIB
| 0x7000FA24
|-
| FUSE_GPU_IDDQ
| 0x7000FA28
|-
| FUSE_TSENSOR_3
| 0x7000FA2C
|-
| FUSE_OPT_SUBREVISION
| 0x7000FA48
|-
| FUSE_TSENSOR_4
| 0x7000FA54
|-
| FUSE_TSENSOR_5
| 0x7000FA58
|-
| FUSE_TSENSOR_6
| 0x7000FA5C
|-
| FUSE_TSENSOR_7
| 0x7000FA60
|-
| FUSE_OPT_PRIV_SEC_DIS
| 0x7000FA64
|-
| [[#FUSE_PKC_DISABLE|FUSE_PKC_DISABLE]]
| 0x7000FA68
|-
| FUSE_TSENSOR_COMMON
| 0x7000FA80
|-
| FUSE_DEBUG_AUTH_OVERRIDE
| 0x7000FA9C
|-
| FUSE_TSENSOR_8
| 0x7000FAD4
|-
| FUSE_RESERVED_CALIB
| 0x7000FB04
|-
| FUSE_TSENSOR_9
| 0x7000FB1C
|-
| FUSE_USB_CALIB_EXT
| 0x7000FB50
|-
| FUSE_SPARE_BIT_0
| 0x7000FB80
|-
| FUSE_SPARE_BIT_1
| 0x7000FB84
|-
| FUSE_SPARE_BIT_2
| 0x7000FB88
|-
| FUSE_SPARE_BIT_3
| 0x7000FB8C
|-
| FUSE_SPARE_BIT_4
| 0x7000FB90
|-
| [[#FUSE_SPARE_BIT_5|FUSE_SPARE_BIT_5]]
| 0x7000FB94
|-
| FUSE_SPARE_BIT_6
| 0x7000FB98
|-
| FUSE_SPARE_BIT_7
| 0x7000FB9C
|-
| FUSE_SPARE_BIT_8
| 0x7000FBA0
|-
| FUSE_SPARE_BIT_9
| 0x7000FBA4
|-
| FUSE_SPARE_BIT_10
| 0x7000FBA8
|-
| FUSE_SPARE_BIT_11
| 0x7000FBAC
|-
| FUSE_SPARE_BIT_12
| 0x7000FBB0
|-
| FUSE_SPARE_BIT_13
| 0x7000FBB4
|-
| FUSE_SPARE_BIT_14
| 0x7000FBB8
|-
| FUSE_SPARE_BIT_15
| 0x7000FBBC
|-
| FUSE_SPARE_BIT_16
| 0x7000FBC0
|-
| FUSE_SPARE_BIT_17
| 0x7000FBC4
|-
| FUSE_SPARE_BIT_18
| 0x7000FBC8
|-
| FUSE_SPARE_BIT_19
| 0x7000FBCC
|-
| FUSE_SPARE_BIT_20
| 0x7000FBD0
|-
| FUSE_SPARE_BIT_21
| 0x7000FBD4
|-
| FUSE_SPARE_BIT_22
| 0x7000FBD8
|-
| FUSE_SPARE_BIT_23
| 0x7000FBDC
|-
| FUSE_SPARE_BIT_24
| 0x7000FBE0
|-
| FUSE_SPARE_BIT_25
| 0x7000FBE4
|-
| FUSE_SPARE_BIT_26
| 0x7000FBE8
|-
| FUSE_SPARE_BIT_27
| 0x7000FBEC
|-
| FUSE_SPARE_BIT_28
| 0x7000FBF0
|-
| FUSE_SPARE_BIT_29
| 0x7000FBF4
|-
| FUSE_SPARE_BIT_30
| 0x7000FBF8
|-
| FUSE_SPARE_BIT_31
| 0x7000FBFC
|-
|}

==== FUSE_SKU_INFO ====
Stores the SKU ID (must be 0x83).

==== FUSE_FA ====
Stores failure analysis mode.

==== FUSE_SOC_SPEEDO_1 ====
Stores the bootrom patch version.

==== FUSE_RESERVED_ODM4 ====
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| Unit type (3 = debug; 0 = retail)
|-
| 2
| Unknown config (must be 1 on retail)
|-
| 3-5
| DRAM id
|-
| 8
| Unknown config mask (must be 0 on retail)
|-
| 9
| Unit type mask (0 = debug; 1 = retail)
|-
| 10
| [4.0.0+] Unknown, returned by smcGetConfig(14)
|-
| 16-19
| [4.0.0+] Unknown config (hardware-type-related)
|}

This stores some device configuration parameters.

==== FUSE_RESERVED_ODM6 ====
This register returns the value programmed into index 0x3A of the fuse array.

==== FUSE_RESERVED_ODM7 ====
This register returns the value programmed into index 0x3C of the fuse array.

==== FUSE_SPARE_BIT_5 ====
Must be non-zero on retail units, otherwise the first bootloader panics.
On debug units it can be zero, which tells the bootloader to choose from two debug master key seeds. If set to non-zero on a debug unit, it tells the bootloader to choose from two retail master key seeds (only the last one matches the retail master key seed).

==== FUSE_PRIVATE_KEY ====
This stores the 160-bit private key (128 bit SBK + 32-bit device key).
Reads to these registers after the SBK is locked out produce all-FF output.

==== FUSE_PUBLIC_KEY ====
This stores the SHA256 hash of the 2048-bit RSA key expected at BCT+0x210.

==== FUSE_RESERVED_SW ====
{| class="wikitable" border="1"
! Bits
! Description
|-
| 5
| ENABLE_WATCHDOG
|-
| 6
| Forced RCM two button mode (0 = Only VOLUME_UP; 1 = VOLUME_UP + HOME)
|-
| 7
| RCM USB controller mode (0 = USB 2.0; 1 = XUSB)
|-
|}

This caches the value of the sw_reserved fuse from the hardware array.

==== FUSE_PKC_DISABLE ====
This caches the value of the pkc_disable fuse from the hardware array.

== eFuses ==
The actual hardware fuses can be programmed through the fuse driver after enabling fuse programming.

Below is a list of common fuse indexes used by Tegra devices (and applicable to the Switch).
Note that the indexes are relative to the start of the fuse array and each element is a 4 byte word. A single fuse write operation always writes the same word at both fuse_array + 0 (PRIMARY_ALIAS) and fuse_array + 1 (REDUNDANT_ALIAS).

{| class="wikitable" border="1"
! Name
! Index
! Bits
|-
| jtag_disable
| 0x00
| 1
|-
| odm_production_mode
| 0x00
| 1
|-
| odm_lock
| 0x00
| 4
|-
| public_key
| 0x0C
| 256
|-
| secure_boot_key
| 0x22
| 128
|-
| device_key
| 0x2A
| 32
|-
| sec_boot_dev_cfg
| 0x2C
| 16
|-
| sec_boot_dev_sel
| 0x2C
| 3
|-
| sw_reserved
| 0x2E
| 12
|-
| ignore_dev_sel_straps
| 0x2E
| 1
|-
| [[#odm_reserved|odm_reserved]]
| 0x2E
| 256
|-
| pkc_disable
| 0x52
| 1
|-
| [[#bootrom_ipatch|bootrom_ipatch]]
| 0x72
| 624
|-
|}

=== odm_reserved ===
The first bootloader only burns fuses in this region.
Both fuse indexes 0x3A (odm_reserved + 0x0C) and 0x3C (odm_reserved + 0x0E) are used for anti-downgrade control. These fuses will have their values cached into [[#FUSE_RESERVED_ODM6|FUSE_RESERVED_ODM6]] and [[#FUSE_RESERVED_ODM7|FUSE_RESERVED_ODM7]].

=== bootrom_ipatch ===
Tegra210 based hardware such as the Switch provides support for bootrom patches. The patch data is burned to the hardware fuse array using a specific format (see [https://gist.github.com/shuffle2/f8728159da100e9df2606d43925de0af shuffle2's ipatch decoder]). The bootrom reads these fuses in order to initialize the IPATCH hardware, which allows overriding data returned for code and data fetches done by BPMP.

The revision stored in FUSE_CP_REV indicates the unique set of values stored in ipatch fuses.

The following represents the patch data dumped from a 2.0.0 Switch console:
Patch address Patch data
0x001016AE 0xDF00 // svc #0x00 (offset 0x48)
0x00103040 0xDF22 // svc #0x22 (offset 0x8c)
0x00106F2E 0xDF26 // svc #0x26 (offset 0x94)
0x0010FB3C 0x2000 // movs r0, #0x00
0x00100856 0xDF2C // svc #0x2c (offset 0xa0)
0x00106F54 0xDF42 // svc #0x42 (offset 0xcc)
0x001012E4 0xDF4B // svc #0x4b (offset 0xde)
0x00104526 0xDF54 // svc #0x54 (offset 0xf0)
0x001043F4 0xDF5D // svc #0x5d (offset 0x102)
0x00117744 0xAC57 // data
0x00117758 0x3D19 // data
0x00103D2A 0x2001 // movs r0, #0x01

The last 4 patches are exclusive to the Switch, while the remaining ones are often included in most Tegra210 based devices.

== Anti-downgrade ==
The first bootloader verifies [[#FUSE_RESERVED_ODM7|FUSE_RESERVED_ODM7]] to prevent downgrading.
How many fuses are expected to be burnt depends the device's unit type as below.

{| 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
|-
| 3.0.1-3.0.2
| 4
| 1
|-
| 4.0.0-4.1.0
| 5
| 1
|-
| 5.0.0
| 6
| 1
|}

If too many fuses are burnt the bootloader will panic immediately.

If too few are burnt, the bootloader will enable fuse programming and write the expected value to fuse indexes 0x3A and 0x3C. Afterwards, fuse programming is disabled and the panic value 0x21 is written to PMC_SCRATCH200 register (0x7000EC40). Finally, the watchdog timer is initialized and programmed to force a reset.

On a subsequent boot, after the anti-downgrade fuses are checked again, the PMC_RST_STATUS register (0x7000E5B4) is checked and if set to 0x01 (watchdog reset) the PMC_SCRATCH200 register (0x7000EC40) will be checked for the panic value 0x21.
PMC_RST_STATUS will only be set back to 0 (power on reset) if the fuse count matches the new expected value, otherwise the system will panic.

Cryptosystem

2018-01-23T13:10:19Z

Motezazer: Some updates

== BootROM ==
The bootrom initializes two keyslots in the hardware engine:

* the SBK (Secure Boot Key) in keyslot 14
* the SSK (Secure Storage Key) in keyslot 15.

Reads from both of these keyslots are disabled by the bootROM.
The SBK is stored in [[Fuses#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY]], which are locked to read out only FFs after the bootrom finishes.

SBK is '''unique''' per console, and not shared among consoles as originally believed.

The SSK is derived on boot via the SBK, the 32-bit console-unique "Device Key", and hardware information stored in fuses.

Pseudocode for the derivation is as follows:
void generateSSK() {
char keyBuffer[0x10]; // Used to store keydata
uint hwInfoBuffer[4]; // Used to store info about hardware from fuses
uint deviceKey = getDeviceKey(); // Reads 32-bit device key from FUSE_PRIVATE_KEY4.
for (int i = 0; i < 4; i++) { // Keybuffer = deviceKey || deviceKey || deviceKey || deviceKey
((uint *)keyBuffer)[i] = deviceKey;
}

encryptWithSBK(keyBuffer); // keyBuffer = AES-ECB(SBK, deviceKey || {...})

// Set up Hardware info buffer
uint vendor_code = *((uint *)0x7000FA00) & 0x0000000F; // FUSE_VENDOR_CODE
uint fab_code = *((uint *)0x7000FA04) & 0x0000003F; // FUSE_FAB_CODE
uint lot_code_0 = *((uint *)0x7000FA08) & 0xFFFFFFFF; // FUSE_LOT_CODE_0
uint lot_code_1 = *((uint *)0x7000FA0C) & 0x0FFFFFFF; // FUSE_LOT_CODE_1
uint wafer_id = *((uint *)0x7000FA10) & 0x0000003F; // FUSE_WAFER_ID
uint x_coord = *((uint *)0x7000FA14) & 0x000001FF; // FUSE_X_COORDINATE
uint y_coord = *((uint *)0x7000FA18) & 0x000001FF; // FUSE_Y_COORDINATE
uint unk_hw_fuse = *((uint *)0x7000FA20) & 0x0000003F; // Unknown cached fuse.

// HARDWARE_INFO_BUFFER = unk_hw_fuse || Y_COORD || X_COORD || WAFER_ID || LOT_CODE || FAB_CODE || VENDOR_ID
hwInfoBuffer[0] = (lot_code_1 << 30) | (wafer_id << 24) | (x_coord << 15) | (y_coord << 6) | unk_hw_fuse;
hwInfoBuffer[1] = (lot_code_0 << 26) | (lot_code_1 >> 2);
hwInfoBuffer[2] = (fab_code << 26) | (lot_code_0 >> 6);
hwInfoBuffer[3] = vendor_code;

for (int i = 0; i < 0x10; i++) { // keyBuffer = XOR(AES-ECB(SBK, deviceKey || {...}), HARDWARE_INFO_BUFFER)
keyBuffer[i] ^= ((char *)hwInfoBuffer)[i];
}

encryptWithSBK(keyBuffer); // keyBuffer = AES-ECB(SBK, XOR(AES-ECB(SBK, deviceKey || {...}), HARDWARE_INFO_BUFFER))

setKeyslot(KEYSLOT_SSK, keyBuffer); // SSK = keyBuffer.
}

== Falcon coprocessor ==
The falcon processor (TSEC) generates a special console-unique key (that will be referred to as the "tsec key").

This is presumably using data stored in fuses that only microcode authenticated by NVidia has access to.

== Package1 ==

=== Key table during package1 ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 11
| Package1Key
| [[Package1]]
| No
| Yes
|-
| 14
| SecureBootKey
| Bootrom
| No
| No
|-
| 15
| SecureStorageKey
| Bootrom
| Yes
| No
|}

=== [1.0.0-3.0.2] Key table after package1 ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1]]
| No
| Yes, on security updates
|-
| 13
| PerConsoleKey
| [[Package1]]
| Yes
| No
|}

=== [4.0.0]+ Key table after package1 (Secure Monitor boot) ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1]]
| No
| Yes, on security updates
|-
| 13
| PerConsoleKeyForNewPerConsoleKeyGen
| [[Package1]]
| Yes
| No
|-
| 14
| StaticKeyForNewPerConsoleKeyGen
| [[Package1]]
| No
| Yes, on security updates
|-
| 15
| PerConsoleKey
| [[Package1]]
| Yes
| No
|}

=== [4.0.0]+ Key table after package1 (Secure Monitor runtime) ===

{| class="wikitable" border="1"
|-
! Keyslot
! Name
! Set by
! Per-console
! Per-firmware
|-
| 12
| MasterKey
| [[Package1]]
| No
| Yes, on security updates
|-
| 13
| NewPerConsoleKey
| Secure Monitor init
| Yes
| Yes, on security updates
|-
| 15
| PerConsoleKey
| [[Package1]]
| Yes
| No
|}

=== Key generation ===
Note: aes_unwrap(wrapped_key, wrap_key) is just another name for a single AES-128 block decryption.

If bit0 of 0x7000FB94 is clear, it will initialize keys like this (probably used for internal development units only):
// Final keys:
package1_key /* slot11 */ = aes_unwrap(f5b1eadb.., sbk)
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x11 ? simpleseed_dev0 : simpleseed_dev1, aes_unwrap(5ff9c2d9.., sbk))
per_console_key /* slot13 */ = aes_unwrap(4f025f0e..., aes_unwrap(6e4a9592.., ssk))

[4.0.0+] Above method was removed.

Normal key generation looks like this on 1.0.0/2.0.0:

keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x4f ? normalseed_dev : normalseed_retail, keyblob+0x20)
per_console_key /* slot13 */ = aes_unwrap(4f025f0e.., keyblob_key)

.. and on 3.0.0, they moved keyslots around a little to generate the same per-console key as 1.0.0:

old_keyblob_key /* slot10 */ = aes_unwrap(aes_unwrap(df206f59.., tsec_key /* slot13 */), sbk /* slot14 */)
keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(bct->pubkey[0] == 0x4f ? normalseed_dev : normalseed_retail, keyblob+0x20)
per_console_key /* slot13 */ = aes_unwrap(4f025f0e.., old_keyblob_key)

.. and on 4.0.0 it was further moved around:

old_keyblob_key /* slot15 */ = aes_unwrap(aes_unwrap(df206f59.., tsec_key /* slot13 */), sbk /* slot14 */)
keyblob_key /* slot13 */ = aes_unwrap(aes_unwrap(wrapped_keyblob_key, tsec_key /* slot13 */), sbk /* slot14 */)
cmac_key /* slot11 */ = aes_unwrap(59c7fb6f.., keyblob_key)

if aes_cmac(buf=keyblob+0x10, len=0xA0, cmac_key) != keyblob[0:0x10]:
panic()

aes_ctr_decrypt(buf=keyblob+0x20, len=0x90, iv=keyblob+0x10 key=keyblob_key)

// Final keys:
package1_key /* slot11 */ = keyblob[0x80:0x90]
master_key /* slot12 */ = aes_unwrap(normalseed_retail, keyblob+0x20)
new_master_key /* slot14 */ = aes_unwrap(2dc1f48d.., keyblob+0x20)
new_per_console_key /* slot13 */ = aes_unwrap(0c9109db.., old_keyblob_key)
per_console_key /* slot15 */ = aes_unwrap(4f025f0e.., old_keyblob_key)

SBK and SSK keyslots are cleared after keys have been generated.

See table above for which keys are console unique.

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 hardcoded constants for the keyblob used in the current revision. Nintendo are withholding all the future hardcoded constants.

This means that if you have an attack on the bootloader, you need to re-preform it every time they move to a new keyblob.

Dumping the SBK and TSEC key of any single system should be enough to derive all key material on the system.

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

==== Keyblob ====
There are 32 keyblobs written to NAND at factory, with each keyblob encrypted with a console-unique key derived from the console's SBK, the console's tsec key, and a constant specific to each keyblob.

Despite being encrypted with console unique keys, though, the decrypted keyblob contents are shared for all consoles.

==== Seeds ====
normalseed_retail = d8a2410a...

[1.0.0] wrapped_keyblob_key = df206f59...
[1.0.0] simpleseed_dev0 = aff11423...
[1.0.0] simpleseed_dev1 = 5e177ee1...
[1.0.0] normalseed_dev = 0542a0fd...

[3.0.0] wrapped_keyblob_key = 0c25615d...
[3.0.0] simpleseed_dev0 = de00216a...
[3.0.0] simpleseed_dev1 = 2db7c0a1...
[3.0.0] normalseed_dev = 678c5a03...

[3.0.1] wrapped_keyblob_key = 337685ee...
[3.0.1] simpleseed_dev0 = e045f5ba...
[3.0.1] simpleseed_dev1 = 84d92e0d...
[3.0.1] normalseed_dev = cd88155b...

[4.0.0] wrapped_keyblob_key = 2d1f4880...

==== 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
|-
| 3.0.1-3.0.2
| 3
| 1
|-
| 4.0.0
| 4
| 1
|}

== Secure Monitor Init ==
On all versions, the key to decrypt [[Package2]] is generated by decrypting a constant seed with the master key. The key is erased after use.

Additionally, starting from 4.0.0, the Secure Monitor init will decrypt another constant seed successively with a special per console key and a special static key passed by package1loader, to generate a new per-console key. The operation will erase these special keys passed by package1loader.

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

Switch System Flaws

2018-01-01T01:30:14Z

Motezazer: Precision

Switch System Flaws

2017-12-30T19:08:59Z

Motezazer: It's a hardware model, not a firmware version

SVC

2017-11-21T17:45:27Z

Motezazer: /* svcReadWriteRegister */

__NOTOC__

= System calls =
{| class=wikitable
! Id || Name || In || Out
|-
| 0x1 || [[#svcSetHeapSize]] || W1=size || W0=result, X1=outaddr
|-
| 0x2 || [[#svcSetMemoryPermission]] || X0=addr, X1=size, W2=prot || W0=result
|-
| 0x3 || [[#svcSetMemoryAttribute]] || X0=addr, X1=size, W2=state0, W3=state1 || W0=result
|-
| 0x4 || [[#svcMapMemory]] || X0=dstaddr, X1=srcaddr, X2=size || W0=result
|-
| 0x5 || [[#svcUnmapMemory]] || X0=dstaddr, X1=srcaddr, X2=size || W0=result
|-
| 0x6 || [[#svcQueryMemory]] || X0=MemoryInfo*, X2=addr || W0=result, W1=PageInfo
|-
| 0x7 || [[#svcExitProcess]] || None ||
|-
| 0x8 || [[#svcCreateThread]] || X1=entry, X2=arg, X3=stacktop, W4=prio, W5=processor_id || W0=result, W1=handle
|-
| 0x9 || [[#svcStartThread]] || W0=thread_handle || W0=result
|-
| 0xA || [[#svcExitThread]] || None ||
|-
| 0xB || [[#svcSleepThread]] || X0=nano || W0=result
|-
| 0xC || [[#svcGetThreadPriority]] || W1=thread_handle || W0=result, W1=prio
|-
| 0xD || [[#svcSetThreadPriority]] || W0=thread_handle, W1=prio || W0=result
|-
| 0xE || [[#svcGetThreadCoreMask]] || W2=thread_handle || W0=result, W1=out, X2=out
|-
| 0xF || [[#svcSetThreadCoreMask]] || W0=thread_handle, W1=in, X2=in2 || W0=result
|-
| 0x10 || [[#svcGetCurrentProcessorNumber]] || None || W0/X0=cpuid
|-
| 0x11 || svcSignalEvent || W0=wevent_handle || W0=result
|-
| 0x12 || svcClearEvent || W0=wevent_or_revent_handle || W0=result
|-
| 0x13 || [[#svcMapSharedMemory]] || W0=shmem_handle, X1=addr, X2=size, W3=perm || W0=result
|-
| 0x14 || svcUnmapSharedMemory || W0=shmem_handle, X1=addr, X2=size || W0=result
|-
| 0x15 || [[#svcCreateTransferMemory]] || X1=addr, X2=size, W3=perm || W0=result, W1=tmem_handle
|-
| 0x16 || svcCloseHandle || W0=handle || W0=result
|-
| 0x17 || svcResetSignal || W0=revent_or_process_handle || W0=result
|-
| 0x18 || [[#svcWaitSynchronization]] || X1=handles_ptr, W2=num_handles. X3=timeout || W0=result, W1=handle_idx
|-
| 0x19 || svcCancelSynchronization || W0=thread_handle || W0=result
|-
| 0x1A || svcArbitrateLock || W0=cur_thread_handle, X1=ptr, W2=req_thread_handle ||
|-
| 0x1B || svcArbitrateUnlock || X0=ptr ||
|-
| 0x1C || svcWaitProcessWideKeyAtomic || X0=ptr0, X1=ptr, W2=thread_handle, X3=timeout || W0=result
|-
| 0x1D || svcSignalProcessWideKey || X0=ptr, W1=value || W0=result
|-
| 0x1E || svcGetSystemTick || None || X0={value of cntpct_el0}
|-
| 0x1F || svcConnectToNamedPort || X1=port_name_str || W0=result, W1=handle
|-
| 0x20 || svcSendSyncRequestLight || W0=light_session_handle, X1=? || W0=result
|-
| 0x21 || svcSendSyncRequest || X0=normal_session_handle || W0=result
|-
| 0x22 || [[#svcSendSyncRequestWithUserBuffer]] || X0=cmdbufptr, X1=size, X2=handle || W0=result
|-
| 0x23 || svcSendAsyncRequestWithUserBuffer || X1=cmdbufptr, X2=size, X3=handle || W0=result, W1=event_handle
|-
| 0x24 || svcGetProcessId || W1=thread_or_process_or_debug_handle || W0=result, X1=pid
|-
| 0x25 || svcGetThreadId || W0=thread_handle || W0=result, X1=out
|-
| 0x26 || svcBreak || X0,X1,X2=info || ?
|-
| 0x27 || svcOutputDebugString || X0=str, X1=size || W0=result
|-
| 0x28 || svcReturnFromException || X0=result ||
|-
| 0x29 || [[#svcGetInfo]] || X1=info_id, X2=handle, X3=info_sub_id || W0=result, X1=out
|-
| 0x2A || svcFlushEntireDataCache || None || None
|-
| 0x2B || svcFlushDataCache || X0=addr, X1=size || W0=result
|-
| 0x2C || [3.0.0+] svcMapPhysicalMemory || ||
|-
| 0x2D || [3.0.0+] svcUnmapPhysicalMemory|| ||
|- style="border-top: double"
| 0x2F || svcGetLastThreadInfo || None || W0=result, W1,W2,W3,W4=unk, W5=truncated_u64, W6=bool
|-
| 0x30 || svcGetResourceLimitLimitValue || W1=reslimit_handle, W2=[[#LimitableResource]] || W0=result, X1=value
|-
| 0x31 || svcGetResourceLimitCurrentValue || W1=reslimit_handle, W2=[[#LimitableResource]] || W0=result, X1=value
|-
| 0x32 || svcSetThreadActivity || W0=thread_handle, W1=bool || W0=result
|-
| 0x33 || svcGetThreadContext3 || W0=thread_handle, W1=[[#ThreadContext]]* || W0=result
|- style="border-top: double"
| 0x3C || svcDumpInfo || ||
|- style="border-top: double"
| 0x40 || svcCreateSession || W2=is_light, X3=? || W0=result, W1=client_handle, W2=server_handle
|-
| 0x41 || svcAcceptSession || W1=port_handle || W0=result, W1=session_handle
|-
| 0x42 || svcReplyAndReceiveLight || W0=light_session_handle || W0=result, W1,W2,W3,W4,W5,W6,W7=out
|-
| 0x43 || svcReplyAndReceive || X1=ptr_handles, W2=num_handles, X3=replytarget_handle(0=none), X4=timeout || W0=result, W1=handle_idx
|-
| 0x44 || svcReplyAndReceiveWithUserBuffer|| X1=buf, X2=sz, X3=ptr_handles, W4=num_handles, X5=replytarget_handle(0=none), X6=timeout || W0=result, W1=handle_idx
|-
| 0x45 || svcCreateEvent || None || W0=result, W1=client_handle ?, W2=server_handle ?
|- style="border-top: double"
| 0x4D || svcSleepSystem || None || None
|-
| 0x4E || [[#svcReadWriteRegister]] || X1=reg_addr, W2=rw_mask, W3=in_val || W0=result, W1=out_val
|-
| 0x4F || svcSetProcessActivity || W0=process_handle, W1=bool || W0=result
|-
| 0x50 || [[#svcCreateSharedMemory]] || W1=size, W2=myperm, W3=otherperm || W0=result, W1=shmem_handle
|-
| 0x51 || [[#svcMapTransferMemory]] || X0=tmem_handle, X1=addr, X2=size, W3=perm || W0=result
|-
| 0x52 || [[#svcUnmapTransferMemory]] || W0=tmemhandle, X1=addr, X2=size || W0=result
|-
| 0x53 || svcCreateInterruptEvent || X1=irq_id, W2=flag || W0=result, W1=handle
|-
| 0x54 || [[#svcQueryPhysicalAddress]] || X1=addr || W0=result, X1=out0, X2=out1, X3=out2
|-
| 0x55 || [[#svcQueryIoMapping]] || X1=physaddr, X2=size || W0=result, X1=virtaddr
|-
| 0x56 || [[#svcCreateDeviceAddressSpace]] || X1=dev_as_start_addr, X2=dev_as_end_addr || W0=result, W1=dev_as_handle
|-
| 0x57 || [[#svcAttachDeviceAddressSpace]] || W0=device, X1=dev_as_handle || W0=result
|-
| 0x58 || [[#svcDetachDeviceAddressSpace]] || W0=device, X1=dev_as_handle || W0=result
|-
| 0x59 || [[#svcMapDeviceAddressSpaceByForce]] || W0=dev_as_handle, W1=proc_handle, X2=dev_map_addr, X3=dev_as_size, X4=dev_as_addr, W5=perm || W0=result
|-
| 0x5A || [[#svcMapDeviceAddressSpaceAligned]] || W0=dev_as_handle, W1=proc_handle, X2=dev_map_addr, X3=dev_as_size, X4=dev_as_addr, W5=perm || W0=result
|-
| 0x5B || svcMapDeviceAddressSpace || ||
|-
| 0x5C || [[#svcUnmapDeviceAddressSpace]] || W0=dev_as_handle, W1=proc_handle, X2=dev_map_addr, X3=dev_as_size, X4=dev_as_addr || W0=result
|-
| 0x5D || svcInvalidateProcessDataCache || W0=process_handle, X1=addr, X2=size || W0=size
|-
| 0x5E || svcStoreProcessDataCache || W0=process_handle, X1=addr, X2=size || W0=size
|-
| 0x5F || svcFlushProcessDataCache || W0=process_handle, X1=addr, X2=size || W0=size
|-
| 0x60 || svcDebugActiveProcess || X1=pid || W0=result, W1=debug_handle
|-
| 0x61 || svcBreakDebugProcess || W0=debug_handle || W0=result
|-
| 0x62 || svcTerminateDebugProcess || W0=debug_handle || W0=result
|-
| 0x63 || svcGetDebugEvent || X0=DebugEventInfo*, W1=debug_handle || W0=result
|-
| 0x64 || svcContinueDebugEvent || W0=debug_handle, W1=[[#ContinueDebugFlags]], X2=thread_id || W0=result
|-
| 0x65 || svcGetProcessList || X1=pids_out_ptr, W2=max_out || W0=result, W1=num_out
|-
| 0x66 || svcGetThreadList || X1=tids_out_ptr, W2=max_out, W3=debug_handle_or_zero || W0=result, X1=num_out
|-
| 0x67 || svcGetDebugThreadContext || X0=ThreadContext*, X1=debug_handle, X2=thread_id, W3=[[#ThreadContextFlags]] || W0=result
|-
| 0x68 || svcSetDebugThreadContext || W0=debug_handle, W1=[[#ThreadContextFlags]], X2=ThreadContext* || W0=result
|-
| 0x69 || svcQueryDebugProcessMemory || X0=[[#MemoryInfo]]*, X2=debug_handle, X3=addr || W0=result, W1=PageInfo
|-
| 0x6A || svcReadDebugProcessMemory || X0=buffer*, X1=debug_handle, X2=src_addr, X3=size || W0=result
|-
| 0x6B || svcWriteDebugProcessMemory || X0=debug_handle, X1=buffer*, X2=dst_addr, X3=size || W0=result
|-
| 0x6C || svcSetHardwareBreakPoint || W0=HardwareBreakpointId, X1=watchpoint_flags, X2=watchpoint_value/debug_handle? ||
|-
| 0x6D || svcGetDebugThreadParam || X2=debug_handle, X3=thread_id, W4=[[#DebugThreadParam]] || W0=result, X1=out0, W2=out1
|- style="border-top: double"
| 0x70 || svcCreatePort || ||
|-
| 0x71 || svcManageNamedPort || X1=name_ptr, W2=max_sessions(?) || W0=result, W1=serverport_handle
|-
| 0x72 || svcConnectToPort || W1=clientport_handle || W0=result, W1=session_handle
|-
| 0x73 || svcSetProcessMemoryPermission || X0=addr, X1=size, W2=perm || W0=result
|-
| 0x74 || [[#svcMapProcessMemory]] || X0=srcaddr, W1=process_handle, X2=dstaddr, X3=size || W0=result
|-
| 0x75 || [[#svcUnmapProcessMemory]] || W0=process_handle, X1=dstaddr, X2=srcaddr, X3=size || W0=result
|-
| 0x76 || [[#svcQueryProcessMemory]] || X0=meminfo_ptr, W2=process_handle, X3=addr || W0=result, W1=pageinfo
|-
| 0x77 || [[#svcMapProcessCodeMemory]] || W0=process_handle, X2=dstaddr, X2=srcaddr, X3=size || W0=result
|-
| 0x78 || [[#svcUnmapProcessCodeMemory]] || W0=process_handle, X1=dstaddr, X2=srcaddr, X3=size || W0=result
|-
| 0x79 || [[#svcCreateProcess]] || X1=procinfo_ptr, X2=caps_ptr, W3=cap_num || W0=result, W1=process_handle
|-
| 0x7A || svcStartProcess || W0=process_handle, W1=main_thread_prio, W2=default_cpuid, W3=main_thread_stacksz || W0=result
|-
| 0x7B || svcTerminateProcess || W0=process_handle || W0=result
|-
| 0x7C || [[#svcGetProcessInfo]] || W0=process_handle || W0=result, X1=[[#ProcessState]]
|-
| 0x7D || svcCreateResourceLimit || None || W0=result, W1=reslimit_handle
|-
| 0x7E || svcSetResourceLimitLimitValue || W0=reslimit_handle, W1=[[#LimitableResource]], X2=value || W0=result
|-
| 0x7F || svcCallSecureMonitor || ||
|}

== svcSetHeapSize ==
<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W1 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) X1 || u64 || <code>OutAddr</code>
|}
</div>

'''Description:''' Set the process heap to a given <code>Size</code>. It can both extend and shrink the heap.

<code>Size</code> must be a multiple of 0x2000000.

On success, the heap base-address (which is fixed by kernel, aslr'd) is written to <code>OutAddr</code>.

[2.0.0+] <code>Size</code> must be less than 0x18000000.

== svcSetMemoryPermission ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || void* || <code>Addr</code>
|-
| (In) X1 || u64 || <code>Size</code>
|-
| (In) W2 || [[#Permission]] || <code>Prot</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Change permission of page-aligned memory region.

Bit2 of permission (exec) is not allowed. Setting write-only is not allowed either (bit1).

This can be used to move back and forth between ---, r-- and rw-.

== svcSetMemoryAttribute ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || void* || <code>Addr</code>
|-
| (In) X1 || u64 || <code>Size</code>
|-
| (In) W2 || u32 || <code>State0</code>
|-
| (In) W3 || u32 || <code>State1</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Change attribute of page-aligned memory region.

This is used to turn on/off caching for a given memory area. Useful when talking to devices such as the GPU.

What happens "under the hood" is the "Memory Attribute Indirection Register" index is changed from 2 to 3 in the MMU descriptor.

{| class=wikitable
! State0 || State1 || Action
|-
| 0 || 0 || Clear bit3 in [[#MemoryAttribute]].
|-
| 8 || 0 || Clear bit3 in [[#MemoryAttribute]].
|-
| 8 || 8 || Set bit3 in [[#MemoryAttribute]].
|}

== svcMapMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || void* || <code>DstAddr</code>
|-
| (In) X1 || void* || <code>SrcAddr</code>
|-
| (In) X2 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Maps a memory range into a different range.

Mainly used for adding guard pages around stack.

Source range gets reprotected to --- (it can no longer be accessed), and bit0 is set in the source [[#MemoryAttribute]].

If dstaddr >= LowerTreshold, the dst-range is enforced to be within the process' "MapRegion". Code can get the range of this region from [[#svcGetInfo]] id0=2,3.

In this case, the mapped memory will have state <code>0x5C3C0B</code>.

As long as (dstaddr+size) < LowerThreshold, then you can map anywhere but the mapped memory will have state <code>0x482907</code> instead.

LowerTreshold is 0x80000000 for 36-bit address spaces, and 0x40000000 for 32-bit ones.

[2.0.0+] Support for the <code>0x482907</code> mappings outside the "MapRegion" were removed.

== svcUnmapMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || void* || <code>DstAddr</code>
|-
| (In) X1 || void* || <code>SrcAddr</code>
|-
| (In) X2 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Unmaps a region that was previously mapped with [[#svcMapMemory]].

It's possible to unmap ranges partially, you don't need to unmap the entire range "in one go".

The srcaddr/dstaddr must match what was given when the pages were originally mapped.

== svcQueryMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || [[#MemoryInfo]]* || <code>MemInfo</code>
|-
| (In) X2 || void* || <code>Addr</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || PageInfo || <code>PageInfo</code>
|}
</div>

'''Description:''' Query information about an address. Will always fetch the lowest page-aligned mapping that contains the provided address.

Outputs a [[#MemoryInfo]] struct.

== svcExitProcess ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) None || ||
|-
| (Out) None || ||
|}
</div>

'''Description:''' Exits the current process.

== svcCreateThread ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || void(*)(void*) || <code>Entry</code>
|-
| (In) X2 || void* || <code>Arg</code>
|-
| (In) X3 || void* || <code>StackTop</code>
|-
| (In) W4 || u32 || <code>Priority</code>
|-
| (In) W5 || u32 || <code>ProcessorId</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || Handle<Thread> || <code>Handle</code>
|}
</div>

'''Description:''' Create a thread in the current process.

Processor_id must be 0,1,2,3 or -2, where -2 uses the default cpuid for process.

== svcStartThread ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<Thread> || <code>Handle</code>
|-
| (Out) None || ||
|}
</div>

'''Description:''' Starts the thread for the provided handle.

== svcExitThread ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) None || ||
|-
| (Out) None || ||
|}
</div>

'''Description:''' Exits the current thread.

== svcSleepThread ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || u64 || <code>Nano</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Sleep for a specified amount of time, or yield thread.

Setting nano=0 means "yield thread".

== svcGetThreadPriority ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W1|| Handle<Thread> || <code>Handle</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || u64 || <code>Priority</code>
|}
</div>

'''Description:''' Get priority of provided thread handle.

== svcSetThreadPriority ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0|| Handle<Thread> || <code>Handle</code>
|-
| (In) W1|| u32 || <code>Priority</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Set priority of provided thread handle.

Priority is a number 0-0x3F. Lower value means higher priority.

== svcGetThreadCoreMask ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W2 || Handle<Thread> || <code>Handle</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || u32 || <code>Out0</code>
|-
| (Out) X2 || u64 || <code>Out1</code>
|}
</div>

'''Description:''' Get affinity mask of provided thread handle.

== svcSetThreadCoreMask ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<Thread> || <code>Handle</code>
|-
| (In) W1 || u32 || <code>In0</code>
|-
| (In) X2 || u64 || <code>In1</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Set affinity mask of provided thread handle.

== svcGetCurrentProcessorNumber ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) None || ||
|-
| (Out) W0/X0 || u64 || <code>CpuId</code>
|}
</div>

'''Description:''' Get which cpu is executing the current thread.

Cpu-id is an integer in the range 0-3.

== svcMapSharedMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<SharedMemory> || <code>MemHandle</code>
|-
| (In) X1 || void* || <code>Addr</code>
|-
| (In) X2 || u64 || <code>Size</code>
|-
| (In) W3 || [[#Permission]] || <code>Permissions</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

Maps the block supplied by the handle. The required permissions are different for the process that created the handle and all other processes.

Increases reference count for the KSharedMemory object. Thus in order to release the memory associated with the object, all handles to it must be closed and all mappings must be unmapped.

== svcCreateTransferMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || void* || <code>Addr</code>
|-
| (In) X2 || u64 || <code>Size</code>
|-
| (In) W3 || [[#Permission]] || <code>Permissions</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || Handle<TransferMemory> || <code>Handle</code>
|}
</div>

This one reprotects the src block with perms you give it. It also sets bit0 into [[#MemoryAttribute]].

Executable bit perm not allowed.

Closing all handles automatically causes the bit0 in [[#MemoryAttribute]] to clear, and the permission to reset.

== svcWaitSynchronization ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || Handle* || <code>HandlesPtr</code>
|-
| (In) W2 || u64 || <code>HandlesNum</code>
|-
| (In) X3 || u64 || <code>Timeout</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || u64 || <code>HandleIndex</code>
|}
</div>

Works with num_handles <= 0x40, error on num_handles == 0.

Does not accept 0xFFFF8001 or 0xFFFF8000 as handles.

== svcSendSyncRequestWithUserBuffer ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || void* || <code>CmdPtr</code>
|-
| (In) X1 || u64 || <code>Size</code>
|-
| (In) W2 || Handle<Session> || <code>Handle</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

Size must be 0x1000-aligned.

== svcBreak ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || u64 ||
|-
| (In) X1 || u64 ||
|-
| (In) X2 || u64 || <code>Info</code>
|-
| (Out) ? || ? || <code>?</code>
|}
</div>

When used on retail where inx0 bit31 is clear, the system will throw a [[Error_codes|fatal-error]]. Otherwise when bit31 is set, it will return 0.

== svcGetInfo ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || u64 || <code>InfoId</code>
|-
| (In) W2 || Handle || <code>Handle</code>
|-
| (In) X3 || u64 || <code>InfoSubId</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) X1 || u64 || <code>Out</code>
|}
</div>

{| class=wikitable
! Handle type || Id0 || Id1 || Description
|-
| Process || 0 || 0 || AllowedCpuIdBitmask
|-
| Process || 1 || 0 || AllowedThreadPrioBitmask
|-
| Process || 2 || 0 || ReservedMapRegionBaseAddress
|-
| Process || 3 || 0 || ReservedMapRegionSize
|-
| Process || 4 || 0 || ReservedHeapRegionBaseAddress
|-
| Process || 5 || 0 || ReservedHeapRegionSize
|-
| Process || 6 || 0 || TotalMemoryUsage
|-
| Process || 7 || 0 || TotalHeapUsage
|-
| Zero || 8 || 0 || IsCurrentProcessBeingDebugged
|-
| Zero || 9 || 0 || Returns ResourceLimit handle for current process. Used by [[Process_Manager_services|PM]].
|-
| Zero || 10 || -1, {current coreid} || Unknown. Output data changes each time this SVC is used. Global and core-specific tick-count?
|-
| Zero || 11 || 0-3 || RandomEntropy from current process. TRNG. Used to seed usermode PRNGs.
|-
| Process || 12 || 0 || [2.0.0+] AddressSpaceStart
|-
| Process || 13 || 0 || [2.0.0+] AddressSpaceSize
|-
| Process || 14 || 0 || [2.0.0+] NewReservedRegionStartAddr
|-
| Process || 15 || 0 || [2.0.0+] NewReservedRegionSize
|-
| Process || 18 || 0 || [3.0.0+] Title-id.
|-
| Thread || 0xF0000002 || 0 || Performance counter related.
|}

== svcDumpInfo ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) None || ||
|-
| (Out) None || ||
|}
</div>

Does nothing, just returns with registers set to all-zero.

== svcReadWriteRegister ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || u64 || <code>RegAddr</code>
|-
| (In) W2 || u64 || <code>RwMask</code>
|-
| (In) W3 || u64 || <code>InValue</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1|| u64 || <code>OutValue</code>
|}
</div>

Read/write IO registers with a hardcoded whitelist. Input address is physical-address and must be aligned to 4.

rw_mask is 0 for reading and 0xffffffff for writing. You can also write individual bits by using a mask value.

You can only write to registers inside physical pages 0x70019000 (MC), 0x7001C000 (MC0), 0x7001D000 (MC1), and they all share the same whitelist.

The whitelist is same for writing as for reading.

The whitelist is:
<code>
0x054, 0x090, 0x094, 0x098, 0x09c, 0x0a0, 0x0a4, 0x0a8, 0x0ac, 0x0b0, 0x0b4, 0x0b8, 0x0bc, 0x0c0, 0x0c4, 0x0c8, 0x0d0, 0x0d4, 0x0d8, 0x0dc, 0x0e0, 0x100, 0x108, 0x10c, 0x118, 0x11c, 0x124, 0x128, 0x12c, 0x130, 0x134, 0x138, 0x13c, 0x158, 0x15c, 0x164, 0x168, 0x16c, 0x170, 0x174, 0x178, 0x17c, 0x200, 0x204, 0x2e4, 0x2e8, 0x2ec, 0x2f4, 0x2f8, 0x310, 0x314, 0x320, 0x328, 0x344, 0x348, 0x370, 0x374, 0x37c, 0x380, 0x390, 0x394, 0x398, 0x3ac, 0x3b8, 0x3bc, 0x3c0, 0x3c4, 0x3d8, 0x3e8, 0x41c, 0x420, 0x424, 0x428, 0x42c, 0x430, 0x44c, 0x47c, 0x480, 0x484, 0x50c, 0x554, 0x558, 0x55c, 0x670, 0x674, 0x690, 0x694, 0x698, 0x69c, 0x6a0, 0x6a4, 0x6c0, 0x6c4, 0x6f0, 0x6f4, 0x960, 0x970, 0x974, 0xa20, 0xa24, 0xb88, 0xb8c, 0xbc4, 0xbc8, 0xbcc, 0xbd0, 0xbd4, 0xbd8, 0xbdc, 0xbe0, 0xbe4, 0xbe8, 0xbec, 0xc00, 0xc5c, 0xcac
</code>

[2.0.0+] Whitelist was extended with <code>0x4c4, 0x4c8, 0x4cc, 0x584, 0x588, 0x58c.</code>

[2.0.0+] The IO registers in range 0x7000E400 (PMC) size 0xC00 skip the whitelist, and do a TrustZone call using [[SMC]] Id1 0xC3000008(ReadWriteRegister).

Here is the whitelist imposed by that SMC, relative to the start of the PMC registers:
<code>
0x000, 0x00c, 0x010, 0x014, 0x01c, 0x020, 0x02c, 0x030, 0x034, 0x038, 0x03c, 0x040, 0x044, 0x048, 0x0dc, 0x0e0, 0x0e4, 0x160, 0x164, 0x168, 0x170, 0x1a8, 0x1b8, 0x1bc, 0x1c0, 0x1c4, 0x1c8, 0x2b4, 0x2d4, 0x440, 0x4d8
</code>

== svcCreateSharedMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W1 || u64 || <code>Size</code>
|-
| (In) W2 || [[#Permission]] || <code>LocalPerm</code>
|-
| (In) W3 || [[#Permission]] || <code>RemotePerm</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || Handle<SharedMemory> || <code>MemHandle</code>
|}
</div>

Other perm can be used to enforce permission 1, 3, or 0x10000000 if don't care.

== svcMapTransferMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || Handle<TransferMemory> || <code>MemHandle</code>
|-
| (In) X1 || void* || <code>Addr</code>
|-
| (In) X2 || u64 || <code>Size</code>
|-
| (In) W3 || [[#Permission]] || <code>Permissions</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

The newly mapped pages will have [[#MemoryState]] type 0xE.

You must pass same size and permissions as given in svcCreateMemoryMirror, otherwise error.

== svcUnmapTransferMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || Handle<TransferMemory> || <code>MemHandle</code>
|-
| (In) X1 || void* || <code>Addr</code>
|-
| (In) X2 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

Size must match size given in map syscall, otherwise there's an invalid-size error.

== svcQueryPhysicalAddress ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || u64 || <code>Addr</code>
|-
| (Out) W0 || [[#Result]]|| <code>Ret</code>
|-
| (Out) X1 || u64 || <code>Out0</code>
|-
| (Out) X2 || u64 || <code>Out1</code>
|-
| (Out) X3 || u64 || <code>Out2</code>
|}
</div>

The inverse operation of [[#svcQueryIoMapping]].

== svcQueryIoMapping ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || u64 || <code>PhysAddr</code>
|-
| (In) X2 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) X1 || void* || <code>VirtAddr</code>
|}
</div>

'''Description:''' Returns a virtual address mapped to a given IO range.

== svcCreateDeviceAddressSpace ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || u64 || <code>StartAddr</code>
|-
| (In) X2 || u64 || <code>EndAddr</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || Handle<DeviceAddressSpace> || <code>AddressSpaceHandle</code>
|}
</div>

'''Description:''' Creates a virtual address space for binding device address spaces and returns a handle.

dev_as_start_addr is normally set to 0 and dev_as_end_addr is normally set to 0xFFFFFFFF.

== svcAttachDeviceAddressSpace ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || [[#DeviceName]] || <code>DeviceId</code>
|-
| (In) X1 || Handle<DeviceAddressSpace> || <code>DeviceAsHandle</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Attaches a device address space to a [[#DeviceName|device]].

== svcDetachDeviceAddressSpace ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || [[#DeviceName]] || <code>DeviceId</code>
|-
| (In) X1 || Handle<DeviceAddressSpace> || <code>DeviceAsHandle</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Detaches a device address space from a [[#DeviceName|device]].

== svcMapDeviceAddressSpaceByForce ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<DeviceAddressSpace> || <code>DeviceAsHandle</code>
|-
| (In) W1 || Handle<Process> || <code>ProcessHandle</code>
|-
| (In) X2 || void* || <code>SrcAddr</code>
|-
| (In) X3 || u64 || <code>DeviceAsSize</code>
|-
| (In) X4 || u64 || <code>DeviceAsAddr</code>
|-
| (In) W5 || [[#Permission]] || <code>Permissions</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Maps an attached device address space to an userspace address.

dev_map_addr is the userspace destination address, while dev_as_addr is the source address between dev_as_start_addr and dev_as_end_addr (passed to [[#svcCreateDeviceAddressSpace]]).

The userspace destination address must have the [[SVC#MemoryState|MapDeviceAllowed]] bit set. Bit [[SVC#MemoryAttribute|IsDeviceMapped]] will be set after mapping.

== svcMapDeviceAddressSpaceAligned ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<DeviceAddressSpace> || <code>DeviceAsHandle</code>
|-
| (In) W1 || Handle<Process> || <code>ProcessHandle</code>
|-
| (In) X2 || void* || <code>SrcAddr</code>
|-
| (In) X3 || u64 || <code>DeviceAsSize</code>
|-
| (In) X4 || u64 || <code>DeviceAsAddr</code>
|-
| (In) W5 || [[#Permission]] || <code>Permissions</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Maps an attached device address space to an userspace address.

Same as [[#svcMapDeviceAddressSpaceByForce]], but the userspace destination address must have the [[SVC#MemoryState|MapDeviceAlignedAllowed]] bit set instead.

== svcUnmapDeviceAddressSpace ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<DeviceAddressSpace> || <code>DeviceAsHandle</code>
|-
| (In) W1 || Handle<Process> || <code>ProcessHandle</code>
|-
| (In) X2 || void* || <code>SrcAddr</code>
|-
| (In) X3 || u64 || <code>DeviceAsSize</code>
|-
| (In) X4 || u64 || <code>DeviceAsAddr</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

'''Description:''' Unmaps an attached device address space from an userspace address.

== svcMapProcessMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || u64 || <code>SrcAddr</code>
|-
| (In) W1 || u64 || <code>ProcessHandle</code>
|-
| (In) X2 || void* || <code>DstAddr</code>
|-
| (In) X3 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

Maps the src address from the supplied process handle into the current process.

This allows mapping code and rodata with RW- permission.

== svcUnmapProcessMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<Process> || <code>ProcessHandle</code>
|-
| (In) X1 || void* || <code>DstAddr</code>
|-
| (In) X2 || u64 || <code>SrcAddr</code>
|-
| (In) X3 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

Unmaps what was mapped by [[#svcMapProcessMemory]].

== svcQueryProcessMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X0 || [[#MemoryInfo]]* || <code>MemInfoPtr</code>
|-
| (In) W2 || Handle<Process> || <code>ProcessHandle</code>
|-
| (In) X3 || u64 || <code>Addr</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || PageInfo || <code>PageInfo</code>
|}
</div>

Equivalent to [[#svcQueryMemory]] except takes a process handle.

== svcMapProcessCodeMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<Process> || <code>ProcessHandle</code>
|-
| (In) X1 || u64 || <code>DstAddr</code>
|-
| (In) X2 || u64 || <code>SrcAddr</code>
|-
| (In) X3 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

Takes a process handle, and maps normal heap in that process as executable code in that process. Used when loading NROs.

== svcUnmapProcessCodeMemory ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<Process> || <code>ProcessHandle</code>
|-
| (In) X1 || u64 || <code>DstAddr</code>
|-
| (In) X2 || u64 || <code>Src Addr</code>
|-
| (In) X3 || u64 || <code>Size</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|}
</div>

Unmaps what was mapped by [[#svcMapProcessCodeMemory]].

== svcCreateProcess ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) X1 || [[#CreateProcessInfo]]* || <code>InfoPtr</code>
|-
| (In) X2 || u64 || <code>CapabilitiesPtr</code>
|-
| (In) X3 || u64 || <code>CapibilitiesNum</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || Handle<Process> || <code>ProcessHandle</code>
|}
</div>

Takes a [[#CreateProcessInfo]] as input.

== svcGetProcessInfo ==

<div style="display: inline-block;">
{| class="wikitable" border="1"
|-
! Argument || Type || Name
|-
| (In) W0 || Handle<Process> || <code>ProcessHandle</code>
|-
| (Out) W0 || [[#Result]] || <code>Ret</code>
|-
| (Out) W1 || [[#ProcessState]] || <code>State</code>
|}
</div>

Returns an enum with value 0-7.

== Debugging ==
[2.0.0+] Exactly 6 debug SVCs require that [[SPL_services#GetConfig|IsDebugMode]] is non-zero. Error 0x4201 is returned otherwise.
* svcBreakDebugProcess
* svcContinueDebugEvent
* svcWriteDebugProcessMemory
* svcSetDebugThreadContext
* svcTerminateDebugProcess
* svcSetHardwareBreakPoint

svcDebugActiveProcess stops execution of the target process, the normal method for resuming it requires svcContinueDebugEvent(see above). Closing the debug handle also results in execution being resumed.

= Enum/Structures =
== ThreadContextRequestFlags ==
Bitfield of one of more of these:

{| class=wikitable
! Bit || Bitmask || Name
|-
| 0 || 1 || NormalContext
|-
| 1 || 2 ||
|-
| 2 || 4 ||
|-
| 3 || 8 ||
|}

== DeviceName ==
{| class=wikitable
! Value || Name
|-
| 0 || DeviceName_AFI
|-
| 1 || DeviceName_AVPC
|-
| 2 || DeviceName_DC
|-
| 3 || DeviceName_DCB
|-
| 4 || DeviceName_HC
|-
| 5 || DeviceName_HDA
|-
| 6 || DeviceName_ISP2
|-
| 7 || DeviceName_MSENCNVENC
|-
| 8 || DeviceName_NV
|-
| 9 || DeviceName_NV2
|-
| 10 || DeviceName_PPCS
|-
| 11 || DeviceName_SATA
|-
| 12 || DeviceName_VI
|-
| 13 || DeviceName_VIC
|-
| 14 || DeviceName_XUSB_HOST
|-
| 15 || DeviceName_XUSB_DEV
|-
| 16 || DeviceName_TSEC
|-
| 17 || DeviceName_PPCS1
|-
| 18 || DeviceName_DC1
|-
| 19 || DeviceName_SDMMC1A
|-
| 20 || DeviceName_SDMMC2A
|-
| 21 || DeviceName_SDMMC3A
|-
| 22 || DeviceName_SDMMC4A
|-
| 23 || DeviceName_ISP2B
|-
| 24 || DeviceName_GPU
|-
| 25 || DeviceName_GPUB
|-
| 26 || DeviceName_PPCS2
|-
| 27 || DeviceName_NVDEC
|-
| 28 || DeviceName_APE
|-
| 29 || DeviceName_SE
|-
| 30 || DeviceName_NVJPG
|-
| 31 || DeviceName_HC1
|-
| 32 || DeviceName_SE1
|-
| 33 || DeviceName_AXIAP
|-
| 34 || DeviceName_ETR
|-
| 35 || DeviceName_TSECB
|-
| 36 || DeviceName_TSEC1
|-
| 37 || DeviceName_TSECB1
|-
| 38 || DeviceName_NVDEC1
|}

== LimitableResource ==
{| class=wikitable
! Value || Name
|-
| 0 || LimitableResource_Memory
|-
| 1 || LimitableResource_Threads
|-
| 2 || LimitableResource_Events
|-
| 3 || LimitableResource_TransferMemories
|-
| 4 || LimitableResource_Sessions
|}

== ProcessEvent ==
{| class=wikitable
! Value || Name
|-
| 0 || ProcessEvent_Created
|-
| 1 || ProcessEvent_DebugAttached
|-
| 2 || ProcessEvent_DebugDetached
|-
| 3 || ProcessEvent_Crashed
|-
| 4 || ProcessEvent_Running
|-
| 5 || ProcessEvent_Exiting
|-
| 6 || ProcessEvent_Exited
|-
| 7 || ProcessEvent_DebugSuspended
|}

== DebugThreadParam ==
{| class=wikitable
! Value || Name
|-
| 0 || DebugThreadParam_ActualPriority
|-
| 1 ||
|-
| 2 || DebugThreadParam_CpuCore
|-
| 3 ||
|-
| 4 || DebugThreadParam_CoreMask
|}

== CreateProcessInfo ==
{| class=wikitable
! Offset || Length || Bits || Description
|-
| 0 || 12 || || ProcessName (doesn't have to be null-terminated)
|-
| 0xC || 4 || ||
|-
| 0x10 || 8 || || TitleId
|-
| 0x18 || 8 || || CodeAddr
|-
| 0x20 || 4 || || CodeNumPages
|-
| 0x24 || 4 || || MmuFlags
|-
| || || Bit0 || Is64bit
|-
| || || Bit3-1 || [[#AddressSpaceType]]
|-
| || || Bit4 ||
|-
| || || Bit5 || EnableAslr
|-
| || || Bit6 || IsSystem
|-
| 0x28 || 4 || || ResourceLimitHandle
|-
| 0x2C || 4 ||
|}

=== AddressSpaceType ===
{| class=wikitable
! Type || Name || Width || Description
|-
| 0 || Normal_32Bit || 32 ||
|-
| 1 || Normal_36Bit || 36 ||
|-
| 2 || WithoutMap_32Bit || 32 || Appears to be missing map region [?]
|-
| 3 || [2.0.0+] Normal_39Bit || 39 ||
|}

== MemoryInfo ==
{| class=wikitable
! Offset || Length || Description
|-
| 0 || 8 || BaseAddress
|-
| 8 || 8 || Size
|-
| 0x10 || 4 || MemoryType: lower 8 bits of [[#MemoryState]]
|-
| 0x14 || 4 || [[#MemoryAttribute]]
|-
| 0x18 || 4 || Permission (bit0: R, bit1: W, bit2: X)
|-
| 0x1C || 4 || IpcRefCount
|-
| 0x20 || 4 || DeviceRefCount
|-
| 0x24 || 4 || Padding: always zero
|}

== MemoryAttribute ==
{| class=wikitable
! Bits || Description
|-
| 0 || IsBorrowed
|-
| 1 || IsIpcMapped: when IpcRefCount > 0.
|-
| 2 || IsDeviceMapped: when DeviceRefCount > 0.
|-
| 3 || IsUncached
|}

== MemoryState ==
{| class=wikitable
! Bits || Description
|-
| 7-0 || Type
|-
| 8 || [[#svcSetMemoryPermission|PermissionChangeAllowed]]
|-
| 9 || ForceReadWritableByDebugSyscalls
|-
| 10 || IpcSendAllowed_Type0
|-
| 11 || IpcSendAllowed_Type3
|-
| 12 || IpcSendAllowed_Type1
|-
| 14 || [[#svcSetProcessMemoryPermission|ProcessPermissionChangeAllowed]]
|-
| 15 || [[#svcMapMemory|MapAllowed]]
|-
| 16 || [[#svcUnmapProcessCodeMemory|UnmapProcessCodeMemoryAllowed]]
|-
| 17 || [[#svcCreateTransferMemory|TransferMemoryAllowed]]
|-
| 19 || MapDeviceAllowed ([[#svcMapDeviceAddressSpace]] and [[#svcMapDeviceAddressSpaceByForce]])
|-
| 20 || [[#svcMapDeviceAddressSpaceAligned|MapDeviceAlignedAllowed]]
|-
| 21 || [[#svcSendSyncRequestWithUserBuffer|IpcBufferAllowed]]
|-
| 22 || IsPoolAllocated/IsReferenceCounted
|-
| 23 || [[#svcMapProcessMemory|MapProcessAllowed]]
|-
| 24 || [[#svcSetMemoryAttribute|AttributeChangeAllowed]]
|}

{| class=wikitable
! Value || Type || Meaning
|-
| <code>0x00000000</code> || MemoryType_Unmapped ||
|-
| <code>0x00002001</code> || MemoryType_Io || Mapped by kernel capability parsing in [[#svcCreateProcess]].
|-
| <code>0x00042002</code> || MemoryType_Normal || Mapped by kernel capability parsing in [[#svcCreateProcess]].
|-
| <code>0x00DC7E03</code> || MemoryType_CodeStatic || Mapped during [[#svcCreateProcess]].
|-
| <code>0x01FEBD04</code> || MemoryType_CodeMutable || Transition from 0xDC7E03 performed by [[#svcSetProcessMemoryPermission]].
|-
| <code>0x017EBD05</code> || MemoryType_Heap || Mapped using [[#svcSetHeapSize]].
|-
| <code>0x00402006</code> || MemoryType_SharedMemory || Mapped using [[#svcMapSharedMemory]].
|-
| <code>0x00482907</code> || [1.0.0] MemoryType_WeirdSharedMemory || Mapped using [[#svcMapMemory]].
|-
| <code>0x00DD7E08</code> || MemoryType_ModuleCodeStatic || Mapped using [[#svcMapProcessCodeMemory]].
|-
| <code>0x01FFBD09</code> || MemoryType_ModuleCodeMutable || Transition from 0xDD7E08 performed by [[#svcSetProcessMemoryPermission]].
|-
| <code>0x005C3C0A</code> || [[IPC_Marshalling|MemoryType_IpcBuffer0]] || IPC buffers with descriptor flags=0.
|-
| <code>0x005C3C0B</code> || MemoryType_MappedMemory || Mapped using [[#svcMapMemory]].
|-
| <code>0x0040200C</code> || [[Thread Local Storage|MemoryType_ThreadLocal]] || Mapped during [[#svcCreateThread]].
|-
| <code>0x015C3C0D</code> || MemoryType_TransferMemoryIsolated || Mapped using [[#svcMapTransferMemory]] when the owning process has perm=0.
|-
| <code>0x005C380E</code> || MemoryType_TransferMemory || Mapped using [[#svcMapTransferMemory]] when the owning process has perm!=0.
|-
| <code>0x0040380F</code> || MemoryType_ProcessMemory || Mapped using [[#svcMapProcessMemory]].
|-
| <code>0x00000010</code> || MemoryType_Reserved ||
|-
| <code>0x005C3811</code> || [[IPC_Marshalling|MemoryType_IpcBuffer1]] || IPC buffers with descriptor flags=1.
|-
| <code>0x004C2812</code> || [[IPC_Marshalling|MemoryType_IpcBuffer3]] || IPC buffers with descriptor flags=3.
|-
| <code>0x00002013</code> || MemoryType_KernelStack || Mapped in kernel during [[#svcCreateThread]].
|}

== ContinueDebugFlags ==
{| class=wikitable
! Bit || Bitmask || Description
|-
| 0 || 1 || SwallowException
|-
| 1 || 2 ||
|-
| 2 || 4 || ResumeAllThreads
|}

== DebugEventInfo ==
{| class=wikitable
! Offset || Length || Description
|-
| 0 || u32 || EventType
|-
| 4 || u32 || Flags (bit0: NeedsContinue)
|-
| 8 || u64 || ThreadId
|-
| 0x10 || || PerTypeSpecifics
|}

AttachProcess specific:
{| class=wikitable
! Offset || Length || Description
|-
| 0x10 || u64 || TitleId
|-
| 0x18 || u64 || ProcessId
|-
| 0x20 || char[12] || ProcessName
|-
| 0x2C || u32 || MmuFlags
|}

AttachThread specific:
{| class=wikitable
! Offset || Length || Description
|-
| 0x10 || u64 || ThreadId
|-
| 0x18 || u64 || TlsPtr
|-
| 0x20 || u64 || Entrypoint
|}

ExitProcess/ExitThread specific:
{| class=wikitable
! Offset || Length || Description
|-
| 0x10 || u32 || ProcessId/ThreadId?
|}

Exception specific:
{| class=wikitable
! Offset || Length || Description
|-
| 0x10 || u64 || ExceptionType
|-
| 0x18 || u64 || FaultRegister
|-
| 0x20 || || PerExceptionSpecifics
|}

=== DebugEventType ===
{| class=wikitable
! Value || Name
|-
| 0 || DebugEvent_AttachProcess
|-
| 1 || DebugEvent_AttachThread
|-
| 2 || DebugEvent_ExitProcess?
|-
| 3 || DebugEvent_ExitThread
|-
| 3 || DebugEvent_Exception
|}

=== DebugExceptionType ===
{| class=wikitable
! Value || Name
|-
| 0 || Exception_UndefinedInstruction
|-
| 1 || Exception_InstructionAbort
|-
| 2 || Exception_DataAbortMisc
|-
| 3 || Exception_PcSpAlignmentFault
|-
| 4 || Exception_DebuggerAttached
|-
| 5 || Exception_BreakPoint
|-
| 6 || Exception_UserBreak
|-
| 7 || Exception_DebuggerBreak
|-
| 8 || Exception_BadSvcId
|}

UndefinedInstruction specifics:
{| class=wikitable
! Offset || Length || Description
|-
| 0x20 || u32 || Opcode
|}

BreakPoint specifics:
{| class=wikitable
! Offset || Length || Description
|-
| 0x20 || u32 || IsWatchpoint
|}

UserBreak specifics:
{| class=wikitable
! Offset || Length || Description
|-
| 0x20 || u32 || Info0
|-
| 0x28 || u64 || Info1
|-
| 0x30 || u64 || Info2
|}

BadSvcId specifics:
{| class=wikitable
! Offset || Length || Description
|-
| 0x20 || u32 || SvcId
|}

= Exception handling =
There is userland code for handling exceptions, however this doesn't seem to be executed on retail mode.

When a usermode exception occurs, it jumps to the main code binary entrypoint (main_binary_address + 0 == '''_start''').

During normal boot '''_start''' is invoked with X0=0 and X1=main_thread_handle (triggering normal crt0 setup).
During an usermode exception '''_start''' is invoked with X0=exception_info0_ptr and X1=exception_info1_ptr instead.

The '''_start''' method determines whether to boot normally or handle an exception if X0 is set to 0 or not.

Cryptosystem

2017-10-19T15:19:19Z

Motezazer: /* Key generation */

4.0.0

2017-10-19T14:47:05Z

Motezazer: checkFuseCoherency

The Switch 4.0.0 system update was released on October 18, 2017. This Switch update was released for the following regions: ALL.

Security flaws fixed: <fill this in manually later, see the updatedetails page from the ninupdates-report page(s) once available for now>.

==Change-log==
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/22525/p/897 Official] ALL change-log:
* Added the following system functionality
* Capture video on select games
* To capture video, hold down the Capture Button during gameplay
* Up to maximum of the previous 30 seconds will be saved in the Album. You can trim the beginning and end of each clip, and post to Facebook and Twitter.
* As of October 18th, 2017, this feature is compatible with The Legend of Zelda: Breath of the Wild, Mario Kart 8 Deluxe, ARMS, and Splatoon 2
* Select from 12 new Super Mario Odyssey and The Legend of Zelda: Breath of the Wild icons for your user
* To edit your user icon, head to your My Page on the top left of the Home Menu > Profile
* Transfer user and save data to another system
* To transfer, head to System Settings > Users > Transfer Your User and Save Data
* Pre-purchase option on Nintendo eShop
* A pre-purchase option will be available for certain games. This option allows pre-load of the game to your system for quicker play when the game is released.
* This feature will be supported by future game releases
* News channel updates
* The news feed has been updated with a new look.
* Unfollowing a channel will remove that channel's content from the news feed and following the channel again will make it reappear.
* Match software version with a group of local users
* To create a group, head to the software's Options > Software Update > Match Version with Local Users
* Everyone's software will be updated to match the most recent version in the group
* All users must be on system menu version 4.0.0 or later to view and join a group
* General system stability improvements to enhance the user's experience, including:
* Changed the specification which hid wireless networks using TKIP security from the network search results. Wireless networks using TKIP security will now display in search results as a grayed-out selection instead of not being displayed
* The Nintendo Switch console supports WEP, WPA-PSK(AES), and WPA2-PSK(AES). If your router is using a different security type (e.g. WPA-PSK(TKIP)), you will need to change this security type within your router's settings.

==System Titles==
<fill this in (manually) later>

* Every single system title was updated, except for: 0100000000000805("Chinese and Korean dictionaries"), 0100000000000808("European, English and Japanese dictionaries"), and 010000000000080C("EULA").
* 4 new sysmodules were added, and new FIRM-package title 010000000000081C was added.

===FIRM===
Everything under RomFS was updated.

The package1 entrypoint address specified by BCT was increased by 0x20-bytes, since there's now an additional 0x20-bytes at the start of package1. The additional data is identical to the 0x20-byte block before it.

====Package1====
setKeyslotFlags (LT_4001011a)
Instead of writing ~flags directly to securityEngine->KEYSLOT_FLAGS[keyslot], this now preserves the high bits of the existing flags.

getOdmFuse4Type (LT_40010614)
This func now includes bits 16-19 in the OR'd flag used in the switch, and now returns 4 as a default invalid result instead of the low bit of [[Fuses|FUSE_SPARE_BIT_5]].

checkFuseCoherency (LT_400106e4)
This func was updated to take into account the new invalid retval for getOdmFuse4Type.
Checks that were only enforced on retail prior to this update (bootROM patch must not be < 0x7F and EKS must be provisionned) are now enforced for dev too.
The now redundant bootROM < 0x1F check was removed.

decryptAndParsePK11 (LT_40010734)
The entrypoint calculation code no longer adds *(package11Header + 0x4) to the address.

generateKeys (LT_400107a2)
setKeyslotFlags(keyslot, 0x15) is now additionally called on keyslots 14 and 15.
The code for switching key generation method depending on fuses (unit type) and last byte of PKC modulus has been removed, and replaced with a call to a single key generation function.
The code block inbetween the keyslot-config code was replaced with just a call to LT_40011264(same function mentioned above).
setKeyslotFlags(keyslot, 0xFF) is now used on keyslots 12 and 15 instead of 12 and 13.

downgradeFuseCheck (LT_400111cc)
The burnt fuse information stored in .rodata now expects 5 fuses to be burnt for retail units, instead of 4.

generateKeysFromBITAddress (LT_40011264)
Instead of calling generateKeysLegacyMethod, this now calls generateKeysFromKeyblobAndKeyseeds (the main key generation function). Legacy key generation code has been removed.

generateKeysFromKeyblobAndKeyseeds (LT_400112f0)
The function now takes in two keyseeds and sizes, previously it only took in one (keyseed, size) pair.
Keyslot 15 (initially SSK) is now used where keyslot 10 was used previously, and keyslot 15 is no longer cleared when keyslot 14 (initially SBK) is cleared.
The [[Flash_Filesystem|Keyblob]] keyseed was updated for keyblob 4.
code block following the keyblob clear code was updated:
After the decrypted keyblob is cleared, decryptDataIntoKeyslot(KEYSLOT_14, KEYSLOT_12, secondKeySeed, secondKeySeedSize) is now called before decryptDataIntoKeyslot(KEYSLOT_12, KEYSLOT_12, firstKeySeed, firstKeySeedSize).
At the end of the function, "decryptDataIntoKeyslot(KEYSLOT_13, KEYSLOT_10, perConsoleKeyseed2, 0x10); clearKeyslot(KEYSLOT_10);" has been replaced with "decryptDataIntoKeyslot(KEYSLOT_13, KEYSLOT_15, perConsoleKeyseed3, 0x10); decryptDataIntoKeyslot(KEYSLOT_15, KEYSLOT_15, perConsoleKeyseed2, 0x10);"

==Keys==
All of these updated titles now use the new [[NCA_Format|NCA]] crypto for [[NCA|non-ncatype0]](all content except .cnmt content), except for all of the FIRM-packages including the new one(required for FIRM installation).

[[Flash_Filesystem|Keyblob]] 4 is now used, instead of 3.

==OSS==
The updated [https://www.nintendo.co.jp/support/oss/index.html OSS] includes WebKit changes.

==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=10-18-17_08-05-13&sys=hac]

Cryptosystem

2017-10-19T14:27:39Z

Motezazer: New keys

Fuses

2017-10-19T14:16:01Z

Motezazer: /* Anti-downgrade */

The Nintendo Switch makes use of Tegra's fuse driver for a number of operations. This driver is mapped to physical address 0x7000F800 with a total size of 0x400 bytes and exposes several registers for fuse programming.

Registers from 0x7000F800 to 0x7000F800 + 0xFF can be used to directly program the hardware fuse array, while registers from 0x7000F800 + 0x100 (FUSE_CHIP_REG_START_OFFSET) to 0x7000F800 + 0x3FC (FUSE_CHIP_REG_END_OFFSET) represent cached values read from certain fuses.

== Registers ==
Below is a list of fuse driver registers used by the Switch's bootloaders.

=== Driver registers ===
{| class="wikitable" border="1"
! Name
! Address
|-
| [[#FUSE_CTRL|FUSE_CTRL]]
| 0x7000F800
|-
| [[#FUSE_REG_ADDR|FUSE_REG_ADDR]]
| 0x7000F804
|-
| [[#FUSE_REG_READ|FUSE_REG_READ]]
| 0x7000F808
|-
| [[#FUSE_REG_WRITE|FUSE_REG_WRITE]]
| 0x7000F80C
|-
| FUSE_TIME_RD1
| 0x7000F810
|-
| FUSE_TIME_RD2
| 0x7000F814
|-
| FUSE_TIME_PGM1
| 0x7000F818
|-
| [[#FUSE_TIME_PGM2|FUSE_TIME_PGM2]]
| 0x7000F81C
|-
| FUSE_PRIV2INTFC
| 0x7000F820
|-
| FUSE_FUSEBYPASS
| 0x7000F824
|-
| FUSE_PRIVATEKEYDISABLE
| 0x7000F828
|-
| [[#FUSE_DIS_PGM|FUSE_DIS_PGM]]
| 0x7000F82C
|-
| [[#FUSE_WRITE_ACCESS|FUSE_WRITE_ACCESS]]
| 0x7000F830
|-
| FUSE_PWR_GOOD_SW
| 0x7000F834
|-
|}

==== FUSE_CTRL ====
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| Fuse command (1 = FUSE_READ; 2 = FUSE_WRITE; 3 = FUSE_SENSE)
|-
| 26
| Fuse power down mode flag (FUSE_CTRL_PD)
|-
|}

Before fuse reading/writing the power down mode must be disabled.
FUSE_SENSE mode flushes programmed values into the [[Fuses#Cache_registers|cache registers]].

==== FUSE_REG_ADDR ====
This register takes the address of the fuse to be read/written/sensed.

==== FUSE_REG_READ ====
This register receives the value read from the fuse.

==== FUSE_REG_WRITE ====
This register takes the value to be written to the fuse.

==== FUSE_TIME_PGM2 ====
This register takes the fuse programming pulse (0xC0 == 19200 kHz).

==== FUSE_DIS_PGM ====
If set to 0x01, this register disables fuse programming.

==== FUSE_WRITE_ACCESS ====
If set to 0x01, this register disables software writes to the fuse driver registers.

=== Cache registers ===
{| class="wikitable" border="1"
! Name
! Address
|-
| [[#FUSE_SKU_INFO|FUSE_SKU_INFO]]
| 0x7000F910
|-
| FUSE_CPU_SPEEDO_0
| 0x7000F914
|-
| FUSE_CPU_IDDQ
| 0x7000F918
|-
| FUSE_FT_REV
| 0x7000F928
|-
| FUSE_CPU_SPEEDO_1
| 0x7000F92C
|-
| FUSE_CPU_SPEEDO_2
| 0x7000F930
|-
| FUSE_SOC_SPEEDO_0
| 0x7000F934
|-
| [[#FUSE_SOC_SPEEDO_1|FUSE_SOC_SPEEDO_1]]
| 0x7000F938
|-
| FUSE_SOC_SPEEDO_2
| 0x7000F93C
|-
| FUSE_SOC_IDDQ
| 0x7000F940
|-
| [[#FUSE_FA|FUSE_FA]]
| 0x7000F948
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY0]]
| 0x7000F964
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY1]]
| 0x7000F968
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY2]]
| 0x7000F96C
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY3]]
| 0x7000F970
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY4]]
| 0x7000F974
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY5]]
| 0x7000F978
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY6]]
| 0x7000F97C
|-
| [[#FUSE_PUBLIC_KEY|FUSE_PUBLIC_KEY7]]
| 0x7000F980
|-
| FUSE_TSENSOR_1
| 0x7000F984
|-
| FUSE_TSENSOR_2
| 0x7000F988
|-
| FUSE_CP_REV
| 0x7000F990
|-
| FUSE_TSENSOR_0
| 0x7000F998
|-
| FUSE_FIRST_BOOTROM_PATCH_SIZE_REG
| 0x7000F99C
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY0]]
| 0x7000F9A4
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY1]]
| 0x7000F9A8
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY2]]
| 0x7000F9AC
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY3]]
| 0x7000F9B0
|-
| [[#FUSE_PRIVATE_KEY|FUSE_PRIVATE_KEY4]]
| 0x7000F9B4
|-
| FUSE_VP8_ENABLE
| 0x7000F9C4
|-
| FUSE_RESERVED_ODM0
| 0x7000F9C8
|-
| FUSE_RESERVED_ODM1
| 0x7000F9CC
|-
| FUSE_RESERVED_ODM2
| 0x7000F9D0
|-
| FUSE_RESERVED_ODM3
| 0x7000F9D4
|-
| [[#FUSE_RESERVED_ODM4|FUSE_RESERVED_ODM4]]
| 0x7000F9D8
|-
| FUSE_RESERVED_ODM5
| 0x7000F9DC
|-
| [[#FUSE_RESERVED_ODM6|FUSE_RESERVED_ODM6]]
| 0x7000F9E0
|-
| [[#FUSE_RESERVED_ODM7|FUSE_RESERVED_ODM7]]
| 0x7000F9E4
|-
| FUSE_SKU_USB_CALIB
| 0x7000F9F0
|-
| FUSE_SKU_DIRECT_CONFIG
| 0x7000F9F4
|-
| FUSE_VENDOR_CODE
| 0x7000FA00
|-
| FUSE_FAB_CODE
| 0x7000FA04
|-
| FUSE_LOT_CODE_0
| 0x7000FA08
|-
| FUSE_LOT_CODE_1
| 0x7000FA0C
|-
| FUSE_WAFER_ID
| 0x7000FA10
|-
| FUSE_X_COORDINATE
| 0x7000FA14
|-
| FUSE_Y_COORDINATE
| 0x7000FA18
|-
| FUSE_GPU_IDDQ
| 0x7000FA28
|-
| FUSE_TSENSOR_3
| 0x7000FA2C
|-
| FUSE_OPT_SUBREVISION
| 0x7000FA48
|-
| FUSE_TSENSOR_4
| 0x7000FA54
|-
| FUSE_TSENSOR_5
| 0x7000FA58
|-
| FUSE_TSENSOR_6
| 0x7000FA5C
|-
| FUSE_TSENSOR_7
| 0x7000FA60
|-
| FUSE_OPT_PRIV_SEC_DIS
| 0x7000FA64
|-
| FUSE_TSENSOR_COMMON
| 0x7000FA80
|-
| FUSE_TSENSOR_8
| 0x7000FAD4
|-
| FUSE_RESERVED_CALIB
| 0x7000FB04
|-
| FUSE_TSENSOR_9
| 0x7000FB1C
|-
| FUSE_USB_CALIB_EXT
| 0x7000FB50
|-
| FUSE_SPARE_BIT_0
| 0x7000FB80
|-
| FUSE_SPARE_BIT_1
| 0x7000FB84
|-
| FUSE_SPARE_BIT_2
| 0x7000FB88
|-
| FUSE_SPARE_BIT_3
| 0x7000FB8C
|-
| FUSE_SPARE_BIT_4
| 0x7000FB90
|-
| [[#FUSE_SPARE_BIT_5|FUSE_SPARE_BIT_5]]
| 0x7000FB94
|-
| FUSE_SPARE_BIT_6
| 0x7000FB98
|-
| FUSE_SPARE_BIT_7
| 0x7000FB9C
|-
| FUSE_SPARE_BIT_8
| 0x7000FBA0
|-
| FUSE_SPARE_BIT_9
| 0x7000FBA4
|-
| FUSE_SPARE_BIT_10
| 0x7000FBA8
|-
| FUSE_SPARE_BIT_11
| 0x7000FBAC
|-
| FUSE_SPARE_BIT_12
| 0x7000FBB0
|-
| FUSE_SPARE_BIT_13
| 0x7000FBB4
|-
| FUSE_SPARE_BIT_14
| 0x7000FBB8
|-
| FUSE_SPARE_BIT_15
| 0x7000FBBC
|-
| FUSE_SPARE_BIT_16
| 0x7000FBC0
|-
| FUSE_SPARE_BIT_17
| 0x7000FBC4
|-
| FUSE_SPARE_BIT_18
| 0x7000FBC8
|-
| FUSE_SPARE_BIT_19
| 0x7000FBCC
|-
| FUSE_SPARE_BIT_20
| 0x7000FBD0
|-
| FUSE_SPARE_BIT_21
| 0x7000FBD4
|-
| FUSE_SPARE_BIT_22
| 0x7000FBD8
|-
| FUSE_SPARE_BIT_23
| 0x7000FBDC
|-
| FUSE_SPARE_BIT_24
| 0x7000FBE0
|-
| FUSE_SPARE_BIT_25
| 0x7000FBE4
|-
| FUSE_SPARE_BIT_26
| 0x7000FBE8
|-
| FUSE_SPARE_BIT_27
| 0x7000FBEC
|-
| FUSE_SPARE_BIT_28
| 0x7000FBF0
|-
| FUSE_SPARE_BIT_29
| 0x7000FBF4
|-
| FUSE_SPARE_BIT_30
| 0x7000FBF8
|-
| FUSE_SPARE_BIT_31
| 0x7000FBFC
|-
|}

==== FUSE_SKU_INFO ====
Stores the SKU ID (must be 0x83).

==== FUSE_FA ====
Stores failure analysis mode.

==== FUSE_SOC_SPEEDO_1 ====
Stores the bootrom patch version.

==== FUSE_RESERVED_ODM4 ====
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| Unit type (3 = debug; 0 = retail)
|-
| 2
| Unknown config (must be 1 on retail)
|-
| 8
| Unknown config mask (must be 0 on retail)
|-
| 9
| Unit type mask (0 = debug; 1 = retail)
|-
|}

This stores some device configuration parameters.

==== FUSE_RESERVED_ODM6 ====
This register returns the value programmed into index 0x3A of the fuse array.

==== FUSE_RESERVED_ODM7 ====
This register returns the value programmed into index 0x3C of the fuse array.

==== FUSE_SPARE_BIT_5 ====
Must be non-zero on retail units, otherwise the first bootloader panics.
On debug units it can be zero, which tells the bootloader to choose from two debug master key seeds. If set to non-zero on a debug unit, it tells the bootloader to choose from two retail master key seeds (only the last one matches the retail master key seed).

==== FUSE_PRIVATE_KEY ====
This stores the 160-bit private key (128 bit SBK + 32-bit device key).
Reads to these registers after the SBK is locked out produce all-FF output.

==== FUSE_PUBLIC_KEY ====
This stores the SHA256 hash of the 2048-bit RSA key expected at BCT+0x210.

== eFuses ==
The actual hardware fuses can be programmed through the fuse driver after enabling fuse programming.

Below is a list of common fuse indexes used by Tegra devices (and applicable to the Switch).
Note that the indexes are relative to the start of the fuse array and each element is a 4 byte word. A single fuse write operation always writes the same word at both fuse_array + 0 (PRIMARY_ALIAS) and fuse_array + 1 (REDUNDANT_ALIAS).

{| class="wikitable" border="1"
! Name
! Index
! Bits
|-
| jtag_disable
| 0x00
| 1
|-
| odm_production_mode
| 0x00
| 1
|-
| odm_lock
| 0x00
| 4
|-
| public_key
| 0x0C
| 256
|-
| secure_boot_key
| 0x22
| 128
|-
| device_key
| 0x2A
| 32
|-
| sec_boot_dev_cfg
| 0x2C
| 16
|-
| sec_boot_dev_sel
| 0x2C
| 3
|-
| sw_reserved
| 0x2E
| 12
|-
| ignore_dev_sel_straps
| 0x2E
| 1
|-
| [[#odm_reserved|odm_reserved]]
| 0x2E
| 256
|-
| pkc_disable
| 0x52
| 1
|-
| [[#bootrom_ipatch|bootrom_ipatch]]
| 0x72
| 624
|-
|}

=== odm_reserved ===
The first bootloader only burns fuses in this region.
Both fuse indexes 0x3A (odm_reserved + 0x0C) and 0x3C (odm_reserved + 0x0E) are used for anti-downgrade control. These fuses will have their values cached into [[#FUSE_RESERVED_ODM6|FUSE_RESERVED_ODM6]] and [[#FUSE_RESERVED_ODM7|FUSE_RESERVED_ODM7]].

=== bootrom_ipatch ===
Tegra210 based hardware such as the Switch provides support for bootrom patches. The patch data is burned to the hardware fuse array using a specific format (see [https://gist.github.com/shuffle2/f8728159da100e9df2606d43925de0af shuffle2's ipatch decoder]) and is executed by the bootrom, replacing it's original code.

The following represents the patch data dumped from a 2.0.0 Switch console:
Patch address Patch data
0x001016AE 0xDF00 // svc #0x00 (offset 0x48)
0x00103040 0xDF22 // svc #0x22 (offset 0x8c)
0x00106F2E 0xDF26 // svc #0x26 (offset 0x94)
0x0010FB3C 0x2000 // movs r0, #0x00
0x00100856 0xDF2C // svc #0x2c (offset 0xa0)
0x00106F54 0xDF42 // svc #0x42 (offset 0xcc)
0x001012E4 0xDF4B // svc #0x4b (offset 0xde)
0x00104526 0xDF54 // svc #0x54 (offset 0xf0)
0x001043F4 0xDF5D // svc #0x5d (offset 0x102)
0x00117744 0xAC57 // data
0x00117758 0x3D19 // data
0x00103D2A 0x2001 // movs r0, #0x01

The last 4 patches are exclusive to the Switch, while the remaining ones are often included in most Tegra210 based devices.

== Anti-downgrade ==
The first bootloader verifies [[#FUSE_RESERVED_ODM7|FUSE_RESERVED_ODM7]] to prevent downgrading.
How many fuses are expected to be burnt depends the device's unit type as below.

{| 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
|-
| 3.0.1-3.0.2
| 4
| 1
|-
| 4.0.0
| 5
| 1
|}

If too many fuses are burnt the bootloader will panic immediately.

If too few are burnt, the bootloader will enable fuse programming and write the expected value to fuse indexes 0x3A and 0x3C. Afterwards, fuse programming is disabled and a magic value (0x21 == TEGRA210) is written to PMC_SCRATCH200 register (0x7000EC40). Finally, the watchdog timer is initialized and programmed to force a reset.

On a subsequent boot, after the anti-downgrade fuses are checked again, the PMC_RST_STATUS register (0x7000E5B4) is checked and if set to 0x01 (watchdog reset) the PMC_SCRATCH200 register (0x7000EC40) will be checked for the magic value (0x21 == TEGRA210).
PMC_RST_STATUS will only be set back to 0 (power on reset) if the fuse count matches the new expected value, otherwise the system will panic.

Flog

2017-09-23T16:18:35Z

Motezazer: /* Official Launch */

This is the system "flog" 01008BB00013C000 [[Title_list|title]]. "flog" is a full-fledged NES emulator and is installed on retail systems since [[1.0.0]].

The titleID for "flog" is used by 3 functions in [[qlaunch]]: 1 for checking whether to launch it, 1 for registering it as an [[AM_services#appletAE|applet]] and 1 to launch it.

The ROM is not loaded via [[Filesystem_services|FS]] but is embedded in the main binary.

"flog" == "golf" backwards. This runs the NES "Golf" game. {1/2}-player via joy-con is supported. Controls are "d-pad" buttons + stick, however motion control while holding the Z{L/R} button is also supported instead of using buttons.

==Official Launch==
[[qlaunch]] periodically checks if the user is in "/RootScene/SceneResidentMenu", which represents the Home Menu (aka main-menu). If so, the following checks are then performed in order:
* The Joy-Cons' state is read from [[HID_Shared_Memory|HID shared memory]] and both must be active and detached from the console.
* "StartSixAxisSensor" [[HID_services#hid|hid]] command is called for each Joy-Con so motion data can be captured.
* After capturing the motion data, the same motion checks for both Joy-Cons must pass at the same time. This motion data is analyzed in a small state machine consisting of a total of 7 steps and the motion itself is a reference to [https://www.youtube.com/watch?time_continue=17&v=BdQg43n2OaM Iwata's Direct gesture]. Hold the Joy-Cons pointing forwards/downwards, then move Joy-Cons to a vertical position, and hold it there for a bit. The Joy-Con grip can be used for this.
* The system's month and day must be July 11th, which is the date of Iwata's [https://en.wikipedia.org/wiki/Satoru_Iwata passing]. The loaded date originates from network-time-sync'd time, regardless of whether the user has it enabled or not. When the system was never connected to the Internet and is on [[1.0.0]] it comes from the user-specified date instead. For newer systems, trying to load the network time if it was never set will result in an error: they won't ever be able to launch flog without a time-sync with Nintendo servers. This is loaded from the [[PCV_services|time]] service-cmds, with the actual time-sync being handled by [[NIM_services|NIM]].
* A wrapper for "GetLanguageCode" [[Settings_services#set|set]] command is called and the returned code must be 0 (JPja), 1 (USen) or 2 (EUen). Other combinations of region and language may have it's code translated internally to a valid one (0, 1 or 2), which seems to be the case for 12 (CNzh), 13 (KRko) and 14 (TWzh).
* Lastly, "IsSystemProgramInstalled" [[NS_Services#ns:am|ns:am]] command is called, which should return 1 if the "flog" title is installed.

Once everything passes it continues to the code which launches "flog". When "flog" is launched a small audio clip named "SeTestTone" is played which matches [https://www.youtube.com/watch?v=SeVTJu_Yn2Y&feature=youtu.be&t=17s this].

==Screenshots==
These screenshots were originally taken by executing flog with an unofficial method.

[[File:Flog0.jpg|200px|thumb|left|Flog main-screen]]
[[File:Flog1.jpg|200px|thumb|left|Flog 1-player]]
[[File:Flog2.jpg|200px|thumb|left|Flog 2-player mode as player-1.]]
[[File:Flog3.jpg|200px|thumb|left|Flog 2-player mode as player-2.]]

Error codes

2017-09-23T16:18:16Z

Motezazer:

= Structure =
These have been redesigned from the 3DS so that they fit within a Aarch64 MOV instruction immediate most of the time (without requiring the additional MOVK).

{| class=wikitable
! Bits || Field
|-
| 8-0 || Module
|-
| 21-9 || Description
|}

When a fatal-error is received the error code is outputted using the following formatter:
%04d-%04x

.. where the first code is <code>2000 + Module</code>, and the other being <code>Description</code>. Bits >=22 from the error-code are unused when displaying fatal-errors, since the Description ends with bit21.

= Modules =
{| class=wikitable
! Value || Name
|-
| 1 || Kernel
|-
| 2 || FS
|-
| 3 || NVIDIA, TransferMemory
|-
| 5 || NCM
|-
| 6 || DD
|-
| 8 || LR
|-
| 9 || Loader
|-
| 10 || CMIF (IPC command interface)
|-
| 11 || HIPC (IPC)
|-
| 15 || PM
|-
| 16 || NS
|-
| 18 || HTC
|-
| 21 || SM
|-
| 22 || RO userland
|-
| 24 || SDMMC
|-
| 26 || SPL
|-
| 100 || ETHC
|-
| 101 || I2C
|-
| 105 || Settings
|-
| 110 || NIFM
|-
| 114 || Display
|-
| 116 || NTC
|-
| 117 || FGM
|-
| 120 || PCIE
|-
| 121 || Friends
|-
| 123 || SSL
|-
| 124 || Account
|-
| 126 || Mii
|-
| 128 || AM
|-
| 129 || Play Report
|-
| 133 || PCV
|-
| 134 || OMM
|-
| 137 || NIM
|-
| 138 || PSC
|-
| 140 || USB
|-
| 143 || BTM
|-
| 147 || ERPT
|-
| 148 || APM
|-
| 154 || NPNS
|-
| 157 || ARP
|-
| 158 || BOOT
|-
| 161 || NFC
|-
| 162 || Userland assert
|-
| 168 || Userland crash
|-
| 203 || HID
|-
| 206 || Capture
|-
| 651 || TC
|-
| 800 || [[Internet_Browser|General web-applet]]
|-
| 809 || [[Internet_Browser|WifiWebAuthApplet]]
|-
| 810 || [[Internet_Browser|Whitelisted-applet]]
|-
| 811 || [[Internet_Browser|ShopN]]
|}

8XX is for/includes system applets.

= Error codes =
{| class=wikitable
! Value || Description || Description
|-
| 0x1C01 || 14 || Invalid kernel capability descriptor
|-
| 0x4201 || 33 || [[SPL_services#GetConfig|IsDebugMode]] isn't set.
|-
| 0xCA01 || 101 || Invalid size
|-
| 0xCC01 || 102 || Invalid address
|-
| 0xCE01 || 103 || Address is NULL / buffer size is too small.
|-
| 0xD001 || 104 || Memory full
|-
| 0xD201 || 105 || Handle-table full.
|-
| 0xD401 || 106 || Invalid memory state / invalid memory permissions.
|-
| 0xD801 || 108 || When trying to set executable permission on memory.
|-
| 0xDC01 || 110 || Stack address outside allowed range
|-
| 0xE001 || 112 || Invalid thread priority.
|-
| 0xE201 || 113 || Invalid processor id.
|-
| 0xE401 || 114 || Invalid handle.
|-
| 0xE601 || 115 || Syscall copy from user failed.
|-
| 0xE801 || 116 || Invalid combination
|-
| 0xEA01 || 117 || Time out? When you give 0 handles to svcWaitSynchronizationN.
|-
| 0xEC01 || 118 || Canceled/interrupted [?]
|-
| 0xEE01 || 119 || Exceeding maximum
|-
| 0xF001 || 120 || Invalid enum
|-
| 0xF201 || 121 || No such entry
|-
| 0xF401 || 122 || Irq/DeviceAddressSpace/{...} already registered
|-
| 0xF601 || 123 || Port remote dead
|-
| 0xF801 || 124 || [Usermode] Unhandled interrupt
|-
| 0xFA01 || 125 || Wrong memory permission?
|-
| 0xFC01 || 126 || Reserved value
|-
| 0xFE01 || 127 || Invalid hardware breakpoint
|-
| 0x10001 || 128 || [Usermode] Fatal exception
|-
| 0x10601 || 131 || Port max sessions exceeded
|-
| 0x10801 || 132 || Resource limit exceeded
|-
| 0x41001 || 520 || Process not being debugged
|-
| 0xE02 || 7 || High byte in input u64 is zero.
|-
| 0x7802 || 60 || The specified [[NCA]]-type doesn't exist for this title.
|-
| 0x7D202 || 1001 || Process does not have RomFs
|-
| 0x7D402 || 1002 || Title-id not found / savedata not found.
|-
| 0x13B002 || 2520 || Gamecard not inserted
|-
| 0x13DA02 || 2541 || Version check failed when mounting gamecard sysupdate partition?
|-
| 0x171402 || 2954 || Invalid gamecard handle.
|-
| 0x196002 || 3248 || Out of memory
|-
| 0x196202 || 3249 || Out of memory
|-
| 0x1A4A02 || 3365 || Out of memory
|-
| 0x235E02 || 4527 || NCA-path used with the wrong titleID.
|-
| 0x250E02 || 4743 || [[NAX0|Corrupted]] NAX0 header.
|-
| 0x251002 || 4744 || Invalid [[NAX0]] magicnum.
|-
| 0x2EE202 || 6001 || Invalid input
|-
| 0x2EE602 || 6003 || Path too long
|-
| 0x2F5A02 || 6061 || Offset outside storage
|-
| 0x313802 || 6300 || Operation not supported
|-
| 0x320002 || 6400 || Permission denied
|-
| 0x326602 || 6451 || Missing titlekey(?) required to mount content
|-
| 0x3EA03 || 501 || Invalid handle
|-
| 0x3EE03 || 503 || Invalid memory mirror
|-
| 0xA05 || 5 || [[Content_Manager_services|NcaID]] not found. Returned when attempting to mount titles which exist that aren't *8XX titles, the same way *8XX titles are mounted.
|-
| 0xE05 || 7 || TitleId not found
|-
| 0x1805 || 12 || Invalid StorageId
|-
| 0xDC05 || 110 || Gamecard not inserted
|-
| 0x17C05 || 190 || Gamecard not initialized
|-
| 0x1F405 || 250 || Sdcard not inserted
|-
| 0x20805 || 260 || Storage not mounted
|-
| 0x408 || 2 || Not initialized.
|-
| 0x608 || 3 || Invalid control StorageID.
|-
| 0x808 || 4 || Storage not found.
|-
| 0xA08 || 5 || Access denied.
|-
| 0xE08 || 7 || Title is not registered.
|-
| 0x409 || 2 || Maximum processes loaded.
|-
| 0x6609 || 51 || Invalid memory state/permission
|-
| 0x6A09 || 53 || Invalid NRR
|-
| 0xA209 || 81 || Unaligned NRR address
|-
| 0xA409 || 82 || Bad NRR size
|-
| 0xAA09 || 85 || Bad NRR address
|-
| 0x1A80A || 212 || Bad magic (expected 'SFCO')
|-
| 0x20B || 1 || Size too big to fit to marshal.
|-
| 0x11A0B || 141 || Went past maximum during marshalling.
|-
| 0x1900B || 200 || Session doesn't support domains.
|-
| 0x25A0B || 301 || Remote process is dead.
|-
| 0x3D60B || 491 || IPC Query 1 failed.
|-
| 0x20F || 1 || Pid not found
|-
| 0x60F || 3 || Process has no pending events
|-
| 0x410 || 2 || Title-id not found
|-
| 0xF010 || 120 || Gamecard sysupdate not required
|-
| 0x1F610 || 251 || Unexpected StorageId
|-
| 0x415 || 2 || Not initialized.
|-
| 0x615 || 3 || Max sessions
|-
| 0xC15 || 6 || Invalid name (all zeroes)
|-
| 0x1015 || 8 || Permission denied
|-
| 0x416 || 2 || Address space is full
|-
| 0x616 || 3 || NRO already loaded
|-
| 0x816 || 4 || Invalid NRO header values
|-
| 0xC16 || 6 || Bad NRR magic
|-
| 0x1016 || 8 || Reached max NRR count
|-
| 0x1216 || 9 || Unable to verify NRO hash or NRR signature
|-
| 0x80216 || 1025 || Address not page-aligned
|-
| 0x80416 || 1026 || Incorrect NRO size
|-
| 0x80816 || 1028 || NRO not loaded
|-
| 0x80A16 || 1029 || NRR not loaded
|-
| 0x80C16 || 1030 || Already initialized
|-
| 0x80E16 || 1031 || Not initialized
|-
| 0x41A || 2 || Argument is invalid
|-
| 0xD01A || 104 || All AES engines busy
|-
| 0xD21A || 105 || Invalid AES engine-id
|-
| 0xCC74 || 102 || Time not set
|-
| 0x287C || 20 || Argument is NULL
|-
| 0x2C7C || 22 || Argument is invalid
|-
| 0x3C7C || 30 || Bad input buffer size
|-
| 0x407C || 32 || Invalid input buffer
|-
| 0x3C9D || 30 || Address is NULL
|-
| 0x3E9D || 31 || PID is NULL
|-
| 0x549D || 42 || Already bound
|-
| 0xCC9D || 102 || Invalid PID
|-
| 0x3CF089 || 7800 || Unknown/invalid libcurl error.
|-
| 0x3E8289-0x3F4089 || 8001-8096 || libcurl error 1-96. Some of the libcurl errors in the error-table map to the above unknown-libcurl-error however.
|}

== FS Error Codes ==

The following are the error codes recognized by nn::fs::detail::LogErrorMessage found in some [[Factory Setup|factory]] titles:

{| class=wikitable
! Error Code || Description || Message
|-
| 0x7802 || 60 || Error: Specified mount name already exists.
|-
| 0xD401 || 106 || Error: Passed buffer is not usable for fs library.
|-
| 0x7D202 || 1001 || Error: Specified partition is not found.
|-
| 0x7D402 || 1002 || Error: Specified target is not found.
|-
| 0xFA002 - 0x138602 || 2000 - 2499 || Error: Failed to access SD card.
|-
| 0x136802 - 0x176E02 || 2500 - 2999 || Error: Failed to access game card.
|-
| 0x177202 || 3001 || Error: Specified operation is not implemented.
|-
| 0x177A02 || 3005 || Error: Specified value is out of range.
|-
| 0x1B5802 - 0x1F3E02 || 3500 - 3999 || Error: Failed to access MMC.
|-
| 0x1F4202 - 0x219602 || 4001 - 4299 || Error: ROM is corrupted.
|-
| 0x219A02 - 0x232602 || 4301 - 4499 || Error: Save data is corrupted.
|-
| 0x232A02 - 0x23EE02 || 4501 - 4599 || Error: NCA is corrupted.
|-
| 0x23F202 - 0x243E02 || 4601 - 4639 || Error: Integrity verification failed.
|-
| 0x244202 - 0x246602 || 4641 - 4659 || Error: Partition FS is corrupted.
|-
| 0x246A02 - 0x248E02 || 4661 - 4679 || Error: Built-in-storage is corrupted.
|-
| 0x249202 - 0x24B602 || 4681 - 4699 || Error: FAT FS is corrupted.
|-
| 0x24BA02 - 0x24DE02 || 4701 - 4719 || Error: HOST FS is corrupted.
|-
| 0x1F4002 - 0x270E02 || 4000, 4300, 4500, 4600, 4640, 4660, 4680, 4700, 4720-4999 || Error: Data is corrupted.
|-
| 0x271002 - 0x2EDE02 || 5000-5999 || Error: Unexpected failure occurred.
|-
| 0x2EE402 - 0x2F1A02 || 6002-6029 || Error: Invalid path was specified.
|-
| 0x2F5A02 || 6061 || Error: Invalid offset was specified.
|-
| 0x2F5C02 || 6062 || Error: Invalid size was specified.
|-
| 0x2F5E02 || 6063 || Error: Null pointer argument was specified.
|-
| 0x2EE002 || 6000 || Error: Precondition violation.
|-
| 0x2EE202 - 0x306E02 || 6001-6199 || Error: Invalid argument was specified.
|-
| 0x307202 || 6201 || Error: OpenMode_AllowAppend is required for implicit extension of file size by WriteFile().
|-
| 0x307002 - 0x313602 || 6200, 6202 - 6299 || Error: Invalid operation for the open mode.
|-
| 0x313802 - 0x31FE02 || 6300-6399 || Error: Unsupported operation.
|-
| 0x320002 - 0x32C602 || 6400-6499 || Error: Permission denied.
|-
| 0x346402 || 6706 || Error: Enough journal space is not left.
|-
| 0x346A02 || 6709 || Error: The open count of files and directories reached the limitation.
|}

= Fatal Errors =
{| class=wikitable
! Error || Description
|-
| 2162-0002
| Can be triggered by running [[SVC|svcBreak]]. The svcBreak params have no affect on the value of the thrown error-code.
|-
| 2168-0000
| Userland ARM undefined instruction exception
|-
| 2168-0001
| Userland ARM prefetch-abort due to PC set to non-executable region
|-
| 2168-0002
| Userland ARM data abort. Also caused by abnormal process termination via [[SVC|svcExitProcess]]. Note: directly jumping to nnMain()-retaddr from non-main-thread has the same result.
|-
| 2168-0003
| Userland PC address not aligned to 4 bytes
|}

= Support Errors =
{| class=wikitable
! Error !! Module || Description || Notes
|-
|
| {web-applets listed above}
| 2750
| MP4 parsing failed.
|}
Normal error-codes displayed by the system also use the same format as fatal-errors.

TSEC

2017-08-12T14:26:02Z

Motezazer: The bootloader does not use the RTC but the timer

TSEC (Tegra Security Engine Controller) is a NVIDIA Falcon microprocessor with crypto extensions. Therefore, all information in this page related to Falcon is identical for TSEC and vice versa.

= Driver =
A host driver for communicating with the TSEC/Falcon is mapped to physical address 0x54500000 with a total size of 0x40000 bytes and exposes several registers.

== Registers ==
{| class="wikitable" border="1"
! Name
! Address
! Width
|-
| [[#FALCON_IRQMSET|FALCON_IRQMSET]]
| 0x54501010
| 0x04
|-
| [[#FALCON_IRQDEST|FALCON_IRQDEST]]
| 0x5450101C
| 0x04
|-
| [[#FALCON_SCRATCH0|FALCON_SCRATCH0]]
| 0x54501040
| 0x04
|-
| [[#FALCON_SCRATCH1|FALCON_SCRATCH1]]
| 0x54501044
| 0x04
|-
| [[#FALCON_ITFEN|FALCON_ITFEN]]
| 0x54501048
| 0x04
|-
| [[#FALCON_CPUCTL|FALCON_CPUCTL]]
| 0x54501100
| 0x04
|-
| [[#FALCON_BOOTVEC|FALCON_BOOTVEC]]
| 0x54501104
| 0x04
|-
| [[#FALCON_DMACTL|FALCON_DMACTL]]
| 0x5450110C
| 0x04
|-
| [[#FALCON_DMATRFBASE|FALCON_DMATRFBASE]]
| 0x54501110
| 0x04
|-
| [[#FALCON_DMATRFMOFFS|FALCON_DMATRFMOFFS]]
| 0x54501114
| 0x04
|-
| [[#FALCON_DMATRFCMD|FALCON_DMATRFCMD]]
| 0x54501118
| 0x04
|-
| [[#FALCON_DMATRFFBOFFS|FALCON_DMATRFFBOFFS]]
| 0x5450111C
| 0x04
|-
|}

=== FALCON_IRQMSET ===
Used for configuring Falcon's IRQs.

=== FALCON_IRQDEST ===
Used for configuring Falcon's IRQs.

=== FALCON_SCRATCH0 ===
MMIO register for reading/writing data to Falcon.

=== FALCON_SCRATCH1 ===
MMIO register for reading/writing data to Falcon.

=== FALCON_ITFEN ===
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| FALCON_ITFEN_CTXEN
|-
| 1
| FALCON_ITFEN_MTHDEN
|-
|}

Used for enabling/disabling Falcon interfaces.

=== FALCON_CPUCTL ===
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| FALCON_CPUCTL_STARTCPU
|-
|}

Used for signaling Falcon's CPU.

=== FALCON_BOOTVEC ===
Takes the Falcon's boot vector address.

=== FALCON_DMACTL ===
{| class="wikitable" border="1"
! Bits
! Description
|-
| 1
| FALCON_DMACTL_DMEM_SCRUBBING
|-
| 2
| FALCON_DMACTL_IMEM_SCRUBBING
|-
|}

Used for configuring the Falcon's DMA engine.

=== FALCON_DMATRFBASE ===
Takes the host's base address for transferring data to/from the Falcon (DMA).

=== FALCON_DMATRFMOFFS ===
Takes the offset for the host's source memory being transferred.

=== FALCON_DMATRFCMD ===
{| class="wikitable" border="1"
! Bits
! Description
|-
| 1
| FALCON_DMATRFCMD_IDLE (this is set if the engine is idle)
|-
| 4
| FALCON_DMATRFCMD_IMEM
|-
| 9-10
| FALCON_DMATRFCMD_SIZE_256B
|-
|}

Used for configuring DMA transfers.

=== FALCON_DMATRFFBOFFS ===
Takes the offset for Falcon's target memory being transferred.

= Boot Process =
TSEC is configured and initialized by the first bootloader during key generation (sub_400114FC).

== Initialization ==
During this stage several clocks are programmed.
// Program the HOST1X clock and resets
// Uses RST_DEVICES_L, CLK_OUT_ENB_L, CLK_SOURCE_HOST1X and CLK_L_HOST1X
enable_host1x_clkrst();

// Program the TSEC clock and resets
// Uses RST_DEVICES_U, CLK_OUT_ENB_U, CLK_SOURCE_TSEC and CLK_U_TSEC
enable_tsec_clkrst();

// Program the SOR_SAFE clock and resets
// Uses RST_DEVICES_Y, CLK_OUT_ENB_Y and CLK_Y_SOR_SAFE
enable_sor_safe_clkrst();

// Program the SOR0 clock and resets
// Uses RST_DEVICES_X, CLK_OUT_ENB_X and CLK_X_SOR0
enable_sor0_clkrst();

// Program the SOR1 clock and resets
// Uses RST_DEVICES_X, CLK_OUT_ENB_X, CLK_SOURCE_SOR1 and CLK_X_SOR1
enable_sor1_clkrst();

// Program the KFUSE clock resets
// Uses RST_DEVICES_H, CLK_OUT_ENB_H and CLK_H_KFUSE
enable_kfuse_clkrst();

== Configuration ==
In this stage the Falcon IRQs, interfaces and DMA engine are configured.
// Clear the Falcon DMA control register
*(u32 *)FALCON_DMACTL = 0;

// Enable Falcon IRQs
*(u32 *)FALCON_IRQMSET = 0xFFF2;

// Enable Falcon IRQs
*(u32 *)FALCON_IRQDEST = 0xFFF0;

// Enable Falcon interfaces
*(u32 *)FALCON_ITFEN = 0x03;

// Wait for Falcon's DMA engine to be idle
wait_flcn_dma_idle();

== Firmware loading ==
The Falcon firmware code is stored in the first bootloader's data segment in IMEM.
// Set DMA transfer base address to 0x40011900 >> 0x08
*(u32 *)FALCON_DMATRFBASE = 0x400119;

u32 trf_mode = 0; // A value of 0 sets FALCON_DMATRFCMD_IMEM
u32 dst_offset = 0;
u32 src_offset = 0;

// Load code into Falcon (0x100 bytes at a time)
while (src_offset < 0xF00)
{
flcn_load_firm(trf_mode, src_offset, dst_offset);
src_offset += 0x100;
dst_offset += 0x100;
}

== Firmware booting ==
Falcon is booted up and the first bootloader waits for it to finish.
// Set host1x sync config
*(u32 *)0x50003300 = 0x34C2E1DA;

// Clear Falcon scratch1 MMIO
*(u32 *)FALCON_SCRATCH1 = 0;

// Set Falcon boot key version in scratch0 MMIO
*(u32 *)FALCON_SCRATCH0 = 0x01;

// Set Falcon's boot vector address
*(u32 *)FALCON_BOOTVEC = 0;

// Signal Falcon's CPU
*(u32 *)FALCON_CPUCTL = 0x02;

// Wait for Falcon's DMA engine to be idle
wait_flcn_dma_idle();

u32 boot_res = 0;

// The bootloader allows the TSEC two seconds from this point to do its job
u32 maximum_time = read_timer() + 2000000;

while (!boot_res)
{
// Read boot result from scratch1 MMIO
boot_res = *(u32 *)FALCON_SCRATCH1;

// Read from TIMERUS_CNTR_1US (microseconds from boot)
u32 current_time = read_timer();

// Booting is taking too long
if (current_time > maximum_time)
panic();
}

// Invalid boot result was returned
if (boot_res != 0xB0B0B0B0)
panic();

== Keygen ==
The Falcon device key is generated by reading SOR registers modified by Falcon.
// Clear host1x sync config
*(u32 *)0x50003300 = 0;

// Generate Falcon device key
u32 falcon_device_key[4];
falcon_device_key[0] = *(u32 *)NV_SOR_DP_HDCP_BKSV_LSB;
falcon_device_key[1] = *(u32 *)NV_SOR_TMDS_HDCP_BKSV_LSB;
falcon_device_key[2] = *(u32 *)NV_SOR_TMDS_HDCP_CN_MSB;
falcon_device_key[3] = *(u32 *)NV_SOR_TMDS_HDCP_CN_LSB;

// Clear SOR registers
*(u32 *)NV_SOR_DP_HDCP_BKSV_LSB = 0;
*(u32 *)NV_SOR_TMDS_HDCP_BKSV_LSB = 0;
*(u32 *)NV_SOR_TMDS_HDCP_CN_MSB = 0;
*(u32 *)NV_SOR_TMDS_HDCP_CN_LSB = 0;

if (out_size < 0x10)
out_size = 0x10;

// Copy back the Falcon key
memcpy(out_buf, falcon_device_key, out_size);

== Cleanup ==
Clocks and resets are disabled before returning.
// Deprogram KFUSE clock and resets
// Uses RST_DEVICES_H, CLK_OUT_ENB_H and CLK_H_KFUSE
disable_kfuse_clkrst();

// Deprogram SOR1 clock and resets
// Uses RST_DEVICES_X, CLK_OUT_ENB_X, CLK_SOURCE_SOR1 and CLK_X_SOR1
disable_sor1_clkrst();

// Deprogram SOR0 clock and resets
// Uses RST_DEVICES_X, CLK_OUT_ENB_X and CLK_X_SOR0
disable_sor0_clkrst();

// Deprogram SOR_SAFE clock and resets
// Uses RST_DEVICES_Y, CLK_OUT_ENB_Y and CLK_Y_SOR_SAFE
disable_sor_safe_clkrst();

// Deprogram TSEC clock and resets
// Uses RST_DEVICES_U, CLK_OUT_ENB_U, CLK_SOURCE_TSEC and CLK_U_TSEC
disable_tsec_clkrst();

// Deprogram HOST1X clock and resets
// Uses RST_DEVICES_L, CLK_OUT_ENB_L, CLK_SOURCE_HOST1X and CLK_L_HOST1X
disable_host1x_clkrst();

return;

= TSEC Firmware =
The actual code loaded into TSEC is assembled in NVIDIA's proprietary fuc5 ISA using crypto extensions.
Stored inside the first bootloader, this firmware binary is split into 4 blobs: Stage0, Stage1, Stage2 and key data.

Firmware can be disassembled with [http://envytools.readthedocs.io/en/latest/ envytools'] [https://github.com/envytools/envytools/tree/master/envydis envydis]:

<code>envydis -i tsec_fw.bin -m falcon -V fuc5 -F crypt</code>

Note that the instruction set has variable length instructions, and the disassembler is not very good at detecting locations it should start disassembling from. One needs to disassemble multiple sub-regions and join them together.

== Stage 0 ==
During this stage key data is loaded and Stage 1 is authenticated, loaded and executed.
Before returning, this stage writes back to the host (using MMIO registers) and sets the device key used by the first bootloader.

=== Initialization ===
Falcon sets up it's own stack pointer.
// Read data segment size from IO space
u32 data_seg_size = *(u32 *)UC_CAPS;
data_seg_size >>= 0x09;
data_seg_size &= 0x1FF;
data_seg_size <<= 0x08;

// Set the stack pointer
*(u32 *)sp = data_seg_size;

=== Stage 1 loading ===
u32 boot_base_addr = 0;
u32 key_data_buf[0x7C];

// Read the key data from memory
u32 key_data_addr = 0x300;
u32 key_data_size = 0x7C;
read_code(key_data_buf, key_data_addr, key_data_size);

// Read the next code segment into boot base
u32 blob1_addr = 0x400;
u32 blob1_size = *(u32 *)(key_data_buf + 0x74);
read_code(boot_base_addr, blob1_addr, blob1_size);

// Upload the next code segment into Falcon's CODE region
u32 blob1_virt_addr = 0x300;
bool use_secret = true;
upload_code(blob1_virt_addr, boot_base_addr, blob1_size, blob1_virt_addr, use_secret);

u32 boot_res = 0;
bool is_done = false;
u32 time = 0;
bool is_blob_dec = false;

while (!is_done)
{
if (time > 4000000)
{
// Write boot failed (timeout) magic to FALCON_SCRATCH1
boot_res = 0xC0C0C0C0;
*(u32 *)FALCON_SCRATCH1 = boot_res;

break;
}

// Load key version from FALCON_SCRATCH0 (bootloader sends 0x01)
u32 key_version = *(u32 *)FALCON_SCRATCH0;

if (key_version == 0x64)
{
// Skip all next stages
boot_res = 0xB0B0B0B0;
*(u32 *)FALCON_SCRATCH1 = boot_res;

break;
}
else
{
if (key_version > 0x03)
boot_res = 0xD0D0D0D0; // Invalid key version
else if (key_version == 0)
boot_res = 0xB0B0B0B0; // No keys used
else
{
u32 key_buf[0x7C];

// Copy key data
memcpy(key_buf, key_data_buf, 0x7C);

u32 crypt_reg_flag = 0x00060000;
u32 blob1_hash_addr = key_buf + 0x20;

// fuc5 crypt cauth instruction
// Set auth_addr to 0x300 and auth_size to blob1_size
cauth((blob1_size << 0x10) | (0x300 >> 0x08));

// fuc5 crypt cxset instruction
// The next 2 xfer instructions will be overridden
// and target changes from DMA to crypto
cxset(0x02);

// Transfer data to crypto register c6
xdst(0, (blob1_hash_addr | crypt_reg_flag));

// Wait for all data loads/stores to finish
xdwait();

// Jump to Stage1
u32 stage1_res = exec_stage1(key_buf, key_version, is_blob_dec);
is_blob_dec = true; // Set this to prevent decrypting again

// Set boot finish magic on success
if (stage1_res == 0)
boot_res = 0xB0B0B0B0
}

// Write result to FALCON_SCRATCH1
*(u32 *)FALCON_SCRATCH1 = boot_res;

if (boot_res == 0xB0B0B0B0)
is_done = true;
}

time++;
}

// Write Falcon device key to registers
set_device_key(key_data_buf);

return boot_res;

== Stage 1 ==
This stage is responsible for reconfiguring the Falcon's crypto co-processor and loading, decrypting, authenticating and executing Stage 2.

=== Crypto setup ===
// Clear interrupt flags
*(u8 *)flags_ie0 = 0;
*(u8 *)flags_ie1 = 0;
*(u8 *)flags_ie2 = 0;

// fuc5 crypt cxset instruction
// Clear overrides?
cxset(0x80);

// fuc5 crypt cauth instruction
// Clear auth_addr
cauth(cauth_old & 0x7FFFF);

// Set the target port for memory transfers
// Target will now be 0 (crypto?)
xtargets(0);

// Wait for all data loads/stores to finish
xdwait();

// Wait for all code loads to finish
xcwait();

// fuc5 crypt cxset instruction
// The next 2 xfer instructions will be overridden
// and target changes from DMA to crypto
cxset(0x02);

// Transfer data to crypto register c0
// This should clear any leftover data
xdst(0, 0);

// Wait for all data loads/stores to finish
xdwait();

// Clear all crypto registers, except c6 which is used for auth
*(u32 *)c0 ^= *(u32 *)c0;
*(u32 *)c1 = *(u32 *)c0;
*(u32 *)c2 = *(u32 *)c0;
*(u32 *)c3 = *(u32 *)c0;
*(u32 *)c4 = *(u32 *)c0;
*(u32 *)c5 = *(u32 *)c0;
*(u32 *)c7 = *(u32 *)c0;

// Update engine specific IO (crypto?)
*(u32 *)0x00020E00 &= 0xEFFFF;

// Update engine specific IO (crypto?)
*(u32 *)0x00010600 |= 0x01;

u32 wait_10600 = 0;

// Wait for some device
while (wait_10600 == 0)
wait_10600 = (*(u32 *)0x00010600 & 0x02);

// Read data segment size from IO space
u32 data_seg_size = *(u32 *)UC_CAPS;
data_seg_size >>= 0x09;
data_seg_size &= 0x1FF;
data_seg_size <<= 0x08;

// Check stack bounds
if ((*(u32 *)sp >= data_seg_size) || (*(u32 *)sp < 0x800))
return;

// Decrypt and load Stage2
load_stage2(key_buf, key_version, is_blob_dec);

// Partially unknown fuc5 instruction
// Likely forces propagation of permissions, hiding all cX registers
acl_chmod(c0, c0);

// Clear all crypto registers and propagate permissions
*(u32 *)c0 ^= *(u32 *)c0;
*(u32 *)c1 ^= *(u32 *)c1;
*(u32 *)c2 ^= *(u32 *)c2;
*(u32 *)c3 ^= *(u32 *)c3;
*(u32 *)c4 ^= *(u32 *)c4;
*(u32 *)c5 ^= *(u32 *)c5;
*(u32 *)c6 ^= *(u32 *)c6;
*(u32 *)c7 ^= *(u32 *)c7;

// Exit Authenticated Mode
*(u32 *)0x00010300 = 0;

return;

=== Stage 2 loading ===
u32 res = 0;

u32 boot_base_addr = 0;
u32 blob0_addr = 0;
u32 blob0_size = *(u32 *)(key_buf + 0x70);

// Load blob0 code again
read_code(boot_base_addr, blob0_addr, blob0_size);

// Generate "CODE_SIG_01" key into c4 crypto register
keygen(0, 0);

// Encrypt buffer with c4
u32 sig_key[0x10];
enc_buf(sig_key, blob0_size);

u32 src_addr = boot_base_addr;
u32 src_size = blob0_size;
u32 iv_addr = sig_key;
u32 dst_addr = sig_key;
u32 mode = 0x02; // AES-CMAC
u32 version = 0;

// Do AES-CMAC over blob0 code
do_crypto(src_addr, src_size, iv_addr, dst_addr, mode, version);

// Compare the hashes
if (memcmp(sig_key, key_buf + 0x10, 0x10))
{
res = 0xDEADBEEF;
return res;
}

u32 blob1_size = *(u32 *)(key_buf + 0x74);

// Decrypt Stage2 blob if needed
if (!is_blob_dec)
{
// Read Stage2's size from key buffer
u32 blob2_size = *(u32 *)(key_buf + 0x78);

// Check stack bounds
if (*(u32 *)sp > blob2_size)
{
u32 boot_base_addr = 0;
u32 blob2_virt_addr = blob0_size + blob1_size;
u32 blob2_addr = blob2_virt_addr + 0x100;

// Read Stage2's encrypted blob
read_code(boot_base_addr, blob2_addr, blob2_size);

// Generate "CODE_ENC_01" key into c4 crypt register
keygen(0x01, 0x01);

u32 src_addr = boot_base_addr;
u32 src_size = blob2_size;
u32 iv_addr = key_buf + 0x40;
u32 dst_addr = boot_base_addr;
u32 mode = 0; // AES-128-ECB
u32 version = 0;

// Decrypt Stage2
do_crypto(src_addr, src_size, iv_addr, dst_addr, mode, version);

// Upload the next code segment into Falcon's CODE region
bool use_secret = true;
upload_code(blob2_virt_addr, boot_base_addr, blob2_size, blob2_virt_addr, use_secret);

// Clear out the decrypted blob
memset(boot_base_addr, 0, blob2_size);
}
}

// fuc5 crypt cxset instruction
// The next 2 xfer instructions will be overridden
// and target changes from DMA to crypto
cxset(0x02);

u32 crypt_reg_flag = 0x00060000;
u32 blob2_hash_addr = key_buf + 0x30;

// Transfer data to crypto register c6
xdst(0, (blob2_hash_addr | crypt_reg_flag));

// Wait for all data loads/stores to finish
xdwait();

// Save previous cauth value
u32 c_old = cauth_old;

// fuc5 crypt cauth instruction
// Set auth_addr to blob2_virt_addr and auth_size to blob2_size
cauth((blob2_virt_addr >> 0x08) | (blob2_size << 0x10));

u32 hovi_key_addr = 0;

// Select next stage key
if (key_version == 0x01) // Use HOVI_EKS_01
hovi_key_addr = key_buf + 0x50;
else if (key_version == 0x02) // Use HOVI_COMMON_01
hovi_key_addr = key_buf + 0x60;
else if (key_version == 0x03) // Use device key
hovi_key_addr = key_buf + 0x00;
else
res = 0xD0D0D0D0

// Jump to Stage2
if (hovi_key_addr)
res = exec_stage2(hovi_key_addr, key_version);

// Clear out key data
memset(key_buf, 0, 0x7C);

// fuc5 crypt cauth instruction
// Restore previous cauth value
cauth(c_old);

return res;

== Stage 2 ==
This stage is decrypted by Stage 1 using an hardware secret (HOVI == Horizon VI?).

== Key data ==
Small buffer stored after Stage 0's code and used across all stages.

{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x00
| 0x10
| Device key
|-
| 0x10
| 0x10
| blob0 auth hash
|-
| 0x20
| 0x10
| blob1 auth hash
|-
| 0x30
| 0x10
| blob2 auth hash
|-
| 0x40
| 0x10
| blob2 AES IV
|-
| 0x50
| 0x10
| HOVI eks seed
|-
| 0x60
| 0x10
| HOVI common seed
|-
| 0x70
| 0x04
| blob0 size
|-
| 0x74
| 0x04
| blob1 size
|-
| 0x78
| 0x04
| blob2 size
|-
|}

== Notes ==

[https://wiki.0x04.net/wiki/Marcin_Ko%C5%9Bcielnicki mwk] shared additional info learned from RE of falcon processors over the years, which hasn't made it into envytools documentation yet:

=== cxset ===

cxset instruction provides a way to change behavior of a variable amount of successively executed DMA-related instructions.

for example: <code>000000de: f4 3c 02 cxset 0x2</code>

can be read as: <code>dma_override(type=crypto_reg, count=2)</code>

The argument to cxset specifies the type of behavior change in the top 3 bits, and the number of DMA-related instructions the effect lasts for in the lower 5 bits.

==== Override Types ====

Unlisted values are unknown, but probably do something.

{| class=wikitable
! Value || Effect
|-
| 0b000 || falcon data mem <-> falcon $cX register
|-
| 0b001 || external mem <-> crypto input/output stream
|}

==== DMA-Related Instructions ====

At least the following instructions may have changed behavior, and count against the cxset "count" argument: <code>xdwait</code>, <code>xdst</code>, <code>xdld</code>.

For example, if override type=0b000, then the "length" argument to <code>xdst</code> is instead treated as the index of the target $cX register.

=== Register ACLs ===

Falcon tracks permission metadata about each crypto reg. Permissions include read/write ability per execution mode, as well as ability to use the reg for encrypt/decrypt, among other permissions. Permissions are propagated when registers are referenced by instructions (e.g. moving a value from read-protected $cX to $cY will result in $cY also being read-protected).

=== Authenticated Mode Entry/Exit ===

Entry to Authenticated Mode always sets $pc to the address supplied in $cauth (ie the base of the signature-checked region). This takes effect when trying to branch to any address within the range covered by $cauth. Entry to Authenticated Mode (also called "Secure Mode") computes a MAC over the $cauth region and compares it to $c6 in order to perform the signature check.

Exit from Authenticated Mode must poke a special register (this seems to be I[0x10300] = 0) before leaving authenticated code pages. Failure to do this would result in the Falcon core halting.

XCI

2017-08-03T11:16:11Z

Motezazer: According to the dumps on the cartridge page

=Header=
The header is 0x200-bytes, at Gamecard+0.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| RSA-2048 signature, presumably.
|-
| 0x100
| 0x4
| Magicnum "HEAD"
|-
| 0x104
| 0x4
| Offset of Secure partition (Size of non-secure data?), in Media Units (0x200 bytes for switch gamecarts)
|-
| 0x108
| 0x4
| 0xFFFFFFFF
|-
| 0x10C
| 0x1
| ?
|-
| 0x10D
| 0x1
| Cartridge Size. 0xF8 = 2 GB, 0xF0 = 4 GB, 0xE0 = 8 GB, 0xE1 = 16 GB
|-
| 0x10E
| 0x1
| ?
|-
| 0x10F
| 0x1
| ?
|-
| 0x110
| 0x8
| ?
|-
| 0x118
| 0x8
| Size of the Gamecart, in Media Units
|-
| 0x120
| 0x10
| ?
|-
| 0x130
| 0x8
| Offset of HFS0 FS partition
|-
| 0x138
| 8
| HFS0 Header size
|-
| 0x140
| 0x20
| SHA256 hash of the HFS0 Header
|-
| 0x160
| 0x20
| SHA256 hash of the crypto header
|-
| 0x180
| 0x4
| 1?
|-
| 0x184
| 0x4
| 2?
|-
| 0x188
| 0x4
| 0?
|-
| 0x18C
| 0x4
| Offset of Secure partition (Size of non-secure data?), in Media Units, again.
|-
| 0x190
| 0x70
| Encrypted data/hashes of some kind
|}

= Cert =

This is for the CERT, located at Gamecard + 0x7000 (always?). This matches exactly the output from fsp-srv IDeviceOperator cmd 206 "GetGameCardDeviceCertificate".

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| RSA-2048 signature, presumably.
|-
| 0x100
| 0x4
| Magicnum "CERT"
|-
| 0x110
| 0x10
| ?
|-
| 0x12A
| 0xD6
| Encrypted data. Some kind of key?
|}

The data between the CERT and the start of the HFS0 is all 0xFF.

= HFS0 =
This is the FS which has magicnum "HFS0" at header+0.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| HFS0 Magic
|-
| 0x4
| 0x4
| Number of files
|-
| 0x8
| 0x4
| Size of the string table
|-
| 0xC
| 0x4
| Zero/Reserved
|-
| 0x10
| X
| File Entry Table
|-
| 0x10 + X
| Y
| String Table
|-
| 0x10 + X + Y
| Z
| Raw File Data
|}

Where File Entry Table consists of Number of Files FileEntries:

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Offset of file in Data
|-
| 0x8
| 0x8
| Size of file in Data
|-
| 0x10
| 0x4
| Offset of filename in String Table
|-
| 0x14
| 0x4
| Size of Hashed region of file (for HFS0s, this is the size of the pre-filedata portion, for NCAs this is usually 0x200).
|-
| 0x18
| 8
| Zero/Reserved
|-
| 0x20
| 0x20
| SHA256 hash of the first (size of hashed region) bytes of filedata.
|}

The string table is 00-padded to align the start of raw filedata with a sector/media unit boundary (usually?).

=Typical Cartridge Layout=
Observed gamecarts contain three partitions: "update", "normal", and "secure".

The update partition (Gamecard partition 0 for fsp-srv cmd 31) contains .cnmt.nca + .nca files for the entire system update required to play the game. Launch day carts contain a full copy of 1.0 ncas, newer carts contain newer sysupdate NCAs etc.

The normal partition contains the .cnmt.nca and the game icondata nca. This is presumably for future compatibility so that if a future update changes the cryptographic protocol for the secure partition, Game icon data can still be shown in the home menu on old firmwares.

The secure partition contains an identical copy of the .cnmt.nca and game icondata nca, as well as all other ncas required for the game.

The entire rest of the gamecard after the secure partition ends is all FF padding.

Cryptosystem

2017-07-31T23:08:47Z

Motezazer: Updated with 3.0.1 information

Package1

2017-07-31T23:08:25Z

Motezazer: Updated with 3.0.1 information

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
|-
| 3.0.1
| 4
| 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.

Cryptosystem

2017-07-26T15:55:31Z

Motezazer:

Cryptosystem

2017-07-26T15:41:48Z

Motezazer: This info was moved in package1

Package1

2017-07-26T15:03:00Z

Motezazer:

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 detect a downgrade attempt. 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 sets a fuse (so that Nintendo knows that you attempted to mess with the bootloader)
* 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.

This method is described on the [[Cryptosystem|cryptosystem]] page.

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

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 encryptd.

=== 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-26T14:53:57Z

Motezazer: Thanks hexkyz

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.
* [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 detect a downgrade attempt. 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 sets a fuse (so that Nintendo knows that you attempted to mess with the bootloader)
* 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.

This method is described on the [[Cryptosystem|cryptosystem]] page.

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

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 encryptd.

=== 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-26T14:25:46Z

Motezazer: Thanks to SciresM for help with writing this page

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] Some fuse is written to.
* The memory controller is powered on and setup to allow GPU DMA to the IRAM. This will be needed to interact with the Falcon.
* [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 detect a downgrade attempt. 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 sets a fuse (so that Nintendo knows that you attempted to mess with the bootloader)
* 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.

This method is described on the [[Cryptosystem|cryptosystem]] page.

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

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 encryptd.

=== 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.

Cryptosystem

2017-07-26T14:19:41Z

Motezazer: Thanks to SciresM for helping with writing this page

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 1 ==

=== Key generation ===

Bootloader stage 1 generates three keys: the stage 2 decryption key, stored in keyslot 0xB; the master static key, which will be used by stage 2 to generate all the static keys, stored in keyslot 0xC; and the master device key, which will be used by stage 2 to generate all the device-specific keys, stored in keyslot 0xD.
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 following table describes the keyblob format.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CMAC over the next 0xA0 bytes
|-
| 0x10
| 0x10
| CTR
|-
| 0x20
| 0x90
| Encrypted keydata
|}

Decrypted Keydata format:

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

32 of these 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).

==== Summary of key derivations ====

The device keyblob seed generation key is unique to each device and obtained from the Falcon. It is used to generate one or several of the keyblob key seeds by decrypting keybloob's seed constants. The keyblob key seeds are decrypted by the SBK to create the keyblob keys.
Each keyblob key is used to decrypt its associated keyblob's keydata, and the keyblob key for the first keyblob is additionally used to generate the master device key.
Each keyblob stores 8 master static key encryption keys, and the stage 2 bootloader decryption key. The master static key is generated by decrypting the master static key seed (one of two constants depending on retail or dev unit) with the master static key encryption key.

=== Step by step generation code ===

* 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.

==== 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 2 ==

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

== Secure world (TrustZone) software ==

The Secure world software performs all runtime cryptographic operations.

It is currently unknown what operations the Secure world software performs.