Nintendo Switch Brew - User contributions [en]

Talk:Package2

2018-01-01T21:53:49Z

Nwert: Blanked the page

Package2

2018-01-01T21:53:02Z

Nwert:

Present in the firmware package titles (0100000000000819, 010000000000081A, 010000000000081B and 010000000000081C) and installed into eMMC storage's [[Flash_Filesystem#User_Partitions|BCPKG2 partitions]], "package2" contains the Switch kernel and the built-in system modules.

= Format =
Package2 is distributed in an already encrypted format. Therefore, it's not additionally encrypted when installed into the flash filesystem.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| [[#Public Keys|RSA-2048]] signature (PKCS#1 v2.1 RSASSA-PSS-VERIFY with SHA256)
|-
| 0x100
| 0x100
| Encrypted header
|-
| 0x200
| Variable
| Encrypted body
|}

== Encryption ==
Package2's contents are AES-CTR encrypted with a key known only by TrustZone.

The encrypted header's CTR is stored as it's first 0x10 bytes (offset 0x100).
The encrypted body is divided in up to 4 sections, each one with a CTR stored inside the decrypted header.

== Header ==
When decrypted, package2's header is as follows.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Decrypted header's CTR
|-
| 0x10
| 0x10
| Section 0 CTR
|-
| 0x20
| 0x10
| Section 1 CTR
|-
| 0x30
| 0x10
| Section 2 CTR
|-
| 0x40
| 0x10
| Section 3 CTR
|-
| 0x50
| 0x4
| Magic "PK21"
|-
| 0x54
| 0x4
| Unknown
|-
| 0x58
| 0x4
| Unknown
|-
| 0x5C
| 0x2
| Version. HighByte must be <{maxver} and LowByte must be >{minver}, where {maxver} and {minver} are constants used by TZ updated with each package1 update.
|-
| 0x5E
| 0x2
| ?
|-
| 0x60
| 0x4
| Section 0 size
|-
| 0x64
| 0x4
| Section 1 size
|-
| 0x68
| 0x4
| Section 2 size
|-
| 0x6C
| 0x4
| Section 3 size
|-
| 0x70
| 0x4
| Unknown
|-
| 0x74
| 0x4
| Unknown
|-
| 0x78
| 0x4
| Unknown
|-
| 0x7C
| 0x4
| Unknown
|-
| 0x80
| 0x20
| SHA-256 hash over encrypted section 0
|-
| 0xA0
| 0x20
| SHA-256 hash over encrypted section 1
|-
| 0xC0
| 0x20
| SHA-256 hash over encrypted section 2
|-
| 0xE0
| 0x20
| SHA-256 hash over encrypted section 3
|}

Each section follows each other immediately and is encrypted with the same key used for encrypting the header.

== Section 0 ==
When decrypted, this section contains the plaintext Switch kernel binary.

== Section 1 ==
When decrypted, this section contains the built-in system modules encapsulated in a custom format.

=== INI1 ===
{| class="wikitable" border="1"
|-
! Offset
! Type
! Description
|-
| 0x0
| u32
| Magic "INI1"
|-
| 0x4
| u32
| Size
|-
| 0x8
| u32
| NumberProcesses
|-
| 0xC
| u32
| Zero
|}

==== KIP1 ====
Kernel internal process?

{| class="wikitable" border="1"
|-
! Offset
! Type
! Description
|-
| 0x0
| u32
| Magic "KIP1"
|-
| 0x4
| char[12]
| Name
|-
| 0x10
| u64
| TitleId
|-
| 0x18
| u32
|
|-
| 0x1C
| u32
| Flags / etc. Byte3 bit0-2: compression-enable for each section, when set.
|-
| 0x20
| [[#SectionHeader]][3]
| Sections
|-
| 0x50
| char[0x20]
| Padding
|-
| 0x70
| u64[0x20]
| KernelCaps
|}

===== SectionHeader =====
{| class="wikitable" border="1"
|-
! Offset
! Type
! Description
|-
| 0x0
| u32
| OutOffset
|-
| 0x4
| u32
| DecompressedSize
|-
| 0x8
| u32
| CompressedSize
|-
| 0xC
| u32
|
|}

===== Compression =====
The compression used here is BLZ, with a modified footer since 3ds. The footer is now 0xC bytes instead of 0x8, and has the form u32 compressed_data_len; u32 initial_index; u32 additional_len_when_uncompressed;

== Section 2 ==
This section has a valid CTR and SHA-256 hash (over NULL) stored in the package2's header, but it's size is always 0. Likely reserved for future expansion.

== Section 3 ==
This section is not present (CTR and SHA-256 hash in package2's header are NULL). Likely reserved for future expansion.

= Versions =
{| class="wikitable" border="1"
|-
! System version
! Package1 maxver constant
! Package1 minver constant
! Package2 version field
|-
| [[2.0.0]]
| 0x3
| 0x4
|-
| [[4.1.0]]
| 0x6
| 0x7
|
|}

= Public Keys =

=== Exponent ===
0x10001

=== Retail Modulus ===
8D 13 A7 77 6A E5 DC C0 3B 25 D0 58 E4 20 69 59
55 4B AB 70 40 08 28 07 A8 A7 FD 0F 31 2E 11 FE
47 A0 F9 9D DF 80 DB 86 5A 27 89 CD 97 6C 85 C5
6C 39 7F 41 F2 FF 24 20 C3 95 A6 F7 9D 4A 45 74
8B 5D 28 8A C6 99 35 68 85 A5 64 32 80 9F D3 48
39 A2 1D 24 67 69 DF 75 AC 12 B5 BD C3 29 90 BE
37 E4 A0 80 9A BE 36 BF 1F 2C AB 2B AD F5 97 32
9A 42 9D 09 8B 08 F0 63 47 A3 E9 1B 36 D8 2D 8A
D7 E1 54 11 95 E4 45 88 69 8A 2B 35 CE D0 A5 0B
D5 5D AC DB AF 11 4D CA B8 1E E7 01 9E F4 46 A3
8A 94 6D 76 BD 8A C8 3B D2 31 58 0C 79 A8 26 E9
D1 79 9C CB D4 2B 6A 4F C6 CC CF 90 A7 B9 98 47
FD FA 4C 6C 6F 81 87 3B CA B8 50 F6 3E 39 5D 4D
97 3F 0F 35 39 53 FB FA CD AB A8 7A 62 9A 3F F2
09 27 96 3F 07 9A 91 F7 16 BF C6 3A 82 5A 4B CF
49 50 95 8C 55 80 7E 39 B1 48 05 1E 21 C7 24 4F

=== Debug Modulus ===
B3 65 54 FB 0A B0 1E 85 A7 F6 CF 91 8E BA 96 99
0D 8B 91 69 2A EE 01 20 4F 34 5C 2C 4F 4E 37 C7
F1 0B D4 CD A1 7F 93 F1 33 59 CE B1 E9 DD 26 E6
F3 BB 77 87 46 7A D6 4E 47 4A D1 41 B7 79 4A 38
06 6E CF 61 8F CD C1 40 0B FA 26 DC C0 34 51 83
D9 3B 11 54 3B 96 27 32 9A 95 BE 1E 68 11 50 A0
6B 10 A8 83 8B F5 FC BC 90 84 7A 5A 5C 43 52 E6
C8 26 E9 FE 06 A0 8B 53 0F AF 1E C4 1C 0B CF 50
1A A4 F3 5C FB F0 97 E4 DE 32 0A 9F E3 5A AA B7
44 7F 5C 33 60 B9 0F 22 2D 33 2A E9 69 79 31 42
8F E4 3A 13 8B E7 26 BD 08 87 6C A6 F2 73 F6 8E
A7 F2 FE FB 6C 28 66 0D BD D7 EB 42 A8 78 E6 B8
6B AE C7 A9 E2 40 6E 89 20 82 25 8E 3C 6A 60 D7
F3 56 8E EC 8D 51 8A 63 3C 04 78 23 0E 90 0C B4
E7 86 3B 4F 8E 13 09 47 32 0E 04 B8 4D 5B B0 46
71 B0 5C F4 AD 63 4F C5 E2 AC 1E C4 33 96 09 7B

Secure Monitor

2017-10-04T20:40:14Z

Nwert:

= Secure Monitor Calls =

The secure monitor provides two top level handlers of which each provides a range of sub handlers.

Secure Monitor Calls follow the ARM SMC calling convention up to a small change:
{| class=wikitable
! Bit number || Bit mask || Description
|-
| 31 || 0x80000000 || Set to 0 means Yielding Call; Set to 1 means Fast Call.
|-
| 30 || 0x40000000 || Set to 0 means SMC32 convention; Set to 1 means SMC64.
|-
| 29-24 || 0x3F000000 || Service Call ranges.
|-
| 23-16 || 0x00FF0000 || Must be zero.
|-
| 15-8 || 0x0000FF00 || Argument type. This is different from the ARM SMC calling convention.
|-
| 7-0 || 0x000000FF || Function number within the range call type.
|}

If bit ''n'' is set in the argument type then parameter X''n'' is treated as a pointer and the kernel will setup address translation for it in [[SVC#svcCallSecureMonitor|svcCallSecureMonitor]].

== Id 0 ==
Functions exposed to user-mode processes using [[SVC|svcCallSecureMonitor]].

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC3000401 || SetConfig || ||
|-
| 0xC3000002 || GetConfig (Same as Id 1 Sub-Id 4.) || ||
|-
| 0xC3000003 || CheckStatus || ||
|-
| 0xC3000404 || GetResult || ||
|-
| 0xC3000E05 || ExpMod || ||
|-
| 0xC3000006 || GetRandomBytes (Same as Id 1 Sub-Id 5.) || ||
|-
| 0xC3000007 || [[#GenerateAesKek]] || ||
|-
| 0xC3000008 || [[#LoadAesKey]] || ||
|-
| 0xC3000009 || [[#CryptAes]] || ||
|-
| 0xC300000A || [[#GenerateSpecificAesKey]] || ||
|-
| 0xC300040B || [[#ComputeCmac]] || ||
|-
| 0xC300100C || [[#LoadRsaPrivateKey]] || ||
|-
| 0xC300100D || [[#PrivateRsa]] || ||
|-
| 0xC300100E || [[#LoadRsaPublicKey]] || ||
|-
| 0xC300060F || [[#PublicRsa]] || ||
|-
| 0xC3000610 || [[#UnwrapRsaEncryptedAesKey]] || ||
|-
| 0xC3000011 || [[#LoadRsaWrappedAesKey]] || ||
|-
| 0xC3000012 || [2.0.0+] GenerateRsaKek || ||
|}

=== GenerateAesKek ===
Takes an "access key" as input, an [[#CryptoUsecase]].

Returns a session-unique kek for said usecase.

=== LoadAesKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped AES key.

The session kek must have been created with CryptoUsecase_Aes.

=== CryptAes ===
Encrypts/decrypts using Aes (CTR and CBC).

Key must be set prior using one of the [[#LoadAesKey]], [[#GenerateSpecificAesKey]] or [[#LoadRsaWrappedAesKey]] commands.

=== GenerateSpecificAesKey ===
Todo: This one seems unrelated to [[#CryptoUsecase]].

=== LoadRsaPrivateKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped RSA private key.

The session kek must have been created with CryptoUsecase_PrivateRsa.

=== PrivateRsa ===
Encrypts using Rsa private key.

Key must be set prior using the [[#LoadRsaPrivateKey]] command.

=== LoadRsaPublicKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped RSA public key.

The session kek must have been created with CryptoUsecase_PublicRsa.

=== PublicRsa ===
Encrypts using Rsa public key.

Key must be set prior using the [[#LoadRsaPublicKey]] command.

=== UnwrapRsaEncryptedAesKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped RSA public key.

Returns a session-unique AES key especially for use in [[#LoadRsaWrappedAesKey]].

The session kek must have been created with CryptoUsecase_RsaWrappedAesKey.

=== LoadRsaWrappedAesKey ===
Takes a session-unique AES key from [[#UnwrapRsaEncryptedAesKey]].

=== enum CryptoUsecase ===
{| class=wikitable
! Value || Name
|-
| 0 || CryptoUsecase_Aes
|-
| 1 || CryptoUsecase_PrivateRsa
|-
| 2 || CryptoUsecase_PublicRsa
|-
| 3 || CryptoUsecase_RsaWrappedAesKey
|}

== Id 1 ==
Functions exposed to the kernel internally.

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC4000001 || CpuSuspend (oyasumi) || ||
|-
| 0x84000002 || CpuOff || ||
|-
| 0xC4000003 || CpuOn || ||
|-
| 0xC3000004 || GetConfig (Same as Id 0 Sub-Id 2.) || ||
|-
| 0xC3000005 || GetRandomBytes (Same as Id 0 Sub-Id 6.) || ||
|-
| 0xC3000006 || Panic || ||
|-
| 0xC3000007 || [2.0.0+] ProtectKernelRegion || ||
|-
| 0xC3000008 || [2.0.0+] ReadWriteRegister || ||
|}

Secure Monitor

2017-10-04T20:34:57Z

Nwert:

= Secure Monitor Calls =

The secure monitor provides two top level handlers of which each provides a range of sub handlers.

Secure Monitor Calls follow the ARM SMC calling convention up to a small change:
{| class=wikitable
! Bit number || Bit mask || Description
|-
| 31 || 0x80000000 || Set to 0 means Yielding Call; Set to 1 means Fast Call.
|-
| 30 || 0x40000000 || Set to 0 means SMC32 convention; Set to 1 means SMC64.
|-
| 29-24 || 0x3F000000 || Service Call ranges.
|-
| 23-16 || 0x00FF0000 || Must be zero.
|-
| 15-8 || 0x0000FF00 || Argument type. This is different from the ARM SMC calling convention.
|-
| 7-0 || 0x000000FF || Function number within the range call type.
|}

If bit ''n'' is set in the argument type then parameter X''n'' is treated as a pointer and the kernel will setup address translation for it in [[SVC#svcCallSecureMonitor|svcCallSecureMonitor]].

== Id 0 ==
Functions exposed to user-mode processes using [[SVC|svcCallSecureMonitor]].

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC3000401 || SetConfig || ||
|-
| 0xC3000002 || GetConfig (Same as Id 1 Sub-Id 4.) || ||
|-
| 0xC3000003 || CheckStatus || ||
|-
| 0xC3000404 || GetResult || ||
|-
| 0xC3000E05 || ExpMod || ||
|-
| 0xC3000006 || GetRandomBytes (Same as Id 1 Sub-Id 5.) || ||
|-
| 0xC3000007 || [[#GenerateAesKek]] || ||
|-
| 0xC3000008 || [[#LoadAesKey]] || ||
|-
| 0xC3000009 || [[#DecryptAes]] || ||
|-
| 0xC300000A || [[#GenerateSpecificAesKey]] || ||
|-
| 0xC300040B || [[#ComputeCmac]] || ||
|-
| 0xC300100C || [[#LoadRsaPrivateKey]] || ||
|-
| 0xC300100D || [[#PrivateRsa]] || ||
|-
| 0xC300100E || [[#LoadRsaPublicKey]] || ||
|-
| 0xC300060F || [[#PublicRsa]] || ||
|-
| 0xC3000610 || [[#UnwrapRsaEncryptedAesKey]] || ||
|-
| 0xC3000011 || [[#LoadRsaWrappedAesKey]] || ||
|-
| 0xC3000012 || [2.0.0+] GenerateRsaKek || ||
|}

=== GenerateAesKek ===
Takes an "access key" as input, an [[#CryptoUsecase]].

Returns a session-unique kek for said usecase.

=== LoadAesKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped AES key.

The session kek must have been created with CryptoUsecase_Aes.

=== DecryptAes ===
Encrypts/decrypts using Aes (CTR, CBC-Encrypt, CBC-Decrypt).

Key must be set prior using one of the [[#LoadAesKey]], [[#GenerateSpecificAesKey]] or [[#LoadRsaWrappedAesKey]] commands.

=== GenerateSpecificAesKey ===
Todo: This one seems unrelated to [[#CryptoUsecase]].

=== LoadRsaPrivateKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped RSA private key.

The session kek must have been created with CryptoUsecase_PrivateRsa.

=== PrivateRsa ===
Encrypts using Rsa private key.

Key must be set prior using the [[#LoadRsaPrivateKey]] command.

=== LoadRsaPublicKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped RSA public key.

The session kek must have been created with CryptoUsecase_PublicRsa.

=== PublicRsa ===
Encrypts using Rsa public key.

Key must be set prior using the [[#LoadRsaPublicKey]] command.

=== UnwrapRsaEncryptedAesKey ===
Takes a session kek created with [[#GenerateAesKek]], and a wrapped RSA public key.

Returns a session-unique AES key especially for use in [[#LoadRsaWrappedAesKey]].

The session kek must have been created with CryptoUsecase_RsaWrappedAesKey.

=== LoadRsaWrappedAesKey ===
Takes a session-unique AES key from [[#UnwrapRsaEncryptedAesKey]].

=== enum CryptoUsecase ===
{| class=wikitable
! Value || Name
|-
| 0 || CryptoUsecase_Aes
|-
| 1 || CryptoUsecase_PrivateRsa
|-
| 2 || CryptoUsecase_PublicRsa
|-
| 3 || CryptoUsecase_RsaWrappedAesKey
|}

== Id 1 ==
Functions exposed to the kernel internally.

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC4000001 || CpuSuspend (oyasumi) || ||
|-
| 0x84000002 || CpuOff || ||
|-
| 0xC4000003 || CpuOn || ||
|-
| 0xC3000004 || GetConfig (Same as Id 0 Sub-Id 2.) || ||
|-
| 0xC3000005 || GetRandomBytes (Same as Id 0 Sub-Id 6.) || ||
|-
| 0xC3000006 || Panic || ||
|-
| 0xC3000007 || [2.0.0+] ProtectKernelRegion || ||
|-
| 0xC3000008 || [2.0.0+] ReadWriteRegister || ||
|}

Flog

2017-09-17T19:55:30Z

Nwert:

This is the system "flog" 01008BB00013C000 [[Title_list|title]]. This is a NES emulator. Installed on retail systems since [[1.0.0]].

The titleID for "flog" is used by 3 funcs in [[qlaunch]]. It's unknown what exactly triggers launching this title officially. This can be run with unofficial methods.

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

[[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.]]

Factory Setup

2017-09-01T03:15:16Z

Nwert:

== Setup Process ==

At the factory, a minimal version of the Switch OS is installed. A modified version of the [[boot2]] title (boot2.manuBoot) is installed that launches an additional "[[Manu Services|Manu]]" sysmodule, and the system config title specifies to launch "Test Application Launcher" instead of qlaunch.

Test Application Launcher is used to launch a number of tests, "CAL0" calibration data is written to NAND, and retail firmware is installed.

== Titles ==

=== Overview ===

Factory firmware contains a stripped down version of the Switch's OS with unnecessary titles removed, and a number of additional debug titles installed.

[[File:TestApplicationLauncher.jpg|400px|thumb|right|TestApplicationLauncher running on a console.]]

==== Removed Titles ====

* The following system data archive titles are present in retail firmware, but not installed at the factory: 0100000000000801, 0100000000000803, 0100000000000804, 0100000000000805, 0100000000000808, 010000000000080A, 010000000000080B, 010000000000080C, 010000000000080D, 010000000000081A, 010000000000081B, 010000000000081E.

* Every System Applet "10XX" title is not installed.

* 01008BB00013C000 ("flog") is not installed.

==== Factory-Only Titles ====

{| class="wikitable" border="1"
|-
! Title ID
! Name
! Description
|-
| 0100000000002000
| "BoardTest"
|
|-
| 0100000000002001
| ?
| Probably Battery Vendor related.
|-
| 0100000000002002
| C1LcdAndKey
| LCD/Keyboard testing.
|-
| 0100000000002003
| C2UsbHpmic
| USB testing.
|-
| 0100000000002004
| C3Aging
| Graphics/Framerate testing.
|-
| 0100000000002005
| C4SixAxis
| Sixaxis (controller peripheral) testing.
|-
| 0100000000002006
| C5Wireless
| Wireless testing.
|-
| 010000000000204E
| A4BoardCalWriti
| Writes calibration data to NAND.
|-
| 010000000000209C
| TestApplication
| "Test Application Launcher", factory qlaunch replacement. Used to launch other tests.
|-
| 010000000000B14A
| [[Manu Services|Manu]]
| Manufacturing sysmodule.
|-
| 1000000000000001
| SystemInitializ
| Initial system installer (used to write/verify console specific ''calibration'' data such as asymmetric keys and write/verify NAND partitions from an initial installation image).
|-
| 1000000000000004
| ?
| ?
|-
|}

Switch System Flaws

2017-08-17T20:05:05Z

Nwert:

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
! Discovered by
|-
| No public hardware exploits
|
|
|
|
|
|-
|}

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

=== 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
|-
| No public ARM TrustZone exploits
|
|
|
|
|
|
|
|-
|}

=== 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
|-
| No public Kernel exploits
|
|
|
|
|
|
|
|-
|}

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

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

Cryptosystem

2017-07-26T21:55:41Z

Nwert:

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

== BootROM ==

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

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

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

== Bootloader stage 0 ==

=== Key generation ===

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

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

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

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

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

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

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

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

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

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

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

== Bootloader stage 1 ==

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

== Secure Monitor ==

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

Package1

2017-07-26T21:46:45Z

Nwert:

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. If too little are set, the bootloader will program the expected bitmap and force a reset. The fuse array and the expected number of burnt fuses is different on unit type 0 (non-retail) and unit type 1 (retail).

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

==== Panic ====

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

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

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

==== Main method ====

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

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

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

==== Secondary method ====

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

== Stage 2 (package1.1) ==

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

=== Header format ===

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

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

Memory layout

2017-07-25T21:07:33Z

Nwert:

= Userspace =
The userspace virtual address space has 38 bits. It seems that when the IPC protocol was designed, it was only 36 bits leading to a weird encoding format.

There are several regions maintained by the kernel, each one starting at the upper bits bit37-21 randomized:
* Main binary region.
* Heap region.
* Stack mapping region, available from [[SVC#svcGetInfo]].

For the stack mapping region, the userland randomizes a page-offset where to start inside the region.
This adds some additional entropy.

Binaries mapped by RO seems to be mapped randomly everywhere in the entire address space. The random base address for each NRO has bits 37-12 randomized, unlike the main binary region.

For all binaries(main area / NROs), the R-- section is always located immediately after R-X. The RW- section is always located immediately after the R-- section. Hence, there's no extra randomization / guard-pages for these sections.

On version [[1.0.0]], the initial binaries loaded into memory by the kernel always have the upper 32-bits as all-zero, so there are 6 fewer bits of layout randomization.

==TLS==
This is the 0x200-byte thread-local-storage, the base address is loaded via ARM threadid register tpidrro_el0.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| [[IPC_Marshalling|IPC]] command buffer
|-
| 0x100
| 0xF8
| ?
|-
| 0x1F8
| 0x8
| Address of threadctx+0x58.
|}

==Thread context==
This is the structure of the 0x228-byte threadctx used by official userland software.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0xA8
| ?
|-
| 0xA8
| 0x8
| Address of the stack-bottom-mirror which the thread was created with.
|-
| 0xB0
| 0x8
| Size of the stack.
|-
| 0xB8
| 0x178
| ?
|}

= Kernel =
Granule size for TTBR0*_EL1 is 4KB.
TTBR0_EL1 vmem starts at vaddr 0x0.
vmem end-addr for TTBR1_EL1 is 0xffffffffffffffff. vmem start-addr for TTBR1_EL1 is 0xFFFFFFF000000000.
T0SZ = 31. Hence, bit-size of the TTBR0*_EL1 vmem region is 33. (0x0000000200000000)
T1SZ = 28. Hence, bit-size of the TTBR1*_EL1 vmem region is 36. (0x0000001000000000)

Note: ARM config for TTBR0 is presumably configured for userland later.

See arm-doc for "Table D4-25 Translation table entry addresses when using the 4KB translation granule".

See arm-doc for "Overview of VMSAv8-64 address translation using the 4KB translation granule".

See arm-doc for "Table D4-11 TCR.TnSZ values and IA ranges, 4K granule with no concatenation of tables".
Both TTBR*_EL1 use "Initial lookup level" 1. Therefore, the TTBR*_EL1 tables are level1.

Due to T*SZ, Stage1/Stage2 translation for the initial table(level1) are the same, except Stage2 uses hard-coded T0SZ.
Basically, the table is accessed as: ((u64*)tablebase)[<IA[y:30]>], where y = (37-T*SZ)+26. That is, starting at bit "y" ending(inclusive) at bit30. For TTBR0*_EL1, y = 32, while for TTBR1_EL1 y = 35.
Hence, for TTBR0, index=((vaddr>>30) & 0x7), and for TTBR1, index=((vaddr>>30) & 0x3f).

As of [[2.0.0]] KASLR is not used.

== [[2.0.0]] ==

"Vector Base Address Register (EL1)" = 0xfffffff7ffc50800.

The table for TTBR0 only contains the following:
* Vmem 0x80000000 is mapped to physmem 0x80000000, using a size loaded from a register. This is only done when: "endaddr = 0x7fffffff + size; if(endaddr >= 0x80000001){...}"
** The size is loaded from: "(u32 *0x70019050 & 0x3fff) << 20;"
** The value written to the MMU-table descriptor is: "physaddr | val | 0x709;". val is 1<<52 when "tmp>>34" is non-zero and when "if((physaddr & 0x3c0000000) == 0)", otherwise val=0. tmp=size at the start and increased by 0xffffffffc0000000 each loop iteration. physaddr is increased by 0x40000000 each loop iteration.

TTBR1:
* vmem 0xFFFFFFF800000000 is mapped to physmem 0x80000000. Similar to above, except tmp=0 due to wrap-around, etc. The chunksize used when increasing addr is 0xfffffff840000000, with another +=0x40000000 separate from the addr cmp for the loop.
** "endaddr = 0x3fffffff + (<size from above> | 0xfffffff800000000); enaddr = (endaddr & 0xffffffffc0000000)-1; if(endaddr >= 0xfffffff800000001){<map mem>}"

* Initializes level2 pagetable descriptor for vmem 0xFFFFFFF7C0000000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFC00000. descriptor = 0x3 | physaddr. physaddr is core-specific.
* The content of the pagetable for the following level3 mmutables are not initialized in the main mmutable-init func. descriptor = 0x8007c003(0x3 | <physaddr tablebase>). tablebase=0x8007c000.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEE00000. physaddr = tablebase + (0x1<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF000000. physaddr = tablebase + (0x2<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF200000. physaddr = tablebase + (0x3<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FFA00000. physaddr = tablebase + (0x7<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FEC00000. physaddr = tablebase.
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF400000. physaddr = tablebase + (0x4<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF600000. physaddr = tablebase + (0x5<<12).
** Initializes level3 pagetable descriptor for vmem 0xFFFFFFF7FF800000. physaddr = tablebase + (0x6<<12).

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0xFFFFFFF7FFC00000..0xFFFFFFF7FFC62000 (inclusive)
| 0x800A0000
| 0x63000
| 0x78B
|
| Kernel .text
|-
| 0xFFFFFFF7FFC63000..0xFFFFFFF7FFC65000 (inclusive)
| 0x80103000
| 0x3000
| 0x6000000000078B
|
| Kernel .rodata
|-
| 0xFFFFFFF7FFC66000..0xFFFFFFF7FFC6E000 (inclusive)
| 0x80106000
| 0x9000
| 0x6000000000070B
|
| Kernel .data/...
|}

The following uses descriptor ORR-value 0x6000000000070B, the size of each one is 0x1000-bytes.
{| class="wikitable" border="1"
|-
! Vmem
! Physmem
|-
| 0xFFFFFFF7FFDCA000 || 0x80060000
|-
| 0xFFFFFFF7FFDCB000 || 0x80061000
|-
| 0xFFFFFFF7FFDCE000 || 0x80068000
|-
| 0xFFFFFFF7FFDD4000 || 0x80062000
|-
| 0xFFFFFFF7FFDD5000 || 0x80063000
|-
| 0xFFFFFFF7FFDD8000 || 0x8006A000
|-
| 0xFFFFFFF7FFDD9000 || 0x8006B000
|-
| 0xFFFFFFF7FFDDE000 || 0x80064000
|-
| 0xFFFFFFF7FFDDF000 || 0x80065000
|-
| 0xFFFFFFF7FFDE2000 || 0x8006C000
|-
| 0xFFFFFFF7FFDE3000 || 0x8006D000
|-
| 0xFFFFFFF7FFDE8000 || 0x80066000
|-
| 0xFFFFFFF7FFDE9000 || 0x80067000
|-
| 0xFFFFFFF7FFDCF000 || 0x80069000
|-
| 0xFFFFFFF7FFDEC000 || 0x8006E000
|-
| 0xFFFFFFF7FFDED000 || 0x8006F000
|-
| 0xFFFFFFF7FFDD2000 || 0x80070000
|-
| 0xFFFFFFF7FFDDC000 || 0x80071000
|-
| 0xFFFFFFF7FFDE6000 || 0x80072000
|-
| 0xFFFFFFF7FFDF0000 || 0x80073000
|}

The following uses descriptor ORR-value 0x60000000000607, the size of each one is 0x1000-bytes.
{| class="wikitable" border="1"
|-
! Vmem
! Physmem
|-
| 0xFFFFFFF7FFDC6000
| 0x70019000
|-
| 0xFFFFFFF7FFDC4000
| 0x7001C000
|-
| 0xFFFFFFF7FFDC2000
| 0x7001D000
|-
| 0xFFFFFFF7FFDC0000
| 0x60006000
|-
| 0xFFFFFFF7FFDC8000
| 0x70006000
|-
| 0xFFFFFFF7FFDFB000
| 0x50041000
|-
| 0xFFFFFFF7FFDFD000
| 0x50042000
|}

The rest are are mapped to core-specific physaddrs, each one is 0x1000-bytes. Descriptor ORR-value = 0x6000000000070B.

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
|-
| 0xFFFFFFF7FFDF7000
| <physaddr from vmem 0xFFFFFFF7FFDF6000> + 0x1000
|-
| 0xFFFFFFF7FFDF3000
| <physaddr from vmem 0xFFFFFFF7FFDF2000> + 0x1000
|-
| 0xFFFFFFF7FFDF6000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF2000
| 0x800XX000
|-
| 0xFFFFFFF7FFDFF000
| 0x800XX000
|-
| 0xFFFFFFF7FFDF9000
| 0x800XX000
|}

= Secure Monitor =

== [[2.0.0]] ==

{| class="wikitable" border="1"
|-
! Vmem
! Physmem
! Size
! Descriptor ORR-value
! Permissions
! Description
|-
| 0x7C010000
| 0x7C010000
| 0x10000
| 0x300
|
| TZRAM
|-
| 0x40020000
| 0x40020000
| 0x20000
| 0x300
|
| iRAM-C
|-
| 0x1F0080000
| 0x50041000
| 0x1000
| 0x40000000000304
|
| ARM Interrupt Distributor
|-
| 0x1F0082000
| 0x50042000
| 0x2000
| 0x40000000000304
|
| Interrupt Controller Physical CPU interface
|-
| 0x1F0085000
| 0x70006000
| 0x1000
| 0x40000000000324
|
| UART-A
|-
| 0x1F0087000
| 0x60006000
| 0x1000
| 0x40000000000324
|
| Clock and Reset
|-
| 0x1F0089000
| 0x7000E000
| 0x1000
| 0x40000000000304
|
| RTC
|-
| 0x1F008B000
| 0x60005000
| 0x1000
| 0x40000000000304
|
| TMR
|-
| 0x1F008D000
| 0x6000C000
| 0x1000
| 0x40000000000304
|
| System Registers
|-
| 0x1F008F000
| 0x70012000
| 0x2000
| 0x40000000000304
|
| SE
|-
| 0x1F0092000
| 0x700F0000
| 0x1000
| 0x40000000000304
|
| SYSCTR0
|-
| 0x1F0094000
| 0x70019000
| 0x1000
| 0x40000000000304
|
| MC
|-
| 0x1F0096000
| 0x7000F000
| 0x1000
| 0x40000000000304
|
| FUSE (0x7000F800)
|-
| 0x1F0098000
| 0x70000000
| 0x4000
| 0x40000000000304
|
| MISC
|-
| 0x1F009D000
| 0x60007000
| 0x1000
| 0x40000000000304
|
| Flow Controller
|-
| 0x1F009F000
| 0x40002000
| 0x1000
| 0x40000000000304
|
| iRAM-A
|-
| 0x1F00A1000
| 0x7000D000
| 0x1000
| 0x40000000000304
|
| I2C5 - SPI 2B-6
|-
| 0x1F00A3000
| 0x6000D000
| 0x1000
| 0x40000000000304
|
| GPIO-1 - GPIO-8
|-
| 0x1F00A5000
| 0x7000C000
| 0x1000
| 0x40000000000304
|
| I2C-I2C4
|-
| 0x1F00A7000
| 0x6000F000
| 0x1000
| 0x40000000000304
|
| Exception vectors
|-
| 0x1F0180000
| 0x40020000
| 0x10000
| 0x40000000000324
|
| iRAM-C
|-
| 0x1F0190000
| 0x40003000
| 0x1000
| 0x40000000000324
|
| iRAM-A
|-
| 0x1F01A0000
| 0x7C010000
| 0x10000
| 0x40000000000380
|
| TZRAM
|-
| 0x1F01C3000
| 0x80010000
| 0x10000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01C2000
| 0x8000F000
| 0x1000
| 0x40000000000324
|
| EMEM
|-
| 0x1F01E0000
| 0x7C013000
| 0xB000
| 0x300
|
| TZRAM (Secure Monitor)
|-
| 0x1F01F0000
| 0x7C01E000
| 0x2000
| 0x300
|
| TZRAM (Secure Monitor init)
|-
| 0x1F01F6000
| 0x7C01E000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01F8000
| 0x7C01F000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FA000
| 0x7C010000
| 0x1000
| 0x300
|
| TZRAM (Secure Monitor exception vectors)
|-
| 0x1F01FC000
| 0x7C011000
| 0x1000
| 0x40000000000300
|
| TZRAM
|-
| 0x1F01FE000
| 0x7C012000
| 0x1000
| 0x40000000000300
|
| TZRAM
|}

SPL services

2017-07-18T23:08:31Z

Nwert:

= spl: =
{| class="wikitable" border="1"
|-
! Cmd || Name || Notes
|-
| 0 || [[#GetConfig]] || wrapper for [[SMC#GetConfig|GetConfig]]
|-
| 1 || ExpMod || user supplied modulus and exponent
|-
| 2 || [[#KeygenAndSealX]] || wrapper for [[SMC#KeygenAndSealX|KeygenAndSealX]]
|-
| 3 || SetKeyslotFromXY || wrapper for [[SMC#SetKeyslotFromXY|SetKeyslotFromXY]]
|-
| 4 || DecryptAESECBWithX || decrypts 0x10 bytes using AES ECB, uses [[SMC#SetKeyslotFromXY|SetKeyslotFromXY]] with a fixed Y
|-
| 5 || [[#SetConfig]] || wrapper for [[SMC#SetConfig|SetConfig]]
|-
| 7 || Prng || uses [[SMC#PrngX931|PrngX931]]
|-
| 9 || ImportExpModParams || wrapper for [[SMC#ImportParamsForFWithXY|ImportParamsForFWithXY]]
|-
| 10 || ExpMod || wrapper for [[SMC#ExpMod|ExpMod]]
|-
| 11 || [[#IsDevUnit]] || uses [[SMC#GetConfig|GetConfig]]
|-
| 12 || KeygenA || wrapper for [[SMC#KeygenA|KeygenA]]
|-
| 13 || [[#DecryptExpModParamsWithXY]] || wrapper for [[SMC#DecryptExpModParamsWithXY|DecryptExpModParamsWithXY]]
|-
| 14 || DecryptAESECB || decrypts 0x10 bytes using AES ECB, uses [[SMC#SetKeyslotFromXY|SetKeyslotFromXY]] with fixed X and Y
|-
| 15 || SymmetricCrypto || wrapper for [[SMC#SymmetricCrypto|SymmetricCrypto]]
|-
| 16 || CMAC || wrapper for [[SMC#CMAC|CMAC]]
|-
| 17 || ImportExpModParams || wrapper for [[SMC#ImportParamsFor10WithXY|ImportParamsFor10WithXY]]
|-
| 18 || ExpModAndKeygenAndSealZ || wrapper for [[SMC#ExpModAndKeygenAndSealZ|ExpModAndKeygenAndSealZ]]
|-
| 19 || SetKeyslotFromZ || wrapper for [[SMC#SetKeyslotFromZ|SetKeyslotFromZ]]
|-
| 20 || KeygenAndSealZ || wrapper for [[SMC#KeygenAndSealZ|KeygenAndSealZ]]
|-
| 21 || ||
|-
| 22 || ||
|-
| 23 || GetSplWaitEvent ||
|}

== GetConfig ==
Takes an input word (ConfigItem), and returns a u64 with the config params.

{| class="wikitable" border="1"
|-
! ConfigItem || Name
|-
| 1 || DisableProgramVerification
|-
| 2 || MemoryConfiguration
|-
| 5 || HardwareType (0=Icosa, 1=Copper)
|-
| 7 || IsRecoveryBoot
|-
| 8 || DeviceId (byte7 clear).
|-
| 9 || BootReason
|-
| 10 || MemoryArrange
|-
| 11 || AllowSkippingNrrSignatures
|-
| 13 || BatteryProfile?
|}

Output from this when used by [[NIM_services|NIM]] must match the [[Settings_services|set:cal]] DeviceId with byte7 cleared, otherwise NIM will panic.

[[Loader services|RO]] checks id11, if set then skipping NRR rsa signatures is allowed.

== KeygenAndSealX ==
Takes 16-bytes as input and two u32s. Outputs random-looking 16-bytes.

Same input gives same output. Output changes when system is rebooted.

== SetConfig ==
Takes two input words, a ConfigItem and the value to set.

{| class="wikitable" border="1"
|-
! ConfigItem || Name
|-
| 13 || Battery profile?
|}

== IsDevUnit ==
No input params.

Returns an u8 flag for whether the system is devunit. Output flag is 0 on retail.

== DecryptExpModParamsWithXY ==
Last SPL cmd used by [[SSL_services|SSL]]-sysmodule for TLS client-privk.

SPL services

2017-07-18T20:46:07Z

Nwert:

= spl: =
{| class="wikitable" border="1"
|-
! Cmd || Name || Notes
|-
| 0 || [[#GetConfig]] || wrapper for [[SMC#GetConfig|GetConfig]]
|-
| 1 || ExpMod || user supplied modulus and exponent
|-
| 2 || [[#KeygenAndSealX]] || wrapper for [[SMC#KeygenAndSealX|KeygenAndSealX]]
|-
| 3 || SetKeyslotFromXY || wrapper for [[SMC#SetKeyslotFromXY|SetKeyslotFromXY]]
|-
| 4 || DecryptAESCBCWithX || decrypts 16 bytes, uses [[SMC#SetKeyslotFromXY|SetKeyslotFromXY]] with a fixed Y and a fixed CBC IV
|-
| 5 || [[#SetConfig]] || wrapper for [[SMC#SetConfig|SetConfig]]
|-
| 7 || Prng || uses [[SMC#PrngX931|PrngX931]]
|-
| 9 || ImportExpModParams || wrapper for [[SMC#ImportParamsForFWithXY|ImportParamsForFWithXY]]
|-
| 10 || ExpMod || wrapper for [[SMC#ExpMod|ExpMod]]
|-
| 11 || [[#GetDevunitFlag]] || uses [[SMC#GetConfig|GetConfig]]
|-
| 12 || KeygenA || wrapper for [[SMC#KeygenA|KeygenA]]
|-
| 13 || [[#DecryptExpModParamsWithXY]] || wrapper for [[SMC#DecryptExpModParamsWithXY|DecryptExpModParamsWithXY]]
|-
| 14 || DecryptAESCBC || decrypts 16 bytes, uses [[SMC#SetKeyslotFromXY|SetKeyslotFromXY]] with fixed X, Y and a fixed CBC IV
|-
| 15 || SymmetricCrypto || wrapper for [[SMC#SymmetricCrypto|SymmetricCrypto]]
|-
| 16 || CMAC || wrapper for [[SMC#CMAC|CMAC]]
|-
| 17 || ImportExpModParams || wrapper for [[SMC#ImportParamsFor10WithXY|ImportParamsFor10WithXY]]
|-
| 18 || ExpModAndKeygenAndSealZ || wrapper for [[SMC#ExpModAndKeygenAndSealZ|ExpModAndKeygenAndSealZ]]
|-
| 19 || SetKeyslotFromZ || wrapper for [[SMC#SetKeyslotFromZ|SetKeyslotFromZ]]
|-
| 20 || KeygenAndSealZ || wrapper for [[SMC#KeygenAndSealZ|KeygenAndSealZ]]
|-
| 21 || ||
|-
| 22 || ||
|-
| 23 || GetSplWaitEvent ||
|}

== GetConfig ==
Takes an input word (ConfigItem), and returns a u64 with the config params.

{| class="wikitable" border="1"
|-
! ConfigItem || Name
|-
| 2 || MemoryConfiguration
|-
| 5 || HardwareType (0=Icosa, 1=Copper)
|-
| 7 || IsRecoveryBoot
|-
| 8 || DeviceId (byte7 clear).
|-
| 9 || BootReason
|-
| 11 || AllowSkippingNrrSignatures
|-
| 13 || BatteryProfile?
|}

Output from this when used by [[NIM_services|NIM]] must match the [[Settings_services|set:cal]] DeviceId with byte7 cleared, otherwise NIM will panic.

[[Loader services|RO]] checks id11, if set then skipping NRR rsa signatures is allowed.

== KeygenAndSealX ==
Takes 16-bytes as input and two u32s. Outputs random-looking 16-bytes.

Same input gives same output. Output changes when system is rebooted.

== SetConfig ==
Takes two input words, a ConfigItem and the value to set.

{| class="wikitable" border="1"
|-
! ConfigItem || Name
|-
| 13 || Battery profile?
|}

== GetDevunitFlag ==
No input params.

Returns an u8 flag for whether the system is devunit. Output flag is 0 on retail.

== DecryptExpModParamsWithXY ==
Last SPL cmd used by [[SSL_services|SSL]]-sysmodule for TLS client-privk.

Secure Monitor

2017-07-12T22:28:21Z

Nwert:

Secure Monitor

2017-07-12T02:16:36Z

Nwert:

Secure Monitor

2017-07-11T23:51:13Z

Nwert:

Secure Monitor

2017-07-11T09:26:36Z

Nwert:

Secure Monitor

2017-07-11T00:40:24Z

Nwert:

Secure Monitor

2017-07-10T08:53:14Z

Nwert:

= Secure Monitor Calls =

The secure monitor provides two top level handlers of which each provides a range of sub handlers.

== Id 0 ==

Cryptography related functions.

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC3000401 || || ||
|-
| 0xC3000002 || (Same as Id 1 Sub-Id 4.) || ||
|-
| 0xC3000003 || || ||
|-
| 0xC3000404 || || ||
|-
| 0xC3000E05 || || ||
|-
| 0xC3000006 || || ||
|-
| 0xC3000007 || || ||
|-
| 0xC3000008 || || ||
|-
| 0xC3000009 || || ||
|-
| 0xC300000A || || ||
|-
| 0xC300040B || || ||
|-
| 0xC300100C || || ||
|-
| 0xC300100D || || ||
|-
| 0xC300100E || || ||
|-
| 0xC300060F || || ||
|-
| 0xC3000610 || || ||
|-
| 0xC3000011 || || ||
|-
| 0xC3000012 || || ||
|}

== Id 1 ==

General and power related functions.

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC4000001 || oyasumi || ||
|-
| 0x84000002 || || ||
|-
| 0xC4000003 || || ||
|-
| 0xC3000004 || (Same as Id 0 Sub-Id 2.) || ||
|-
| 0xC3000005 || || ||
|-
| 0xC3000006 || || ||
|-
| 0xC3000007 || || ||
|-
| 0xC3000008 || || ||
|}

Secure Monitor

2017-07-10T03:02:17Z

Nwert: Created page with "= Secure Monitor Calls = The secure monitor provides two top level handlers of which each provides a range of sub handlers. == Id 0 == {| class=wikitable ! Sub-Id || Name |..."

= Secure Monitor Calls =

The secure monitor provides two top level handlers of which each provides a range of sub handlers.

== Id 0 ==

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC3000401 || || ||
|-
| 0xC3000002 || (Same as Id 1 Sub-Id 4.) || ||
|-
| 0xC3000003 || || ||
|-
| 0xC3000404 || || ||
|-
| 0xC3000E05 || || ||
|-
| 0xC3000006 || || ||
|-
| 0xC3000007 || || ||
|-
| 0xC3000008 || || ||
|-
| 0xC3000009 || || ||
|-
| 0xC300000A || || ||
|-
| 0xC300040B || || ||
|-
| 0xC300100C || || ||
|-
| 0xC300100D || || ||
|-
| 0xC300100E || || ||
|-
| 0xC300060F || || ||
|-
| 0xC3000610 || || ||
|-
| 0xC3000011 || || ||
|-
| 0xC3000012 || || ||
|}

== Id 1 ==

{| class=wikitable
! Sub-Id || Name || In || Out
|-
| 0xC4000001 || || ||
|-
| 0x84000002 || || ||
|-
| 0xC4000003 || || ||
|-
| 0xC3000004 || (Same as Id 0 Sub-Id 2.) || ||
|-
| 0xC3000005 || || ||
|-
| 0xC3000006 || || ||
|-
| 0xC3000007 || || ||
|-
| 0xC3000008 || || ||
|}