The authtoken’s hidden strength!

I was wrong about the authtoken.

Earlier, I thought the Wii could decrypt the authtoken - that’s why the wii quits without using it for authp. I spent a great deal of time searching the game’s code for the key to decrypt it. But, on closer look of the Wii’s network traffic, I noticed something.

After the wii received the authtoken from naswii.nintendowifi.net, it then logged in at gpcm.gs.nintendowifi.net using the authtoken, then afterwards logged in gamestats with the authp command. The gpcm login returns the profileid inside the authtoken. If I replace the challenge & authcode from naswii with a pair from somebody else, then the profileid received from the gpcm login will be different from my normal profileid of 249190728. When I intercept this gpcm login and change whatever profileid that comes back, into my profileid, the wii will continue to login to authp and go fully online.

This tells me 2 things:

1) The wii has my profileid in its savedata

2) The wii cannot decrypt the authtoken, the check it was doing was seeing if gpcm’s profileid response was equal to what it had in the savedata.

So… I do not have the key to the authtoken at all! The encrypt-key is at naswii.nintendowifi.net and the decryption-key is at gpcm.gs.nintendowifi.net. Suddenly, the authtoken that I thought was so weak has risen to undefeatable. I have high confidence that the charset I’m seeing in the various authtokens I’ve seen are created from AES encryption; which takes longer than 100 years to brute-force.

So now the only avenue left to me, is to figure out the pattern from my earlier post about inputs to generate a particular pauthr. Unless I can get the keys I need out of those servers somehow, I need to figure out how to get naswii to produce the authtoken & challenge for a particular profileid.

yikes! >_<