Difference between revisions of "boot2"

From Rare Gaming Dump
(Created page with "Also known as the NAND. The Wii contains 512 MiB of NAND flash storage, which is used to store "system software", channels (including Virtual Console titles), game saves, and...")
 
m
 
(23 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Also known as the NAND.
+
{{DISPLAYTITLE: boot2}}
  
The Wii contains 512 MiB of NAND flash storage, which is used to store "system software", channels (including Virtual Console titles), game saves, and system settings.
+
<span style="background: #F1EBEB; border: 2px #CACACA solid; padding: 2px 1px 2px 4px;">
 +
[[File:Wii.png |30px]] This topic has a Wiibrew article. For more information, check [http://wiibrew.org/wiki/boot2 here].</span>
  
Physical layout:
+
'''boot2''' is the Wii's third-stage bootloader; it is stored in the [[BroadOn]] WAD format, which includes a ticket that is encrypted with the common key and signed.
The NAND flash device is divided into 4096 blocks of 8 clusters. Each cluster is 8 pages. Each page is 2048 bytes of data and 64 bytes of "spare data" (used for error-correction (ECC) data and HMAC signatures on individual clusters).
 
  
Block 0 (pages 0-0x3F): boot1
+
boot2 versions 0 through 5 are known to exist. 0 is used at the factory to install the first few titles, 1 is only seen on prerelease consoles including those with the [[Startup Disc Menu]] installed, 2 is seen on earlier units, 3 came preinstalled on some newer systems, 4 was deployed to all Wiis with a system menu update and preinstalled on some systems before the update, 5 was distributed on the Wii mini and some newer RVL-101 systems.
boot1 is the second-stage bootloader; it is decrypted by boot0, which resides on a read-only mask ROM inside the Starlet coprocessor. Its primary function is to load and decrypt boot2.
+
 
Block 0 is guaranteed by the manufacturer to be valid, so there is no bad block map necessary.
+
==boot2 update controversy==
Blocks 1-7 (Pages 0x40 - 0x1ff) : boot2 (two copies and blockmaps)
+
 
boot2 is the third-stage bootloader; it is stored in a modified WAD format, including a ticket that is encrypted with the common key and signed.
+
Upon the release of the 4.2 System Menu update, which is believed to be the first time that a boot2 update was deployed to existing systems, it was discovered that a flaw in the [[ES]]_ImportBoot function used to update boot2 lead to the bricking of consoles which were installing the update.
Block 8 / Cluster 0x40 / Page 0x200: beginning of per-console unique data
+
 
Clusters 0x40 - 0x7EFF: Encrypted filesystem data. Data is encrypted with a per-console AES key, and then signed with a (separate, per-console) HMAC key.
+
It is unknown if this issue was ever encountered outside of this update, since this is believed to be the only time that a boot2 update was deployed to existing systems.
Clusters 0x7F00-0x7FFF: Filesystem metadata (SFFS, unencrypted). There are 16 superblocks contained therein — one every 16 clusters.
+
 
 +
==Verification==
 +
 
 +
boot2 is verified by [[boot1]], a program which cannot be changed on normal retail systems after factory setup due to [[boot0]] verifying it against a fixed hash in the non-rewritable [[OTP]]. As such, it is impossible to downgrade boot1 to enable the use of a modified boot2 on Wiis which do not have a boot1 version which is vulnerable to the fakesigning bug, therefore making it impossible to install BootMii as boot2 (or other custom boot2 solutions) on these Wiis. These Wiis are known as [[LU64+]] systems.
 +
 
 +
==sd_boot==
 +
 
 +
During the [[Wii Factory Process]], a special boot2 known as "sd_boot" is used. This boot2 will verify and launch a [[BroadOn]]-format [[WAD]] from the SD card rather than continuing boot from NAND. sd_boot has an exploit in the SD reading code which allows for arbitrary code execution at coldboot with an SD card inserted, and as a retail signed sd_boot title is available which can be installed on any Wii (even [[Bollywood]]), this removes the previous restriction of not being able to run code (such as BootMii) as boot2 on newer Wiis.
 +
 
 +
This boot2 uses version number 0, while the earliest 'normal' boot2 has version number 1.
 +
 
 +
==nandboot==
 +
 
 +
nandboot is a special boot2 build which seems to have been used only for testing. When executed, it loads executable data placed at NAND pages 0x80-0xAF and jumps straight to it. This happens without any security check, so it can be used to run unsigned code (such as BootMii) just like with sd_boot. The advantage of executing code with nandboot is that no SD/SDHC card is needed, which makes it suitable for the [[Wii Mini]].
 +
 
 +
This boot2 also uses version number 0. In order to install this boot2, zeroing out the boot2 version in the SEEPROM is needed.
 +
 
 +
{{Template:WiiNavbox}}
 +
 
 +
[[Category:Wii]]
 +
 
 +
[[Category:Nintendo]]
 +
 
 +
[[Category:Firmware]]

Latest revision as of 09:50, 7 April 2023


Wii.png This topic has a Wiibrew article. For more information, check here.

boot2 is the Wii's third-stage bootloader; it is stored in the BroadOn WAD format, which includes a ticket that is encrypted with the common key and signed.

boot2 versions 0 through 5 are known to exist. 0 is used at the factory to install the first few titles, 1 is only seen on prerelease consoles including those with the Startup Disc Menu installed, 2 is seen on earlier units, 3 came preinstalled on some newer systems, 4 was deployed to all Wiis with a system menu update and preinstalled on some systems before the update, 5 was distributed on the Wii mini and some newer RVL-101 systems.

boot2 update controversy

Upon the release of the 4.2 System Menu update, which is believed to be the first time that a boot2 update was deployed to existing systems, it was discovered that a flaw in the ES_ImportBoot function used to update boot2 lead to the bricking of consoles which were installing the update.

It is unknown if this issue was ever encountered outside of this update, since this is believed to be the only time that a boot2 update was deployed to existing systems.

Verification

boot2 is verified by boot1, a program which cannot be changed on normal retail systems after factory setup due to boot0 verifying it against a fixed hash in the non-rewritable OTP. As such, it is impossible to downgrade boot1 to enable the use of a modified boot2 on Wiis which do not have a boot1 version which is vulnerable to the fakesigning bug, therefore making it impossible to install BootMii as boot2 (or other custom boot2 solutions) on these Wiis. These Wiis are known as LU64+ systems.

sd_boot

During the Wii Factory Process, a special boot2 known as "sd_boot" is used. This boot2 will verify and launch a BroadOn-format WAD from the SD card rather than continuing boot from NAND. sd_boot has an exploit in the SD reading code which allows for arbitrary code execution at coldboot with an SD card inserted, and as a retail signed sd_boot title is available which can be installed on any Wii (even Bollywood), this removes the previous restriction of not being able to run code (such as BootMii) as boot2 on newer Wiis.

This boot2 uses version number 0, while the earliest 'normal' boot2 has version number 1.

nandboot

nandboot is a special boot2 build which seems to have been used only for testing. When executed, it loads executable data placed at NAND pages 0x80-0xAF and jumps straight to it. This happens without any security check, so it can be used to run unsigned code (such as BootMii) just like with sd_boot. The advantage of executing code with nandboot is that no SD/SDHC card is needed, which makes it suitable for the Wii Mini.

This boot2 also uses version number 0. In order to install this boot2, zeroing out the boot2 version in the SEEPROM is needed.