Prelaunch Wii

This article describes factors of the Wii's displaying the Startup Disc Menu.

Hardware

These Wiis had their PCBs manufactured during the week of August 13, immediately after boot2v1 and IOS9v1 were built.

Console ID

All retail Wii's began with 02 in their console ID. For example you might have a Launch-Day Wii console with a ID of 0204cef9 if you bought it from the local shop back in 2006.

boot1 revision “a”

This is common for early Launch-day Wii's, up to console ID 021e7bed or so.

boot2v1

See boot2v1.

Only five titles installed

The titles are 1-2, IOS4v3, IOS9v1, BCv0, MIOSv0. This is 4MB of content.

1-2

1-2 is a 2MB stub of a system menu, version 1, using IOS4. Just like all System Menu titles — including all system menus and the NDEV menu — it has a string identifying it as “NDEV BOOT PROGRAM v%X.%02X (SYSTEM MENU:”. This is the only thing many people will hear about using IOS4.

There is a second 1-2 TMD found in unused clusters (v0), but it is unclear from the HackMii post whether this is a System Menu or a disc that runs as 1-2 to get higher privileges.

Other stuff

We were able to scrape unused parts of NAND and find fragments and evidence of even older content, and in some cases entire contents. IOS4v3 is 0x5f331 bytes, but there’s an IOS4v1 (with a strange cid of 35016B91) that is only 0x28e51 bytes. IOS9v1 is a healthy 0x19ed76 bytes, but there’s a bizarro IOS9v1 with the same cid (0) and version, but only 0x2a671 bytes long. The stub system menu (v1, 0x200500 bytes) shadows an older v0 that is only 0x80500 bytes long. Certain strings indicate that there is some code to install updates off a disc and to boot a disc .. and that’s about it, the rest of the binary seems to be graphics.

We think what happened was that a few thousand Wiis were made with this “skeleton” set of files on NAND. Of those, most were sent out to game stores for pre-launch kiosks — it’s not clear if the startup discs were sent along with the Wiis or shortly afterwards (which would explain the photos online of the kiosks showing the screen). Some were probably also set aside as replacement units in service centers, and apparently a few actually made it into the hands of customers — which is why Nintendo had to put up a web page pleading for people with those consoles to return them for a new system. Of all of these, most would have had the disc installed by the service center — and then maybe they had to return the disc? (We're not sure why else I’d have such a hard time finding one). Of the rest, people would have sent them back to Nintendo to get working Wiis.

The only Wiis left out would be ones where the owners somehow wouldn’t (or couldn’t) send the Wii back to Nintendo for repair. This Wii that landed in our hands was assembled from spare parts — the case, main board and drive all came from different sources. I suspect that somebody “came across” a pile of main boards, and tried to assemble them all into working systems — when they were finished, they may have had 10 working Wiis and then this one, and then they probably put it in a box somewhere on a shelf and forgot about it, then sold it along with some other broken Wiis to someone else. Nobody would ever have been in a position to return this one to Nintendo, but whoever put it together must have hoped to fix it someday (which is why they didn’t just throw out the board).

The big thing that’s missing is any definite answers about how this NAND came to be. The one thing I can say is that it looks like it is “fresh” enough that we can see most of the original contents of flash — many clusters have not yet been overwritten. There are a few different patterns we can see by looking at some files which appear to be created incrementally — it’s clear that clusters are allocated in scattered chunks of contiguous blocks.

testlog.txt

• cluster 5382 — testlog.txt is created with the single line “BOARD_TEST=START,V1.0″
• cluster 7242 — testlog.txt updated with “BOARD_TEST=OK,V1.0″
• cluster 0210, 5302: testlog.txt updated with “FINAL_TEST=START,V1.0″
• cluster 01ab: testlog.txt updated with “FINAL_TEST=OK,V1.0″
• cluster 2782: testlog.txt updated with “WRITE_NAND_DATA1=START,1.1.0″
• cluster 2784: testlog.txt updated with “WRITE_NAND_DATA1=OK,1.1.0″
• cluster 027a, 5703: testlog.txt updated with “SERIAL_NO_REGISTER=OK,1.1.0″
• cluster 0602: testlog.txt updated with “WIRELESS_TEST=OK,RVL001.01″
• cluster 3c42: testlog.txt updated with “PRECHECK_DATA=START,1.2.0″
• cluster 02a2, 34c3: testlog.txt updated with “PRECHECK_DATA=OK,1.2.0″

cert.sys

• cluster 032a: cert.sys with XS00000003 cert
• cluster 032b: cert.sys with XS00000003 and CA00000001 certs
• cluster 01e9, 0207, 0331: cert.sys with XS00000003, CA00000001 and CP00000004 certs

You might expect the rest of flash … that which was never touched … to be all FF or 00, or something. However, it’s not. 441M of the decrypted flash is what looks like several copies of the same random garbage string — except, it’s garbage where all the bytes are 0..7F. Here’s a compressed form of all of the garbage from the flash, if anyone wants to try to figure out what it is: http://static.hackmii.com/garbage.7z

Okay, I figured out what happened. Combining some of the information I dredged out of this flash with some of the stuff from my older factory post/research:

One of the titles listed above is “0002” — specifically, that’s 00010000-30303032, and it’s installed into flash from a WAD, and then executed using IOS9 with the AHBPROT flag set. It reads a list of tests to perform from an SD card — all.ini, which we only had fragments of before. That file lists 8 sets of tests, and then a filename, arguments, and description for each. The DOL files listed there are read from the SD card and executed. One of the tests, NandIOS2.dol, ended up being left in NAND on the older “factory” Wii, and I scraped it out of flash 2 years back but didn’t look at it too closely. Going back to it, I see that it writes out a 25.6MB file, /tmp/nandTest.dat, with random data … which it then CRCs, reads back, and checks to make sure it was written and read correctly. Disassembling the random data function, it looks like this: s32 seed = 1; s16 rand(void) { seed *= 0x41C64E6D; seed += 12345; return (s16) seed >> 16; } u8 getRandomChar(void) { return rand() >> 8; } The fact that rand() returns a signed value means that when it is shifted right, the sign bit (which is always 0) will be extended, resulting a number that is always positive but within the range of a signed 8-bit integer (0 .. 127, or 0 .. 0x7F, which matches what we see). The file is 25.6MB long, which is almost identical to the compressed size of the data we saw — so that’s the sequence length (thanks segher for pointing that out!). I’m not quite sure why we see multiple copies of it — either the test gets run multiple times, or something is copying chunks of data around in flash.

Powering on the thing

When you turn on one of these old Wii consoles you will be prompted to insert a startup disk allowing you to set your Launch-Day Wii Console up.

There’s a bit of code in the normal Wii’s System Menu — see BS2 states 9/10 — where it checks for a disc with the special ID ‘RAAE’. If it finds it, it refuses to load the disc — but by all other indications, this would be a valid Wii disc. This was the ID associated with the “Startup Disc”, and this check was placed in the final system menu to keep anyone from trying to use that disc a second time.

It is possible to boot RealWnD by changing the disc to the ID RAAE.

To our delight, the screen faded to black, and RealWnD started up. This turned to frustration when I realized that the only way to start the program dumping was to navigate its menu using a Wiimote, and I had no way of syncing a Wiimote to this Wii without a working System menu. I quickly hacked GC pad support into the RealWnD code, burned it, booted it, and then watched it crash because I forgot to call PAD_Init(). A third try ended up working, and an hour later I had a NAND dump of an almost-unmodified Wii on my SD card.

From there, it was fairly straightforward to proceed, though we probably did end up burning 10 discs trying to get the thing fully recovered to “normal” status. I burned the old “NTSC Semi-Brick Fix Disc” (with the first bytes changed to RAAE) to install system menu 3.2, then ran into problems trying to get the Hackmii Installer to work (it didn’t like the ancient versions of IOS installed on it) and I couldn’t get any games to play — even Zelda insisted on installing an update, which failed every time I tried! After using Bannerbomb to run Dop-MII to install a couple of newer versions of IOS and update boot2 (more later), I was able to install the rest of the standard channels with a normal Super Paper Mario disc, and then install BootMii as boot2 and dump the keys out so I could dump the keys to SD.

Sources

All this information was obtained from http://hackmii.com/2010/09/insert-startup-disc/ when I first made this page --LewisMC (talk) 19:55, 24 March 2015 (CET)