Problems with ACCOUNTLOGONPROOF using MBNCSUtil

[Sveet]

my problem is that i see no problem and yet there is one somewhere.
my function is this:

Code Select Expand


private void C_SID_AUTH_ACCOUNTLOGONPROOF()
        {
            /*
             * C->SID_AUTH_ACCOUNTLOGONPROOF
             * 0x54
             *
             * (BYTE[20]) CLIENT PASSWORD PROOF
             */

            Packet p = new Packet(0x54);
            byte[] loginProof = new byte[20];
            nls.LoginProof(loginProof, 0, 20, serverSalt, serverKeyB);
            p.add(loginProof);
            Enqueue(p);
            Output("BNET", "SID_AUTH_ACCOUNTLOGONPROOF SENT");
        }


very simple, but every time i log into battle.net i have the problem that i get invalid password, even though i know its right and that everything is extracted correctly. i logged into battle.net regular and sniffed a set of real serverSalt and serverKeyB to test.

Code Select Expand


0000   ff 53 48 00 00 00 00 00 73 90 aa 92 c9 25 00 18  .SH.....s....%..
0010   b7 50 39 20 1f 0b 05 14 c5 db 5c 28 fc 08 ab fd  .P9 ......\(....
0020   73 1e fb f7 0f 3f 84 04 5b 16 ee c4 73 19 aa ea  s....?..[...s...
0030   02 15 46 3a d9 b5 6f 28 95 02 4a 49 ae 91 72 bb  ..F:..o(..JI..r.
0040   bc 56 96 bf 13 9e 0e 6b                          .V.....k


added them into the function manually,

Code Select Expand


            serverSalt = new byte[] { 0x73, 0x90, 0xaa, 0x92, 0xc9, 0x25, 0x00, 0x18, 0xb7, 0x50, 0x39, 0x20, 0x1f, 0x0b, 0x05, 0x14, 0xc5, 0xdb, 0x5c, 0x28, 0xfc, 0x08, 0xab, 0xfd, 0x73, 0x1e, 0xfb, 0xf7, 0x0f, 0x3f, 0x84, 0x04 };
            serverKeyB = new byte[] { 0x5b, 0x16, 0xee, 0xc4, 0x73, 0x19, 0xaa, 0xea, 0x02, 0x15, 0x46, 0x3a, 0xd9, 0xb5, 0x6f, 0x28, 0x95, 0x02, 0x4a, 0x49, 0xae, 0x91, 0x72, 0xbb, 0xbc, 0x56, 0x96, 0xbf, 0x13, 0x9e, 0x0e, 0x6b };


and then debugged to see what the result.

my client sent this:

Code Select Expand


0000   ff 54 18 00 9c ac 23 1f 7e 20 4c fa 9b e5 6a 23  .T....#.~ L...j#
0010   90 2c b0 56 fd 66 54 b1                          .,.V.fT.


and my bot builds this (just the logon proof):

Code Select Expand


[0x00000000] 0x11 byte
[0x00000001] 0x1e byte
[0x00000002] 0x12 byte
[0x00000003] 0xd8 byte
[0x00000004] 0x90 byte
[0x00000005] 0x23 byte
[0x00000006] 0xba byte
[0x00000007] 0xee byte
[0x00000008] 0xbe byte
[0x00000009] 0xe9 byte
[0x0000000a] 0x12 byte
[0x0000000b] 0xcf byte
[0x0000000c] 0x3f byte
[0x0000000d] 0x21 byte
[0x0000000e] 0x9c byte
[0x0000000f] 0xa7 byte
[0x00000010] 0x83 byte
[0x00000011] 0xbd byte
[0x00000012] 0x6d byte
[0x00000013] 0x2a byte



[Ribose]

Those values change every logon sequence (M[1], sent in SID_AUTH_ACCOUNTLOGONPROOF depends on A (which is basically a random number, but constant throughout each logon), B (which you receive), S (which you receive) and some other constants), so inputting your own from other logons will never work.

I can't see anything wrong with that code, however.

[MyndFyre]

There's not really a way to validate that you're not hitting an edge case in MBNCSUtil, however since I've never had this be a repeated problem for the same account (there is an occasional problem that cannot be addressed on the client side) I doubt it's the case.  More likely you're malforming 0x53 or 0x54 when sending them over the wire to Battle.net.

[Sveet]

i read that and it said bnet doesnt use SHA-1 for wc3, but rather SRP. is that true? if so, is there an implementation in BN# for that?

edit:: and also, should i be doing something with the server signature from 0x50?

[Hdx]

Standard SHA-1 is used in SRP, which is used by WC3.
The bug he was referring to was the one about it not zeroing it's buffer. Which is a rare case indeed.
What you need to do, is use a and B from 0x53 to form your M1 of 0x54.
Show us the full code and we can see.
Also, THIS DOSEN'T WORK on PVPGN servers cuz well, they suck.

[Sveet]

Standard SHA-1 is used in SRP, which is used by WC3.
The bug he was referring to was the one about it not zeroing it's buffer. Which is a rare case indeed.
What you need to do, is use a and B from 0x53 to form your M1 of 0x54.
Show us the full code and we can see.
Also, THIS DOSEN'T WORK on PVPGN servers cuz well, they suck.

logging into BNet servers.

everything is coming out as the packet says:

Code Select Expand


        private void S_SID_AUTH_ACCOUNTLOGON(Packet p)
        {
            /*
             * S->SID_AUTH_ACCOUNTLOGON
             * 0x53
             *
             * (DWORD) STATUS
             * (BYTE[32]) SERVER SALT
             * (BYTE[32]) SERVER KEY (B)
             */
            uint result = p.ReadUInt32();
            if (result == 0x00000000)
            {
                Output("BNET", "SID_AUTH_ACCOUNTLOGON PASSED");
                serverSalt = p.ReadByteArr(32);
                serverKeyB = p.ReadByteArr(32);
                C_SID_AUTH_ACCOUNTLOGONPROOF();
            }
            else if (result == 0x00000001)
            {
                Output("BNET", "SID_AUTHACCOUNTLOGON ACCOUNT DOESN'T EXIST");
            }
            else
                Output("BNET", "SID_AUTH_ACCOUNTLOGON FAILED");
        }


i've already double checked that its getting everything out of the packet correctly, that the first thing i checked.

oh, and the ReadByteArr() function returns a byte array as it is in the packet, little endian style.

[MyndFyre]

i read that and it said bnet doesnt use SHA-1 for wc3, but rather SRP. is that true? if so, is there an implementation in BN# for that?

edit:: and also, should i be doing something with the server signature from 0x50?

BN# and MBNCSUtil implements the SRP for Battle.net as part of the NLS class.

[Ribose]

BN# and MBNCSUtil implements the SRP for Battle.net as part of the NLS class.

Hey, out of boredom, I realized your NLS class should be capitalized as "Nls" according to MSDN:

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters.

But yeah, on subject, that code should work right, provided that the packet buffer class is working correctly.

[Sveet]

the packet class is working, its sent every other packet fine, extracted fine. and capitalizing the first letter is for classes and methods that are words. NLS is short for New Login System. Microsoft uses the same thing, it is an ASCIIEncoder not an AsciiEncoder.

edit:: and MyndFyre, can you IM me on AIM or MSN next time you read this? i really want to sort this out, and i think we could fairly fast if we talked more than once every other day lol

[Sveet]

bumpity bump bump!

still unresolved and looking for help!

[MyndFyre]

bumpity bump bump!

still unresolved and looking for help!

It's your problem, I'd think that if you wanted help you'd probably try to seek me out on AIM instead of asking me to find you.  I'm not that motivated.

[Sveet]

bumpity bump bump!

still unresolved and looking for help!

It's your problem, I'd think that if you wanted help you'd probably try to seek me out on AIM instead of asking me to find you.  I'm not that motivated.

ive checked every single time and youre never on... thats why i wanted you to IM me, cause i can never catch you online! I added you on both MSN and AIM....

[MyndFyre]

So just for future readers' reference: we isolated this problem as a logic error in reading the server key B.  It was coming in over the wire correctly but the last byte was being read as 0.

[Sveet]

So just for future readers' reference: we isolated this problem as a logic error in reading the server key B.  It was coming in over the wire correctly but the last byte was being read as 0.

yes, it was in my buffer class (which was used in my recieve packets function), when you called function Sub(int,int) it made a new array the right length, but the for loop was 1 too small and left the last byte 0. i'm actually surprised that i got all the way to the login proof with that error.