smtddr's notes

[Things I find interesting]

naswii’s login algorithm research

Hello again,

In the previous blog post, I mentioned that I could make almost arbitrary changes to the login parameters to naswii.nintendowifi.net, to give me write-access to different profileIDs.

Another bit of info I happened to run into purely by accident, is that someone out there somehow ran a very debugmode’ish SmashBrowsBrawl. I know it’s SmashBrowsBrawl because in the debug output, gamecd=RVL-RSBJ. Random googling is how I ran into http://pastie.org/pastes/511148/

There was alot of info in this log loading all kinds of game data, but only the network part is of interest to me:

    File Read (NAND): /net0.bin (size:10272 byte, adr:0×9264d7a0) at 2018
    << RVL_SDK - SO release build: Jun 28 2007 18:29:42 (0×4199_60831) >>
    << RVL_SDK - NCD release build: Jun 28 2007 18:29:29 (0×4199_60831) >>
    match status changed Link up
    << RVL_SDK - DWC release build: Dec 25 2007 17:12:24 (0×4199_60831) >>
    match status changed DWC ready
    DWC_UNKNOWN :*******************************
    DWC_UNKNOWN : [pseudo login id]
    DWC_UNKNOWN : LN_ID : 000000000RSBJ3rlgn2b
    DWC_UNKNOWN :+++++++++++++++++++++++++++++++
    DWC_UNKNOWN : [authentic login id]
    DWC_UNKNOWN : LN_ID : 4motnvmkhRSBJ3rlgn2b
    DWC_UNKNOWN :+++++++++++++++++++++++++++++++
    DWC_UNKNOWN : GS_ID : 130621302
    DWC_UNKNOWN :*******************************
    DWC_DEBUG :!!DWC_InitFriendsMatch() was called!!
    DWC_LOGIN :Login Init
    DWC_LOGIN :******************************************
    DWC_LOGIN : pseudo UserID : 0000000000000000
    DWC_LOGIN : pseudo PlayerID : f7585c4b
    DWC_LOGIN : authentic UserID : 000004b63b7fda91
    DWC_LOGIN : authentic PlayerID : f7585c4b
    DWC_LOGIN :******************************************
    DWC_DEBUG :ServerBrowserLimitUpdate timeout reset.(DWCi_MatchInit)
    DWC_DEBUG :!!DWC_LoginAsync() was called!!
    << RVL_SDK - SOCKET release build: Jun 28 2007 18:29:43 (0×4199_60831) >>
    DWC_DEBUG :!!DWC_UpdateServersAsync() was called!!
    DWC_DEBUG :But ignored.
    match status changed Wait login
    DWC_ACHECK :Confirmed the backend of GameSpy server.
    DWC_LOGIN :Start Remote Auth
    DWC_LOGIN : Hmm.. you already have authentic login id.
    << RVL_SDK - NHTTP release build: Jun 27 2007 16:27:59 (0×4199_60726) >>
    DWC_AUTH : url = https://naswii.nintendowifi.net/ac
    NCD proxy-settings are disabled
    DWC_AUTH : HTTP_X_GAMECD = RSBE
    DWC_AUTH : action = login
    DWC_AUTH : gsbrcd = RSBJ3rlgn2b
    DWC_AUTH : userid = 0×000004b63b7fda91
    DWC_AUTH : makercd = 01
    DWC_AUTH : macadr = 0017ab47d45a
    DWC_AUTH : lang = 01
    DWC_AUTH : CalendarTime = 000101000207
    DWC_AUTH : confmethod = 00
    DWC_AUTH : csnum = LU102325391
    DWC_AUTH : cfc = 0360566410380004
    DWC_AUTH : region = 01
<< RVL_SDK - SSL release build: Jun 21 2007 13:10:10 (0×4199_60726) >>
    DWC_AUTH : request_callback = 0
    DWC_AUTH : locator=Z2FtZXNweS5jb20*&retry=MA**&returncd=MDAx&token=TkRTMC9DTXlVVXVESVpVdmNIdlJBbFZ0dENudW16QTI3Qk9lUjVVYlpxZTRyNDFmM0dEMzM1T1pGa2ppVW9qd09CeHlKMUNNUlhKNzBxVzMzY1lWTEY3aTJibnRCSnZWTUQyR2E5anNPS3hVQTcxeGFjNjdBYWd6OW1Yd2dWNDlPUUE*&challenge=MjZKOEUwVFk*&datetime=MjAwOTA2MTQwMTM1NDg*

    DWC_AUTH : (11) locator=gamespy.com
    DWC_AUTH : (1) retry=0
    DWC_AUTH : (3) returncd=001
    DWC_AUTH : (131) token=NDS0/CMyUUuDIZUvcHvRAlVttCnumzA27BOeR5UbZqe4r41f3GD335OZFkjiUojwOBxyJ1CMRXJ70qW33cYVLF7i2bntBJvVMD2Ga9jsOKxUA71xac67Aagz9mXwgV49OQA
    DWC_AUTH : (8) challenge=26J8E0TY
    DWC_AUTH : (14) datetime=20090614013548
    DWC_AUTH :NHTTPDestroyResponse()
    DWC_AUTH :DWCi_Auth_EndProcess()
    DWC_LOGIN : *** Auth Done
    DWC_LOGIN :Succeeded to remote authentication.
    DWC_LOGIN :Finished connecting to GP server, result = 0
    DWC_LOGIN : gs profile id is valid.
    DWC_UNKNOWN : loginElapsedTime (1820 msec)
    DWC_UNKNOWN : login latencyy level = [1]

I was very surprised that the game was handling the 13 digit userid as an integer(made clear by the hex-repesentation of it while logging in). I surely expected it to be used as a string and was trying to reverse the login algorithm on that assumption. Apparently, on a Linux 32bit machine, this number must be stored in a double.

NOTE:——————————————————

This confused me at first, because I assumed int = 4 bytes, and long = 8 bytes. But in fact, BOTH “int” and “long” are four bytes! Why have both data types then??? Who knows, there must be some history to this. I just know, that on an Ubuntu 32bit machine, that’s how it is. Try it:

int main(int argc, char* argv[])
{
    printf(”%d\n”,sizeof(long));
    return 0;
}

This prints “4″. Change the “long” to “double”, then it’ll print 8. ———————————————————–

Anyways, seeing that the game handles this as a number not a string, I now know that I should do my research using a double to store the userid.

In the list below, on the left of the equal sign, is the profileID I have write access to. On the right, is the userid & gsbrcd I have to use to get said-access.

I don’t see a pattern yet, but I’m thinking about it. I know GameSpy engineers love their XOR’ing with seemingly arbitrary constants. They also enjoy doing purposefully integer-overflowing operations.

\pauthr\365053742 = 1608132906883 + emptyset
\pauthr\365053726 = 1608132906883 + s
\pauthr\365119857 = 1608132906883 + st
\pauthr\365119888 = 1608132906883 + stk
\pauthr\365053711 = 1608132906883 + stkj
\pauthr\365119939 = 1608132906883 + stkj0
\pauthr\365120008 = 1608132906883 + stkj0l
\pauthr\365120054 = 1608132906883 + stkj0lo
\pauthr\365120095 = 1608132906883 + stkj0lo4
\pauthr\365120141 = 1608132906883 + stkj0lo4c
\pauthr\365120186 = 1608132906883 + stkj0lo4c9
\pauthr\249190728 = 1608132906883 + stkj0lo4c9r

\pauthr\364633305 = 1608132906883 + 00000000000

\pauthr\365167273 = 7102253590412 + emptyset
\pauthr\365053742 = 1608132906883 + emptyset
\pauthr\365054954 = 1608132906882 + emptyset
(No authtoken) = 1608132906881 + emptyset

\pauthr\365053742 = 1608132906883 + emptyset
\pauthr\365053846 = 1608132906883 + A
\pauthr\365054388 = 1608132906883 + AA
\pauthr\365054411 = 1608132906883 + AAA
\pauthr\365054802 = 1608132906883 + AAAA
\pauthr\365054839 = 1608132906883 + AAAAA
\pauthr\365054683 = 1608132906883 + AAAAAAAAAAA
\pauthr\365054724 = 1608132906883 + AAAAAAAAAAB
\pauthr\365054891 = 1608132906883 + Z

\pauthr\365053742 = 1608132906883 + emptyset
\pauthr\365118842 = 1608132906883 + 0
\pauthr\365121176 = 1608132906883 + 00
\pauthr\365121484 = 1608132906883 + 000
\pauthr\365121616 = 1608132906883 + 0000
\pauthr\365121837 = 1608132906883 + 00000
\pauthr\365191280 = 1608132906883 + 000000
\pauthr\365191679 = 1608132906883 + 0000000
\pauthr\365191982 = 1608132906883 + 00000000
\pauthr\365192031 = 1608132906883 + 000000000
\pauthr\365192078 = 1608132906883 + 0000000000
\pauthr\364633305 = 1608132906883 + 00000000000

So, there it is. I’ve determined that this login-process is case-insesitive, so I lowercase everything.

Do you see a pattern? To get \pauthr\264646755 , do you know what gsbrcd & userid have to be? ^_^

My own “authentic login id” is 1epm31js3stkj0lo4c9r.

My theory is, based on the order data seems to be available in the debug logs, is that the string “1epm31js3″ + 249190728(my profileid), is used in some kind of computation to produce the userid 1608132906883.

The game then gives naswii my userid and the “stkj0lo4c9r” string, which clearly produce the profileID.