BootMii as boot2 on new Wii's

Basically, that number is an upper bound. The first key tried might actually be it, but the last key is just as likely to be.

If you could find a way to guesstimate, based on the public key, what the private key is likely to be in the range of, things would speed up.

I am new to hacking the Wii so this is probably a dumb question but I would like to know the answer anyways.

Is the private key that unlocks boot2 unique to each Wii, or if you successfully bruteforced one Wii would you be able to unlock boot2 on all Wii's?

elmoreas

Yes. If you found the private key, you could have bootmii boot2 on all wiis. It is not unique to each wii.

If we found that private key, we could sign anything. Channels, saves, the like. We could do anything that Nintendo could.

Quote
WikiFSX
If we found that private key, we could sign anything. Channels, saves, the like. We could do anything that Nintendo could.

Meaning that provided we can run code somehow (you'd still need an exploit for this) we could do anything, install anything, modify anything. Basically, it would be the single greatest achievement of Wii hacking. But it is incredibly unlikely.

Just a thought (which doesn't probably work because it's so obvious, so someone must have thought about and done it already if it would work, but I have to mention it anyway because ***if*** it will work and I just sit and hold the information for myself that would be just horrible):

If I understand things correctly the fakesigning bug works as follows:

The Wii checks whether 2 strings (=keys) match using strcmp() which tells whether they match if the first x characters in the strings match, where x is the length of the shortest string and neither string must be an empty string. This would mean that "WiiProgrammingIsFun" and "W" would be considered matching, so all that has to be done to fakesign is try every 1 character long key until it matches, which would take a maximum of 256 tries if I've got things right (since a 1-byte-character can be 1 of 256 possible values).

In this case, we could think of "WiiProgrammingIsFun" as the private key. Then, wouldn't we know the first character in the key and can just contrinue testing every key starting with"W" and wait until we find the second character of the string (in maximum 256 tries), then repeat the process, starting with "Wi" until we have the whole private key? This way, we could find the private key with maximum only 256*256=65536 (the number of bytes in a 2048-bit-key times the number of possible values of each byte) tries, which is far (FAR!!!) less than the billions of billions of billions of billions of billions of billions of billions... of tries it would take to guess it "the natural way".

Edit: Reworked calculations



Edited 1 time(s). Last edit at 01/22/2010 02:24PM by profetylen.

Quote
profetylen
Just a thought (which doesn't probably work because it's so obvious, so someone must have thought about and done it already if it would work, but I have to mention it anyway because ***if*** it will work and I just sit and hold the information for myself that would be just horrible):

If I understand things correctly the fakesigning bug works as follows:

The Wii checks whether 2 strings (=keys) match using strcmp() which tells whether they match if the first x characters in the strings match, where x is the length of the shortest string and neither string must be an empty string. This would mean that "WiiProgrammingIsFun" and "W" would be considered matching, so all that has to be done to fakesign is try every 1 character long key until it matches, which would take a maximum of 256 tries if I've got things right (since a 1-byte-character can be 1 of 256 possible values).

In this case, we could think of "WiiProgrammingIsFun" as the private key. Then, wouldn't we know the first character in the key and can just contrinue testing every key starting with"W" and wait until we find the second character of the string (in maximum 256 tries), then repeat the process, starting with "Wi" until we have the whole private key? This way, we could find the private key with maximum only 256*256=65536 (the number of bytes in a 2048-bit-key times the number of possible values of each byte) tries, which is far (FAR!!!) less than the billions of billions of billions of billions of billions of billions of billions... of tries it would take to guess it "the natural way".

Edit: Reworked calculations

I think I understand, but just to clarify: Currently, using trucha bug, we install fakesigned content by having the first character bruteforced and then sticking a 0 after it. You're saying we have the first character, so we put that in, then another character, then a 0. And we try all possibilities for the second character until it is accepted. Then we move onto the third, and so on. Am I correct?

This seems like a brilliant idea, although I would have thought that if it were going to work, TT would have thought of this by now. But if not, this is absolutely genius. I cannot see any reason for it not to work, although that could just be my n00bish-ness in regards to hacking and cryptology.

We could even speed up the proccess by linking many computers together and using the spare processor to create on semi super computer. sorta like this.

Quote
Crisco
We could even speed up the proccess by linking many computers together and using the spare processor to create on semi super computer. sorta like this.

I'm not sure we could. I think we may need to run the bruteforcer on the Wii, so we can see if the signing is successful. Anyway, with such a relatively small number of possibilities, it would probably take at most a couple of weeks if this method were to work.

@SifJar: Yes, that is what I meant, if you by 0 mean a null-byte. I don't see a reason why it wouldn't work either, but I'm not 100 % sure that the fake-signing bug works the way I described either. Also I don't remember exactly how RSA works either, so i guess I'll read up on it and the fake-signing bug now!

@Cirsco: If things works the way I hope they do, there's not even a need for speeding things up since we only need a maximum of 65536 signing tries and I'd say every try would take a maximum of 10 seconds (and probably much less), we could have the key in less than 181 hours = 1 week and 12 hours with only 1 console from the point we have created the program that does the sign check.

Edit: spelling



Edited 2 time(s). Last edit at 01/22/2010 07:32PM by profetylen.

Quote
profetylen
Just a thought (which doesn't probably work because it's so obvious, so someone must have thought about and done it already if it would work, but I have to mention it anyway because ***if*** it will work and I just sit and hold the information for myself that would be just horrible):

If I understand things correctly the fakesigning bug works as follows:

The Wii checks whether 2 strings (=keys) match using strcmp() which tells whether they match if the first x characters in the strings match, where x is the length of the shortest string and neither string must be an empty string. This would mean that "WiiProgrammingIsFun" and "W" would be considered matching, so all that has to be done to fakesign is try every 1 character long key until it matches, which would take a maximum of 256 tries if I've got things right (since a 1-byte-character can be 1 of 256 possible values).

In this case, we could think of "WiiProgrammingIsFun" as the private key. Then, wouldn't we know the first character in the key and can just contrinue testing every key starting with"W" and wait until we find the second character of the string (in maximum 256 tries), then repeat the process, starting with "Wi" until we have the whole private key? This way, we could find the private key with maximum only 256*256=65536 (the number of bytes in a 2048-bit-key times the number of possible values of each byte) tries, which is far (FAR!!!) less than the billions of billions of billions of billions of billions of billions of billions... of tries it would take to guess it "the natural way".

Edit: Reworked calculations

[wiibrew.org]
it's not that simple because those are not keys that you are comparing but hash values (the decrypted value from the header and the one computed on the content).

see [en.wikipedia.org]
without the private key, you cannot encrypt anything valid, you can only decrypt the header value with the public key to check if decrypted hash matches the content computed hash so, to fake a signature, you have to modify bytes in the content and the encrypted hash until both match.

the bug(s) was used to reduce the number of tries, that's all, it does not give you anything but a content with a hash matching the decrypted value.

the only way to have the private key and encrypt (sign) stuff is to try every possible keys to encrypt something until decryption return the intial value , which would take you many many years.



Edited 2 time(s). Last edit at 01/22/2010 07:44PM by ekeeke.

Again another noob with another "?possibility?".

If I understand the privated key correctly, it is the same on all Wii's so the same code and encyrption is used on each Wii.

Instead of linking PCs to bruteforce one Wii why not try the opposite, in a sense anyways. Have people run a bruteforcer on their Wii when they are not using it and have their PC's linked only to share what keys have been tried so the same key is not tried twice accross the network. Granted this would still take a very very very very long time, but it increases your chance of hitting the key at random with each new person who donates their Wii's down time over time.

Or

We could always hire a super ninja spy to steal it from Nintendo HQ. jk ;) Hey that would make a good homebrew game. Get the Wii Private Key.

Anyways back to my point could you not do the reverse of linking multiple PCs to one Wii and run Multiple Wii&PCs in tadom accros a network? Just a thought.

Elmoreas

The Wii itself knows absolutely nothing about the private key, and is much slower. Using BOINC (as someone else said) is actually the best idea for a bruteforce.

A bruteforce is a bad idea.



Edited 1 time(s). Last edit at 01/23/2010 03:44AM by WikiFSX.

Oh sorry I must have missed that post. So I guess my idea is a no go. But that was to be expected. Oh well there is always option number 2.....

Elmoreas

@ekeeke: That's too bad! Thanks for explaing it however! :)

@profetylen: It's impossible to find out if any part of the key is correct. We can either know that it is 100% wrong or 100% right, for the most part.

Quote
WikiFSX
@profetylen: It's impossible to find out if any part of the key is correct. We can either know that it is 100% wrong or 100% right, for the most part.

The most part? When can we?

I don't think that we ever can. I was just unsure.

Quote
WikiFSX
I don't think that we ever can. I was just unsure.

Ok! Thanks for explaining! :)

If we have the hash of the encrypted contents, and can generate the hash of decrypted contents, by downloading a title with NUSD and decrypting using common key, can we not somehow compare the two and calculate from that the key required to encrypt it? I'm guessing if this was possible the encryption would have been cracked years ago, but I figured I'd still ask...