News from HackMii Team:
From the checker statistics, we’re seeing about 10% of Wiis with the new boot1 (all newer ones). What will happen to those new Wiis that have it?
At first, BootMii will not be compatible with those Wiis. A modified boot2 will not run on them, period. However, there is a way of accomplishing some of BootMii’s goals on those Wiis, by installing BootMii as the System Menu’s IOS, or as an entirely separate IOS, for example. There are pros and cons to these options, and they’re not as good as installing BootMii as boot2, but they are possibilities worth exploring. We won’t support them when BootMii first comes out (lest we delay it even further), but one or more of them might come in the future.
Since people seem to love to compare Preloader to BootMii, I’m going to throw it in the comparison as well. Here’s a table comparing the following attributes of the four solutions:
Brick resistance: chances of it helping you if you brick your Wii
Update resistance: chances of surviving a Nintendo update
Update safety: chances of causing a brick when the Wii is updated in the future
Code execution: what kinds of code you can actually run with it
Complexity: how many things can go wrong while using it
Low-level install: how easy it is to install using a hardware programmer
Compatible with return: does “Return to Wii Menu” run it?
Note that the metrics on the table are mostly relative to one another. “Low” doesn’t mean crap, it means lower than “Medium” or “High”.
BootMii as (separate) IOS is a special case. It would be useful for people who want to use software designed to run under BootMii (that is, using custom ARM code, not IOS) starting from code under IOS, without regard for having it run on boot or brick-safety. This is basically a completely safe option, but also the least powerful one.
Brick resistance: BootMii as boot2 has high brick resistance because it _only_ relies on boot1 and boot2, which are in a reserved area of NAND. BootMii-boot2 will run even if your entire NAND Filesystem is hosed, and only requires the first megabyte or so of NAND to be intact (containing boot1 and boot2). BootMii as IOS does quite a bit worse, because it does require a sane NAND Filesystem, and also a sane enough structure that the original boot2 won’t choke on it. However, it doesn’t require any PPC code to run, nor does it run any additional drivers (for example, WC24), so some failure modes related to system files are eliminated. Preloader also depends on the System Menu IOS and runs on the PPC side, so it only saves you from brick problems that affect the System Menu (although these are pretty popular, so it’s still significant) - it won’t help for anything affecting IOS. Of note is that BootMii-boot2 doesn’t require anything on NAND that is dependent on your NAND keys, so the parts of NAND that are required are exactly the same (at least among Wiis with the same boot1 version).
Update resistance: BootMii as boot2 is likely to survive updates, because it’ll only be overwritten if boot2 is updated. Nintendo has never done that so far. BootMii as IOS would be overwritten with a System Menu IOS update, and Preloader would be overwritten with a System Menu update, both of which happen often and are pretty likely. Interestingly, BootMii as a regular IOS is more likely to survive, simply because it would be installed alongside existing software and won’t be overwritten by any update. None of the options will survive a targeted attack - this is just a measure of how likely a “normal” update will remove them.
Update safety: BootMii as boot2 is essentially 100% safe. This is because boot1 can’t be changed, so the only thing that will affect it is a boot2 update. This would remove it, but that wouldn’t cause a brick. The only way an update could brick a Wii with BootMii as boot2 would be due to a deliberate sabotage attempt by Nintendo (”if we detect bootmii, deliberately brick that Wii”), which won’t happen because they would likely be held legally liable for the damage. BootMii as an IOS, on the other hand, could cause a bad brick if boot2 is updated to check the signature of the installed System Menu IOS. Boot2 hasn’t been updated yet, so this gives BootMii as SysMenu IOS a slightly better chance than Preloader, which would suffer from the same issue if either the System Menu IOS or boot2 are updated to perform this check. Since BootMii as a separate IOS doesn’t participate in the boot process, it is obviously 100% safe (unless Nintendo does something stupid like crash if any unsigned software is found, but that’s not going to happen because it would cause legal trouble as well).
Code execution: This is pretty simple. BootMii lets you run ARM (Starlet) code, which gives you full control (including the possibility of running PPC code). Preloader just lets you run PPC code under IOS.
Complexity: BootMii-boot2 is very simple. It only depends (obviously) on boot1 and on the SD card and FAT drivers. The code is very small and straightforward, and there’s also a very low level bypass mode that will make BootMii boot boot2 directly, bypassing everything. There is very little that can go wrong with BootMii-boot2. Once you move to BootMii as the System Menu IOS, you’re depending on boot2 itself (fairly big and complex). Preloader adds to that a normal IOS. I’m not scoring BootMii as an IOS here, because it mostly depends on what you use to run it in the first place. You could consider it the most complex of all, though.
Low-level install: Because boot2 is the same across all consoles, and boot1 is the same across a large group of consoles, you can just flash BootMii-boot2 onto any console using a dumb NAND programmer. The other options require tinkering with the filesystem and access to the NAND keys, which is a lot harder to do.
Compatible with return: This is an interesting one: what happens when you “return to the Wii Menu” in a game? If you’re using a hypothetical System Menu replacement, you’d want it to return there. BootMii-boot2 won’t do this, because “return to Wii Menu” boots the System Menu directly, not via boot2, so you’ll just get the standard menu. BootMii as the System Menu IOS and Preloader will work - it’ll return to them. BootMii as any random IOS obviously won’t. Note that in general having this option is never a bad idea, because you could always configure whatever code BootMii loads to default to the System Menu if relaunched from a game, if that’s what you want.
As you can see, there’s an option for BootMii for those with new consoles, but you lose out on a lot of the benefits. Are there possibilities other than those listed here? Another bug could be found in boot1 (although I think that isn’t very likely). It’s also possible that SHA-1 will be broken badly enough for us to be able to replace boot1 - this is unlikely, but you never know what our cryptologist friends will come up with next. There’s one solution that could exist now though: using a hardware NAND “modbios” chip to run BootMii on boot, either as boot2 or as the System Menu IOS. This is an ideal solution, especially for those who want homebrew and Nintendo updates to coexist, as it would be 100% brick-proof and 100% update-proof and update-compatible, and also undetectable by Nintendo software if done right. The downside is having to solder up to 16 wires to your NAND chip. If it existed, I’d definitely go for it myself, though. Maybe someday it might. One catch: if you have the new boot1, you’ll need to extract your keys beforehand using some sort of homebrew exploit anyway.
It may sound like I’m specifically writing this article to be pro-BootMii and anti-preloader. However, the preloader comparison was added because people keep comparing it to BootMii, even though it’s quite unrelated. I’m not claiming that either tool is better, just that BootMii was designed with the explicit goal of brick protection. Preloader wasn’t designed for brick prevention - that’s just a side effect (crediar told me to mention this). I’m specifically comparing BootMii and Preloader on the points that relate to BootMii’s design goals, and I won’t hide that fact. Consider that both tools can be used together: you could boot a (possibly slightly modified) preloader binary using BootMii, and get the best features of both. Crediar reviewed this post before I published it.
http://hackmii.com/2009/02/bootmii-and-the-new-boot1/
