Notes from inside your Wii

HackMii header image 2

bricks wanted?

November 1st, 2009 by bushing · 28 Comments

To continue with the theme of my last post on updates and bricking:

I don’t have an actual explanation for any of the 4.2 bricking, and I suspect Nintendo doesn’t really, either — I don’t think they keep a copy of the NAND keys for each device, and I doubt they have any readily-available way of retrieving them.   As a matter of personal curiosity, I would be interested in doing a post-mortem on such a Wii myself.

If you have a bricked Wii that fulfills the following requirements:

  • Worked just fine before the 4.2 update
  • Is now unusable after the 4.2 update (black screen, error message from system menu, etc)
  • Has an old, vulnerable boot1 (such that BootMii/boot2 could be installed), or
  • Has a known set of keys (either from a BootMii NAND backup or running xyzzy at some point in the past)
  • Did not have anything too odd done to the system menu or boot IOS (but I’m a bit flexible on this point)

… please let me know.   I would be interested in getting a dump of the NAND from the system so I can figure out exactly what caused it to die — if you already had such a dump (and the keys), that would be great, but if I not I could dump it myself (again, assuming you have the keys or it’s old enough that I could install BootMii/boot2 with a flash programmer.)

Tags: Wii

28 responses so far ↓

  • 1 Hsilamot // Nov 1, 2009 at 8:18 pm

    i’m interested in this, i don’t play too much with the NAND and other risky things on my wii, but i whould like to know more about this.

    In my case i got a new boot1 which don’t allow the boot2 update, for now i’m curious, what are the famous Keys you talk about? what do they do?

    also, in the case of bricked wiis, are some way to save them? like a NAND reader/writer or something, also in this it is possible for me to rewrite the nand directly and put BootMii on boot2?, and also, if it is possible why not put it into boot1?, as far as i know the restriction is in place since boot1 has control over the code being updated, but if we write directly into the nand chip there should be no restriction.


  • 2 madcapslaugh // Nov 2, 2009 at 12:36 am

    sounds like a great idea, look forward to seeing what comes out of this, also is there some kind of donation set up for your projects in general?

  • 3 Suigintou // Nov 2, 2009 at 12:41 am

    Sounds interesting, at least somebodies doing something about it.

  • 4 nik138 // Nov 2, 2009 at 1:18 am

    I have such a dump but i dont have the keys 🙁 otherwise i would have fixed it .

  • 5 bushing // Nov 2, 2009 at 2:42 pm

    @Hsilamot: I’ve covered these topics, but it’s been a long time, so I’ll post the links:


    Note that the situation has changed since I wrote those posts; they eventually fixed boot1 (probably right around the time I wrote http://hackmii.com/2008/06/genie-into-bottle-mios/, but we didn’t discover it until http://hackmii.com/2009/02/bootmii-and-the-new-boot1/).

    It’s not that boot1 can’t be modified — it’s that if you make any changes to it, your Wii won’t boot. It doesn’t matter if you use software or hardware to reflash it, and no, there’s no way to change the hash stored in OTP.

    The NAND keys (NAND AES key, NAND HMAC key) are needed in order to create a new, valid filesystem to program into a flash chip for a Wii. They are also needed (at least the first one) to decode a raw NAND dump from a Wii, to see what happened to it.

    As I wrote in http://hackmii.com/2009/04/warranty/, I don’t think they store these keys once the Wii leaves the factory, so Nintendo doesn’t really have any way of performing this analysis, either. If they really wanted to, they could create a “forensics” boot2 (and sign it) and reflash that with a chip programmer, but I doubt they go to the trouble.

    @madcapslaugh: We don’t generally solicit donations, but the closest we have is a donation box for BootMii.

  • 6 DCX2 // Nov 2, 2009 at 2:50 pm

    @nik138 – I thought that the NAND dumper also dropped the keys onto the destination, and at some point even began attaching the keys to the image..?

    @Hsilamot – The old boot1 had a signing bug (the code of which is the banner of this website) in a cryptographic procedure that allowed them to write their own boot2 replacement. The new boot1 no longer has that cryptographic flaw, so they can’t replace boot2. Keys are numbers used during such cryptography, and they make life harder for people who want to do anything without Nintendo’s permission.

    If you’re using a standard boot2 and your NAND gets screwed up, there’s not much you can do. You might be able to re-flash with external hardware, but this would not be easy or safe. You cannot re-write boot2 unless you can generate a cryptographic result that agrees with the key (which was the weak point in old boot1). You cannot write over boot1 because it is encrypted, hashed, and then compared against a hash in One-Time-Programmable memory. I don’t think boot0 ever had a signbug.

    You can use the search bar on the side and plug in things like boot1 and boot2 to read a lot of what I just said in earlier posts.

  • 7 Slowking // Nov 3, 2009 at 8:09 am

    Well we all know that error #003 comes from System Menu 4.2 U/J/P searching for the korean key and when it finds it, bricking the Wii.
    I thought you had a korean Wii bushing. You should be able to reacreate this. Just region change it and update it to 4.2. There you go one bricked Wii. 😉

  • 8 Sephiroth // Nov 4, 2009 at 1:42 am


    i thought bushing wants a wii that got bricked because of the boot2 update included in the 4.2 update…but then again i wonder what bushing expects from a nand dump, because as far as i know boot2 is NOT part of the nand itself,so he should not be able to get any information out of the nand dump.

    this should be happening inside a 4.2 bricked wii:

    load boot0 -> ok load boot1 -> ok load boot2 -> fail, cannot continue loading nand FS -> brick.

    please correct me if I’m wrong somewhere ^^

  • 9 Luke Usher // Nov 4, 2009 at 5:15 am

    Boot 2 is stored in the nand, which is why a bootmii nand backup, or any other full nand backup (as long as keys are present) is able to be used to diagnose a brick.

    IIRC, boot0 is stored on a write-once chip, along with the keys, and a hash of boot1, which is why boot0 or boot1 can not be modified. Boot1 and boot2 are loaded from the first blocks of the nand, located in the blocks before the actual filesytem data starts.

  • 10 Sephiroth // Nov 4, 2009 at 12:07 pm

    @ Luke Usher:

    ok but why doesn’t a bootmii restore overwrite the blocks where bootmii is stored? are these blocks simply skipped by bootmii? otherwise a failed restore could leave a bootmii/boot2 wii in a bricked state because if the blocks for bootmii are written incorrectly you can’t even access the bootmii screen.

    so i guess the bootmii blocks are left untouched…

  • 11 DCX2 // Nov 4, 2009 at 12:39 pm


    I would bet that BootMii is in the NAND dump, but that’s a good question on the NAND restore. It very well could, and it would work fine unless there was a bit flipped during the restore process in the boot2 section.

    I also remember reading something about “boot2 update code”, which might mean that you need a special routine to write into the boot2 section of NAND.

  • 12 Luke Usher // Nov 4, 2009 at 1:39 pm


    I remember reading somewhere, possibly on this blog but I’m not sure, that Bootmii skips over the boot2 section of the nand on restore, so that Bootmii is also present

    A different function is used to update boot2, as unlike IOS, it is not stored on the actual NAND filesystem, but just as an executable located in the early blocks, and the usual update functions only work on the filesystem itself.

  • 13 Hypershell // Nov 17, 2009 at 6:29 pm

    Probably old news to you guys by now, but NSMBWii carries the Boot2 update despite not carrying the 4.2 update. Wonder how likely a brick off of that would be?
    (I don’t know about you guys but I have more faith in the integrity of my disc than I do in that of my internet connection)

    Speaking of which, was there any actual point to Nintendo updating Boot2? I haven’t heard of it actually affecting anything, either official or unsigned, once the update is (safely) said and done.

    On the idea of Nintendo doing a “phorensics” Boot2, wouldn’t they have to in order to preserve the Wii Shop Account of an unmodded brick? I wonder if that was saved or if people who returned their Wiis had to start with a blank slate.

    And if they haven’t, that mean they have no way to detect a softmod from a Boot2-bricked Wii, correct?

  • 14 bushing // Nov 18, 2009 at 4:59 am

    @everyone: Yes, BootMii prevents you from shooting yourself in the foot by overwriting boot1 or boot2 when you restore a NAND dump. Both are present in the actual dump file, though.

    @Hypershell — updating boot2 via disc is probably about the same as updating from the network. No, there was absolutely no point in them updating it, other than to wipe out BootMii and force users to reinstall it. There is no behavioral difference between any of the boot2 versions.

    If you send your Wii in for service and it’s bricked, they look at the serial number on the bottom of the case and pull up your Wii Shop account from their server database, and then transfer that over to the replacement Wii (again, in the server database — they never have to touch either Wii).

    As I wrote here, if you send Nintendo a Wii that can’t boot the system menu, they have no way of detecting a softmod (or the Homebrew Channel, or anything else, for that matter).

  • 15 Trump_Card // Nov 18, 2009 at 4:36 pm

    I’ve got a Wii that was bricked installing the update off of the New Super Mario Bros. The system menu was 4.0 before “updating”. It froze at the beginning of the update so I don’t know what it actually did, but now when I turn the Wii on I just get a black screen. I can’t get the rescue menu up either.

    I didn’t have BootMii installed, only the HBC and I never had a keydump unfortunately. It’s free for analysis if needed!

  • 16 Trump_Card // Nov 18, 2009 at 4:38 pm

    As an addition to the above, this is a launch day Wii so it’s very much succeptible to the boot1 bug but I didn’t want to mess with my boot2 in case it bricked. Guess I don’t have to worry about that anymore! I figured the disc update would be safe!

  • 17 halsafar // Dec 17, 2009 at 9:35 pm

    So, not to sound like a hound. But I have been using bootmii installed in boot2 since the day of the first beta release. It has been the pride and joy of my Wii, always amazes people.

    I have been reading all of the comments on this site about the 4.2 update and I am confused about one thing.

    Did bootmii cause this? Or do you not know for sure? Are people without boot mii getting bricked, if so I would conclude bootmii has nothing to do with it.

    I have fw3.4U loaded right now with HBC1.06, bootmii/boot2 (newest) installed. I just bought New Super Mario Bro’s out of excitement and then remembered how out of date my Wii is. Should I update or will I be mailing you my Wii soon (heh)? I did a NAND dump with the keys already just in case.

  • 18 marcan // Dec 23, 2009 at 4:05 am

    BootMii should not cause any increased chance of bricks. People without BootMii are getting bricked. The chances of brickage are slim; they’re relevant in the grand scheme of things for Nintendo, but individually they’re pretty slight.

  • 19 erikie // Dec 30, 2009 at 2:24 pm

    Maybe not the place to comment, but I think I have a bricked mainboard that was produced in 07 week 1 (mainboard says: PRN M07 1) it is a version 01 board. Strange thing is this comes out of a half year old wii which was bricked by someone. It contains boot1c.
    As this board is quite old, could they replaced the cpu with a new key or did they change the key. That is my question
    it contains Hollywood AA and Broadway B cpu

  • 20 59672 // Jan 2, 2010 at 10:15 pm

    I recently got a brick from updating. I couldn’t run any other software but bootmii. I restored my wii but im going to see if i can get it to brick again by updating. fyi i got my wii on launch.

  • 21 bushing // Jan 4, 2010 at 11:40 am

    “PRN M07 1”? Where do you see that? The date code for the main PCB is on the bottom of the board, under where the SD slot is located.

    You can see the date code on the Broadway and Hollywood chips — it’s the first 4 digits of the last line with numbers on each chip package. No, it’s not possible that they replaced the CPU or changed keys, I think you misread the date code on the PCB.

  • 22 bushing // Jan 4, 2010 at 11:58 am

    If this happens to anyone else, please take a NAND dump of the bricked state and just send me that dump.

  • 23 erikie // Jan 5, 2010 at 7:19 am

    I got this information from underneath the revision type of the mainboard next to the SD slot. As it is a v01 board. I will take a picture of the board and post it later. Are you still interested in images of boards? As I have all 3 versions at home.

  • 24 erikie // Jan 5, 2010 at 11:24 am

    Looked at the mobo again now I am at home. Here are some date codes from the chips:
    Hollywood: 0830
    Broadway: 0830
    Mainboard: 08338 (Rev 01)
    This one already had boot1c in nand memory.

  • 25 bushing // Jan 5, 2010 at 10:17 pm

    Erkie: the main thing there is that your board was made in week 30-33 of 2008 — so we know that the transition to boot1c (the first fixed one) happened in 2008, I don’t think the exact PCB rev is as important.

    I’d be more interested in finding someone with a PCB (or more specifically, a Hollywood chip) that was made in 2008 but had boot1b.

  • 26 erikie // Jan 12, 2010 at 3:50 am

    I found a board with a Hollywood that has date code 0807 and has boot1b in it. I managed to get bootmii into the nand it works, only problem I have is that it is not doing any more than that. cboot2 fails to load IOS and system menu is not coming on. Although ios30 is present on the system with sysmenu 3.1. Could this be a cpu failure?

  • 27 Bruce // Mar 12, 2010 at 8:53 am

    My wii got bricked yesterday… But it isnt the “standar” brick.
    The wiimotes are not synced anymore.. I press power on, the light goes green, the drive spins, and the blue led flashes 2 times (fast). On screen i get nothing. (no signal from composite nor component).
    I had bootmii installed as boot2. This wii is from the launch day (usa version), and was with firmware 3.4U. (HBC installed as channel)
    If i put a SD card (2G) where bootmii used to run, the system turns on, the blue led does not flash, but still got no signal on screen.

    Do you have any idea what could be wrong ?

    The system was beign used and “someone” forgot to turn it off til the next day. Then she just saw the green light and turned it off. (didnt check if there was something on screen).
    (I already got the system opened, and am checking if there is any sign of overheated areas)

  • 28 Bruce // Apr 14, 2010 at 10:29 am

    Well, fixed it myself.
    It seems my WII got overheated and the video chipset was giving a hard time. I did a reflow and the wii came back to life. (that hot air station has been really useful).
    Another WII came to my hands, dead. Difference was i could get to the black screen with firmware version on it. I updated from 3.4 to 4.1, and nothing got fixed.
    Guess what…. it was the bluetooth module. Dont know how or why it died. Good thing they are cheap on eBay 🙂

You must log in to post a comment.