The Mechanism for Boot1 to Choose Bootmii Instead of Boot2 May 26, 2009 02:18PM | Registered: 14 years ago Posts: 26 |
Re: The Mechanism for Boot1 to Choose Bootmii Instead of Boot2 May 26, 2009 03:22PM | Admin Registered: 15 years ago Posts: 271 |
17:50:54 <@bushing> TD-Linux: sure. boot2 -- as with all versions of IOS -- is actually 2 parts 17:50:57 <@bushing> 1) an ELF file 17:51:02 <@bushing> 2) a small stub that loads that ELF file 17:51:16 <@bushing> we replace #2 and then write it into an unused area of flash 17:51:23 < WiiPower> and how does it do that? I thought it's boo1->BootMii->backed up boot2 17:51:32 < TD-Linux> yes 17:51:38 <@bushing> so we don't even overwrite either of the copies of boot2 that are stored in flash 17:51:56 < TD-Linux> they only change the boot2 loader so it loads their copy 17:52:00 <@bushing> however, we have a block map in our copy of boot2 that has a higher generation number than the other two copies, so it takes priority and the system sees it first 17:52:01 < TD-Linux> maybe we should come up with a new term 17:52:04 < TD-Linux> boot2a and boot2b? 17:52:18 < TD-Linux> bushing, oh what wait? 17:52:19 <@bushing> eh, loader and payload? 17:52:31 < TD-Linux> you don't have to erase the stub part at all? 17:52:53 <@bushing> lol we pulled a clever 17:53:11 < WiiPower> ahh, so if you would get a boot2 update by nintendo, it would get added, and boot1 just starts the latest found version? 17:53:18 <@bushing> we make a copy of boot2 with our loader (stub) and their ELF file, and we write it to unused blocks 17:53:25 <@bushing> yes, more or less 17:53:56 < TD-Linux> bushing, so you used a loophole in their filesystem? but boot2 isn't stored in the filesystem, is it? 17:54:48 <@bushing> TD-Linux: er, not quite. let me explain 17:55:47 <@bushing> a block is 64 pages of 2K -- so, 128K. the first 8 blocks are reserved for boot1 and boot2 (so, 1 megabyte) 17:56:12 <@bushing> the Wii can also have up to 80 bad blocks, so they have to account for that -- although the first block is never bad 17:56:23 <@bushing> so boot1 goes into the first block (block 0) 17:56:44 <@bushing> they then have 2 copies of boot2 in the remaining 7 blocks (blocks 1-7) 17:57:47 <@bushing> the first copy of boot2 starts at the "first valid block" in 1..7, and counts forward. the second copy starts at the "last valid block" in 1..7, and counts backward 17:58:05 <@bushing> boot2 takes up two blocks 17:58:51 <@bushing> so if all seven blocks are good (the most common case), you have the first copy of boot2 in blocks 1 and 2, and the second copy in 7 and 6 17:58:56 < TD-Linux> do blocks have physical significance on the nand like pages do? I assume you erase by pages 17:59:20 <@bushing> yes -- a block is defined as the minimum amount of data that can be erased at one time 17:59:25 <@bushing> so you have to erase an entire block at a time 17:59:36 < TD-Linux> oh okay, not a page 17:59:42 < TD-Linux> so what's the significance of a page then? 17:59:54 < Oliveira> 1 block = 128kbytes ? 17:59:59 < TD-Linux> do you read a page at a time or something? 18:00:04 < Oliveira> (I'm not considering ECC data) 18:00:16 <@bushing> Oliveira: yes. TD-Linux: generally, yes 18:00:32 < Oliveira> that explains the malfunction on that wii lol 18:00:36 < TD-Linux> the only flash I've really used that low level before was NOR flash 18:00:39 < Oliveira> 1 bad command= boot1 erased 18:00:44 <@bushing> you can read parts of a page, and you can write parts of a page, but there are some limitations (you can only write to one page in 4 separate accesses) 18:00:48 <@bushing> yup 18:00:53 <@bushing> aaaanyway 18:00:57 < TD-Linux> it had 16KB block sizes, and of course was read a byte at a time 18:01:08 <@bushing> here's how it knows what blocks out of those 1..7 to use: 18:01:34 <@bushing> there's a "bad block map" that is written at the end of a block --- it has a magic value, and then a generation number 18:02:13 < TD-Linux> I assume this takes away from the block's capacity right? it's not stored somewhere separate and magical 18:02:35 <@bushing> yes, but it's not much 18:02:41 <@bushing> it looks like this: 18:02:41 <@bushing> 00627c0: 26f29a40 1ee684cf 00000002 01000000 &..@............ 18:02:41 <@bushing> 00627d0: 00000000 01010101 01010101 01010101 ................ 18:03:34 <@bushing> the first 8 bytes are the magic value (that's how it gets recognized) 18:03:47 <@bushing> 00000002 is the generation number (more on this in a bit) 18:04:27 <@bushing> the rest show which blocks are valid. one byte per block. so this shows that block 0 is invalid, blocks 1,2,3,4,5,6,7 are valid, and then blocks 8... are invalid (01 = invalid, 00 = valid) 18:05:13 <@bushing> so boot1 scans the last page of each block in 1..7 to look for that magic marker, and then picks the one with the highest generation number 18:05:38 <@bushing> this NAND image also has 18:05:39 <@bushing> 00e67c0: 26f29a40 1ee684cf 00000003 01000000 &..@............ 18:05:40 <@bushing> 00e67d0: 00000000 01010101 01010101 01010101 ................ 18:05:47 <@bushing> so it will use that one -- but they're both the same 18:06:07 <@bushing> so it will try to load boot2 from blocks 1 and 2, and if that fails, it will try loading from 7 and 6 18:06:21 <@bushing> this leaves blocks 3, 4 and 5 unused 18:06:34 <@bushing> so we write our bootmii stub + boot2 elf to blocks 3 and 4 18:06:44 <@bushing> and then write this blockmap: 18:07:10 <@bushing> 26f29a40 1ee684cf 00000004 01010100 00000000 01010101 01010101 01010101 18:07:18 <@bushing> to the end of block 4 18:07:50 <@bushing> who can tell me why that works? :) 18:08:01 < Cattlesna> 4 > 3? 18:08:09 < Daeken> ... wow. 18:08:14 <@bushing> right, but why will that load our copy of boot2 but not theirs? 18:08:20 < Daeken> that's simple and elegant :) 18:08:30 < Daeken> invalid marks on the other blocks :) 18:08:49 <@bushing> this delayed our release by a good month or two, but we had to do it because otherwise we broke GameCube compatibility 18:08:51 < Cattlesna> one byte per block for a 0/1 value is quite wasteful 18:09:03 <@bushing> thanks Daeken :) the nice part is that we can just erase those two blocks of flash and it will go back to the way it was before 18:09:19 < Daeken> yea, that's pretty awesome 18:09:23 < Daeken> nice work 18:09:31 <@bushing> it was marcan or dhewg's idea 18:09:59 <@bushing> the problem with GameCube mode is that when it launches, it runs BC which runs boot2 which runs MIOS which runs the GC IPL which loads your game 18:10:20 <@bushing> BC is very similar to boot1, and in recent updates they fixed the fakesign bug there 18:10:30 <@bushing> (which was foreshadowing that they had fixed it in boot1, too) 18:10:50 < TD-Linux> but then why does BC not load bootmii? 18:10:58 <@bushing> because it has an invalid signature :) 18:11:08 <@bushing> so it falls back on the second copy 18:11:12 < TD-Linux> wow that's kinda silly 18:11:13 <@bushing> which is the original boot2 18:11:27 < TD-Linux> so does that mean on old wiis with non-updated BC, gamecube games fail? 18:11:32 < Oliveira> so it relies on updated BC ? 18:11:45 < Daeken> TD-Linux: don't see why, the signatures would match 18:11:55 <@bushing> no, because bootmii can detect GC mode and pass it through correctly 18:12:03 <@bushing> the problem was that BC was not detecting ANY valid boot2s 18:12:11 < TD-Linux> oh OK 18:12:11 <@bushing> (new BC) 18:12:34 < TD-Linux> why not just patch BC? 18:12:48 <@bushing> we argued about that for *weeks* 18:12:59 < Oliveira> would be inelegant ? XD 18:12:59 <@bushing> and that's what I originally wanted to do 18:13:10 <@bushing> but yeah ... there were several reasons 18:13:17 <@bushing> 1) what Oliveira said 18:13:21 < WiiPower> ok, now i see why the release took so long, but i also see that it's worth it, as it seems to be a very very nice solution 18:13:39 < Daeken> Oliveira: simpler is nearly always better, when you can manage it 18:13:54 <@bushing> 2) if nintendo updated BC again, then we'd have to go and repatch it. this avoids that 18:14:17 < Oliveira> PSP devs were promissing their own OS back in 2007 we're in 2009 and nothing ever happened ... look what the wii scene have now ... lol 18:14:39 <@bushing> 3) before, in order to uninstall boot2 (legally) we had to write a backup copy of the original boot2 stub/loader to SD, and you needed to provide that. with this, we just erase two flash blocks and it's uninstalled 18:14:40 < TD-Linux> we don't really have our own OS yet 18:14:45 < TD-Linux> mini begins that 18:15:22 < Oliveira> the framework is being built... onm the PSP it didn't even get started. that's what I meant 18:15:41 <@bushing> the thing is, this only works if you start with a valid, unpatched boot2 ... everyone that tested bootmii for us (10 people?) before we switched installation methods had to go back and use a WAD (*gasp) in order to get this to work 18:15:42 < Oliveira> even thought the hackers had control over the boot chain 18:15:47 < Daeken> man, i really need to get a wii so i can contribute in some way :P 18:15:53 <@bushing> that's why we couldn't release a beta before we got this working 18:16:14 <@bushing> because we didn't want half the people to have to completely uninstall in order to update to the next beta 18:16:42 <@bushing> TD-Linux: so even though this was harder than patching BC, it had some advantages 18:17:05 < PhxTank> more short term work for long term benefit. 18:17:21 < PhxTank> makes sense 18:17:31 <@bushing> the final straw was when I was doing some testing, and had ES_ImportBoot write a version of boot2 to flash without writing the ECC data. (if boot1 sees uncorrectable ECC errors, which it would, it just ignores the ECC data and tries to load it anyway) 18:17:53 <@bushing> I don't know why it did that and I can't reliably reproduce it 18:18:11 <@bushing> but some people in the field have seen it -- I've gotten dumps from people which had that, too 18:18:27 <@bushing> but that convinced me that we had tested OUR code at least as well as Nintendo did, so .... 18:18:49 < TD-Linux> hah maybe they won't be updating boot2 in the near future 18:19:12 <@bushing> yeah, I don't know if they will or not. I look forward to seeing if they try ... 18:19:27 <@bushing> and it still booted, etc, because it just ignored the missing ECC data 18:19:38 <@bushing> you wouldn't know unless you bothered to look at the flash dump with a hex editor etc 18:21:03 <@bushing> but yeah, when we did that, we really just rewrote the whole installer :/ 18:21:14 <@bushing> (and included support for HBC and DVDX) 18:21:35 <@bushing> the fact that they blocked /dev/flash in new IOSes slowed us down, too 18:21:47 <@bushing> so we then had to reboot into MINI, dump flash to RAM, then go back into IOS 18:22:01 <@bushing> (for some Wiis) 18:22:24 <@bushing> and repeat that to write it out, of course 18:27:23 < WiiPower> Hmm, the patched BC seeing and skipping the trucha signed BootMii 18:27:54 < WiiPower> shoudln't that think that the other boot2s are inside broken blocks? 18:28:25 < WiiPower> so nintendo is nice that they try to start them 18:28:29 < Daeken> WiiPower: no, because it will ignore the block containing the block map. 18:28:47 < Daeken> that's why the redundancy of the block map is so important for it to work properly 18:28:48 < WiiPower> does the block contain the signature? 18:29:21 < Daeken> sounds like it to me 18:29:27 *** AlexLH ~alexlh@ip68-98-113-91.ph.ph.cox.net has quit [Quit: BootMii is teh awsum] 18:29:28 < Daeken> bushing: is that correct? 18:30:29 <@bushing> hm? i'm not sure I understand 18:30:35 <@bushing> we mark the original first copy of boot2 as bad 18:30:42 <@bushing> and leave the original second copy of boot2 as good 18:30:47 < Daeken> ahh... i see 18:30:56 < WiiPower> ? 18:31:01 < WiiPower> now i'm confused 18:31:15 < Daeken> so it sees the bad signature on your boot2 replacement and goes to the original that's aftr it 18:31:28 <@bushing> no, the block map is just at the end of the block (any block) 18:31:30 < WiiPower> but i'm tired, which is most likely why i don't understand 18:31:47 < WiiPower> ahh 18:31:53 < WiiPower> no 18:32:20 <@bushing> Daeken: right. so we found a behavior difference between boot1 and BC and exploited it for the sake of compatibility 18:32:43 <@bushing> (sort of -- if they behaved the same, there would be no need to do this workaround) 18:32:59 < Daeken> got it 18:35:16 < WiiPower> so to summarize if the question comes up in the future, BootMii is installed as boot2, leaves the original boot2 where it is, but tricks the wii to think it's in bad blocks which is why BootMii gets started 18:35:19 < WiiPower> ? 18:39:12 < WiiPower> BootMii is installed additional to boot2, leaves the original boot2 where it is, tricks the wii to think the real boot2 is in bad blocks, which is why the wii starts the backup copy of boot2 which is BootMii then* 18:40:00 < WiiPower> even if that should not be 100% truth, i think it's closer as BootMii overwrites boot2 18:42:03 < kennyboy> so in conclusion.. bootmii tricks boot2 xD.. 18:42:54 < SquidMan> bootmii pwnd boot2 18:43:25 < kennyboy> indeed 18:45:11 <@bushing> WiiPower: yes, although bootmii is only a modified version of boot2 18:45:32 <@bushing> technically, we could make bootmii load one of the other copies of boot2 from flash and run it instead of concatenating the two together, but meh 18:46:01 < TD-Linux> bootmii tricks boot1, not boot2 ;) 18:46:16 < WiiPower> "only"... 18:46:35 <@bushing> well, I just wanted to be clear that bootmii doesn't really modify the behavior of the rest of the system 18:46:48 <@bushing> the bootmii stub, the part that's in flash 18:46:55 <@bushing> not to be confused with the thing that's on the SD 18:47:43 < TD-Linux> the thing on SD should be given a different name 18:47:46 < WiiPower> BootMii would work if the other blocks were really ALL bad? 18:47:54 < TD-Linux> or the modified boot2 should be given a different name 18:48:31 < Oliveira> if I understood well, the stuff on SD are MINI and Bootmii-PPC 18:49:05 < kennyboy> stub (loader) is standing in some kind of fork on the road.. then boot1 comes up to it and asks where it needs to go.. and the stub decides (bootmii left, wii right.. ) 18:49:51 <@bushing> TD-Linux: yes, that's why the ppc code on the SD is called "ceiling cat" 18:49:58 < TD-Linux> and armboot.bin (which is mini + PPC loader right) 18:50:11 <@bushing> because we asked segher what we should name it and that's the name he chose because he picks the best names evar 18:50:23 <@bushing> WiiPower: which other blocks? 18:50:35 < WiiPower> 1,2,5,6,7 18:50:41 <@bushing> TD-Linux: armboot.bin is MINI, straight up 18:50:45 <@bushing> yes, it would work 18:50:51 < TD-Linux> how does it know to load Bootmii-PPC then? 18:50:55 < WiiPower> ok, now i understand more 18:51:32 <@bushing> [gitweb.bootmii.org] 18:52:13 < WiiPower> that's mini's main, right? 18:52:30 < TD-Linux> return vector; 18:52:32 < WiiPower> it loads the ppc.elf and then "does its stuff"? 18:52:36 < TD-Linux> what kind of hackery is going on there? 18:53:38 < TD-Linux> bushing, so there is currently no way to reload mini without reloading ppcboot.elf? 18:55:45 <@bushing> TD-Linux: correct 18:56:04 < TD-Linux> I hope it has decent ways to reset itself then... I haven't looked at most of that code 18:56:17 <@bushing> reset itself? 18:56:30 < TD-Linux> like if you load a different PPC binary 18:56:46 <@bushing> here, look at [gitweb.bootmii.org] 18:56:52 <@bushing> the bottom, boot2_ipc
Re: The Mechanism for Boot1 to Choose Bootmii Instead of Boot2 May 26, 2009 05:25PM | Registered: 15 years ago Posts: 1,012 |
Re: The Mechanism for Boot1 to Choose Bootmii Instead of Boot2 May 27, 2009 02:12AM | Registered: 14 years ago Posts: 26 |
Re: The Mechanism for Boot1 to Choose Bootmii Instead of Boot2 May 27, 2009 10:46AM | Admin Registered: 15 years ago Posts: 16 |
Re: The Mechanism for Boot1 to Choose Bootmii Instead of Boot2 May 27, 2009 03:31PM | Registered: 14 years ago Posts: 26 |
Quote
dhewg
Please do not release an app which wipes critical NAND blocks, that is highly dangerous. Oh, and hardcoding block #3 and #4 is like the worst idea ever :P
Our installer already has an uninstall procedure for BootMii/boot2, and it does a shitload of checks before erasing anything. It will be part of the beta2 release, a little patience please.
Thanks