this is pretty mega stuff.
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
this is pretty mega stuff.
Cool. I always like Marcan's explanations. He explains all the coding stuff in language that I can understand.
Anyway, this bootmii program looks really promising.
i bet they can do really awesome stuff with it
my question is this...will this still require the zelda hack or is it going to be another/better means of getting homebrew on the wii?
There are currently 1 users browsing this thread. (0 members and 1 guests)