(Note: this is a continuation of http://hackmii.com/2008/06/factory/)
Last week, I bought two brand-new Wiis (the first new ones I’ve ever owned!) and dumped their NAND Flash filesystems before powering them on for the first time. I was able to recover some interesting info (although nothing earth-shattering).
The two Wiis:
LU5757004xx (id 0x047854xx): This unit was purchased Jun 27th from a major “big box” electronics retailer (Best Buy) here in California. The PCB has a datecode of “1208”, meaning the 12th week of 2008 — I bought it in the 26th week, so it’s taking them 14 weeks to get the units from the factory to the store shelf, which seems rather slow to me. (Wiis are still very hard to find here; all stores sell out of Wiis on the same day they receive the shipment.) The drive PCB has a datecode of “1008”, and is presumably a D2C2.
LU3477336xx (id 0x046d2b5a): This unit was purchased July 1st from a specialty game retailer (GameStop). The PCB has a datecode of 0808, as does the drive PCB — so it’s taking them even longer to ship units to the smaller retailers. I’m guessing that these two consoles came from different factories (hence LU5x vs LU3x).
Both devices contained new silicon revs — “Broadway B” and “Hollywood AA”. The LU3x Wii uses a strange, foil-shielded DI cable that I have never seen before.
Some photos:
Looking at the contents of the NAND flash, boot1 is unchanged on both units. This is great news — Nintendo has now shipped 28+ million vulnerable copies of boot1! boot2 has been changed slightly — both units have boot2 version 3, where all of the Wiis I had seen previously had boot2 version 2. (Version 1 was never publicly released, as far as I can tell — it might be used at the factory.) There are two changes between versions 2 and 3:
- ELF loader at the beginning of boot2 was expanded, and now has some added code which pokes at some DRAM or PLL registers before starting boot2
- The internal build date inside boot2 was changed from “0x090106” to “0x041707”. (Interesting that they’re using an American date format here — maybe this is BroadOn?)
Before we dig into the filesystems, I’d like to draw your attention to /sys/uid.sys. Whenever a new title is run for the first time on your Wii, a new UID is generated for that title and stored in this file. This means that this file also serves as a record of all of the titles that have ever been run on a given Wii, and gives the order of installation:
$ xxd -g4 -c12 sys/uid.sys 0000000: 00000001 00000002 00001000 ............ 000000c: 00000001 00000004 00001001 ............ 0000018: 00000001 00000009 00001002 ............ 0000024: 00010000 3132334a 00001003 ....123J.... 0000030: 00010000 0000dead 00001004 ............ 000003c: 00000001 00000100 00001005 ............ 0000048: 00000001 00000101 00001006 ............ 0000054: 00010000 3132314a 00001007 ....121J.... 0000060: 00000001 00000015 00001008 ............ 000006c: 00010000 30303032 00001009 ....0002.... 0000078: 00000001 0000000b 0000100a ............ 0000084: 00000001 0000000c 0000100b ............ 0000090: 00000001 0000000d 0000100c ............ 000009c: 00000001 0000000e 0000100d ............ 00000a8: 00000001 0000000f 0000100e ............ 00000b4: 00000001 00000011 0000100f ............ 00000c0: 00000001 00000014 00001010 ............ 00000cc: 00000001 00000016 00001011 ............ 00000d8: 00000001 0000001c 00001012 ............ 00000e4: 00000001 0000001e 00001013 ............ 00000f0: 00000001 0000001f 00001014 ............ 00000fc: 00000001 00000021 00001015 .......!.... 0000108: 00000001 00000022 00001016 .......".... 0000114: 00000001 00000023 00001017 .......#.... 0000120: 00010002 48414341 00001018 ....HACA.... 000012c: 00010002 48414141 00001019 ....HAAA.... 0000138: 00010002 48415941 0000101a ....HAYA.... 0000144: 00010002 48414641 0000101b ....HAFA.... 0000150: 00010002 48414645 0000101c ....HAFE.... 000015c: 00010002 48414241 0000101d ....HABA.... 0000168: 00010002 48414741 0000101e ....HAGA.... 0000174: 00010002 48414745 0000101f ....HAGE.... 0000180: 00010008 48414b45 00001020 ....HAKE... 000018c: 00010008 48414c45 00001021 ....HALE...! 0000198: 00010000 31323245 00001022 ....122E..."
The first column is the offset within the file. The second and third columns specify the Title ID, and the fourth is the sequential UID assigned by IOS to files generated by that title.
All of the Title IDs that begin with “00010000” are discs — 123J, “0000dead”, 121J, 0002, and 122E. I’m going to venture to guess that 1-2 (System Menu), 1-4 (IOS4) and 1-9 (IOS9) are all preinstalled in the NAND FS by an unknown mechanism. The system menu installed is probably the stripped-down, text-only DevKit menu — more on this later. These could also be installed by 123J, but I don’t know how that would work. 1-2 must be installed before any disc may be booted, and 1-2 must have at least IOS9 to function.
Next, a disc containing 123J is inserted; this disc may also contain “0000dead” as a second partition. That is a highly odd title ID — perhaps the filesystem that was on the Wii until this point was unencrypted, and this “dead” disk “killed” the NAND FS by encrypting it with the per-console key? All we can really do is speculate.
Next, a disc containing 121J is inserted; it may install 1-100 (BC) and 1-101 (MIOS). At this point, a test of the GameCube emulation mode might be conducted.
Next, a disc containing an update partition with 1-15 (IOS21) and “0002” is inserted. (BTW, all of these discs will auto-boot because they have ‘0’ or ‘1’ as the first byte of their Title ID — this makes them much easier to use in a factory setting.) 0002 seems to conduct most of the burnin / testing that we saw in my earlier post; it probably runs using IOS21.
Finally, a disc called “122E” is inserted. Note that this is the first disc that is specific to NTSC/US (hence the ‘E’ ending) — it contains an update partition with all of the remaining versions of IOS (11, 12, 13, 14, 15, 17, 20, 22, 28, 30, 31, 33, 34, 35 — note the lack of 36 and 37, and this is the old, vulnerable version of IOS30). It also contains the default set of channels — many of which are specific to NTSC/US — and installs the NTSC/US system menu (in this case, 3.2U). 122E itself probably performs the final cleanup — deleting diagnostic programs, etc — before the Wii is packaged and shipped to the retailer.
Here, the differential analysis of the 16 different filesystem “superblocks” will prove useful. If we look at the history of the filesystem, we see:
- rename /tmp/launch.sys to /sys/launch.sys. (Contents are 0001000030303032, so the system is preparing to boot “0002”.
- delete /tmp (this is the first action taken by boot2 when it mounts the NAND filesystem)
- create an empty /tmp
- nothing (?)
- delete /sys/launch.sys
- create entry for /tmp/space.sys (this seems to be an empty placeholder file that is created whenever launch.sys is deleted, to ensure there will be space for launch.sys to be recreated later even if the filesystem fills up)
- expand space.sys from 0 bytes to 0xe0 bytes
- rename /tmp/space.sys to /sys/space.sys
- delete /meta/00010000 (and its contents, which are 30303032/title.met), which had only the text “DataChk” and the Title-ID 00010000-“0002” inside of it)
- create an empty /tmp/30303032.tik
- delete the empty /tmp/30303032.tik
- delete /ticket/00010000/30303032.tik, which was the real ticket for “0002”
- delete the empty /ticket/00010000 directory
- delete the directory /title/00010000/30303032, including its contents content/title.tmd, content/00000000.app, content/00000001.app and an empty data directory)
- append the line “CHECK_NAND_DATA=OK,Ver.3.1.144” to /shared2/test/testlog.txt.
You may find the final filesystem listing here. It may be interesting to note that /shared2/test/testlog.txt has a UID of 1007, meaning that it was created by 121J, not 0002. Hmm.
Distilling that list a bit, we get the following sequence of events: 00010000-“0002” is launched. It deletes itself from NAND, including its ticket and contents — apparently this wasn’t actually a disc at all, but a channel in NAND (very odd). Then, it adds the CHECK_NAND_DATA line to the end of the test log.
Fortunately, our ability to rewind the filesystem back a few steps means we can see what the NAND contents of 0002 were. Here is the output of the ‘strings’ command on its main DOL. This program seems to be the one that runs all of the tests; I’m guessing that it reads an “all.ini” file (parts of which we saw here) from SD card, as well as most or all of the test executables.
Although we don’t have filesystem data for these, just by scraping through the unused clusters in the filesystem I was able to find these files (for which I just made up names, based on the contents of the files):
In theory I should be able to run these files, but I haven’t had any luck doing so (they just hang) and I haven’t had time to figure out why.
Lastly, I should point out that every time you insert a disc into the Wii, the system menu reads the banner for the disc (to display in the Disc Channel) and also caches the main DOL of the disc into /title/00000001/00000002/data/cache.dat. The last disc inserted into this Wii was 122E, so we have the DOL file from that disc in cache.dat — strings output is here. (Upon further examination, it looks like this program may install 00010000-“0002” from a DataChk.wad on the DVD filesystem, and then execute it — this would change the above sequence of events somewhat.)
Comparing the two Wiis to each other revealed the only significant differences as being in /title/00000001/00000002/data/settings.txt; more on this another day.
28 responses so far ↓
1 Jayden // Jul 7, 2008 at 10:40 pm
It’s just amazing what you are doing. Thanks for keeping us informed.
2 HyperHacker // Jul 7, 2008 at 10:48 pm
Neat. I wonder if Japanese Wiis would have more interesting leftovers?
3 asdf // Jul 8, 2008 at 12:22 am
The 122E DOL contains the string
“H4A should not be cleared because of Broadway errata.”
This at least suggests the possibility that the Broadway chip has some significant bugs, which may be one reason for a chip rev. Of course this runs against conventional console wisdom and can create a compatibility can of worms, so who knows.
4 DtD // Jul 8, 2008 at 1:12 am
I’m curious as to why Nintendo had to revise Broadway/Holywood. You’d think if the bug affected normal users, this would result in leaving all the Wii owners with old versions with buggy consoles…
Anyway, great work Bushing, glad to hear you finnally got some Wiis to experiment on. So, how early didja have to wake up for one? =P
I remember seeing some Wiis at my local Wallmart at about 11 PM (when they restock it seems) and they were already half gone!
~DtD
5 DtD // Jul 8, 2008 at 1:14 am
We should get people patrolling Nintendo’s trash for defective Wiis, they might have somthing interesting. (<<Meant as half joke 😉 )
6 littlestevie // Jul 8, 2008 at 3:22 am
@DtD: that idea isnt as silly as it sounds.
back in the xbox days i managed to “aquire” an xbox debug kit that bungie threw out when they bricked it.
(was an easy repair i own an official licence for xdk and with some trickery managed to boot the restore disk)
whos to say the same couldnt happen with a wii?
littlestevie
7 Anthony // Jul 8, 2008 at 4:47 am
Absolutely fascinating!
8 Jake // Jul 8, 2008 at 6:42 am
@ Bushing: “…all of these discs will auto-boot because they have ‘0′ or ‘1′ as the first byte of their Title ID — this makes them much easier to use in a factory setting.”
WHOA, did I read that right?
Can you encode a disc to auto boot post-factory? It seems like this may be the way to create brick-fixing discs.
In fact, this might be a great feature to be able to add to your own discs…If you have a game you know you want to play when it’s inserted, just make it auto-bootable, skipping the Wii Menu at boot and going straight into the game.
Or maybe I’m completely misunderstanding you.
9 marcan // Jul 8, 2008 at 6:48 am
An auto-boot disc will only run if the System Menu gets to the Warning screen and succesfully displays it. Any brick that screws that up and an auto-boot disc will not run at all.
As for errata, it is typical for errata to stay in chips because it’s simpler to work around it in software. For example, Nintendo has several bugs in Hollywood that have been there from the start, and they haven’t fixed them because it’s just not woth it. They probably won’t fix errata in newer revisions – rather, the changes are probably cost / power / size optimizations, and changes to support different versions or variants of the rest of the Wii hardware.
10 WiiNoob // Jul 8, 2008 at 7:44 am
bushing im sorry you had to pay 500 dollars plus tax. =P
11 tona // Jul 8, 2008 at 9:56 am
What’s with all the DVD functions in factory2_wtester4?
Like this one:
@@@ (DVDLowWaitForCoverClose) IOS_IoctlAsync returned error: %d
Are those deprecated gamecube functions or something?
12 GoNintendo » Blog Archive » Just how long does it take to get a Wii from the factory to retailers- What are you waiting for? // Jul 8, 2008 at 10:11 am
[…] Link // Cache-busting and pageid values var random = Math.round(Math.random() * 100000000); if (!pageNum) var pageNum = Math.round(Math.random() * 100000000); document.write(”); document.write(”); […]
13 Just how long does it take to get a Wii from the factory to retailers | Games Blog // Jul 8, 2008 at 11:02 am
[…] Link Read more from the original source: Just how long does it take to get a Wii from the factory to retailers […]
14 ynh // Jul 8, 2008 at 11:19 am
Very good stuff bushing!
My question is, how are you able to dump all this information from the memory without the use of a port?
15 bushing // Jul 8, 2008 at 2:24 pm
@Jake: I had initially hoped what you described would be the case, but it was not so — see http://www.openwii.org/forums/viewtopic.php?t=655
@ynh: I cheated — I carefully desoldered the NAND flash chip from each device, and attached the chip to a NAND flash carrier board from atvgc.com and then connected it to an Infectus chip. After dumping, I carefully soldered the chips back into each Wii, cleaned them up, put them back together, and sold them to coworkers. 🙂
16 marcan // Jul 8, 2008 at 3:05 pm
@tona:
Most of the DVD stuff is ported over for the gamecube, and “Cover” has stuck as a legacy term for “disc in”. When you hit eject and pop the disc out, it’s the same as where you have the cover open on the Gamecube, and the virtual cover “closes” when you put a disc in.
17 Pizza2004 // Jul 8, 2008 at 4:44 pm
Just putting in to say what I had with the disc drive thing in the old post. Look at the end of factory to find out what I am talking about.
18 Nintendo Everything - Our second language is Nintendo++ » Blog Archive » The real reason behind Wii stock issues: Factory to store travel // Jul 8, 2008 at 6:30 pm
[…] Source […]
19 SenorClean // Jul 8, 2008 at 9:44 pm
I’d wager that the revisions would be for cost / power consumption optimisations…. things that don’t really affect us directly.
Nice article bushing – I enjoyed reading 🙂
20 vettacossx // Jul 9, 2008 at 2:03 am
@ Bushing: “…all of these discs will auto-boot because they have ‘0′ or ‘1′ as the first byte of their Title ID — this makes them much easier to use in a factory setting.”
can you like “devhook” the info stored in the cache if that makes any sense to you?
21 Kolt // Jul 9, 2008 at 6:45 am
@ Bushing:
Couldn’t we test the theory that Wiis can be unbricked through some type of software?
If you had kept one of those Wiis, you could have intentionally bricked it….perhaps making a small, unnoticeable mark on the main board.
Then, you could send it to Nintendo for repair. Once you got it back, we would know for sure if they had just trashed the main board and replaced it.
Obviously, it would cost money for the service fee…but I know I could make a donation myself, and I am sure others here could also.
Am I way off base here? Some reason this would not work?
22 Anonymous coward // Jul 9, 2008 at 8:10 am
Has anyone else noticed from the string dump that they’ve got MetroTRK in there? It’s an embedded system debugger which works with a serial I/O. I’ve no idea what the Wii version can do but on Symbian mobiles it allows executable files to be transferred to the phone and run (one use is ROMPatcher where it copies the ROM to RAM and allows you to make changes to the RAM version which stay until reset).
There must be some way to start up MetroTRK, and it must be fairly low-level, such as one of the first things it checks before moving onto the warning screen.
If it’s user friendly for technical support then it’d be through a Gamecube controller port (or perhaps more than one port) or GC memory card slot or the SD card slot or possibly USB and the diagnostic program would be able to reset everything (perhaps getting the system into a state ready for the 123J disc).
If it’s not so user friendly for tech support then it’d mean they’d have to open the console up and attach something to the board to allow serial communication with MetroTRK.
This is just my speculation, in the end it may have been put there by Nintendo as a tool for game developers, but if so it’s odd that it’s in IOS4.
23 fireace // Jul 9, 2008 at 7:35 pm
I had a thought. You say that uid.sys stores all the titles that have been run so far. But that would require some sort of software to already be on the Wii in order to record it. So for all we know there has been software run on the Wii before the recording started. Also the first 3 titles are not run from a disk. This leads me to believe there is 2 possibilitys. It could be like you said they are flashed onto NAND by an unknown mechanism. Or it could be that there is software run from a disk before the recording of titles starts that puts the first 3 titles on and the software that records them. I guess this disk, if it exists, would be the ‘golden disk’ your looking for.
24 G. Random // Jul 9, 2008 at 8:27 pm
On past Nintendo consoles (at least as far back as the SNES) they regularly fixed chipset errata, with the stipulation that all commercial games were tested on the buggiest versions before they’d be released to manufacturing. So it’s ultimately pointless for them to fix, but they’ve historically done it anyway. Maybe it’s a Japanese thing and we wouldn’t understand.
25 Shambler // Jul 10, 2008 at 2:10 am
Woah. I so didn’t know bushing was on the iphone dev team till just then 😛
Awesome work man.
Also, I’m incredibly impressed by all this Wii hackery, and deeply appreciate what you’re doing to safeguard our Wiis against bricking. Admittedly I can’t see that happening to me at least, unless Nintendo gets all malicious on us, I don’t use any of those “backup” solutions people keep going on about 😛
Keep up the good work!
26 wicked // Jul 13, 2008 at 1:02 pm
I was interested to see the L2CAP text in that strings output. Thats normally a type of VPN tunnel like PPTP. I don’t know enough to know if that is significant, but its interesting that there is networking code in there. Did I also mention that YOU ROCK!!
27 ioftro // Jul 14, 2008 at 3:51 am
How can it be possible to program a wii if it doesn’t have data ports… Maybe a barebones system menu is programmed prior to soldering? Then a full system update dvd is then installed before leaving the factory?
Could be a multiple process? I wish there was a system restore dvd that, with a couple of button combination during power up would initiate a dvd read command and reinstall. I guess until you guys figure out things, my wii is dead. 🙁
28 Capt_Trips // Aug 24, 2008 at 9:50 am
Bushing and Marcan,
What comes after 122E?
Mine says UPD, UPE.
I played a cd before I ever played Wii Sports.
My serial begins LU319 and ends 08. It was made in China. I also have in sysconf file a messed up entry of CDXXX… before the standard IPL settings.
As always, I expect to be moderated or not posted due to demeanor, tone, lack of clarity or relevance. But also as always, I pray you are looking into this.
Thanks for your time and hard works.
You must log in to post a comment.