Notes from inside your Wii

HackMii header image 2

BootMii: The Beginning

October 14th, 2008 by marcan · 94 Comments

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 three 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 😉

Happy hacking!

Tags: Wii

94 responses so far ↓

  • 1 http://maikelsteneker.blogspot.com/ // Oct 14, 2008 at 7:04 am

    That was a very interesting read! Thanks for keeping everyone (including me) updated about this. There’s one thing which made me worry a bit: “which lets us install a fakesigned boot2 of our choice.”
    Of course, you know what you’re doing, but Nintendo should be able to fix the fakesign bug, right? Is it possible to avoid this when BootMii is installed? Also, would this mean that future Wii’s may not be able to use BootMii, no matter what you hack?

  • 2 Link // Oct 14, 2008 at 7:08 am

    May I say that this sounds awesome? Well, I’ll do. That’s really really great work you’re showing off there.. and I guess as it’s more or less ultimately ensuring safety of the internal system, it would be very interesting to use this for “deep hacking”.. the typical fear “I might brick my Wii” could vanish for many situations.

    So.. good work there!

  • 3 bushing // Oct 14, 2008 at 7:08 am


  • 4 kwijibo // Oct 14, 2008 at 7:12 am

    So… is anyone going to discuss the possible disadvantages of running with full Starlet access? Doesn’t this make writing a backup loader pretty trivial?

  • 5 marcan // Oct 14, 2008 at 7:12 am

    suck it.

    Nintendo can fix the bug in new factory Wiis (they can’t fix the fakesigning bug in boot1 in current Wiis). While we will still be able to have something to an extent similar to BootMii-Core once (if) that happens, it will depend on boot2 at least and therefore you’ll lose a lot of the brickproofing, because it will require a somewhat sane filesystem. It will also be quite a bit more intrusive.

    Nothing we can do about this. The Wii was meant to have a chain of trust during boot. If they actually secure it down to boot2, we won’t be able to hook earlier. There might still be some other exploitable bug in boot1 though.

  • 6 Kyosys // Oct 14, 2008 at 7:14 am

    That was a nice read. I am really looking forward to this, but I don’t like the fact that the last sentence sounds awfully like what the duke nukem forever devs have been telling us for the last 10 years 😉

  • 7 Croc // Oct 14, 2008 at 7:31 am

    That’s a really nice code you guys put together. So, with BootMii one would be able to, let’s say, run some operating system (like some linux distro) without any interference from the Big N’s code, and thus having full access to the hardware.

    Am I assuming this correctly? Or does it already happen when you run one of those linux distros available for the Wii?

    Besides that, BootMii could also be used to run something other than homebrew, right? And when people realize this (not too long from now) is when all that bitching about piracy and homebrew will be on again. Let’s get ready for some flames… =p~

  • 8 https://flyne.myopenid.com/ // Oct 14, 2008 at 7:38 am

    Awesome work.
    You mentioned that the stub you install is an ELF-loader, yes? But then you say the file it attempts to launch is /system/iosboot.bin. Will files built to be launched by the homebrew channel be able to be launched by BootMii?

  • 9 BootMii - Fazendo unbrick do Nintendo Wii 100% via Software - NewsInside // Oct 14, 2008 at 7:50 am

    […] de um pequeno dispositivo de hardware ligado a porta de memory card do GameCube, o Pessoal do HackMii vem agora com mais uma novidade, o […]

  • 10 Run Anything on your Wii with BootMii // Oct 14, 2008 at 8:27 am

    […] good folks at HackMii are working on a new project they call BootMii. BootMii provides a hook into the Wii system very early in the booting process (at boot2). Being […]

  • 11 marcan // Oct 14, 2008 at 9:37 am

    Not any more than it is today, at least not with BootMii-Core. Writing a copy loader is more about hacking IOS and less about getting access to the console.

    Well, right now Linux runs under IOS, but you can already replace that right now – it’s just that nobody has bothered to do that yet. IOS runs on a separate CPU, so you still need to write some code to interface on the other side. As far as we know, there is no way of just giving access to the peripherals to the PPC – it’s a hardware thing, and you need to go through Starlet. BootMii-Core doesn’t help with any of this, although other parts of the BootMii platform might (such as code examples as to how one might go about doing the above).

    Remember, BootMii-Core is centered around boot – and therefore, stuff like brickproofing, convenience, patching Nintendo code, etc. By itself it doesn’t really have much to do with Linux, which could potentially load its own Starlet code other ways.

    BootMii-Core runs Starlet code. This is fundamentally different from running HBC applications. You can eventually load “normal” apps, but that’s not BootMii-Core’s job. That’s the next “level” – to do it (run normal apps, run “special” apps, etc) we’ll have to write the proper iosboot.bin to do the work, and then THAT can load the normal apps. iosboot.bin is really low level code. BootMii-Core isn’t an application launcher, or even a Starlet code launcher – it only launches ONE file, iosboot.bin, and then that’s supposed to take it from there. We want (need!) to keep BootMii as simple as possible as we want to minimize the need for updates (nobody likes overwriting boot2).

    On the video, you see an iosboot.bin that ONLY loads the normal boot2 and patches it to load HBC. Then the normal Wii boot process does the rest, except that instead of the System Menu it takes you straight to HBC. It’s not HBC that is being loaded from SD (although it could be).

  • 12 DanielHueho // Oct 14, 2008 at 9:38 am

    Wow, BootMii really looks awesome…
    But I have a (kinda noob) question: since this thing make able to have direct access to Wii hardware, bypassing the IOS, is possible to achieve some performance enhancement for normal homebrew? Like, to give an example, make able to use the full capabilities of the Hollywood processor for 3D applications, or this have been done already?

    Great work, anyway. I hope you are really having fun with this :P.

  • 13 marcan // Oct 14, 2008 at 10:28 am

    We can already access the full Wii performance. Not using IOS in this case would just mean we’d have to rewrite more code. We arlready have full 3D performance (it’s just that very few people bother to write nice 3D demos)

  • 14 xSpiky // Oct 14, 2008 at 12:06 pm


    Only stupid question, graphics resolution of Wii (480p) is limited by HW (Hollywood) or starlet limit this (boot)?
    I read something like that resolution is limited by IOS (I don’t believe this).

  • 15 IBNobody // Oct 14, 2008 at 12:49 pm


    Once Bootmii core is released, the first thing I plan on doing is setting up menuloader to run on start-up.

  • 16 marcan // Oct 14, 2008 at 2:01 pm

    It’s a hardware limit.

  • 17 someone // Oct 14, 2008 at 2:13 pm

    Out of interest, do Korean Wiis have the signing bug fixed in boot1?

  • 18 Kingcool // Oct 14, 2008 at 2:51 pm

    So with bootmii we may able to see USB 2.0 support?:)

  • 19 Blackbits // Oct 14, 2008 at 2:52 pm

    Too technical for me, but so well explained that it was an interesting read! :-)
    Congrats on your great work.

  • 20 Zim // Oct 14, 2008 at 5:44 pm

    Pure awesomeness.

    Anyways, if you haven’t been asked this already, which I doubt, I can at least guess that you guys were expecting a question such as this:

    You say that “the sky’s the limit” with BootMii.
    Does that mean that developers could create a backup-loader to run backups FROM the Disc Channel, with no errors or issues whatsoever?

    Or, maybe, and I know that this might sound a little crazy, but could someone also program a PSX Emulator to run from the Disc Channel? Even better, could someone make it run actual, legal copies of PSX games? Dreamcast? Gamecube? CD-i? (joking)

  • 21 SquidMan // Oct 14, 2008 at 6:57 pm

    Awesome work guise!
    This is gonna be fun =D

  • 22 Remadon // Oct 14, 2008 at 9:21 pm


  • 23 HyperHacker // Oct 14, 2008 at 10:03 pm

    Niiiice. How difficult would it be if we did want to add in that LCD? :-p

    I’m wondering about the potential to make the system brickproof. You say the only ways a program could write to flash, and thus overwrite BootMii or Boot1, is using IOS calls or custom Starlet code. When you’re in at this level, shouldn’t it be possible to prevent those calls from working and patch any holes that would allow custom Starlet code? Like what Nintendo tried to do?

    Also, the name BootMii Core reminds me of Cubia Core from .hack. Rather fitting.

    Kudos on reaching the holy grail of Wii hacking.

  • 24 marcan // Oct 14, 2008 at 10:26 pm

    BootMii has nothing to do with copy loaders. Making one that boots from the disc channel is already possible, but it’s harder, and the people making copy loaders tend to take the easy, crappy methods. We don’t care and we don’t have anything to do with that stuff.

    USB 2.0 support also has nothing to do with any of this.

    Blocking Nintendo from updating boot2 is part of the eventual plan. However, we can’t practically speaking block all software (homebrew) from doing that. We can just kill Nintendo’s normal update method.

  • 25 BootMii ist viel mehr... - Wiihack.de // Oct 15, 2008 at 1:28 am

    […] im video soll nur zur Debugging zwecken gedient haben. das komplette statemend seht ihr hier: BootMii: The Beginning Wenn das nicht viel versprechend […]

  • 26 whodares // Oct 15, 2008 at 2:33 am

    @marcan: Surely patching ES_ImportBoot is futile. You’d have to patch every IOS version, however, if Nintendo do an update, all they’ll need to do is roll down the new (unpatched) IOS first, then they’ll have access to a working ES_ImportBoot function?

    Unless you managed to patch the Wii Update process, and also the update data off discs.

  • 27 BootMii-Core - La Wii è nelle nostre mani! « Wii’s Temple - Tempio Dell’Hacking Wii. // Oct 15, 2008 at 6:13 am

    […] – La Wii è nelle nostre mani! Il coder marcan ha pubblicato un intervento su HackMii spiegando in cosa consiste il BootMii. Esso è un insieme di programmi che consente di caricare un […]

  • 28 marcan // Oct 15, 2008 at 6:28 am

    Ah, my friend… but this won’t be traditional patching.

    We’re envisioning/planning/writing a patching system (we’re in all three stages at the same time, for different parts :P) designed to patch IOSes as they are loaded (not directly in NAND, but in RAM), using a patching system that is intelligent enough (if the patches are written correctly) that one or two variants of a patch should be enough to cover all existing IOSes and probably most future ones.

    Besides, we can just replace /dev/boot2 with junk all inside IOS and it would instantly kill boot2 updates, as a fallback. That should work with pretty much any IOS.

  • 29 Louise // Oct 15, 2008 at 8:24 am

    Coding question:

    The upper 14MB (?) are Starlet-reserved, and
    the Starlet got some private ram at 0xFFFExxxx/0xFFFFxxxx. Right?

    Does this memory split still apply with BootMii, or is the memory now completely shared?

    I hope for the latter! 😉

  • 30 marcan // Oct 15, 2008 at 9:00 am


    Starlet’s private RAM is Starlet’s private RAM, but the MEM2 split is configurable. You can make it be whatever you want (even all shared, or none shared) using Starlet code (which you can run from BootMii).

  • 31 Matando // Oct 15, 2008 at 9:53 am

    All I have to say is excelllent work. Good job all of you :)

  • 32 C4B0S3 // Oct 15, 2008 at 10:04 am

    Nice work guys!
    I would also like to know if the korean boot1 is fixed so that bootmii wont run on these consoles :)

  • 33 http://emailtoid.net/i/2db6ddbf/c3ba7666/ // Oct 15, 2008 at 11:14 am

    bloody brilliant.

    enjoyed the article: well explained and thorough.

    Re-writing the Wii OS from scratch? If I understand correctly, this is probably the natural next step, and then have it entirely replace the system menu….no? A man can dream………

  • 34 whodares // Oct 15, 2008 at 11:15 am

    @marcan: Nice idea, I’m assuming that means you can intercept the IOS launching.

    However, couldn’t Nintendo load/activate an IOS without interference from BootMii?

    Also, could you not let /dev/boot2 spit out the “original” boot2? It would also mean you could allow consoles to update boot2, but still retain BootMii Core. Would mean you could keep updated with any major (useful) changes.

    The only danger to that is if they add Anti-BootMii code in the new boot2 and it bricks the Wii somehow (although with BootMii controlling the boot2 installation, BootMii should still remain active, and you should remain recoverable)

  • 35 Louise // Oct 15, 2008 at 11:19 am


    Great news=)

    So if I want to use both CPU’s in parallel, and with shared MEM1 and MEM2, I can no longer execute my code from HBC?

    Will an API for configuring the address space be in libogc?

  • 36 bugger // Oct 15, 2008 at 11:44 am

    Great, now we have a way to patch boot2 (BootMii), IOS (Patchmii), and System Menu (Starfall).
    And I repeat:
    1. Source
    2. A way to develop things

  • 37 metroid maniac // Oct 15, 2008 at 11:51 am

    can you make it have the option to boot a .dol/elf directly from the sd? in case the hbc gets corrupt

  • 38 marcan // Oct 15, 2008 at 1:17 pm

    We can load IOS with patches in memory. Those patches can instruct it to patch any further IOS that it loads (well, what we’re actually going to do is make it call our own code to perform IOS loads, so it keeps the “chain of patches”).

    This is never going to be entirely “Nintendo-proof”. If they want to kill BootMii they will, no question about that. Our objective isn’t to make it impossible for them to screw with your system. What we want to do is kill their standard update methods. The simple fact that we can run code with full privileges means that they can, too, if they want. I doubt they’d go down that road, though.

    As for boot2 updates – we’ll deal with them when they come. Chances are we won’t need them, as boot2 provides NO system services. Nothing new should ever need any kind of functionality in boot2. IF they come we’ll block the normal update method. This means the update will fail. Worst case something “depends” (probably artificially) on the new boot2 and the Wii is “bricked” – but BootMii will still work, so then we’ll figure out a solution and everything will be back to normal for those affected. We’re not going to risk reinjecting boot2 updates into BootMii automatically.

    When some other parts of BootMii come out you’ll be able to launch IOS-free code from HBC, sure, by loading your IOS code from there (via a stub IOS or something like that). But don’t expect to use libogc or the existing IOS services. Unless you’re writing a recovery application or something along those lines, there isn’t much point.

    We’re not planning on making IOS obsolete, or on switching Wii homebrew away from IOS. That’s dumb because IOS is free code already done for us and we’re not going to do work to make libogc not use it. The only reason we might not want IOS is when we don’t want it to limit us. There are pretty much just three categories of applications that might warrant that:
    – recovery tools
    – hacking tools
    – WiiLinux

    We’re not going to devote a substantial effort to make using the IOS code in BootMii useful for standard applications, nor will we be developing all of the necessary drivers. We’re not replacing IOS in the general purpose case. If you want to write a NAND tool that needs to run without IOS, or a keydumper, or WiiLinux wants to use a proxy IOS to get easy hardware access, that’s one thing – and that’s the point. But I don’t see a reason to waste time making normal homebrew use it too.

    How about, you know, waiting until it’s done?

    @metroid maniac:
    Eventually, that’s the point. But don’t expect to run normal applications that way. It will have to be custom stuff specifically designed to run from within the BootMii environment.


    Keep in mind the intention here. BootMii IOS-free operation will be used for recovery tools and special cases. BootMii’s future IOS patches will extend IOS the way PatchMii does to make it more useful for applications. Normal homebrew will still run under IOS, although that IOS will be less restricted than the standard one, via patches applied by BootMii.

  • 39 ThePonyPusher // Oct 15, 2008 at 1:56 pm


    So pretty much when you its not “Nintendo Proof” and they will need to change their boot method ways, you mean they will need to code an update within the the BootMii environment, instead of their traditional ways to be able to effectively remove BootMii?

  • 40 BootMii: Die offizielle Erklärung - Beitrag - Wii Will Rock You! // Oct 15, 2008 at 2:15 pm

    […] Blogartikel auf HackMii.com bringt nun eine genaue Beschreibung zu BootMii. Der Software-Hack klinkt sich direkt in den […]

  • 41 marcan // Oct 15, 2008 at 2:26 pm


    Either that, or at least they’d have to add an entirely new way of updating boot2 to an IOS (and install it beforehand), or change IOS enough that our blocking patches are all inefficient. I could also make it so that if any of the boot2-blocking patches fail BootMii aborts the IOS load, which would protect you from that case. They can still work around all of this but it gets increasingly complicated and I doubt they’re going to end up doing it.

  • 42 Louise // Oct 15, 2008 at 3:15 pm


    I think it sounds reasonable not to drop the IOS code, if it can be used =)

    The reason I am interested in getting rid of the memory split, is that I am writing (hopefully the first) a dual core Wii demo.

    I will use the PPC for the first 9 effects or so, and during that time, I will have the ARM pre calculate a raytracing animation for the 10th part.

    But already now with no z-buffering or shadows the pre calc’ed data is 20MiB, so it will never fit in the ARM’s reserved memory space.

    I would prefer if the demo could be a regular HBC application, with the BootMii requirement of course =)

    Would that be possible, or will I have to make the demo a boot2 loader?

  • 43 tech3475 // Oct 15, 2008 at 3:38 pm

    I can ultimately see the only way to avoid boot2 being vanillaised (or erased completely by nintendo as revenge) would be a form of custom firmware.

    By which I mean that someone releases a slightly modified update that removes any checks for old boot2 versions and modified names/FS.

    Personally I hope someday we can have a wii version of pandora, which lets face it must exist for nintendo probably similar to savemii.

  • 44 tech3475 // Oct 15, 2008 at 3:41 pm

    BTW just saw the video….how do you do this stuff:
    e.g. finding bugs in savestates
    creating your own bootloader

  • 45 .:Asphalt Warriors:. - Page 988 - Mario Kart Wii Forum - The Biggest Mario Kart Wii Community // Oct 15, 2008 at 3:48 pm

    […] have to wait a little longer. The site here BootMii: The Beginning says that it is still in work. They will tells us when it is fully finish. I can’t wait to get my […]

  • 46 marcan // Oct 15, 2008 at 7:04 pm

    The ARM has access to all memory at all times (MEM1 and MEM2). That’s necessary to access the buffers passed to it by the PPC. The PPC is the only one restricted from touching ARM’s reserved area.

    TBH though, using the ARM for precalculating graphics data is… highly unusual. I mean, mad props if you get it to work, but I wouldn’t bother with it myself (note that the ARM doesn’t have a floating-point coprocessor – it’s integer only, and I think multiplication only at that – no hardware divisions).

    Your first problem is that libogc requires IOS, which means that the code running on Starlet needs to coexist with Nintendo’s stuff, and needs to be loaded from NAND. You definitely need to use libogc, because that’s where you get your graphics functions. That means the most logical way to implement your precalculation function would be as an IOS module (using neimod’s IOS toolkit, and registering your own custom device to do the work). The problem with that is that you need to install it to an IOS in NAND to get it to load (that means you won’t be able to run your application without at least some degree of installing a custom IOS). Fortunately, you can reuse most of an existing IOS, since IOS30+ contents are shared, so you can just provide your extra driver, keeping everything else from, say, IOS30. When you install your title, just don’t provide any data for the shared contents that you’re borrowing – IOS shouldn’t care, as it can get those from the preinstalled IOS. You’ll still have to install your stuff to a new IOS slot. Then you can launch that and call it to have it do the work.

  • 47 og01 // Oct 16, 2008 at 1:07 am

    @ marcan
    So with this can we boot – starting the System menu using a patched/old IOS that re-introduces the trucha signing bug, DVD lib and other patches?

    forgive my misunderstanding if I am wrong, I have read over this a couple of times now.

  • 48 Louise // Oct 16, 2008 at 7:22 am

    > The ARM has access to all memory at all times (MEM1 and MEM2).

    Excellent! That’s what I need most of all =)

    > TBH though, using the ARM for precalculating graphics data is…

    Yes =) I have a very efficient algorithm to do floats, so hopefully the user will realize what going on when all effects on the screen requires floats =)

    Right now the ARM speed is not so much a problem. I can just include a text screen somewhere in the demo, and I have another 5 seconds of pre calc time =)

    The problem is really the memory. I need all I can get! Right I am even doing a RunLenghtEncoding on the data to save some space.

    So if the ARM’s reserved memory somehow could be utilized, it would be great.

    I am a little scared to mess with the IOS, and also to require others to do the same in order to watch the demo.

    I’ll try and catch you on irc about this =)

  • 49 HyperHacker // Oct 16, 2008 at 4:40 pm

    “That means the most logical way to implement your precalculation function would be as an IOS module […]. The problem with that is that you need to install it to an IOS in NAND to get it to load”
    Can BootMii not provide a method to have the ARM jump to arbitrary code in memory?

    As for updates, I think the best thing to do would be patch the system menu or IOS to refuse to install them, period. Then have a homebrew app that downloads and installs patched updates from the Internet or SD card. That would prevent the potential case where someone else uses their new game in your Wii, and it installs some update that breaks BootMii. You’d have to turn it off and update using the homebrew app instead.

  • 50 marcan // Oct 17, 2008 at 2:25 am

    If you run your own code you’re not running IOS. libogc wants IOS. Louise wants libogc.

    Installing updates using homebrew is a great idea and has been on my mind for a while – and when we get the special “menuloader” for use with BootMii, it’ll definitely come with a similar patch to get rid of updates. Maybe if we get some time we’ll write a homebrew update installer :)

  • 51 Capt_Trips // Oct 17, 2008 at 11:53 am

    Please do whatever it takes to make this thing legal:

    That means Artificial Boots 0, 1 and 2, not just a splice into boot 2.

    I am just praying Nintendo is pleased with this, Otherwise it is all over.

    As a rare aside, Props for the idea Marcan. Did you get the idea only after opening up the Wii?

    Btw, Patents protect process and idea. You cannot use Nintendo’s process! You cannot open up the wii until you have a new process! You can only open up the wii to proove that process! You guys did everything backwards!

    Stop posting videos! Stop incriminating yourselves! Clean up your room!

  • 52 nightwatch // Oct 17, 2008 at 9:59 pm

    At least in theory it might be possible to use a “User Account Control” type of system for updating boot2. That is, whenever the Broadway asks IOS to upload a new boot2, just trap the request and make sure the user assents.

    If it’s not feasible to communicate with the user directly like that in IOS, an alternative could be to require that the user sign custom boot2 updates with a secret user-specific key. The user’s public key could be read from the SD card on startup and then stored in IOS memory, untouchable by Broadway-accessible code. Any updates not cryptographically signed by the user would be rejected. Nintendo couldn’t forge the signature, because the private key would be different for each user, and they couldn’t replace the public key on the SD card with their own, because BootMii would have already stored that key safely before any Nintendo code could run.

    Of course, I don’t claim to know that much about the technical limitations here: this is just theory. :)

  • 53 HyperHacker // Oct 18, 2008 at 5:47 pm

    Right, but you could add/patch an IOS call that would jump to an arbitrary memory location. You’d still be using IOS, but with the ability to take over the ARM core at will.

  • 54 Itsme // Oct 19, 2008 at 10:34 am

    On an entirely different subject, the monitor you’re using seems to be a normal computer TFT. (or is that me?)
    How did you connect those two?

  • 55 marcan // Oct 19, 2008 at 1:00 pm

    A DIY VGA transcoder. Google for “X2VGA”, it’s a similar (commercial) device. The DIY one is the box with the red and green LEDs sitting under the monitor.

    That’s true. Although just patching IOS would also let you do that, but with the BootMii platform you could seamlessly add it to any IOS without patching it physically.

    I only approved your post to reply to it. You have no clue how patent law works. You have no clue how copyright law works. We’re not infringing on anyone’s copyright. We’re not infringing on any real patents. We might be infringing on software patents, just like pretty much all software out there, and that’s entirely irrelevant because we don’t care about software patents and neither does anyone else (except for companies who want to harass each other) – and they weren’t even legal (yet) in europe last I checked. Using boot0 or boot1 is completely legal. Splicing into boot2 is legal as long as we don’t distribute the spliced result. We can’t use a custom boot0 or boot1 unless you’re willing to have a go at your Wii with a focused ion beam microscope. In other words, you’re a clueless idiot. Stop posting nonsense on the forums. Don’t expect to get your next comment approved unless you’ve done your research and post actual facts.

  • 56 Itsme // Oct 19, 2008 at 1:31 pm

    You guys are heroes around here by the way. :)

    And I know this post will be deleted, just wanted to be polite. 😉

  • 57 marcan releases more info on BootMii | NES Hacks // Oct 19, 2008 at 2:57 pm

    […] Source […]

  • 58 Wii/NDS - 任天堂破解資訊網站 - Dash Hacks Network » Blog Archive » BootMii 更詳盡的資訊 // Oct 21, 2008 at 7:55 am

    […] 來源 […]

  • 59 Lucario // Oct 22, 2008 at 2:37 pm

    Great job! but what would you need to instal it, like just the sd card or something we have to buy etc…, and what happens if the boot2 you guys release somehow got corrupted, would that brick your wii or just not work?

  • 60 Deozaan // Oct 23, 2008 at 8:28 pm

    You said you didn’t think Nintendo would block BootMii, but that’s exactly what they’ve done with the new system update. Obviously that means they’ve been working on it since before you posted this. How do you feel about that now?

  • 61 marcan // Oct 24, 2008 at 4:02 am

    Nintendo didn’t block BootMii – they can’t. What they did is block normal BootMii installs, which is fine by me because we have several exploits to make it work anyway. When BootMii-Core comes out it’ll work on updated Wiis.

    If boot2 gets corrupted your Wii will be bricked. However, since it’s verified and the installer will check four or five times in different ways to ensure consistency, that should never happen. Any corruption would trigger many checks to fail and it wouldn’t get installed.

  • 62 Zim // Oct 24, 2008 at 5:13 am

    It’s good to hear that you guys have come up with more exploits.

    But the question to ask now would be this:
    Would any of these other exploits work against the most recent update? Will you guys come up with a homebrew app to fix this (BootMii?)?

  • 63 marcan // Oct 24, 2008 at 5:17 am

    Yes, there are exploits that work with the most recent update.

  • 64 HCK // Oct 24, 2008 at 6:48 am

    Awesome news Marcan 😉

    You all rule, guys! They have no chance to block homebrew with you on our side!

  • 65 DRayX // Oct 24, 2008 at 11:39 am

    Will BootMii allow or person to install the homebrew channel on a Wii with the latest update, or will it require a new version of the homebrew channel installer? Glad to hear that you at least have some way of installing unsigned code now that they have fixed the signing bug in all versions of IOS.

  • 66 Lucario // Oct 24, 2008 at 2:17 pm


    sounds really awesome cause now my wii will brick proof. oh and like i asked what might u need to do this(install it) im sorry i might have missed what u have said in previous comments to install boot2 with only SD card and a computer? oh and what version of linux would u reccomend for an advanced hacker, cause i want linux i just want best one in your opinion.

  • 67 chungy // Oct 24, 2008 at 2:22 pm

    In an earlier comment, you said “We want (need!) to keep BootMii as simple as possible as we want to minimize the need for updates (nobody likes overwriting boot2).”

    This isn’t completely clear to me. When you say nobody likes overwriting boot2, are you meaning of the potential dangers of modifying the way the Wii boots, or the possibility of a catastrophic power failure during installation?

    In the case of the later, I would think Nintendo would be very wary to update boot2 as well; surely the majority of Wii owners do not have any homebrew installed (or bootmii), and Nintendo wouldn’t particularly like fixing bricked Wiis partially caused by them (a power failure certainly will have a hand in it, too).

    I’ve not completely seen how the NAND filesystem operates, either. Is there any sort of journaling to prevent such catastrophes?

  • 68 lordofhyphens // Oct 24, 2008 at 5:31 pm

    Couldn’t leave a comment in the appropriate blog posting, but re: SaveMii, have you considered taking a “copyleft” approach to the design (see http://www.wired.com/techbiz/startups/magazine/16-11/ff_openmanufacturing?currentPage=all)? The article’s talking points seem to be similar to your concerns regarding SaveMii and the copycats.

  • 69 wiisixtyfour // Oct 24, 2008 at 6:02 pm

    So even if I accidentally updated yesterday, I could still install BootMii?
    Then, since BootMii doesn’t require IOS, couldn’t you make a downgrader?

  • 70 HyperHacker // Oct 25, 2008 at 11:53 pm

    wiisixtyfour: see reply #63.

    chungy: I don’t think a power failure is really something to worry about during this process. The actual write process should only take milliseconds; you’d have to have *extremely* unfortunate timing to have it cut out mid-write. The real danger is in the code; any bug in boot2 or the installer could brick the console. Nobody likes overwriting boot2 because it’s vital to the boot process.

    I wonder if new Wiis have or will have the signature bug fixed in boot1. Does the installer check for that?

  • 71 wiisixtyfour // Oct 26, 2008 at 12:50 pm

    yeah, i figured that out, but are there going to be ways to downgrade the IOSs so that they have the fakesign bug again?

  • 72 spyro25 // Oct 26, 2008 at 11:31 pm

    i have a bricked korean wii, updated it with PAL wii music (i know, i know).

    I never installed the homebrew channel before the bricking

    Will bootmii help me to finally unbrick my wii?

  • 73 BootMii, saviour of Wii’s | Caesar's // Oct 27, 2008 at 4:35 pm

    […] BootMii cares about your wallet and saves you days of frustration. […]

  • 74 SnoFox // Oct 27, 2008 at 4:45 pm

    Sweet! I can wait until it is released! I sent my Wii into Nintendo to clean the disc drive, and when I got it back, it came with a notice saying it “Malfunctioned” and they gave me a new Wii with, of course, firmware 3.3. So now I can use some homebrew, like parts of Gecko OS. -.-‘

    Well, before I get too excited, I WILL be able to get around stuff like that with BootMii, right?

  • 75 Lucario // Oct 28, 2008 at 8:33 pm


    were did u send your wii? like whats there emailing address to do that cause i might do that can u give me the information needed to do this please thatnks:)

  • 76 aguamelon // Oct 30, 2008 at 11:51 pm

    I didnt get it, if you are not doing this to run normal homebrew apps, what is this for then? Dont get me wrong this looks good but i dont really understand what will the enduser be able to do?

  • 77 HyperHacker // Oct 31, 2008 at 9:28 pm

    What BootMii does (or future versions will likely do) for the average user:
    -Makes the console nearly impossible to accidentally brick. As long as boot2 is intact, it will be possible to boot a recovery program.
    -Prevents Nintendo blocking homebrew methods.

    And for the advanced coders and hackers:
    -Provides a “backdoor” to load arbitrary code on Starlet at bootup, which gives full control of the system.
    -Easier IOS hacks, without having to patch them in NAND nor run a program every time.

  • 78 cheatman3005 // Nov 1, 2008 at 8:17 pm

    I hope this will come out soon. I want my Wii back. Dang Banners. Oh well.

    Anyways, Keep up the good work, marcan.

  • 79 metroid maniac // Nov 8, 2008 at 1:15 am

    does iosboot.bin contain any code? or is it just a trigger? if it’s a code will we be able to see wiird direct from system boot on the menu, without launching gecko os? also, can starlet code do graphics? so u could make a no ios recovery app

  • 80 SnoFox // Nov 9, 2008 at 6:43 pm

    @ Lucario: Nintendo has an online request for order repairs. I had to go through the Super Smash Bros error section before I found the link. If you’re looking to send SSBB and Wii in use this form: http://my.nintendo.com/consumer/repair/repair_form_us_ssbb.jsp
    If it’s something else, you should go to Nintendo.com, and click support. BE SURE TO BACK UP YOUR SAVES BEFORE SENDING! I lost all my saves, and all my homebrew that wasn’t on an SD card because of something that happened in the shipping process. I got a Wii, but I’ve lost hours and hours from SSBB, Zelda, and the rest of my games.

  • 81 metroid maniac // Nov 13, 2008 at 1:31 am

    can there be a splash screen on some sort of delay on the stub? so that we have a better chance of recovery if bootmii core screws up lol. will there be two different kinds of stub, one which loads bootmii automatically, another that loads boot2. i would like the second one :-) (i only want to use it as brick recovery. damn out of region updates)

  • 82 FF1981 // Nov 14, 2008 at 8:51 am

    Someone told me that bootmii can’t work on Korean wii. I don’t know it is true or not ,and it is very very important to me .Pleaes tell me ! You are my last chance to save my wii.

    Since my fully bricked wii has no help now, I have no reason to keep it .Maybe I can send it
    to you, seriously,I am not kidding.

    Sorry for bugging you,good luck to your work

    my e-mail: ZZZFANG2003@YAHOO.COM.CN

  • 83 What’s next at tonatonari // Nov 18, 2008 at 11:16 am

    […] what do we really want to do? Rely on as little of Nintendo’s code as possible. This is what BootMii is all about. We want to hook into the Wii processes as early as possible, so we don’t have […]

  • 84 KickBan.net - Technical Blog » on the Wiiire. // Nov 23, 2008 at 6:35 am

    […] people are really working hard to make the Wii video Game system awe – wait for it – some. […]

  • 85 zeldarocks // Dec 10, 2008 at 2:29 pm

    @Marcan: how will installation of Bootmii work, will it be a Twilight-esque installation or will it be from the SD card directly?

  • 86 metroid maniac // Dec 16, 2008 at 1:31 am

    sry i’ve been kinda noobish but can you set bootmii installer to run off ios 16? As far as I know it is vunerable to fakesigning, only has one version and isn’t in updates. I mean as time goes on the bugs might get smaller to the point at which they are unusable.

  • 87 marcan // Dec 17, 2008 at 7:11 am

    IOS16 is illegal and will go away with the next update. We don’t plan on ever using it.

  • 88 Cathryne // Dec 29, 2008 at 8:58 am

    Lucario asked the following above, and I am left with the same question:

    “…what would you need to install it, like just the sd card or something we have to buy etc…”

    Are you at a pointin development that you can give us some insight into possible installation method(s) for BootMii once it is released? Even a “we’ll tell you when we’re ready” response would be appreciated. I’m very excited about the possibilities.

  • 89 Corysmart // Jan 4, 2009 at 7:38 am

    Using Bootmii couldn’t you delete the system menu and use your own. Plus when updates are downloaded couldn’t they be patch so updates won’t install ios’es but only updates for channels like the Shop Channel or Mii channel. All of you are extreamely talented hackers andI give you props.

  • 90 aledTH // Jan 4, 2009 at 9:21 am

    This is interesting. Will Bootmii have GUI? Will it have two buttons to load the Wii Menu or another thing (like HBC)?

  • 91 metroid maniac // Jan 19, 2009 at 12:45 am

    bootmii is awesome. when i’ve installed it i’m gonna install starfall. i dont want to take the risk (3.2j)

  • 92 chrisemersonnc // Aug 17, 2009 at 4:14 am

    First of all –> /bow_down – this is pure genius/awesomness.

    Secondly –> Where is the official forum for technical issues w/this? I’ve tried quite a few SD cards on the Wiibrew compatibility list and nothing is working. I’ve tried FAT, FAT32 and various cluster sizes but no matter what, the Wii doesn’t boot into BootMii after I install the files on the SD card :(

  • 93 Hack la Wii « Projet Galaxie De L'Oeil Noir // Jan 15, 2010 at 2:59 pm

    […] nouveau, tout chaud, le BootMii. Jusqu’à présent, il fallait tout faire sur la plate-forme fournie par Nintendo et […]

  • 94 別再花錢硬改Wii啦,軟改自己來,照樣玩台片! | 蝴蝶養貓 // May 7, 2010 at 12:29 pm

    […] more extensive "takeover" of the Wii than The Homebrew Channel. You can read more about it here and here, if you're […]

You must log in to post a comment.