HackMii

Notes from inside your Wii

HackMii header image 2

IOS: history, build process

June 30th, 2009 by bushing · 21 Comments

Another nerdy post, sorry. I want to talk about this “unsoftmoddable Wii” crap, but I need to go into some background first.

I’ve written in the past about IOS — or at least I’ve meant to — but it seems especially relevant now.

IOS probably stands for “Input/Output System” — because that’s what it does. It regulates I/O between the Broadway (PPC) and most of the rest of the Wii’s peripherals. It seems to have been written mostly from scratch by BroadOn.

Generally, when we talk about IOS, we mean the “firmware” that runs while normal code (game, system menu, etc) is running on the PPC. However, the same codebase is used to build boot2, boot1 and arguably even boot0! You can almost think of it as a set of matroshka dolls:

  • boot0 – ~1.4K
  • boot1 / BC – ~ 17K
  • boot2 – ~160K
  • IOS (multiple versions) – ~ 1.8MB each

There are many other ways to describe this situation — boot2 is the “kernel” and IOS is kernel + modules; boot1 is a stripped-down version of boot2; boot0 is a stripped down version of boot1. The important part is that they are all compiled out of the same codebase. That’s why the same strncmp() bug was present in boot1, BC, boot2 and all versions of IOS.

IOS has changed forms quite a bit over time, and in the past, you could see this in the different versions of IOS installed on the system. The very first version of IOS (IOS4) was (is?) probably just used for factory work — it has USB, SD, DI and basic networking drivers (for the USB ethernet dongle), but lacked SSL / KD (WiiConnect24) / WiFi support; somehow, this fit into just 400K! It was once even up on Nintendo’s download servers, but then they took it down (and have since replaced it with a stub version).

One of the fun things we do is look for clues about the process behind all of this. Every version of IOS has a build date (or several) embedded in it. IOS 4 has a build date of 8/10/2006. Actually, it’s easiest to see if I take all of the version information I have and sort it by build date … here’s the first part:

IOS vers. TMD vers. build date build tag
IOS12 6 Jun 4, 2006 fw.RVL.12.0.6.viper.0611041415
IOS4 3 Aug 10, 2006
boot2 2 Oct 1, 2006
IOS16 257 Oct 25, 2006 fw.RVL.16.1.1.viper.0611171440
IOS17 512 Oct 25, 2006 fw.RVL.17.2.0.viper.0611301141
IOS20 12 Oct 25, 2006 fw.RVL.20.0.12.viper.0702221710
IOS21 517 Oct 25, 2006 fw.RVL.21.2.5.viper.0708311326
mios 5 Nov 2, 2006 mios.64.0707060932
bc 2 Nov 2, 2006 bc.0611021443
IOS11 10 Nov 14, 2006 fw.RVL.11.0.10.viper.0611141652
IOS13 10 Nov 14, 2006 fw.RVL.13.0.10.viper.0611141652
boot2 3 Apr 17, 2007
IOS30 1040 Jun 25, 2007 fw.RVL.30.4.16.viper.0708311036
IOS31 1040 Jun 25, 2007 fw.RVL.31.4.16.viper.0708311036
IOS15 260 Aug 31, 2007 fw.RVL.15.1.4.viper.0708311323
IOS37 2070 Feb 23, 2008 firmware.64.0802290707
bc 4 Mar 4, 2008 bc.0803040819
mios 8 Mar 13, 2008 mios.0803140448
IOS30 2576 Apr 3, 2008 firmware.64.0804050736
IOS31 2576 Apr 3, 2008 firmware.64.0804050738
mios 9 Jun 5, 2008 mios.0806101043
bc 5 Jun 10, 2008 bc.0806101038
IOS4 ? Jul 11, 2008
boot2 4 Jul 11, 2008
IOS10 768 Jul 11, 2008 firmware.64.0808061128
IOS11 256 Jul 11, 2008 firmware.64.0808061135
IOS20 256 Jul 11, 2008 firmware.64.0808061144
IOS30 2816 Jul 11, 2008 firmware.64.0808070639
IOS37 3609 Jul 11, 2008 firmware.64.0808070706
IOS37 3612 Jul 11, 2008 firmware.64.0901260758
IOS28 1292 Jul 14, 2008 firmware.64.0808050212
IOS31 3088 Jul 14, 2008 firmware.64.0808041103
IOS4 65280 Aug 7, 2008 firmware.64.0808070753

I’ll let those of you out there fill in the timeline of outside events (24c3 presentation, Freeloader, Trucha Signer, Twilight Hack, HBC, etc). The interesting parts to note are the build dates of IOS37 and onwards. The version of BC that follows is the first version of BC with the strncmp bug fixed — which makes sense if they build all code out of the same source tree. BC is very similar to boot1, so Nintendo had a fixed boot1 at this time — it’s still not clear when they actually rolled that out in the factory. IOS30 and 31 were the rebuilt to block Freeloader (etc), and then shortly thereafter, boot2v4 was built.

boot2 does not actually check any signatures, so it doesn’t make sense for Nintendo to rebuild it just for the sake of fixing the signature-checking code. Instead, I think this probably was to support a PCB rev or two, but more about that later…

Tags: Wii

21 responses so far ↓

  • 1 Jayden // Jun 30, 2009 at 4:49 am

    I love your nerdy posts. Where else would we get this interesting information?

  • 2 niko86 // Jun 30, 2009 at 5:50 am

    I’ve been waiting for awhile another great post Bushing, thank you.

    I may not understand nor appreciate all the information in this blog but its does make for a great read. More please and soon!

  • 3 ahnold11 // Jun 30, 2009 at 7:01 am

    Lol, I don’t envy you. It’s a tough job trying to educate the masses (the never ending battle against ignorance ๐Ÿ˜‰ Hopefully this will explain that all the IOS/code comes from a common place/foundation and so any fixes introduced to 1, ultimately get introduced to them all. In the case of boot-2, those fixes are largely irrelevant.

    It is entertaining though to read about people’s crackpot theories regarding Nintendo’s “slick schemes” to make the Wii “unsoftmodable”.

    Great job on the blog all together though. Initially I just wanted to try out a little homebrew on the Wii, but ended up fascinated by all the work you guys do here. The particularities of the Wii’s inner workings makes for a really interesting read.

  • 4 emailtoid.net/i/0eae7f19/… // Jun 30, 2009 at 10:36 am

    Great post, very interesting read. Love this kind of “techno babble” ๐Ÿ™‚

  • 5 tech3475 // Jun 30, 2009 at 10:49 am

    I always enjoy these “nerdy” posts. In fact i think there should be more.

    I am always interested in how the consoles work or how they were hacked (enjoyed the conference at cc, thanks for posting it).

    Thanks again.

  • 6 Muzer // Jun 30, 2009 at 11:16 am

    I haven’t really been paying attention recently. What is all this unsoftmoddable wii crap I’m getting glimpses of?

  • 7 xeron // Jun 30, 2009 at 1:12 pm

    Don’t apologise for nerdy posts. Those are the ones I always hope to find when I visit the site!

  • 8 noir // Jun 30, 2009 at 1:56 pm

    IOS generally stands for Internal Operating System. Interesting post, look forward to the next.

  • 9 Henkka // Jun 30, 2009 at 2:28 pm

    Also love your nerdy posts.. Waiting for actual information about these “unsoftmoddable” wiis.. Is that only going to be bother for the pirates or something? Is this the LU64 thingy I saw at some of the less respected sites on wii community?

  • 10 darksamus // Jun 30, 2009 at 3:52 pm

    I agree with Jayden. Any addition knowledge about the Wii is appreciated, nerdy or not. After all, we are on the outside looking in: Team Twiizers is privy to far more about the Wii than most of us. So please, nerdy-post to your heart’s content.

  • 11 Louise // Jun 30, 2009 at 4:46 pm

    The table only needs an “Estimated cost in engineering hours”. Or would that be evil? =)

  • 12 Zetetic // Jul 1, 2009 at 1:27 am

    I second Jayden.
    Please sir, can I have some more.

  • 13 Suigintou // Jul 1, 2009 at 1:31 am

    I second that emotion.

  • 14 stan423321 // Jul 1, 2009 at 5:11 am

    Interesting… but if “boot”s are just stripped versions of each other, why aren’t boot1 and boot2 merged? I understand that boot0 must fit a very small unrewritable memory cell. But then what the hell does b1 do? It is already checked for authenticity by b0, right?

  • 15 Sonic4Ever // Jul 1, 2009 at 10:29 am

    There’s probably no point in knowing what I ask but I’ll do it anyway: What does “viper” mean?

  • 16 bushing // Jul 2, 2009 at 4:15 am

    @noir: Interesting. This certainly would qualify for that name (“Internal Operating System”), since it’s completely hidden.

    @stan423321: boot1 has to be able to fit within the first 48 pages of flash (so, 96K). It also can not be upgraded on existing Wiis, so if there are any bugs in it, they’re kinda screwed (c.f. BootMii).

    boot1 can’t read the NAND filesystem; it only knows how to read boot2 from a specific set of blocks in NAND.

    I have a theory — with little evidence — that they pre-program every NAND flash chip with boot2v1 and an unencrypted NAND filesystem containing just IOS4 and the text-only “NDEV” menu (1-2). They install some of the system titles (newer IOSes, etc), and then at some point they run a program that encrypts the entire filesystem with the per-console unique key and then upgrades boot2 to v2 (or v3 or v4). I am still searching for that program — but it would explain why we’ve never seen boot2v1 anywhere and why IOS4 is never used.

    @Sonic4Ever: I suspect that “Viper” may be their codename for what we call “Starlet” — the ARM core inside their “I/O Bridge”.

  • 17 someone // Jul 2, 2009 at 9:03 am

    As I worked out the dates of various hacks/homebrew/exploits I thought I’d post them to save other people the effort…

    28th December 2007 – 24c3 – “The State of the Wii”
    10th Feburary 2008 – Twilight Hack
    26th February 2008 – Trucha Signer
    14th March 2008 – Freeloader
    24th May 2008 – HBC
    10th July 2008 – PatchMii
    12th August 2008 – DVDX
    28th December 2008 – 25c3 – “Wii Fail”
    30th March 2009 – USB Loader
    12th May 2009 – Banner Bomb
    13th May 2009 – BootMii

    They might have had more success with forcing people to update if they simply stopped them playing online unless they update to the latest version instead of adding insignificant new ‘features’ (apart from perhaps the SD card update) and asking them to update…

  • 18 abraxo // Jul 2, 2009 at 12:01 pm

    I remember a previous post here that mentioned bc in passing, but IIRC at the time its function was unknown. What is the purpose of bc?

    I have a couple of other questions which I might as well ask while I’m posting. There are crashes that occur with some reliability on some GameCube games when played on a GameCube which do not seem to occur when the same titles are run on the Wii. I’m sure it is almost impossible to know for definite without investigating further, but is there anything obvious in the Wii’s architecture that would account for this phenomenon?

    As an extension of this question, would it be possible to patch a Wii’s firmware in such a way that remote debugging of GameCube games might be achieved? Would you have to settle for something lame like just printing out all the system calls, or does the ARM have sufficient jurisdiction over the PPC that you could do better than that? (I know you could do some of this with a GC emulator, but I’m curious anyway.)

  • 19 zeldarocks // Jul 6, 2009 at 3:36 pm

    @abraxo, I suspect you are right about Gamecube games that would freeze on the Gamecube now work fine on Wii without any crashes, one such exanmple would be the Zelda Collector’s Edition for Gamecube, where Majora’s mask suffered from random freezing at any tine during the game. Now when played on Wii, the game plays fine, without any crashing issues whatsoever.

  • 20 Respect // Jul 22, 2009 at 12:28 pm

    Hi. Sorry if isn’t the correct place to ask this question, but I bought Wii very recently like 2 weeks a go, and I can’t install the bootmii on boot2 :\ and I don’t want to instal on IOS. Anything to do?

  • 21 Daverball // Jul 26, 2009 at 11:53 pm

    @Respect: Sorry pal, but if you read recent posts and the FAQ then you would know, that you have an incompatible boot1 version, which will most likely never allow you to install it as boot2.

You must log in to post a comment.