New Exploit for the Wii - [SD Boot] announced.

alexander1970 · May 18, 2020

SDBoot: BootMii shown in boot2 on every Wii

A few weeks ago, BroadOn leak mentioned "sd_boot", among other things, with which WAD files can be loaded directly from an SD card when the Wii is started. Now RedBees and Fluffy have shown an exploit that enables BootMii in boot2 on EVERY Wii.

sd_boot is actually used in the WIi manufacturing process; the source code for this, including a retail-signed WAD, appeared in the BroadOn leak a few weeks ago. RedBees has now released a rather humorous preview trailer that shows BootMii in boot2 on a new Wii in which the Trucha bug in boot1 was actually fixed.

This is a gap in the SD read code, which enables foreign code execution when cold booting (i.e. when the console is started).

An installer for SDBoot has not yet been released. The only catch is that the sd_boot WAD cannot be obtained legally and a standard SD card (i.e. not SDHC / XC) is required.

It is probably the most significant breakthrough in the Wii homebrew scene and finally a comprehensive brick protection for everyone! Except for Wii mini owners, of course, since they don't support SD cards anyway.

Source:wiidatabase.de (german)

Zurdonx · May 18, 2020

Oh YES.

th3joker · May 18, 2020

Love the video editing so quirky

E1ite007 · May 18, 2020

Zurdonx said:

Oh YES.
Click to expand...

Oh NO!
-Knuckles the Equidna

Anyway, this is pretty nice.

KleinesSinchen · May 18, 2020

Theory: Cool

In practice: Not so cool. Since the exploit does not rely on a SHA1 hash collision replacing boot1 with a custom version (which is theoretically possible with enough compute power=money) but on a properly signed bootloader copyrighted by Nintendo, this is not really what I hoped for.

Don't get me wrong: The development is good, the possibilities are good. Brick protection for all, long term usability like continue using a console with partially damaged NAND. It's just the legal status that comes from relying on leaked data. Feels like everything that comes from this leak is "poisoned".

An installer could probably never distributed in the way the HackMiiInstaller it is now. If it requires SD boot all the time this is a bit of a downer anyway (wear and tear with constantly swapping SD ←→ SD(HC|XC) and no boot without SD.

banjo2 · May 18, 2020

Congratulations to RedBees and Fluffy on this development, along with anyone else involved

OT, but I do wonder if that's the same Fluffy that I knew ages ago

alexander1970 · May 24, 2020

A little "Background":

Basic Overview of the Wii Factory Process:

During hardware manufacturing,boot0 is imprinted into the Mask ROM inside the Hollywood/Bollywood.

[*]Hollywood is the name of the graphics chip (GPU) used in the Nintendo Wii. It was designed by ATI (now AMD), and was manufactured using the same 90nm process as the Broadway CPU. Hollywood is a direct evolution of Flipper, the GPU used in the Wii's predecessor, the GameCube; in fact, the two GPUs are fundamentally identical. They are very similarly capable, with the Wii's GPU being clocked 50% faster (243MHz, as opposed to Flipper at 162MHz) with the same memory pool (3MB). Hollywood provides no improvements in programmability compared to Flipper, however the benefit of this similarity between the two chips is that Hollywood is completely backwards compatible with Flipper.

Hollywood comes with the addition of an ARM chip, nicknamed "Starlet", which is clocked at the same speed as the graphics chip (243MHz). Starlet handles I/O, wireless (via SDIO) and security functionality among other things, and is responsible for the running of the Wii's IOS (internal operating system). Effectively, Starlet is the only meaningful difference between Hollywood and Flipper.

[*]Bollywood is a revision of the Hollywood package inside the Wii first issued in mid-late 2008. It has modified timing from the original Hollywood, preventing older IOS versions from running and necessitating an update to all IOS versions and other software based on the IOS codebase for them to run on Bollywood. All Bollywood units also come packaged with a patched boot1, preventing use of the Trucha Bug to load unsigned code at boot time.

Bollywood units are more commonly known as LU64+, due to the original serial number variation which was observed in NTSC Wiis when they began to ship with Bollywood. (This is inaccurate, as many serial numbers prior to LU64 contain Bollywood chips).

During initial programming of the NAND chip, a "prewrite" image is flashed to NAND. This image contains boot1 and a special boot2 known as "sd_boot".

At the packaging plant, the Wii is powered on for the first time with SD card number 1 inserted. This SD card contains an image with various BroadOn-format WADs; sd_boot will load one of these WADs, an installer program which installs the other WADs to NAND. These WADs typically include a System Menu, IOS4, and IOS9.

Once the System Menu is installed, the "123J" disc is inserted. It is unknown what the actual title of this disc is, however it possibly serves the purpose of encrypting the NAND filesystem, updating boot1, and setting the console's eFuses.This disc seems to contain a partition with the title ID "0000dead", which may contain the program which encrypts the NAND filesystem.

Another disc known as RVL_UJI_DIAG (or 121J) is inserted, along with another SD card ("#1.5"). This disc runs test programs on the system to validate the operation of the hardware, writing logs to testlog.txt in the process; it then registers the console's serial number (over Waikiki), generates the system's Setting.txt, and other actions to prepare for the next step of the process.

The final disc, known as 122E, is then inserted; this disc installs a WAD called "DataChk.wad" from the SD card, which contains Data Check and Log Check.

Data Check and Log Check (0002) verifies the results of 121J, to ensure that the logs and product info data on the system are correct.

The contents of 122E's update partition are then installed, containing the standard set of channels for retail along with the production Wii System Menu.

Some Bollywood Wiis have a disc ID of "0003" in their uid.sys as well. It's currently unknown what it does, but it is generally found immediately after 122E and right before any signs of retail usage (typically seen as the 00010000-00555045 of a disc's UPDATE partition.)

Source: https://wiki.mariocube.com

W00fer · May 30, 2020

alexander1970 said:

SDBoot: BootMii shown in boot2 on every Wii
Click to expand...

For Wii Mini that is incorrect as somebody already soldered the SD port back onto it

Deadlyfoez and his channel describe frequently about Wii mini hacks.

MetoMeto · Oct 20, 2020

These are great news since i have my second Wii withOUT the ability for boot2 instalation, only bootmii as an IOS.
Cant wait for this...If this really comes out i can finally use my non boot2 Wii since its in best condition~

XFlak · Oct 20, 2020

What i don't like about sd boot is that without an SD card the wii will not boot at all. So if your sd card reader breaks, the wii won't work until it is repaired.

In theory sd boot will be unnecessary, instead something more like bootmii will be created that works on all wiis, and possibly will even have usb support. I'm not sure if this will happen anymore though with DeadlyFoez deciding to retire, there aren't many ppl with the recovery skills, motivation and time to safely test updates to boot2

CABLE53 · Dec 7, 2020

Another way you might be able to save a banner bricked Wii (nothing of the super low level kind of bricks. This wouldn't replace this awesome method of saving your Wii)that can't load the system menu, might be accessing through Priiloader or an entirely different app, the system menu update trigger and update the Wii through Priiloader, or the HBC from an app, or something like that, without visiting the system menu; removing the invalid banner or a problem fixable via sys update. Just an idea that would be cool.

CABLE53 · Dec 8, 2020

Also, if there isn't a boot down process in the Wii NAND already, then it might be possible to slowly turn the Wii off. Since everything I've read about the unwriteable stuff exists when the Wii is powered on, going just that one direction, and not off, the other direction. It seems to me that if there isn't a down boot process of System Menu>IOS>boot2>boot1>boot0, then you could write such a program down to the IOS and turn it off regularly from there(Basically just a reversed Priiloader). Since you can only brick the Wii if it's turned on(without dissecting hardware dangerously or taking a sledgehammer to it), a certain bunch of safety nets could be set during the off process since you are still technically booted into the system menu while the Wii was bricked. This means that if you get an error message saying "System Files have been corrupted" or something like that while exiting the HBC or any other app. While that screen is there, you would normally go "Oh crap!" and hope that boot2 was installed and working or, that Priiloader can help you. Theoretically, the boot down process would be triggered by the power button tapped once as if to get into idle mode(yellow lighted button) and then stop the power from exiting the wii, temporarily to automatically perform a system update to heal from banner bricks and possibly a NAND Restore via BootMii access(or some other HBC app). That means Wiis without GC ports can heal their Wiis(me. even though my Wii is fully operational). I don't know if this is feasible or possible, but just another cool idea.

I also wonder if there is an exploit in the idle shutdown(Wiiconnect24, yellow power button state) setting option to allow unauthorized code inside the boot process that would be sheltered by the setting option itself to create more Wii Restore possibilities(instead of booting down to the usual idle mode, you could boot down to a custom idle mode that listens for SD card NAND BootMii restores as well as the usual Wiiconnect24(Riiconnect24) updates and solve issues from there via NAND restore). Using whatever changes to allow a separate software to run the system, as from the System Menu, you can somewhat change the type of boot you want to start from.

If these options work, then it solves the legal issues with SD_boot, and no illegal keys/WADs needed. Also, this would have to be a brick protected app like the HBC(unless the HBC isn't brick protected which would pose other crappy issues).

If these options don't work, then oh well, at least they were fun thoughts anyway.

All of this would have to be tested of course, but since I can't test it until I learn how to write a simple HBC app :] and also have the resources, someone else with the resources and more in-depth know-how can.