Talk:IOS/QA

From WiiBrew
Jump to navigation Jump to search
  • I'm curious. How does starlet handle Wii mode and gamecube mode? Also, are there other modes, such as a difference in access rights between the wii menu, and a running game?
During Wii mode, the normal Starlet code ("IOS") runs -- during GameCube mode, a compatibility layer called "MIOS" runs. Yes, the system menu has special access rights that go beyond those of a normal game -- for example, it can see the files of all of the games (to allow you to back up save games), and it can initiate firmware updates. Bushing 05:22, 13 February 2008 (PST)
  • The reason why I bring it up, is because I'm curious what kind of barriers Nintendo has put up to flashing firmware from within a game. (I understand that a flaw has been found in the code dubbed 'BOOT1' which could provide a hole in the chain of trust and open the door for custom firmware which doesn't bother doing security checks. But, can the NAND even be accessed from wii game mode?)
The raw NAND (encrypted sectors) can be accessed by any game, but that is not useful unless you know the encryption key (which is hard to get). Aside from that, games can access certain parts of the filesystem on the NAND -- specifically, the files that "belong" to that game. Bushing 05:22, 13 February 2008 (PST)
  • Some games do firmware updates. 142.59.172.116 01:58, 13 February 2008 (PST)
No, they don't. Games specify their required IOS version in the TMD -- when the system menu detects that a game requires a version of IOS that you don't already have installed, it checks to see if the disc also contains an update partition. If so, it installs the contents of the update partition before letting you run the game. Games themselves do not have permission to modify firmware. Bushing 05:22, 13 February 2008 (PST)
Actually, the system menu will check the game's update partition first, which contains a file describing the updates included with the game. It will apply these updates as long as they're newer than the versions on your Wii, whether the game actually requires them or not. Marcan 08:18, 13 March 2008 (PDT)
  • I thought there were a lot of different IOS 'versions'. Games that asked me to update were generally only games that also had a lot more in their update partition then just newer IOS versions (a lot of IOS versions and many more update files). Along the same lines isn't the IOS that comes with Zelda (that Zelda uses) very basic allowing only fairly little things (i.e. no USB / Wifi). (signature here :))?
There are. For example, Super Mario Galaxy comes with IOS versions 11, 12, 13, 15, 17, 20, 21, 30, 31, 33, 35, and it requires 35. (It also comes with a bunch of channels, etc, but that's not relevant -- your observation about large vs small update partitions is just coincidence.)
Okay maybe this is something simple but I don't get how the different IOS 'versions' work. Is version 35 'newer' than version 33 like firmware 3.4 is newer than 3.3? Or should I view them as seperate modules which can all be installed/uninstalled without interference? In the first case I don't understand why there are so many versions used (why not all install the newest), in the latter case I don't understand why SMG comes with so many versions when it only needs 35. Foobar.fighters 10:20, 9 December 2008 (UTC)
Yes, Zelda uses an old IOS version (15? don't remember). AFAICT, WiFi support is in all versions of IOS, even if the games don't use it -- the system menu uses it, and it needs to be able to phone home to get system updates. Likewise, everything supports raw USB, because that's how it communicates with the Bluetooth adapter. The glaring omission in Zelda's IOS is USB keyboard support -- we'd either need to write our own driver for USB HID (yech) or preferably find an exploit in a newer game, if we want to be able to use the keyboard. Bushing 04:53, 14 February 2008 (PST)
Zelda uses IOS9. Time has gone by, and we can now reboot to a newer IOS, so USB keyboard support is not a problem as long as the user has an IOS that supports it. Marcan 08:18, 13 March 2008 (PDT)
  • So basically our injected code running inside the game isn't allowed to touch things like the firmware?
More or less. The games aren't allowed to touch it, either, assuming the Starlet does its job correctly.
  • If we got the key somehow, is raw writing to the NAND possible, or only reading the encrypted data?
Writing may be possible, but it doesn't help unless you get the key "somehow". (Hint: That's very hard to do)
  • Supposing we just refused to update the firmware (not connecting to the Internet and using ISOs with the update partition removed, etc), would these restrictions stop us from doing other fun things, or do we basically have free reign over the rest of the machine? 142.59.172.116 15:09, 13 February 2008 (PST)
Refusing to update the firmware serves no purpose unless Nintendo does something to prevent homebrew from running -- it's not clear that that is possible, or worth their time. That has nothing to do with the second part of your question -- we have "free reign" in the sense that we can do anything a game can do, but we are restricted from modifying the way the system works (patching the system menu, installing new channels, etc.) Bushing 04:53, 14 February 2008 (PST)
  • Let me know if I understand correctly. The key that is used to decrypt/encrypt the firmware is unique to each console, and is in the OTP area accessible by starlet only?
Yes. Well, the key used to encrypt BOOT1 is common, but that's irrelevant because we can't modify BOOT1 as it is checked against a hash in OTP. The key used to encrypt the NAND filesystem is unique to each console. However, firmware updates as delivered over the network and on update discs are, of course, encrypted with a common key. Marcan 08:18, 13 March 2008 (PDT)
  • That's too bad. I was really hoping to see a linux penguin on one of my channel icons some time soon :)
Oh, that may very well come. Newer games like WiiFit install channels. We can also assume the system menu's permissions now, using some newly discovered /dev/es calls. We just need to figure out how to make channels :) Marcan 08:18, 13 March 2008 (PDT)
  • If/when a future system menu update blocks truchasigned discs, could the Twilight exploit be used to downgrade to a Trucha friendly system menu?
Maybe. Wait and see. Bushing 03:16, 29 March 2008 (PDT)
  • So IOS38 comes with Animal Crossing, If I let the disc run it's update, will it also update other things, or does it just add IOS38?... And if no one knows, how can I find this out for myself? --NikoKun 18:40, 24 November 2008 (UTC)
I went and ripped the update IOS files off the disc, and the __update.inf is dated 2008/09/17, and none of the october updates are included on the disk, nothing beyond ios38, so no 51 or whatnot. So would I be correct to assume that this disc update does not remove the fakesign bugs out of the important IOS files, since it's so old? I know this probably isn't the best place to ask, and some direction would be nice, but if someone sees this, that understands it, could I get some advice?--NikoKun 01:58, 25 November 2008 (UTC)
Ok, so I ran the disc update (from animal crossing) after I was confident enough with my findings. And sure enough, nothing from the October update was added that I can tell, and it was a ridiculously fast/small update, only appeared to add IOS38. Yay me. Anyway, this little segment I posted can be deleted if it doesn't need to be here.--NikoKun 02:47, 25 November 2008 (UTC)
  • Are there a fixed number of "slots" for storing different versions of the IOS software (eg 256 or something like that)? Also, where is the space allocated to store all the IOS versions? --korg 06:13, 26 November 2008 (UTC)
There are 256 slots usually used to refer to IOS versions, and I think they are fixed. IOSes are stored in the Wii's system memory. --FSX 09:33, 19 March 2009 (UTC)

Replacing IOS's?

If the IOS's are replacable, what prevents us from replacing the newer IOS's that fix the fakesigning bug with older copies that do not fix the fakesigning bug? —Preceding unsigned comment added by Keybounce (talk • contribs) 16:27, 16 September 2009 (UTC)

Dop-IOS/Dop-IOS MOD nothing. --Daid 16:28, 16 September 2009 (UTC)
Well, you do need to have at least one vulnerable IOS left, to install unsigned/fakesigned IOSes in the first place. .Hyper//Hacker 17:43, 16 September 2009 (UTC)
1. Only pirates need the trucha bug in all IOS, all others need it only in IOS36, if they need it at all. 2. Use the old IOS versions on a new Wii and enjoy a nice, not recoverable brick. 3. IOS37 and up never had the bug. Besides of that, you can't downgrade an IOS with normal methods, you need either an exploit for this, or you need to delete the IOS before downgrading. And deleting IOS requires an IOS with ES_Identify bug(and AnyTitle Deleter). PS: Deleting IOS is stupid and can brick Wiis easily. --WiiPower 20:33, 16 September 2009 (UTC)
Yeah. In summary, you can't downgrade an IOS to an older version without deleting it first; deleting it first is difficult. Even if you manage to accomplish this, that IOS may not run, depending on how new your Wii is, and it will get overwritten the next time you install an update. -- Bushing 11:11, 18 November 2009 (UTC)

IPC Question

  • The structure for an IOS IPC call has arguments. But each argument is only 4 bytes. Are these just pointers to the arguments, or something different?
Retrieved from "https://wiibrew.org/w/index.php?title=Talk:IOS/QA&oldid=93705"