I've been working on a bot, using MBNCSUtil, but when I send my 0x53 I get IP Banned

[code]
        private void C_SID_AUTH_ACCOUNTLOGON()
        {
            /*
             * C-> SID_AUTH_ACCOUNTLOGON
             * 0x53
             *
             * (BYTE[32]) CLIENT KEY ('A')
             * (STRING) USERNAME
             */

            Packet p = new Packet(0x53);
            byte[] loginAccount = new byte[32 + userName.Length + 1];
            nls.LoginAccount(loginAccount, 0, loginAccount.Length);
            p.add(loginAccount);
            Enqueue(p);
        }

[/code]

Enqueue is just my method to add the packet to my outbound queue. Did I use the function wrong? The documentation is very lacking. If you cant help me with the MBNCSUtil part, if you want to tell me how to do this without it that would be appreciated too.



edit:: well i figured out it wasnt this at all, it was that i messed up my handling of S->SID_AUTH_CHECK, had the call to this function outside the switch instead of next to the passed result. my problem now is that my CDKey Public value's arent matching what i've sniffed and i'm getting "Invalid CDKey" results.

[code]
        private void C_SID_AUTH_CHECK()
        {
            /*
             * C->SID_AUTH_CHECK
             * 0x51
             *
             * (DWORD) Client Token
             * (DWORD) EXE Version
             * (DWORD) EXE Hash
             * (DWORD) Number of CDKeys in Packet
             * (BOOL) Spawn CDKey
             *
             * For Each CDKey:
             * (DWORD) Key Length
             * (DWORD) CDKey product
             * (DWORD) CDKey public value (Value1)
             * (DWORD) Unknown (0)
             * (DWORD) [5] Hashed Key Data
             *
             * (STRING) Exe Information
             * (STRING) CDKey Owner Name
             */

            Packet p = new Packet(0x51);
            clientToken = (uint)new Random().Next();

            p.add(clientToken);

            int version = CheckRevision.GetExeInfo((WAR3PATH + "war3.exe"), out exeInfoString);
            p.add(version);

            string[] files = new string[] { WAR3PATH + "War3.exe", WAR3PATH + "storm.dll", WAR3PATH + "Game.dll" };
            int mpqNum = Util.MpqNumber(mpqFileName);
            int checkSum = CheckRevision.DoCheckRevision(valueString, files, mpqNum);
            p.add(checkSum);

            p.add((int)2); // number of CD keys

            p.add((uint)0);

            // key 1
            p.add(CD1.Key.Length);
            p.add(CD1.Product);
            p.add(CD1.Value1);
            p.add((uint)0);
            p.add(CD1.GetHash(clientToken, serverToken));

            // key 2
            p.add(CD2.Key.Length);
            p.add(CD2.Product);
            p.add(CD2.Value1);
            p.add((uint)0);
            p.add(CD2.GetHash(clientToken, serverToken));

            p.add(exeInfoString);
            p.add("Sveet");

            Enqueue(p);
        }
[/code]


edit2 :: well looking at my server and client tokens it noticed that my server token comes in as aabbccdd but is saved by BitConverter as ddccbbaa. should it be that way or should i find a different method of converting my bytes to ints?

edit3 :: i'm getting invalid cdkey with either endian-ness of the bytes...

Use BN#: http://www.jinxbot.net/bns/

[quote author=Smarter link=topic=17779.msg181091#msg181091 date=1231576032]
Use BN#: http://www.jinxbot.net/bns/
[/quote]

that is what im using............... MBNCSUtil = Section of BN#

I'm curious as to how exactly your building your CD1/2 objects. As well as how you're handling your Server/client token as you mentioned the reverse endianess.
If you could post a few packet logs and your values. {client, server, key, etc} we could take a look. In theory you're doing it right.

[quote author=Hdx link=topic=17779.msg181095#msg181095 date=1231592590]
I'm curious as to how exactly your building your CD1/2 objects. As well as how you're handling your Server/client token as you mentioned the reverse endianess.
If you could post a few packet logs and your values. {client, server, key, etc} we could take a look. In theory you're doing it right.

[/quote]

my cd1/cd2 objects are CDKey objects from MBNCSUtil.
my Packet class is something i made myself before i started using MBNCSUtil, and have added lots of features (thinking about adding a stream like feature so i can just do p.NextInt() )


my handling of S->SID_AUTH_INFO is this:

[code]
        private void S_SID_AUTH_INFO(Packet p)
        {
            /*
             * S-> SID_AUTH_INFO
             * 0x50
             *
             * (DWORD) LOGON TYPE
             * (DWORD) SERVER TOKEN
             * (DWORD) UDP VALUE
             * (QWORD) MPQ FILETIME
             * (STRING) IX86VER FILENAME
             * (STRING) VALUESTRING
             */

            ASCIIEncoding enc = new ASCIIEncoding();
            logonType = BitConverter.ToInt32(p.Data, 4);
            serverToken = BitConverter.ToInt32(p.Data, 8);
            udpValue = BitConverter.ToInt32(p.Data, 12);
            mpqFileTime = BitConverter.ToInt64(p.Data, 16);
            int lastSize = Util.ExtractString(p.Data, 24, ref mpqFileName);
            lastSize = Util.ExtractString(p.Data, lastSize, ref valueString);
            serverSignature = Util.Sub(p.Data, lastSize, p.Data.Length - 1);

            C_SID_AUTH_CHECK();
[/code]

where i generate and handle my client token is in method C_SID_AUTH_CHECK() in my first post.


what im sending out for 0x51
[code]
0000   ff 51 90 00 12 c7 f3 2d b8 18 16 01 cd 91 32 79
0010   02 00 00 00 00 00 00 00 1a 00 00 00 0e 00 00 00
0020   b5 a2 19 00 00 00 00 00 5c 27 c5 e1 21 1f a1 05
0030   07 95 3c 2b 8a 20 20 a1 3f 82 09 da 1a 00 00 00
0040   12 00 00 00 8c e7 21 00 00 00 00 00 58 29 dc 68
0050   0d 48 f0 3d a7 dc e3 81 c0 58 e4 28 d6 33 a3 ec
0060   77 61 72 33 2e 65 78 65 20 36 2f 32 37 2f 30 38
0070   20 30 30 3a 30 31 3a 33 35 20 34 37 31 30 34 30
0080   00 69 43 43 75 70 2e 44 6f 74 41 48 6f 73 74 00
[/code]
this is the 0x50 packet i recieved
[code]
0000   ff 50 e6 00 02 00 00 00 eb 25 9b 68 c2 2f 56 00  .P.......%.h./V.
0010   00 31 ef 00 70 5f c7 01 76 65 72 2d 49 58 38 36  .1..p_..ver-IX86
0020   2d 31 2e 6d 70 71 00 43 3d 32 34 33 34 35 34 34  -1.mpq.C=2434544
0030   36 38 20 42 3d 31 35 36 37 33 37 33 33 31 20 41  68 B=156737331 A
0040   3d 32 32 30 33 35 36 31 33 32 31 20 34 20 41 3d  =2203561321 4 A=
0050   41 5e 53 20 42 3d 42 2d 43 20 43 3d 43 2b 41 20  A^S B=B-C C=C+A
0060   41 3d 41 2d 42 00 70 4f 01 21 1e 24 62 47 c8 1c  A=A-B.pO.!.$bG..
0070   a5 73 5e 27 32 b7 fd 13 f9 df 43 a5 73 21 24 c9  .s^'2.....C.s!$.
0080   69 6e fb a5 8e 3f 73 8c 1a 1c a3 ed 7c 3d 84 68  in...?s.....|=.h
0090   a6 7f 73 99 9d 5c 90 f2 ad fa 75 73 25 42 dd b7  ..s..\....us%B..
00a0   e9 98 aa b6 f3 cb c6 f9 0a 5d 4e 00 62 4d 19 bc  .........]N.bM..
00b0   6d 61 9e 88 fc a3 98 a8 6e a3 b3 65 0a d2 83 1e  ma......n..e....
00c0   11 e8 8e c1 e4 2f 05 ce fc 07 79 f3 5b 32 9a 75  ...../....y.[2.u
00d0   be 03 5a c4 bb 19 d5 6e 2f dd 8f 5e 0c 34 69 b2  ..Z....n/..^.4i.
00e0   1b 2d a9 a8 18 6e                                .-...n
[/code]

what it looks like (same CDKeys) logging into bnet on the client:
0x51 sent
[code]
0000   ff 51 8e 00 de de a5 0f b8 00 16 01 ad df 73 b4
0010   02 00 00 00 00 00 00 00 1a 00 00 00 0e 00 00 00
0020   b5 a2 19 00 00 00 00 00 46 52 a5 50 eb d4 89 c0
0030   80 81 9c cc 17 34 df 2e 8f f3 02 3f 1a 00 00 00
0040   12 00 00 00 8c e7 21 00 00 00 00 00 00 2e db a7
0050   29 fc bf 9d 9a 5f e4 1e ca b4 bd 58 4c 61 81 4f
0060   77 61 72 33 2e 65 78 65 20 30 36 2f 32 37 2f 30
0070   38 20 30 30 3a 30 31 3a 33 35 20 34 37 31 30 34
0080   30 00 4a 6f 65 20 46 6f 72 74 6d 61 6e 00
[/code]

0x50 recieved
[code]
0000   ff 50 e6 00 02 00 00 00 d6 59 53 cd 31 4c 41 00  .P.......YS.1LA.
0010   00 31 ef 00 70 5f c7 01 76 65 72 2d 49 58 38 36  .1..p_..ver-IX86
0020   2d 35 2e 6d 70 71 00 43 3d 32 30 32 34 32 31 32  -5.mpq.C=2024212
0030   38 31 33 20 42 3d 39 30 39 34 35 36 33 31 39 20  813 B=909456319
0040   41 3d 35 33 39 37 37 34 37 38 39 20 34 20 41 3d  A=539774789 4 A=
0050   41 2d 53 20 42 3d 42 5e 43 20 43 3d 43 5e 41 20  A-S B=B^C C=C^A
0060   41 3d 41 2b 42 00 bd a0 92 6c 5c b5 07 30 c3 a9  A=A+B....l\..0..
0070   6a eb 3a ea 96 da 52 b2 df d4 bd ce 7c 7b 83 4d  j.:...R.....|{.M
0080   d1 19 97 15 94 71 d9 98 01 2a 67 c8 7c a5 8e 5e  .....q...*g.|..^
0090   4e 68 e1 ff b0 b6 56 3a 0b ae 09 43 2e 23 29 4e  Nh....V:...C.#)N
00a0   83 ac 60 fe 12 8a 95 f7 df 04 6f f3 bf a5 fa 06  ..`.......o.....
00b0   43 d2 4e 18 fe dd d6 a2 ef dc 9d e9 80 be a1 87  C.N.............
00c0   20 a0 4f 47 a2 b2 57 4f 5f 5b 67 7e 1f 8b 19 a0   .OG..WO_[g~....
00d0   eb 6f 45 18 ee 94 56 bb a9 73 6b 31 34 8a a3 74  .oE...V..sk14..t
00e0   f0 ee 0f da 25 5a                                ....%Z
[/code]




edit::well not that it makes a huge deal, but i got everything working on a PVPGN server, i dont know why it not accepting my CDKeys on BNet...

edit2:: well i guess not everything, the password hash seems to be different for PVPGN than for bnet so i just get invalid password when i get that far. i really want to know why my CDKeys arent going through :(

Key: WVJJ64GXCEE7HCFGHH4BEXM22Y
Public: 0x003D2455
Product: 0x0000000E
Private:  60 18 A8 04 0F A6 36 A4 96 21
Server Token: 0xC3E42EA5
Client Token:  0x3D340489
Hash: D5 38 93 6A 8B F8 FC 94 73 BA 39 3D 57 77 81 AF 29 FB C5 41

tell me what you get when you work with those values?

[quote author=Hdx link=topic=17779.msg181122#msg181122 date=1231726892]
Key: WVJJ64GXCEE7HCFGHH4BEXM22Y
Public: 0x003D2455
Product: 0x0000000E
Private:  60 18 A8 04 0F A6 36 A4 96 21
Server Token: 0xC3E42EA5
Client Token:  0x3D340489
Hash: D5 38 93 6A 8B F8 FC 94 73 BA 39 3D 57 77 81 AF 29 FB C5 41

tell me what you get when you work with those values?
[/quote]

this is what i sent out:
[code]
0000   ff 51 63 00 89 04 34 3d b8 18 16 01 fd d4 c7 43  .Qc...4=.......C
0010   01 00 00 00 00 00 00 00 1a 00 00 00 0e 00 00 00  ................
0020   55 24 3d 00 00 00 00 00 5d 4c d7 6d 03 fa d8 0c  U$=.....]L.m....
0030   65 3a 41 11 7d 72 8f c6 f7 b4 c7 f8 77 61 72 33  e:A.}r......war3
0040   2e 65 78 65 20 36 2f 32 37 2f 30 38 20 30 30 3a  .exe 6/27/08 00:
0050   30 31 3a 33 35 20 34 37 31 30 34 30 00 53 76 65  01:35 471040.Sve
0060   65 74 00                                         et.
[/code]

and this is what i got
[code]
0000   ff 51 09 00 03 02 00 00 00                       .Q.......
[/code]

and maybe im still rusty with my endian knowledge and being used to seeing it, but this is what the DWORD looks like when it goes thru my packet:
[code]
0x00020300
[/code]

if its little endian shouldnt it be 00 00 02 03 and big endian be 03 02 00 00? my result extraction code is simple:
[code]
uint result = BitConverter.ToUInt32(p.Data, 4);
[/code]

which should make a uint out of the bytes starting at index 4 (5th item, which is the 03)



and for the record, the CDKey Class calculates my public, private and hash for me, so i didnt put them in manually. i havent looked through this to check mine, i will do that right now (just want the post to get out there)


edit::

well i noticed the product ID was 0E000000 not 0000000E so i reversed it but still got bad product. did you give me a fake key hoping i'd get wrong product as a test or is something wrong?

[code]
0000   ff 51 63 00 89 04 34 3d b8 18 16 01 ea c9 fe e9  .Qc...4=........
0010   01 00 00 00 00 00 00 00 1a 00 00 00 00 00 00 0e  ................
0020   55 24 3d 00 00 00 00 00 5d 4c d7 6d 03 fa d8 0c  U$=.....]L.m....
0030   65 3a 41 11 7d 72 8f c6 f7 b4 c7 f8 77 61 72 33  e:A.}r......war3
0040   2e 65 78 65 20 36 2f 32 37 2f 30 38 20 30 30 3a  .exe 6/27/08 00:
0050   30 31 3a 33 35 20 34 37 31 30 34 30 00 53 76 65  01:35 471040.Sve
0060   65 74 00                                         et.
[/code]

btw its much easier to compare packets if i post them here to look at lol


edit 2:: i thought i should mention it and it probably means nothing, but i've been sniffing a lot of really weird big packets sent to and from the server during the login (before i send 0x51). one of them that i sent was like the 0x01 initial byte, but it was just 0x02.... been seeing them for a little while but still confusing..

[quote author=Sveet link=topic=17779.msg181127#msg181127 date=1231776293]
and this is what i got
[code]
0000   ff 51 09 00 03 02 00 00 00                       .Q.......
[/code]

and maybe im still rusty with my endian knowledge and being used to seeing it, but this is what the DWORD looks like when it goes thru my packet:
[code]
0x00020300
[/code]
[/quote]
You're starting too early on the first 00 which actually belongs to the packet header.  The number in little-endian is 0x00000203, and the final zero is an empty string's null terminator.

[quote author=Sveet link=topic=17779.msg181127#msg181127 date=1231776293]
if its little endian shouldnt it be 00 00 02 03 and big endian be 03 02 00 00? my result extraction code is simple:
[code]
uint result = BitConverter.ToUInt32(p.Data, 4);
[/code]

which should make a uint out of the bytes starting at index 4 (5th item, which is the 03)
[/quote]
Your extraction code is correct.  However, when you deal with larger packets it is advisable to treat them like a stream instead of discrete units of data.  The DataReader class facilitates this, so you can do something like ReadUInt32(), ReadCString(), ReadByte() and not need to worry about positions changing.

[quote author=MyndFyre[vL] link=topic=17779.msg181128#msg181128 date=1231778173]
[quote author=Sveet link=topic=17779.msg181127#msg181127 date=1231776293]
and this is what i got
[code]
0000   ff 51 09 00 03 02 00 00 00                       .Q.......
[/code]

and maybe im still rusty with my endian knowledge and being used to seeing it, but this is what the DWORD looks like when it goes thru my packet:
[code]
0x00020300
[/code]
[/quote]
You're starting too early on the first 00 which actually belongs to the packet header.  The number in little-endian is 0x00000203, and the final zero is an empty string's null terminator.

[quote author=Sveet link=topic=17779.msg181127#msg181127 date=1231776293]
if its little endian shouldnt it be 00 00 02 03 and big endian be 03 02 00 00? my result extraction code is simple:
[code]
uint result = BitConverter.ToUInt32(p.Data, 4);
[/code]

which should make a uint out of the bytes starting at index 4 (5th item, which is the 03)
[/quote]
Your extraction code is correct.  However, when you deal with larger packets it is advisable to treat them like a stream instead of discrete units of data.  The DataReader class facilitates this, so you can do something like ReadUInt32(), ReadCString(), ReadByte() and not need to worry about positions changing.
[/quote]

well, as i said in a previous post, i am about to add that capability to my packet class.

and about the endianness, why is it starting at the 00 of 09 00 if my code tells it to start at the index behind that?

edit:: well i changed it to read at '5' instead of '4' and it got the "correct" read. maybe i should go back through my code and change all of them, maybe thats where my problems are happening.

edit2:: also, if someone could give me a rule of thumb for endianness. for example, if someone writes it are they writing it big endian or little endian or are they writing it how it should look in the packet. and should everything in packets be little endian?


edit3:: had a bit of a "duh" moment, realized i was getting wrong product error because i didnt change the code in 0x50 to send WAR3 instead of W3XP (i only send your key to make the test as clean as possible), now i get invalid cdkey, i bet it has something to do with my CD hash...

edit4:: so i did a test at my last edit, but forgot to change my hash from yours to the hash alg (only changed server and client token), and when i did it worked! i have invalid password when i try to log in though, im gonna take a look and if i have problems ill post. thanks a ton for your help (seems my BitConverter problem was the big problem after all!)



edit5:: soooooooooooo someone want to tell me the deal with server salt and serverkeyb? bnet docs says 32 bytes each but i get the 32 bytes for server salt and theres only 13 left for the serverkeyb.

Battle.net's packets are all little-endian, except (I believe) when they send IP addresses, which are sent in network byte-order (big-endian).

I would submit that your Data property on your packet class is erroneous if you're getting the incorrect result from your call to BitConverter.ToUInt32(p.Data, 4), and that it is not reflective of what you're printing out.  To validate, please perform the following operations and print the results:

[code]
Console.WriteLine("{0:x8}", BitConverter.ToUInt32(p.Data, 0));
Console.WriteLine("{0:x8}", BitConverter.ToUInt32(p.Data, 1));
Console.WriteLine("{0:x8}", BitConverter.ToUInt32(p.Data, 2));
Console.WriteLine("{0:x8}", BitConverter.ToUInt32(p.Data, 3));
Console.WriteLine("{0:x8}", BitConverter.ToUInt32(p.Data, 4));
Console.WriteLine("{0:x8}", BitConverter.ToUInt32(p.Data, 5));
try {
Console.WriteLine("{0:x8}", BitConverter.ToUInt32(p.Data, 6));
} catch {
Console.WriteLine("Exception triggered on last due to array overflow.");
}
[/code]

If you're working in Winforms or another graphical UI and the Console is not available to you, you can trace:

[code]
// using System.Diagnostics;

Trace.WriteLine(BitConverter.ToUInt32(p.Data, 0).ToString("x8"));
Trace.WriteLine(BitConverter.ToUInt32(p.Data, 1).ToString("x8"));
Trace.WriteLine(BitConverter.ToUInt32(p.Data, 2).ToString("x8"));
Trace.WriteLine(BitConverter.ToUInt32(p.Data, 3).ToString("x8"));
Trace.WriteLine(BitConverter.ToUInt32(p.Data, 4).ToString("x8"));
Trace.WriteLine(BitConverter.ToUInt32(p.Data, 5).ToString("x8"));
try {
Trace.WriteLine(BitConverter.ToUInt32(p.Data, 6).ToString("x8"));
} catch {
Trace.WriteLine("Exception triggered on last due to array overflow.");
}
[/code]

[code]
Packet p2 = new Packet(0x25);
            p2.add(new byte[] { 0x03, 0x04, 0x05 });
            Output("Test for MyndFyre[vL]");
            Output(string.Format("{0:x8}", BitConverter.ToUInt32(p2.Data, 0)));
            Output(string.Format("{0:x8}", BitConverter.ToUInt32(p2.Data, 1)));
            Output(string.Format("{0:x8}", BitConverter.ToUInt32(p2.Data, 2)));
            Output(string.Format("{0:x8}", BitConverter.ToUInt32(p2.Data, 3)));
            Output(string.Format("{0:x8}", BitConverter.ToUInt32(p2.Data, 4)));
            Output(string.Format("{0:x8}", BitConverter.ToUInt32(p2.Data, 5)));
            try {
            Output(string.Format("{0:x8}", BitConverter.ToUInt32(p2.Data, 6)));
            } catch {
            Output("Exception triggered on last due to array overflow.");
            }
[/code]


Test for MyndFyre[vL]
000725ff
03000725
04030007
05040300


i got that far before i got array overflow, but i figure that it is enough for you. as you can see it starts at ff which is 0, then 25 which is 1, 07 which is 2, 00 which is 3, ect.

the weirdest thing is that it is inconsistant with what my program has shown... if you'd like to contact me on AIM or MSN i can show you my packet class (or i can post here...)


edit:: and the property just adds the FF <ID> <SIZE> <DATA>

edit2:: it seems the problem was in my function that reads the packets, but thats fixed now. thanks.

edit3:: now, i cant get my SID_AUTH_ACCOUNTLOGONPROOF working, i always get wrong password:

[code]
        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);
        }
[/code]

i've double-triple checked that my serverSalt and serverKeyB are correctly extracted, and my username and password are right (obviously).

and on a side note, for the client salt and verifier in 0x52 (SID_AUTH_ACCOUNTCREATE), can they be any values or do they have a specific meaning/use?

oh and if it matters, p.add(byte[]) leaves the bytes in big endian, and i've tried swapping them around (i have a Util.SwapBytes(byte[]) func) but to no avail.