#WII KEEP BOOT.ELF CODE#

There are two major advantages to this: first, if the installation is interrupted, the second copy will still function normally to boot second, when boot2 is loaded by BC, an updated version of BC will reject BootMii due to an invalid signature, but the second copy can still be loaded fine. Otherwise, it loads the real boot2, which remains intact when BootMii-boot2 is installed.īootMii also only installs into the first copy of boot2. The second section checks to see if an SD card is inserted if so, it loads /bootmii/armboot.bin and executed it. The space normally allocated for the ELF loader is split into two sections itself for technical reasons the first section is a custom ELF loader that loads the second section. Along with the 4.2 update, Nintendo released a new version of boot2 ( boot2v4) there is nothing in boot2v4 that prevents BootMii from working, but it will overwrite an existing BootMii installation when it is installed. Unfortunately, the only way we could completely stop Nintendo from blocking homebrew is by patching updates on-the-fly, or somehow preventing overwriting boot2. This has many advantages, such as making it very difficult to brick, and slowing Nintendo from blocking homebrew.

#WII KEEP BOOT.ELF CODE#

BootMii hijacks the boot process before the normal boot2 is run, optionally allowing code to be run directly from the SD Card. This means it can be hacked, updated, and corrupted. boot2, however, can be modified (with some restrictions). boot1, although stored on the NAND, is signed by a value in write-once memory and therefore cannot be changed without rendering a console unable to boot. boot0 is part of Hollywood and read-only. However, there is mini (a homebrew IOS-like software), which can be modified specifically for the program, ie, for better communication to the Linux kernel.īootMii-boot2 is a modified version of boot2's ELF loader, which is loaded by boot1, which is loaded by boot0. Unfortunately, all homebrew currently require an IOS, because libogc requires one. For example, if you have corrupted the System Menu, you can use DOP-Mii to reinstall the System Menu. Source code is available under GPLv2 at (tbd).īoth mini and CEIL1NG_CAT must be present in order to draw a user interface, because the Starlet cannot directly access the Video Interface.īootMii allows anything from Recovery modes (creating a practically unbrickable Wii), to lazy access of the Homebrew Channel. If it exists, mini loads this executable into memory, boots up the Broadway (ppc) and executes that binary in parallel with mini.

CEIL1NG_CAT (or bootmii-ppc) - When mini runs, it looks for a file named /bootmii/ppcboot.elf on the SD card.

Source code is available under GPLv2 here.

mini - This is a rudimentary replacement for IOS that is best suited for low-level recovery functions.

Otherwise, it will fall back to loading boot2. If so, it tries to load and execute /bootmii/armboot.bin instead of boot2. When run, it looks to see if an SD card is inserted.

BootMii - This is a small bit of ARM code which is injected into boot2 or IOS254, replacing Nintendo's internal ELF loader.

It checks your Wii to make sure it can safely be modified, saves some vital data for disaster recovery, and installs the rest of the components.

HackMii Installer - This is a simple ELF file which may be run using your favorite method (HBC, str2hax, or any other exploit which can load standard executables).

BootMii comes in a group of four pieces of software:

Wii keep boot.elf