User:Hallowizer/Factory3
I’ll be updating stuff from Factory 2.
Before I continue, I want to mention that you may have ideas that came from supposed “leaks.” Please do not discuss those here.
First, 122E installing DataChk is a very confusing thing. My guess is that DataChk also comes in 122E’s update partition, and Nintendo never removed that code.
Next, bushing said that LU64+ consoles have “crap installed into the slots for IOS3, IOS4, and IOS254.” We know that IOS4 is used by the factory System Menu, from the “Insert Startup Disc” NAND. The fact that IOS3 was never used by homebrew or known to be pirated (like IOS16) suggests that this must’ve been used in the factory. I messaged some people on Discord (thank you DraconicNEO and zepd76 for your files!), who were able to send me their /sys/uid.sys files, from WFE units. When put through uid.sys Reader, both had identical factory stuff:
00000001-00000002 ...� 00000001-00000004 ...� 00000001-00000100 ..�. 00000001-00000101 ..�� 00010000-30303030 0000 00000001-00000003 ...� 00000001-00000024 ...$ 00010000-30303032 0002 00000001-00000009 ... 00000001-0000000a ... 00000001-0000000b ...� 00000001-0000000c ...� 00000001-0000000d ... 00000001-0000000e ...� 00000001-0000000f ...� 00000001-00000010 ...� 00000001-00000011 ...� 00000001-00000014 ...� 00000001-00000015 ...� 00000001-00000016 ...� 00000001-0000001c ...� 00000001-0000001e ...� 00000001-0000001f ...� 00000001-00000021 ...! 00000001-00000022 ..." 00000001-00000023 ...# 00000001-00000025 ...% 00000001-00000026 ...& 00000001-00000028 ...( 00000001-00000029 ...) 00000001-0000002b ...+ 00000001-0000002d ...- 00000001-0000002e .... 00000001-00000030 ...0 00000001-00000032 ...2 00000001-00000033 ...3 00000001-00000034 ...4 00000001-00000035 ...5 00000001-00000037 ...7 00000001-00000038 ...8 00000001-00000039 ...9 00000001-0000003a ...: 00000001-0000003c ...< 00000001-0000003d ...= 00000001-00000046 ...F 00000001-00000050 ...P 00010002-48414341 HACA 00010002-48414141 HAAA 00010002-48415941 HAYA 00010002-48414641 HAFA 00010002-48414645 HAFE 00010002-48414241 HABA 00010002-48414741 HAGA 00010002-48414745 HAGE 00010008-48414b45 HAKE 00010008-48414c45 HALE 00010001-48434c45 HCLE 00010001-48414a45 HAJE 00010001-48415045 HAPE 00010001-48414445 HADE 00010001-48415445 HATE 00010001-48434745 HCGE 00010000-31323245 122E 00010000-30303033 0003 00010000-00555045 .UPE 00010000-53503245 SP2E
The first thing I immediately noticed was that 122E and .UPE are the only discs inserted now. SP2E is Wii Sports Resort, which may have also been inserted to clear the cache.dat. We can assume that 0000 and 0003 are normal channels, just like 0002 (DataChk).
The next difference here is that IOS3 and IOS36 seem to be installed first by 122E, probably indicating that 122E uses IOS3, and DataChk uses IOS36.
Later, I was curious about my /meta, which seems to have an entry for the System Menu, IOS4, and IOS9 on them. These all have one thing in common: they get installed through magic prior to inserting discs. My theory was that these get installed through the same mechanism that installs that initial set of titles. (I later found out that those files contained build tags, aka content 0.)
I decided I should test this theory by asking for the /meta contents of these people. It turned out both of them had empty /meta directories. Seemed very strange.
But, there is one other interesting thing. One thing bushing noted was that DataChk deletes its /meta entry when it uninstalls itself. There seems to be no reason for this to happen, besides the factory IOSes including code to write to /meta on title install.
Wait a minute. If IOS used to write to /meta, this probably means an IOS-like tool is being used to install this initial set of titles. And, it makes sense that this tool was updated to stop writing to /meta.
So, we have a mysterious IOS used to install IOS4 and the System Menu (and IOS9 on older consoles). There is no way this IOS could have been installed as a title, because it does not exist in uid.sys. The only explanation is that this exists at some point in the boot process. We can immediately rule out boot0, because it’s stored in ROM. While boot1 can probably be modified in the factory due to boot0 allowing a blank hash, no known mechanisms exist in IOS that allow boot1 to be rewritten. It is possible that 0000 or 0003 updates boot1 through AHBPROT, but this seems very risky, considering that there is only one copy present. The only remaining option is it being preinstalled into boot2.
Regarding boot2, we have seen v2, v3, v4, and v5 on consoles. The Startup Disc Menu console seems to have boot2v1, but that does not have the features previously listed. The only remaining option is boot2v0 (which I’ve now created a page for).
Another interesting thing to notice is that on LU64+ consoles, if 122E uses IOS3, then BC, MIOS, and 0000 were probably installed by boot2v0. 0000 is most likely a title that updates to boot2v4 or boot2v5, and gets loaded by boot2v0 after it finishes installing the initial titles.
I still have several questions, for example:
- Where do the initial titles get installed from?
- What does 0003 do?
- What is .UPE?
Following previous patterns, 0003 is probably installed by .UPE in its update partition. Maybe UPE is short for Update Partition English? Although we have no evidence, .UPE probably also installs an up to date System Menu, although I still don’t know what 0003 does. It definitely deletes itself, since DraconicNEO said they don’t have that title installed. On the other hand, .UPE does seem to be installed (as a real disc), which is interesting.
The last comment on “factory 2” says something about .UPE coming after 122E on RVL-CPU-20 consoles; this may mean the System Menu creates it on initial setup. I’ll look into this when I have time.
Update: I’ve been told that .UPE is the title ID used in the TMD for disc update partitions. This means SP2E was not inserted to clear the cache.dat, and 0003 must be installed from somewhere else, probably in 122E’s code. Maybe it’s in the place 0002 used to get installed?
Going back to /meta, my IOS4 and IOS9 meta entries say sd_os1_1.64; I don’t know what made me think that was a build tag, but IOS build tags usually contain something like “firmware” in them. My System Menu says systemmenu.rvl.0.4, which may be a build tag though. I’m guessing IOS4 and IOS9 don’t have build tags, which caused it to default to this one, and the SD thing looks suspicious. Maybe these are getting installed from an SD card with that ID? Or maybe boot2v0 has that build tag?
Going with theory 2, which seems more likely, most IOSes have 64 in their build tag, which may refer to the Wii having 64MB of memory, and the main part is os1_1 not 1.64. os1_1 probably refers to version 1.1 of boot2v0; I don’t know what version 1.0 was, although 1.1 may have fixed the signing bug.
EDIT: Probably not actually. My Wii was bought around January 2008, so the signing bug was still unfixed everywhere.
As for the Wii Mini, there appears to be a dummy slot for the SD card. I wouldn’t be surprised if it is present at the factory for use by boot2v0 and 0002, then removed afterward. I’ll look into this once I can get a Wii Mini uid.sys.
Another update: I just downloaded boot2v4 from NUS, and it does not seem to have a build tag in it. I found build date strings reporting 7/11/08, but this does not look like the build tag of boot2v0. This most likely means this build tag does not belong to boot2v0, and boot2v0 is instead responsible for chainloading this IOS (possibly through even more factory tools we have never heard of), and this IOS is probably internally known as SDOS (possibly meaning it lives on an SD card). I still think the initial titles are loaded from there, because there seems to be no reason to not do that.
Also, I just noticed that the 4.2 stubs don't exist in the uid.sys I put above. I'm not sure what installs them, but they were not anywhere in the file (even in the part where the user's titles are). We can see IOS80 on here, so it must have System Menu 4.3 installed. It is also evident that an update has been done at some point in time, because IOS62 does get installed after the end of the segment I uploaded. I would conclude that stub IOSes do not get added to uid.sys, except we clearly see entries for IOS10 and IOS11, which come preinstalled as stubs.
Update: I have received a Wii Mini uid.sys (thank you Thonker!):
00000001-00000002 ... 00000001-00000004 ... 00000001-00000100 ... 00000001-00000101 .. 00010000-30303030 0000 00000001-00000003 ... 00010000-00555045 .UPE 00000001-00000050 ...P 00000001-0000000c ... 00000001-0000000d ... 00000001-0000000e ... 00000001-0000000f ... 00000001-00000011 ... 00000001-00000015 ... 00000001-00000016 ... 00000001-0000001c ... 00000001-0000001f ... 00000001-00000021 ...! 00000001-00000022 ..." 00000001-00000023 ...# 00000001-00000024 ...$ 00000001-00000025 ...% 00000001-00000026 ...& 00000001-00000029 ...) 00000001-0000002b ...+ 00000001-0000002d ...- 00000001-0000002e .... 00000001-00000030 ...0 00000001-00000035 ...5 00000001-00000037 ...7 00000001-00000038 ...8 00000001-00000039 ...9 00000001-0000003a ...: 00000001-0000003b ...; 00000001-0000003d ...= 00000001-0000003e ...> 00000001-00000009 ... 00010002-48435945 HCYE 00010002-48414341 HACA 00010000-00555044 .UPD 00010000-30383045 080E 00010000-30373945 079E 00010000-525a5445 RZTE
RZTE is Wii Sports Resort. I don't know if this was inserted to clear the cache.dat, or if Thonker played this disc. Either way, it's clear that this is the end of the factory list.
The first thing that should jump out is that there is no 122E, 0002, or 0003. This probably means the SD slot is not present at the factory, and SDOS cannot be run. While we don't have anything supporting this, I wouldn't be surprised if the Wii Mini instead had a "USBOS" or "WaikikiOS" that installs these initial titles, since Waikiki is normally used for testing anyway. I also don't know if the new boot2 that loads this IOS is still boot2v0.
Since 0000 is still there, I assume it does some essential setup, like updating boot2 to boot2v5. 122E was probably replaced by 080E and 079E. They seem like they might be different partitions of the same disc, given the similarities between them; maybe 080E handles the update stuff, and 079E is the new DataChk? 080E might also be installing 079E to the NAND to gain AHBPROT access.
If someone has a NAND dump from an unused Wii Mini, it would be interesting to see a strings output of the cache.dat; it might be possible to confirm or disprove some of this using that.
Update 8/21/2021: Just checked, and it seems like /meta/00010002 has the dummy banners seen for the stub Forecast and News channels (and probably Wii Shop, which doesn't behave as expected). Therefore, here's my theory regarding this:
I think older versions of IOS and SDOS install the first content of a title to /meta whenever they must be installed. While this has the intended effect of putting banners there, it also has the side effect of putting IOS build tags there. Because Nintendo didn't want a repeat of IOS16, they decided to stop writing those files (but in the process, revealed even more!!!).
Also, about the IOS tags in this launch Wii: it still seems like the System Menu, IOS4, and IOS9 are all being installed by boot2v0, but there's a different set of files in /meta. My assumption is that /meta was implemented later on, and SDOS 1.0 didn't have code to write to it.
But also, IOS9's builtin tag on here is just "os.64." This most likely means SDOS is not what I previously thought; instead, it refers to the factory IOS4 (and IOS9 on older consoles). Forget what I said about the whole chainloading thing from boot2v0; I was wrong. The reason this isn’t SDOS is because these /meta files were created by IOS itself (probably IOS4), not boot2v0, when the IOSes got updated.
I also just got a Korean uid.sys:
00000001-00000002 ... 00000001-00000004 ... 00000001-00000009 ... 00010000-3132334a 123J 00010000-0000dead ..ޭ 00000001-00000100 ... 00000001-00000101 .. 00010000-3132314a 121J 00000001-00000015 ... 00010000-30303032 0002 00000001-00000025 ...% 00000001-00000028 ...( 00000001-00000029 ...) 00000001-0000002b ...+ 00000001-0000002d ...- 00010002-4841434b HACK 00010002-48414141 HAAA 00010002-4841594b HAYK 00010002-4841424b HABK 00010008-48414b4b HAKK 00010000-31323245 122E 00010000-30303033 0003 00010000-00555044 .UPD 00010000-524d474b RMGK 00010000-525a4445 RZDE 00010000-525a444a RZDJ 00010001-525a444a RZDJ 00000001-00000033 ...3 00010000-00555050 .UPP 00000001-0000000b ... 00000001-0000000c ... 00000001-0000000d ... 00000001-0000000e ... 00000001-0000000f ... 00000001-00000011 ... 00000001-00000014 ... 00000001-00000016 ... 00000001-0000001c ... 00000001-0000001e ... 00000001-0000001f ... 00000001-00000021 ...! 00000001-00000022 ..." 00000001-00000023 ...# 00000001-00000024 ...$ 00010008-48414b50 HAKP
It seems very weird that most of these titles are not installed at the factory (because of .UPD). However, the more interesting thing is that 123J and 121J are still there, although 0003 still exists. This may help with identifying the function of 0003 in the first place.
On top of this, /meta seems to have the same build tags on there, which probably means boot2v0 hasn't been updated to stop writing these build tags. The only thing I see different overall from the boot2v3 log is 0003, which I can only assume is a tool used to perform tests without GameCube ports (although I believe they still use GC ports at the factory). I currently do not have an RVL-CPU-20 uid.sys, so I cannot make any definite conclusions about this.
10/1/2021
After dumping my NAND files, it seems like the System Menu was version 0, IOS4 was version 3, and IOS9 was version 1 according to /meta. The IOSes match those on the startup disc Wii, and the system menu was also found in pieces on that Wii, which means anything interesting about the startup disc IOSes can be used for this.
Important correction
According to HackMii's filesystem listing, /meta is created by the System Menu. However, it is still clear that SDOS is installed from an SD card, which makes boot2v0 very likely.
0000dead and 0000
Now that I think about it, the factory discs must've had their own update partition ID; 0000dead comes before all the update stuff on bushing's Wii, and 0000 comes before all the updates on RVL-101, so that's probably the update partition of those. I don't have an explanation for why the disc is called "dead" though.