Reading in Bootmii.org, I was told Bootmii and Priiloader do their things in completely different ways. Bootmii patches itself in boot2 to work properly, right? But where do Priiloader patches itself? According to Wiibrew Wiki: "Priiloader places itself in boot sequence before the system menu", but I would bet it isn't in boot2, otherwise it wouldn't work in any console that had the fixed (newer) boot1. So, would it be right after the moment the system menu starts the PPC?

Quote
Aobx
Just thinking, you cannot modify the boot1 EEPROM, since it would be detected by the boot0 hash check and the system would halt. But why can't you modify boot0, since nothing checks it? Is boot0 stored in a kind of memory that isn't erasable?

Anyway, wouldn't be the best way to create a vulnerability. Seems not easy to erase and rewrite in a EEPROM. Not the kind of thing everyone can do.

I guess this question came unnoticed, since it was made in the middle of another discussion, but if you could me on that too, I'd be grateful.

Quote
Aobx
Reading in Bootmii.org, I was told Bootmii and Priiloader do their things in completely different ways. Bootmii patches itself in boot2 to work properly, right? But where do Priiloader patches itself? According to Wiibrew Wiki: "Priiloader places itself in boot sequence before the system menu", but I would bet it isn't in boot2, otherwise it wouldn't work in any console that had the fixed (newer) boot1. So, would it be right after the moment the system menu starts the PPC?

Priiloader renames the system menu and gives its own executable the name that the system menu previously had. Then, when boot2 runs, it loads Priiloader instead of the system menu.

Quote
Aobx

Quote
Aobx
Just thinking, you cannot modify the boot1 EEPROM, since it would be detected by the boot0 hash check and the system would halt. But why can't you modify boot0, since nothing checks it? Is boot0 stored in a kind of memory that isn't erasable?

Anyway, wouldn't be the best way to create a vulnerability. Seems not easy to erase and rewrite in a EEPROM. Not the kind of thing everyone can do.

I guess this question came unnoticed, since it was made in the middle of another discussion, but if you could me on that too, I'd be grateful.

Boot0 is stored in one time programmable memory. There is no way to modify it.



Edited 1 time(s). Last edit at 06/08/2010 04:22PM by jbc007.

Thanks for answering, jbc. I wonder if a system menu reinstallation could really "uninstall" everything, as the dev suggest. If the old system menu is renamed, wouldn't the reinstalled system menu just overwrite Priiloader and leave the old system menu alone? Not that the reinstallation wouldn't work, but is there a chance to have an old and inactive system menu taking up space in the NAND (since 512mb is so little space)? Unless the overwrite process isn't hardcoded, but since Ninty lets so many things pass up. Or maybe the upgrade code overwrite an entire paste where all the system menu files are included, even Priiloader and the old system menu. Is something like that?

Apparently, installing a system menu will delete Priiloader as well as the old system menu, although I have never found an explanation of how that works. However, at least with Preloader and probably Priiloader too, some files, such as the hacks and any installed .dols, are not deleted by installing a new system menu. The size of such files is usually small, so they can easily go unnoticed. However, they can be removed with a program called NANDClean. The Priiloader uninstaller may also remove all files associated with Priiloader, but I'm not sure.

That means a person has to deactivate hacks before reinstalling the system menu, or he/she will to reinstall Preloader again just to deactivate them? So that's the reason for NANDClean. Also, I've never heard about a Priiloader uninstaller, always thought you had to overwrite the system menu for this.

Since we were talking about how far can Priiloader offer brick protection, and a missing/corrupted system IOS is beyond that reach, I turned my attention to SaveMii(Frii). Can't it autoboot the update partition of a game which has the system IOS needed?

SaveMii(Frii) boots the Recovery Menu, which is a feature of the System Menu. If the System Menu cannot boot, then SaveMii(Frii) is completely ineffective. You may ask "Then what's the point?": It can fix bricks caused by out-of-region updates (these initially start as semi-bricks I think, but can become more, according to the WiiBrew page on bricks), and if you have a modchip, you can make an autoboot homebrew disc with AnyTitle Deleter to delete channels with bad banners causing banner bricks, or MyMenuify to recover original System Menu theme recovering from a brick.

So its uses are limited, and it cannot be used as you suggested.

Regarding Priiloader uninstallation: When the System updates a title, I believe it completely cleans out the folder on NAND where it was stored first (in this case I believe that is /title/00000001/00000002/), thus removing the old System Menu .DOL and the Priiloader .DOL. However, hacks and installed DOL are not stored here, so are not deleted by System Menu update.

In other words, missing/corrupted system IOS can only be recovered with Bootmii/boot2, right? A semi-brick wouldn't be much of a problem with a functional homebrew channel. If you are on a lower version of a system menu, you can even upgrade through disk channel, rendering SaveMii(Frii) useless. Otherwise, it would be a good idea. Interesting knowing about that use for a modchip, but with those new D3-2 drives this seems to be not the perfect sollution for brick protection. Fixing that boot1 is pretty mean from Nintendo, since Bootmii isn't related to piracy. Also, homebrew serves right both the user and Nintendo, since it gives to the console functions a user wants, at the same time that Nintendo doesn't have to pay royalties for the same function. Of course, there's piracy, but I think Nintendo is attacking the wrong apps.

How come a semi-brick can evolve to a full brick? I mean, I've never heard of the console making auto-modifications on itself, every modification comes from the user (either prompting him/her to do it or made from homebrews). I don't understand. Also, I've read from Wiibrew Wiki that SaveMii(Frii) can do something when only SYSCONF is screwed up. The autoboot disk talked about is a custom made or the one from Nintendo?

Quote
Aobx
In other words, missing/corrupted system IOS can only be recovered with Bootmii/boot2, right?

yes

Quote
Aobx
A semi-brick wouldn't be much of a problem with a functional homebrew channel. If you are on a lower version of a system menu, you can even upgrade through disk channel, rendering SaveMii(Frii) useless. Otherwise, it would be a good idea.

No brick protection can be all that useful for semi-bricks, as they can always be fixed. However, out of region updates can (usually?) cause full bricks. In such a situation, SaveMii(Frii) is quite useful.

Quote
Aobx
Interesting knowing about that use for a modchip, but with those new D3-2 drives this seems to be not the perfect sollution for brick protection.

Actually, there is a mod chip like device that works on wiis with D3-2 drives, but I won't name it here as it pertains to piracy.

Quote
Aobx
Fixing that boot1 is pretty mean from Nintendo, since Bootmii isn't related to piracy.

Although Bootmii is not intended as a piracy tool, it breaks all security on the wii. Even if Nintendo fixed the bug used by Trucha Bug restorer and the pirates never found a suitable replacement (without the trucha bug or other IOS exploits only Team Twiizers knows of, software based piracy is impossible), software based piracy will continue as long as Bootmii exists.

Quote
Aobx
Also, homebrew serves right both the user and Nintendo, since it gives to the console functions a user wants, at the same time that Nintendo doesn't have to pay royalties for the same function. Of course, there's piracy, but I think Nintendo is attacking the wrong apps.

Most of us here probably agree with that, but if homebrew didn't exist, software based piracy wouldn't exist either. Furthermore, every minute that people use homebrew is a minute they are not playing games that they have to pay for. Nintendo probably feels that this reduces game sales.

Quote
Aobx
How come a semi-brick can evolve to a full brick? I mean, I've never heard of the console making auto-modifications on itself, every modification comes from the user (either prompting him/her to do it or made from homebrews). I don't understand.

If I understand correctly, it has to do with corruption of the SYSCONF. When you turn on a wii for the first time or after formatting it, it performs a setup (I'm not sure, but maybe some issue related to the semi-brick could also make it perform the setup). If the wii is semi-bricked (meaning the console area setting and the system menu region are different), it will perform the setup for the wrong region. As I understand it, this puts certain critical files in the wrong places, so the wii can't find them when it boots. This causes the opera error message when the wii boots. Full brick.

Quote
Aobx
Also, I've read from Wiibrew Wiki that SaveMii(Frii) can do something when only SYSCONF is screwed up.

Yes, it does work when the SYSCONF is screwed up, provided the system menu and its IOS are intact. Under the right circumstances, it can be used to fix the opera brick I described above.

Quote
Aobx
The autoboot disk talked about is a custom made or the one from Nintendo?

Either. The one from Nintendo can not be obtained legally, so it is unsupported here. It does not work on system menu 4.0 and higher, as it uses IOS 16, which Nintendo stubbed with the 4.0 update since previously it was pirated to enable more piracy. Homebrew autoboot discs can be far more useful than Nintendo's, and they generally are preferred. However, they must be fakesigned, so they won't work on system menu 3.3 or higher unless the system menu IOS is trucha patched.

Thanks for answering that much, jbc. In fact, I've read about three modchips that work on D3-2, but none of them work using dvds. I thought D3-2 itself already refused to read any dvd, isn't it that way? Wouldn't that mean no modchip could ever work using dvds again?

Anyway, having the trucha signed system IOS plus an autoboot disk, which kind of recovery disk would you recommend? I've never heard of any disk regarded as brick protection, like Bootmii and Priiloader are.

Quote
Aobx
Thanks for answering that much, jbc. In fact, I've read about three modchips that work on D3-2, but none of them work using dvds. I thought D3-2 itself already refused to read any dvd, isn't it that way? Wouldn't that mean no modchip could ever work using dvds again?

Anyway, having the trucha signed system IOS plus an autoboot disk, which kind of recovery disk would you recommend? I've never heard of any disk regarded as brick protection, like Bootmii and Priiloader are.

You are correct, no modchips working with D3-2 drives work with discs, they use other methods. But they aren't really to be discussed here.

As for a recovery disc, depends on the brick. If its a banner brick from a bad channel, then either AnyTitle Deleter to delete the title, or the utility you used to install the channel to uninstall it again (won't be named here as the only one currently available is used for warez mainly). For a brick from a bad theme, MyMenuify to reinstall default theme, or to install a different theme. For an out-of-region update causing Opera error screen on boot, dop-Mii or a WAD installer to reinstall the correct System Menu.

However, it should be noted that a far better option is to have BootMii/boot2 and/or Priiloader as brick protection, rather than rely on brick recovery.

I learned from Bootmii.org that even Bootmii/boot2 isn't invincible, if a victim of "targeted attack". For all we discussed here, I can only imagine this attack overwriting boot2. Isn't this the only way?

Supposing the attack doesn't target Bootmii, but the system itself, it could delete the system IOS, for example. But how would someone be a victim of "targeted attack"? I can't imagine someone hacking your Wii by distance (maybe with Ftpii, if you're careless, but the distance would be short). I think the user has to be tricked into doing this attack on his/her own Wii. Is there a possibility for a IOS wad to delete things even during its installation? Or the installing procedure can't take files being deleted? I'd like to make clear this thing of "targeted attack".

I believe that refers to Nintendo removing things from or even bricking a wii when an update is performed. If Nintendo wanted to, they could release an update which would check for and delete all homebrew (this does not mean that it would be impossible to reinstall homebrew after the update). They have already done this to a certain extent, although they did a very bad job of it.

Nintendo could also release an update that would automatically brick any wii that has homebrew. Although it is believed that this will not happen, the 4.2 update already bricks region changed Koren wiis.

In any case, a "targeted attack" can not occur to any wii without its owner's consent. It also can not be done by anyone other than Nintendo unless, of course, the attacker has physical access to the wii. Therefore, there is absolutely nothing to worry about.

In theory, some asshole could release a bricker, but hopefully no-one with the knowledge to do so would be evil enough. I won't go into explicit details of how it would be done, but I feel its fairly obvious. It'd probably be released claiming to be something else (maybe some sort of warez thing if it was by some anti-warez person, that happened for DS, it was called r0mloader. There was also a hentai one. Neither were publicly released, only shared with one or two people privately IIRC), and people would run it.

I sincerely hope that the Wii scene never comes to that. As it is, get your downloads from a respectable source, and make sure you read that other people have used it first if you're worried.

Almost as I thought, good to see that no one other than Nintendo can brick your Wii if you think before doing certain things.

I was messing around with my Wii, and I tested something that I knew it would give me a code dump. I noticed that after a code dump (or even a plain black screen) your wiimote stops responding. Why does that happen? As for I know (learned from Wiibrew Wiki), apps, channels and games do not run on top the system menu; instead, the sm is closed and the desired application is loaded. Hence, the application is on its own with its used IOS. Would it be wrong to say the current IOS is called off, when a code dump occurs? In some cases, the app can reload and boot again, but it can't in others. Hard to understand.

I don't really know much about code dumps, but you are right that System Menu is not running while anything else is running. I'm not sure what you mean by "called off" in reference to IOS?

It's not a technical term. By "called off" I meant just "shut down".

Hmm, I don't think the IOS is shutdown completely, or there would be no visual output, and pressing reset could never return to HBC, because IOS handles communications between hardware (e.g. video out and reset button) and PPC. Not sure what does happen, but I don't think the IOS is shutdown.

Quote
SifJar
Hmm, I don't think the IOS is shutdown completely, or there would be no visual output

Only Broadway can use video output, Starlet can't use video output. IOS only provides a libusb interface for Bluetooth, Broadway handles communication with wiimotes through that libusb interface. When Broadway crashes, it has to shutdown the wiimote, since a DSI is a IRQ and Broadway/Starlet IPC uses IRQ.

Thanks for explaining, yellowstar. So the crash is in the Broadway, not in the IOS.

Just bumping for another question. I've been reading [wiibrew.org] and after talking with someone, came up the question: "How exactly the Wii detects a backup disk being not an original disk?" I thought about the encryption with the private key, to sign it as an original one. Is this right? When is the disk encrypted? During manufacturing? While being wrote with the game? There's something that doesn't go in a backup disk and therefore makes the difference.