26
edits
Changes
Jump to navigation
Jump to search
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.
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.