Boot2 Hash Question

From my understanding the new boot1 checks the hash value of the boot2 in order to make sure it has not been tampered with and will not allow booting of any code that does not have the value correct. This brings me to the two questions on this :

1. If the boot2 MUST have the same hash value then how is it that Nintendo can alter this file and still have the boot1 recognize it. If this is the case I would assume that the hash is not an exact value but a range of values determined by an algorithm, and that Nintendo would then have to insert dummy data in order to ascertain such a hash. Therefore would it be theoretically possible to find the algorithm that dictates the accepted hash values?

2. Hash values are mathmatically limited. Theoretically one could duplicate a hash, as it is not a true random and therefore must have a calcuable way of being duplicated. If this is in any way probable would the use of dummy data in the boot2 (after being altered with BootMii) be a way in tricking the boot1 into thinking that the boot2 is legitimate?

These are thoughts from my presumptions on what I understand of the internal workings of the Wii and from what I have seen that Nintendo can do with certain update capabilities. If these presumptions are faulty please let me know, if they are not then further discussion may be useful as I have a few professors at hand that love a challenge and may be willing to help in finding these values. (1 Prof is a cracker that retired from a cyber security company into teaching, 1 is a prob&stats / calculus instructor that loves a challenging problem, and the last is an electronic engineer.)

TY All and best of luck,
Ambedrake

boot2 doesn't have a hash, its signed by Nintendo and the signature is checked.

Then is it possible to find such a signature from the NAND dump that BootMii creates?

Ok so sorry for the ignorance of the previous post, my instructor that cracks for fun has informed me that using an exact match of Nintys sig is a copyright violation. Though he did give me an interesting idea. from previous research OTP memory can in turn be rewritten if altered to do so, is this a reasonable path to try? Also is there a way to dump Boot1 so that we can go through it with a fine toothed comb? And lastly I understand that boot2 is signed, but that signature is in its own location, would it be possible (and legal) to create a program that overwrote a portion of boot2 leaving the rest of it in tact and work to allow bootmii to boot before the rest of the code while placing bootmii into another seperate location in the NAND?

Quote

from previous research OTP memory can in turn be rewritten if altered to do so

OTP = One Time Programmable. So, no, you cannot write it. I even think they don't even know where it's physically located on recent board versions.

Quote

And lastly I understand that boot2 is signed, but that signature is in its own location, would it be possible (and legal) to create a program that overwrote a portion of boot2 leaving the rest of it in tact and work to allow bootmii to boot before the rest of the code while placing bootmii into another seperate location in the NAND?

That's how bootmii works. But it needs a signature which boot1 finds valid.

I think you need to read a bit more about crypto security. [en.wikipedia.org]
Without the private key from Nintendo there is little you can do, except exploit bugs (like the sign bug). And the private key is a close guarded secret, getting your hands on it might even break a few laws.

It would afaik be legal to have a properly signed boot2 (I dont see much difference between that and say, the new PSP Action Replay, which is properly encrypted to work on an unmodified PSP), as the signature is computer generated, and so can't be copyrighted.

However, the signature is not on the Wii. Because it is private key crypto (i think thats the right name), Nintendo have a private key, and Wii consoles have the public key (aka the Common Key, posted on HackMii ages ago and widely known). The public key can decrypt anything signed with the private key. Therefore no Wii needs to know the private key. Loads of stuff from the Wii can be decrypted using the common key, however, stuff cannot be signed with it. That is why we need trucha bug, which allows us to "fake sign" stuff, making the Wii think it has been signed with the private key.

Hope I have explained this well enough for you to understand, if not, sorry.

Mmk so now I think I understand this better, this is right up my crypto profs alley i'm going to see if he wants to make this part of his project list. TY and hope there's a new bug found in boot1 (though i doubt it)