Hacking KongsNutz IOS information thread.

[BenJeremy]

CIO36 is IOS249? Are they patches or extensions? What is the difference between a fakesign exploit and a banner exploit - i.e. why is the CIOS the most important thing?

Great questions. I'll take a stab:

CIOS36 is not really IOS249 per se. The Wii has IOS "slots" in which IOS'es can be installed. They are numbered from 0 to 254. Only the lower slots (61 and below) are currently used by legitimate Wii IOS'es. The rest are unused.

cIOS36 is a customized version of the legitimate Wii IOS version 36. Technically it could be installed into any unusued IOS slot, but it is most commonly installed into slot # 249. That then becomes IOS249.

The fakesign exploit came about when it was discovered that the Wii developers used a flawed version of the C string compare function (strncmp) to check the validity of content signatures. The function would check each character of the signature string until it reached the end of the string or until it reached a null byte. I think the issue here is that it did not check the length of the signature string to begin with. If you create a signature string with a null byte early in the string, the mathematical odds of it being seen as valid are much greater, since there are far fewer characters to compare (the strncmp function stops at the first null byte).

START SPECULATION
The banner exploit is new to the Wii and has not been publicly released yet. In general a banner exploit would be similar to other exploits on other systems where there is a flaw in processing graphic images (think TIFF exploit on PSP, BMP or PNG exploits on Windows, etc...). The exploit would likely involve an unchecked buffer and employ a stack or heap corruption method.
END SPECULATION

cIOS is important to softmodders because later versions included code to access DVD content from the Wii's optical drive. This allows the cIOS to be used to read burned games as DVD's. Additional PPC code (i.e. a "loader") is then used to tell the system to load the game from the DVD.

Whew...

Most of this I believe to be accurate, but there are always those who know it better

Thanks for taking a stab at these.

I hope this guide gets linked in the pinned "useful guides" topic.

 

[BenJeremy]

The fakesign exploit came about when it was discovered that the Wii developers used a flawed version of the C string compare function (strncmp) to check the validity of content signatures. The function would check each character of the signature string until it reached the end of the string or until it reached a null byte. I think the issue here is that it did not check the length of the signature string to begin with. If you create a signature string with a null byte early in the string, the mathematical odds of it being seen as valid are much greater, since there are far fewer characters to compare (the strncmp function stops at the first null byte).

Just a thought.... but why can't we generate valid signatures using the fakesigning bug? Start with a one character signature, until we get a valid one, then work in the next character... Maybe I'm off here, but couldn't we produce valid signatures using the 3.2 Wiis to figure out the full signature of a custom, downgrading IOS?

 

[fogbank]

Just a thought.... but why can't we generate valid signatures using the fakesigning bug? Start with a one character signature, until we get a valid one, then work in the next character... Maybe I'm off here, but couldn't we produce valid signatures using the 3.2 Wiis to figure out the full signature of a custom, downgrading IOS?

Well I think theoretically you could, but at this time it's not possible. Signing involves hashing the content, so the signature would be different for each individual title created. I believe that those who have tried have had trouble generating the correct hash from the content. Someone figured out the hashing algorithm but was unable to get their hashes to match known hashes. Without the correct hash you can't build a valid signature, even using the faksesigning bug to validate one character at a time.

This is stuff I'm pulling from memory so it may be a little off...

EDIT: Actually much of the response above is probably a little "off"... I would suggest you read the blogs at hackmii.com and the article below for more accurate and detailed info:

http://debugmo.de/?p=61

As far as I know we have no means (or hope) of creating a valid signature without the private key.

 

[Bloodlust]

CIO36 is IOS249? Are they patches or extensions? What is the difference between a fakesign exploit and a banner exploit - i.e. why is the CIOS the most important thing?

Great questions. I'll take a stab:

CIOS36 is not really IOS249 per se. The Wii has IOS "slots" in which IOS'es can be installed. They are numbered from 0 to 254. Only the lower slots (61 and below) are currently used by legitimate Wii IOS'es. The rest are unused.

cIOS36 is a customized version of the legitimate Wii IOS version 36. Technically it could be installed into any unusued IOS slot, but it is most commonly installed into slot # 249. That then becomes IOS249.

The fakesign exploit came about when it was discovered that the Wii developers used a flawed version of the C string compare function (strncmp) to check the validity of content signatures. The function would check each character of the signature string until it reached the end of the string or until it reached a null byte. I think the issue here is that it did not check the length of the signature string to begin with. If you create a signature string with a null byte early in the string, the mathematical odds of it being seen as valid are much greater, since there are far fewer characters to compare (the strncmp function stops at the first null byte).

START SPECULATION
The banner exploit is new to the Wii and has not been publicly released yet. In general a banner exploit would be similar to other exploits on other systems where there is a flaw in processing graphic images (think TIFF exploit on PSP, BMP or PNG exploits on Windows, etc...). The exploit would likely involve an unchecked buffer and employ a stack or heap corruption method.
END SPECULATION

cIOS is important to softmodders because later versions included code to access DVD content from the Wii's optical drive. This allows the cIOS to be used to read burned games as DVD's. Additional PPC code (i.e. a "loader") is then used to tell the system to load the game from the DVD.

Whew...

Most of this I believe to be accurate, but there are always those who know it better

Ok, just a quickie, for example is CIOS36.wad overwritten when IOS36-64-v1042.wad is installed over it?

 

[fogbank]

Ok, just a quickie, for example is CIOS36.wad overwritten when IOS36-64-v1042.wad is installed over it?

Assuming that you are referring to the CIOS36.wad from CIOSCorp then yes, installing IOS36-64-v1042.wad will overwrite the modified IOS36 from CIOSCorp with the authentic IOS36 v1042.

 

[fogbank]

Just a thought.... but why can't we generate valid signatures using the fakesigning bug? Start with a one character signature, until we get a valid one, then work in the next character... Maybe I'm off here, but couldn't we produce valid signatures using the 3.2 Wiis to figure out the full signature of a custom, downgrading IOS?

Ok, this may be a little better explanation (had to go back and re-read some of the info from long ago

).

This applies to game discs, but is probably relevant to adding other content to the Wii filesystem.

The signature is produced by hashing the content and encrypting that hash with the private key.

The exploit also takes advantage of the fact that the RSA decryption of an all zero encrypted message is all zeroes. If the encrypted signature is changed to all zeroes, it is decrypted to all zeroes, and the flawed hash verification (using strncmp) sees it as valid.

We cannot, however, manipulate the decrypted hash value because we don't have the private key. In order to do what you proposed we would need to create our own test hash values and encrypt them with the private key in order to make them decrypt to our original test hash values.


Of course if we had the private key we wouldn't need to do any of that anyway.

 

[BenJeremy]

Thanks for the replies.... I realized it wouldn't be that simple, but worth a mention, I guess.

Now I just have to wait patiently until somebody reveals an exploit that works on 4.0 firmware.