A few days ago I posted a video of something that we’ve come to call BootMii. I think it’s time to answer some questions about what it really is, what it does, and how it will help you. Oh, and by the way, before I bore you and you stop reading this, at least note that BootMii is entirely software-based. The hardware in the video is merely for debugging.
The first thing that you need to realize is that BootMii isn’t a single application or hack - it’s a platform for hacks. Up until now, we’ve had little control over what software our Wiis truly run. Sure, we can run our own stuff, but ultimately we’re users of the system - everything we do has to go through Nintendo’s software. We can avoid updates and try to understand the existing system, but we’re still dependent on it. Every piece of Wii Homebrew currently depends on Nintendo’s IOS. This isn’t a bad thing (it provides many bits of code that we don’t have to write), but it also means we have to follow its rules.
Now, there have been some hacks around the system, of course. PatchMii was developed to get rid of some of the restrictions of IOS - but it’s not particularly practical, and only really works for one IOS at a time. Starfall gets rid of some annoyances of the system menu, but it’s an ugly low-level filesystem hack that will get erased with any Nintendo update. And at any time Nintendo can come and update the entire system to patch all the holes. Of course, we don’t expect the latter to happen (we have / will find more holes), but nonetheless it’s still unnerving to a degree.
BootMii - let’s call it the BootMii platform - is about changing that. Instead of being users of the system, doomed to hacking our ways from the inside, we’re going to turn the tables around. Now we’ll have control and Nintendo’s software will have to go through us to do anything.
Before going into details though, I must mention another subtle but important detail about how we’ve decided to go about designing BootMii. While we will be taking control of the system, we want to accomplish that while minimizing any changes to the existing system. This has many advantages. By keeping BootMii separate from the existing system for the most part, we can switch it on and off at will. This might become handy if, for example, Nintendo decides to start banning homebrewers from online games.
Now, I’ve said that BootMii is a platform. We’re still working on designing and building most of it, so don’t expect detailed explanations about the still-to-be-written pieces. Instead, today I’ll talk about the part of BootMii that was demoed in the video: BootMii-Core.
BootMii-Core is a very important piece of BootMii, ideologically speaking. What it does is give us full control of the console as early in the boot process as possible. A mere fraction of a second after you hit the power button on your console, BootMii-Core will already be running and you’ll have the ability to do anything at that point. This isn’t the only advantage, though. By being such an early hook, BootMii-Core is also the most brick-resistant piece of software that can be written for the Wii. You’d have to deliberately brick your Wii to kill BootMii, excluding one particular type of update by Nintendo (we’ll get to that later).
Let’s revisit the boot sequence of the Wii. The very first piece of code that runs is boot0, which is part of the mask artwork of the Hollywood chipset and thus entirely untouchable. It loads boot1 from the beginning of NAND and verifies it against a hash stored in non-writable memory. This ensures that boot1 is also untouchable (you’ll brick your Wii if you try). Here’s where it gets interesting: boot1 is supposed to load boot2 from a special reserved section of the NAND Flash memory. Boot2, which is a sort of mini-IOS, then kicks off the loading of the system menu (and ends up loading its required IOS beforehand). However, the boot2 verification uses the same exact infrastructure as the one used in the rest of the Wii, and it is also vulnerable to the fakesigning bug. Since boot1 is untouchable once the Wii leaves the factory, every current Wii in existence (as far as we know) is and forever will be vulnerable to this bug, which lets us install a fakesigned boot2 of our choice.
As you may have guessed, BootMii-Core is such a fakesigned boot2. However, it isn’t a hacked version of boot2, nor is it a replacement for boot2. First, you need to realize that boot2 as it actually is stored isn’t a monolithic piece of software. The following applies to boot2 and to all IOSes prior to IOS30, and to the boot file of IOS30 and beyond. These IOS binaries are in a simple format that is in two parts: a simple header, a small ELF loader, and the payload ELF proper. The ELF contains the actual IOS/boot2 code, and the ELF loader is a simple stub that loads it into memory and runs it. BootMii-Core replaces the ELF loader, leaving the original boot2 ELF payload intact.
Now, getting a bit more technical, the BootMii-Core “ELF loader” is itself a two-part file. Due to hardware limitations (strange memory accesses on the Wii and other technicalities that took us forever to figure out), we can’t just stick the main BootMii-Core code in place of the ELF loader. We actually have to make it its own loadable file, and then load it using our own ELF loader. Therefore, BootMii-Core replaces the boot2 ELF loader with a composite file consisting of our own ELF loader (the “stub”), and the BootMii-Core payload (the “loader” - we’ll get to that). Our new “boot2″ now consists of three parts: Our stub ELF loader, the BootMii-Core ELF, and the original BOOT2 ELF - the former two taking up the spot of the original ELF loader.
The stub is a hopefully very simple piece of code that does two things: decide whether to load BootMii or the original boot2, and then load and jump to the selected option. Now, this isn’t going to be the normal way of falling back to boot2 - this is meant to be just a last-resort recovery option in case something goes seriously wrong (which would usually mean we’ve made a mistake). Getting the stub loader to load the original boot2 will probably involve something annoying like repeatedly pressing the RESET button on boot and hoping that the stub catches it. Let’s hope that we never have to resort to that.
The real fun starts in the loader portion. It’s a loader because it loads other code - from an SD card. Here’s the gist of the process: if the loader can successfully mount an SD card and load a certain file from it (/system/iosboot.bin), it will run it. Otherwise, it will just fall back to normal boot2 and your Wii boots normally.
That’s it. That’s BootMii-Core. From there, you can take it anywhere - you can stick a file on an SD card and it’ll be running about a second after you turn on your Wii - with full control over Starlet, and therefore full control over Broadway, Hollywood, and the rest of the Wii’s hardware. No restrictions. Cool, huh?
Now, I did mention that BootMii-Core also helped immensely with brick resistance. The Nintendo DS had FlashMe, which replaced the boot portion of the code and also placed a recovery stub inside a write-protected portion - you had to physically short out a jumper on the DS to install it and consequently to remove or break it. Unfortunately for us, no such hardware-based protection exists on the Wii. Sorry, folks, but we can’t stop someone if they’ve really set their mind on bricking your Wii (so please, be careful with the stuff that you run on it!) However, BootMii-Core is immune to almost any damage that you may cause to your Wii’s flash. It only depends on its own integrity and on boot1’s. boot2 (and therefore BootMii-Core) is stored in a separate section of the NAND, independent from the filesystem. This means that you could delete or format the entire directory structure of your Wii, and BootMii-Core would still run. This is one of the advantages of being independent from the original boot2 - that boot2 does depend on FS stuff as it expects certain things to be there and tries to mount the filesystem. There are only four possible ways of potentially overwriting the area where BootMii-Core and boot1 reside:
Using /dev/flash under IOS (untested)
Using /dev/boot2 under IOS (untested) (does not apply to boot1)
Using ES_ImportBoot (and a proper real or fakesigned boot2 that is newer than the current version) (does not apply to boot1)
Using direct hardware writes from outside of IOS, using some sort of custom code on Starlet (ask bushing about this one - he’ll tell you how fun it is to forget a NAND-erasing call in some early BootMii code)
Nintendo can still update boot2 though - and in the process overwrite BootMii-Core with a pristine copy. We’ll try to avoid this (by using a larger version number for BootMii-Core), but the ultimate solution will be to patch IOS to remove ES_ImportBoot and therefore Nintendo’s ability to do so. But that’s a topic for another chapter…
So what can you do with BootMii-Core anyway? Well, the sky’s the limit - you’re running Starlet code on boot, really, there are no limits. However, a simple example was seen in the video: by using a very simple iosboot.bin that just loads the original boot2 and patches it to change the boot title, we can run The Homebrew Channel on boot instead of the system menu. This by itself will already let you fix banner / system menu bricks and the like, as long as you have HBC and BootMii-Core installed. As a more elaborate example, you could load a NAND backup/restore utility from SD, using custom code instead of IOS and without depending on the filesystem. This would let you fix pretty much any brick that didn’t mess up BootMii-Core. And of course, other parts of the BootMii platform will also take advantage of this run-on-boot system to let you do more fun things. We’ll talk about those when the time comes
Oh, and don’t worry, we’ll release BootMii-Core when it’s ready. No need to pester us for the release date
http://hackmii.com/2008/10/bootmii-the-beginning/
