Tweet
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 0×047854xx): 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 0×046d2b5a): 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 “0×090106″ to “0×041707″. (Interesting that they’re using an American date format here — maybe this is BroadOn?)
This is a very minor change, so I’m not surprised that Nintendo has not decided to push this update to existing Wiis in the field. It might be a change to accommodate the new Hollywood rev (of unknown purpose), or might fix some yield problem identified in the factory.
Before we dig into the file systems, 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:
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 ID's 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 pre-installed 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 file system “superblocks” will prove useful. If we look at the history of the file system, 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 file system)
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 file system 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 file system 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):
nandtest.dol (231776 bytes)
wtester4.dol (957760 bytes)
ndevboot.bin (284112 bytes)
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.
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 0×047854xx): 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 0×046d2b5a): 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 “0×090106″ to “0×041707″. (Interesting that they’re using an American date format here — maybe this is BroadOn?)
This is a very minor change, so I’m not surprised that Nintendo has not decided to push this update to existing Wiis in the field. It might be a change to accommodate the new Hollywood rev (of unknown purpose), or might fix some yield problem identified in the factory.
Before we dig into the file systems, 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:
Code:
$ 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..."
All of the Title ID's 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 pre-installed 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 file system “superblocks” will prove useful. If we look at the history of the file system, 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 file system)
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 file system 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 file system 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):
nandtest.dol (231776 bytes)
wtester4.dol (957760 bytes)
ndevboot.bin (284112 bytes)
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.