You may have seen various things on the internet talking about something called SDboot. There's a lot of information out there, correct and incorrect, so I figured I'd cover it.

Before I can explain SDboot, I need to explain the Wii boot process.

To the user, booting the Wii seems pretty simple. On a stock Wii, you turn it on, and it displays the health screen after 2-3 seconds. Seems pretty simple. However, even on a stock Wii, there's plenty going on that the user does not see.

There are 5 main stages to the Wii boot process. In order, they are:

boot0 > boot1 > boot2 > IOS > System Menu

boot0 is stored inside the Starlet, the ARM processor located inside the Wii's Hollywood GPU. boot0's job is to verify the beginning of the NAND memory, namely boot1. It checks the hash of boot1 against a hash stored in the Wii's OTP (one time programmable memory). This hash is programmed in at the factory, and as the name implies, it can never be changed after that. If the hash matches, boot0's main job is done, and the Wii continues on to boot1. If the hash doesn't match, the Wii will fail to boot.

boot1 is stored at the beginning of the Wii's NAND memory. Essentially, the only reason it exists is to verify boot2, as boot0 isn't large enough to do that. When boot1 executes, it checks the hash of boot2. If the hash matches, the Wii continues to boot2. If the hash doesn't match, the Wii will fail to boot. However, the original version of boot1 that shipped on Wiis had the same fatal strncmp flaw that plagued most of the Wii's IOS. This meant that boot1 could be tricked into thinking that boot2 was properly signed when it wasn't. This was used by BootMii to install it as boot2, which provided exceptional brick protection, since there was rarely a brick where boot2 didn't function. However, Nintendo eventually caught on to this fatal flaw, and along with IOS, they eventually patched boot1 as well. However, because of what I mentioned before regarding boot0 verifying boot1 against a one time programmable hash, Nintendo could never install the patched boot1 on the Wiis that already had the vulnerable boot1. They could only do it on brand new Wiis. This patched boot1 shipped with all Wiis with the "Bollywood" board, which is also referred to somewhat inaccurately as "LU64+". This is inaccurate as there are many serials before LU64 that are also affected. My own Wii, which is an LU38, is also affected. On these Wiis, BootMii could never be installed as boot2 (or so they thought...), as the fake signing trick would no longer work.

boot2 is stored in the Wii's NAND memory right after boot1. boot2's job is to initialize IOS, with instruction telling IOS to load the System Menu. This is the last "invisible" (I'll explain why that's in quotes in a second) part of the boot process. Once IOS is loaded and then the System Menu, that's when the user sees the health screen. The reason why invisible is in quotes is because Wiis that have BootMii installed as boot2 hijack this process. Rather than initializing IOS, boot2 (now BootMii) instead loads the BootMii files off the SD card, which eventually leads to the user seeing BootMii appear on screen (however this can be bypassed by moving or deleting the BootMii files on the SD Card or editing the config file to autoboot to System Menu) rather than the System Menu. boot2 is also where SDboot becomes a factor, but more on that later.

IOS is also stored on the Wii's NAND memory, and it's essentially everything the user cares about on a Wii. IOS is to a Wii as Windows is to a computer. IOS, like the boot process before it, runs on ARM (remember the Starlet) code.

Lastly, the System Menu. Stored on the NAND memory as well. Keeping with the theme of the last analogy, the System Menu is to IOS as the Explorer shell is to Windows. The System Menu is launched by IOS, as it was instructed to do so when IOS was loaded by boot2. When the System Menu loads, that is when the health screen appears. The System Menu is also the first piece of PowerPC code that that Wii runs.

So that's the Wii boot process. It's pretty cool how all this can happen in the span of a couple seconds.

SDboot is essentially a modified version of boot2 that loads images off an SD card. It was used in the manufacturing process to install all the basic parts of IOS and things like WADs.

SDboot was used to speed up the manufacturing process at the factory. By having SDBoot on every Wii at the factory, they could save time and install everything the Wii needs with just a simple SD card.

There's really not much to say here. SDboot was part of the massive Nintendo leak that I'm sure you've heard of.

The reason why SDboot is so important boils down to the fact that the version of SDboot that was part of the leak was fully signed by Nintendo, meaning that it can be installed on the Wii and pass verification by boot1.

Normally, this wouldn't mean much, as you can't just load any image through an SD card because SDboot loads WAD files, which must be signed. However, an exploit was discovered in SDboot that allows us to run basically any image. The implications of this are huge.

This would mean that by loading an image off of an SD card, it would now be possible to use BootMii as boot2 on Wiis that do not have a vulnerable boot1. It would essentially make all Wiis nearly unbrickable.

While SDboot does have a fair amount of pros, there are some cons.

SDboot is and came from a leak of copyrighted Nintendo material. It's extremely illegal to distribute. However, this applies to SDboot itself, not the exploit.

SDboot is only compatible with non-SDHC, aka 2GB or less SD cards. These are pretty hard to find nowadays, especially for a good price.

Installing SDboot is an ordeal of its own. In order to do it, it requires zeroing out the boot2 version in the SEEPROM to bypass the Wii's boot2 downgrade protection, along with actually flashing a boot2 image. Both of these are risky and can leave you with a permanently bricked Wii if something goes wrong.

With SDboot installed on a Wii, you have to have a compatible SD card with the correct image on it for the Wii to boot. It will not boot without it. However, once the Wii is fully booted, the SD card can be swapped with a different one and you won't need the SDboot SD card again until the next time you boot your Wii.

Personally, I think the benefits outweigh the drawbacks, but to each their own.

SDboot is compatible with all Wiis (besides vWii), including the Wii Mini, but is only useful for Wiis without a vulnerable boot1. For Wiis that do have a vulnerable boot1, it makes more sense to just install BootMii as boot2 the normal way.

There's no real confirmed date. There's still lots of work and testing to get done, especially with an actual installer as it must be tested to ensure the chance of bricking is low. I'd give it a few months at least.

I hope this post was informative.

WARNING: Sharing links to the leak itself, SDBoot, or any other material of the leak is highly illegal.