Well, it seems the the Nintendo Wii scene is growing at a great speed, just when you think it has slowed down, marcan and bushing come out and announce another great hack for soft modded Wii's. marcan's post is huge, but I do recommend reading it, it is easy to understand (Even if you don't know much about Wii hacking) But it will for sure change Wii hacking for the best. Can you say- "Never fear bricking your Wii again" ??? and how about "Full console control" ???
Oh yeah, read it!
Marcan @ HackMii Wrote:BootMii: The Beginning
October 14th, 2008 by marcan · 16 Comments
A few days ago I posted a video of something that wee’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, wee’ve had little control over what software our Wiis truly run. Sure, wee can run our own stuff, but ultimately wee’re users of the system - everything wee do has to go through Nintendo’s software. Wee can avoid updates and try to understand the existing system, but wee’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 wee don’t have to write), but it also means wee 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, wee don’t expect the latter to happen (wee 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, wee’re going to turn the tables around. Now wee’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 wee’ve decided to go about designing BootMii. While wee will be taking control of the system, wee 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, wee 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. Wee’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 (wee’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 wee 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), wee can’t just stick the main BootMii-Core code in place of the ELF loader. Wee 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” - wee’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 wee’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 wee 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 wee 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. Wee’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, wee 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. Wee’ll talk about those when the time comes :)
Oh, and don’t worry, wee’ll release BootMii-Core when it’s ready. No need to pester us for the release date ;)
Happy hacking!
- Source: [HackMii]
<3 Marcan
Hmm, I"ve been out of the Wii hacking scene for way too long, once I left -Hacks, I stopped going to nes-hacks, I always got there by PSP-Hacks homepage. I need to get back there soon.
wow...i got to be honest, i didnt actually understand the large portion of that, but from what i gathered it means that homebrew devs can use it to take full control of the system, in dependant of the IOS limitations?
Indeed, when a Wii is turned on, you has to load files right at the start (boot0, boot1 and boot2) boot0 and boot1 can not be modified, but when boot2 loads it can be modified (fakesigned boot2) so run anything you want. Pretty much allowing you to run unsigned code right at the start of a boot of the system menu, pretty much giving you full control of the console. So if your Nintendo Wii is bricked (Any kind of brick) and you can not get to the system menu, you could use bootmii to boot to the homebrew channel and run and reinstall NAND flash memory to fix you brick :) bushing also goes on to say the "BootMii-Core is also the most brick-resistant piece of software that can be written for the Wii." Also Bootmii could someday be used to run unsigned code to allow things like back up loaders right from the disk channel and there for making the Compatibility of burnt games make much much higher, Very neat ask if you ask me.
Just yesterday the Wii hacking scenee got and update from Team Twiizers about there highly anticipated hack named "BootMii" Some of may have seen this thread when I first made it, and now finally wee get another update. If you have no clue what this is please read the whole thread.
HackMii Wrote:Wee haven’t made an update on BootMii for a while but never fear, things are progressing. Part of what takes so long is figuring out what the edge cases are that could cause things to fail and in this regard wee need your help!
Wee’ve developed a BootMii Compatibility Checker that wee need as many people as possible to run on their Wii. This little utility will check your boot1 against a list of known versions and tell us if you have one that wee haven’t seen. Wee’ve recently seen a few boot1 versions floating around that break BootMii so with your help wee’re compiling a list of safe boot1’s to use in our installer so that you get a better quality BootMii.
Current stats: 279 reports of “normal” (compatible) boot1 (2cdd…), 12 reports of “variant 1″ (4a7c…) and 20 reports of what I was calling the “Korean boot1″ (f01e…). The latter will not be compatible with BootMii, and it looks like it’s not just Korean Wiis (or, as noted in the comments below, they could be region-changed Korean Wiis). Console IDs greater than 100000000 decimal appear to be using the new “Korean” boot1, and the rest are using either the normal one or the variant.
What are you waiting for? Download and run Checker and do your part for BootMii.
Update: Checker will not work on Wiis running v3.4 of the System Menu, or version 3.3 with the October 23 IOS update, or if you have an updated IOS picked as default for libogc for whatever reason. Don’t worry, BootMii will run just fine on v3.4 when it’s released. DO NOT downgrade or do anything else just to get this to work. If it doesn’t work, it’s okay, wee don’t need people doing dangerous things just to add a few extra data points.
Update: Marcan asked me to remind you that by running Checker you’re consenting to Checker sending your data about your Wii to us. Checker tells you about this when you run it, but apparently my WiFi sucks and takes longer to init than most people’s so you may not have time to read it all before it sends the info (wee should have added an explicit delay there).
Update: Just to clarify Checker does not install anything on your Wii, it just collects your ConsoleID (this is used in exported save games), boot1 hash, boot2 version, region, video mode and the IOS version it’s running under and sends it back to us over Wifi. It does not peek at anything you may have installed on your Wii so you can put those tinfoil hats away now.
Update: Would the user with IP 173.17.17.42, who found this post via this GBATemp thread, running Firefox 3.0.6 under Windows XP, with a brand new Wii, NG ID 0×07235f5d, and boot2 version 4 please contact us? This is the very first time wee’ve heard of this version of boot2, and wee’d like to see it. Pretty please.
I can't wait to see what Team Twiizers pulls outta there hats this time.
- Source: [HackMii]
Today marcan cleared up the difference's of preloader vs. BootMii, and more info about the newly found "Boot 1" that now come with newer Wii consoles. If you have been keeping up to date with BootMii it is indeed a good read. It will indeed change Wii hacking for the best.
marcan Wrote:BootMii and the new boot1
February 18th, 2009 by marcan · 10 Comments
From the checker statistics, wee’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. Wee won’t support them when BootMii first comes out (lest wee 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
* Boot speed: how fast you can be running code from SD since boot
* 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 poo poo, 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 wee 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.
- Source: [HackMii]
![[Image: Necropost.jpg]](http://img.photobucket.com/albums/v253/Durandal49/Thinglys/New/FESS/Necropost.jpg)