From the Data Array from 0x01 BNLS_CDKEY, what am I suppose to use for 0x51?

DWORD - ClientToken - Tracking Value
DWORD - Exe Version - Got this from 0x1A
DWORD - Exe Hash - Got this from 0x1a
DWORD - Key Count - Simple
DWORD - Spawn - Only 1 ( True ) for STAR or W2BN

Per Key // using 1 key
DWORD - Key Length - 16, Ex: AAAABBBBCCCCDDDD
DWORD - Key Product - D2DV Maybe?
DWORD - Key Public Value - The actual key?
DWORD - Unknown - Always zero

DWORD - Hashed Key Data -
  1. Client Token - Tracking Value
  2. Server Token - Got this from 0x50
  3. Key Product (from decoded CD key) - Don't know
  4. Key Public (from decoded CD key) - Don't know
  5. (DWORD) 0 - Always zero
  6. Key Private (from decoded CD key) - Don't Know

String - Exe Info - Got this from 0x1A
String - Owner - Well this isn't obvious at all ;)

[code]    NumberOfCDKeys = GetNumberOfKeys(typ)
     
   CDKeyOneBuf = HashC.DoCDKeyOne(CDK1, sKey, cKey) 'CDKEY ONE
   
   Select Case NumberOfCDKeys
       Case 0
           'LTRD, RHSD, RHSS can also use this function, (proven fact pre-lockdown).
       Case 1
           CDKeyHashDat = CDKeyOneBuf
       Case 2
           CDKeyTwoBuf = HashC.DoCDKeyTwo(CDK2, sKey, cKey) 'CDKEY TWO
           CDKeyHashDat = CDKeyOneBuf & CDKeyTwoBuf
       Case Else
           'There are no products that have more then 2
           'cdkeys as of yet, But.. since the packet
           'could take more then 2, possibly they're
           'setting up for some expansion to an expansion
           'games?
   End Select
   
   
   With pb
       .InsertDWORD cKey
       .InsertDWORD version
       .InsertDWORD Checksum
       .InsertDWORD NumberOfCDKeys
       .InsertDWORD Spawn
       .InsertNonNTString CDKeyHashDat
       .InsertNTString exeinfo
       .InsertNTString CDKeyUsername
       .SendBuffer sck, Bnet, &H51
   End With
   
   Set pb = Nothing[/code]

Leave it to you to figure out what CDKeyHashDat actually is.

[code]For Each Key:
  (DWORD) Key Length
  (DWORD) CD-key's product value
  (DWORD) CD-key's public value
  (DWORD) Unknown (0)
  (DWORD) [5] Hashed Key Data[/code]
1+1+1+1+5=?

[quote author=Hdx link=topic=18229.msg184700#msg184700 date=1273294472]
[code]For Each Key:
  (DWORD) Key Length
  (DWORD) CD-key's product value
  (DWORD) CD-key's public value
  (DWORD) Unknown (0)
  (DWORD) [5] Hashed Key Data[/code]
1+1+1+1+5=?
[/quote]

9, the array I'm getting from 0x01 ;)

Damn I'm good, IPBanned from all four servers, ah well, this will a painfully long trial and error process.

[quote author=Trunning link=topic=18229.msg184705#msg184705 date=1273299655]
Damn I'm good, IPBanned from all four servers, ah well, this will a painfully long trial and error process.
[/quote]

PvPGN helps a lot when testing. Especially setting up a local instance.

I can change my Ip, otherwise I probably would ;)

I'm getting result 512 back from 0x51, ah well I got some work to do.

[quote author=lord2800 link=topic=18229.msg184706#msg184706 date=1273299839]
[quote author=Trunning link=topic=18229.msg184705#msg184705 date=1273299655]
Damn I'm good, IPBanned from all four servers, ah well, this will a painfully long trial and error process.
[/quote]

PvPGN helps a lot when testing. Especially setting up a local instance.
[/quote]
PvPGN is for failures, only way for you to get real results is by using and abusing the real system.

[quote author=Trunning link=topic=18229.msg184707#msg184707 date=1273299985]
I can change my Ip, otherwise I probably would ;)

I'm getting result 512 back from 0x51, ah well I got some work to do.
[/quote]
0x200 = Invalid CDKey

Edit: Wasn't putting in the client token and server token into the HashedKeyData array, trying that now.

Can't see why, I sent 0x01 to BNLS, got the Data array, and assigned it like so.

[code] packet.KeyLength = pkt.Data[0];
packet.CDKeyProduct = pkt.Data[1];
packet.CDKeyPublic = pkt.Data[2];
packet.Unknown = pkt.Data[3]; // 0 either way
packet.HashedKeyData[0] = pkt.Data[4];
packet.HashedKeyData[1] = pkt.Data[5];
packet.HashedKeyData[2] = pkt.Data[6];
packet.HashedKeyData[3] = pkt.Data[7];
packet.HashedKeyData[4] = pkt.Data[8];[/code]

Edit: Still getting invalid CDKey...

I'm about to try this, but I have still haven't used pkt.Data[7] or [8] elements, so I doubt this will work, I'm basing my code on this.

[code]CMSG_SID_AUTH_CHECK packet;
packet.ClientToken = g_Cookie;
packet.ExeVersion = g_ExeVersion;
packet.ExeHash = g_ExeHash;
packet.KeyCount = 1;
packet.Spawn = 0;
packet.KeyLength = pkt.Data[0];
packet.CDKeyProduct = pkt.Data[1];
packet.CDKeyPublic = pkt.Data[2];
packet.Unknown = pkt.Data[3]; // 0 either way
packet.HashedKeyData[0] = g_Cookie;
packet.HashedKeyData[1] = g_ServerToken;
packet.HashedKeyData[2] = pkt.Data[4];
packet.HashedKeyData[3] = pkt.Data[5];
packet.HashedKeyData[4] = 0;
packet.HashedKeyData[5] = pkt.Data[6];
packet.ExeInfo = g_ExeInfo;
packet.Owner = (char*)malloc(4);
strcpy_s(packet.Owner, 4, "abc");[/code]
[code]struct CMSG_SID_AUTH_CHECK {
DWORD ClientToken;
DWORD ExeVersion;
DWORD ExeHash;
DWORD KeyCount;
DWORD Spawn;
// --------------------
DWORD KeyLength;
DWORD CDKeyProduct;
DWORD CDKeyPublic;
DWORD Unknown;
DWORD HashedKeyData[6];
// --------------------
char* ExeInfo;
char* Owner;
};[/code]

[quote author=l)ragon link=topic=18229.msg184709#msg184709 date=1273302826]PvPGN is for failures, only way for you to get real results is by using and abusing the real system.
[/quote]

Of course you don't use PvPGN and say your code works, but it sure does make getting the BNCS sequence down easier. It saved me hours of waiting every time I screwed something innocuous up that took me 30 seconds to fix (and had to wait 5 minutes to test again).

This is my current code, for constructing the packet. It's commented, if anything is wrong tell me, which it is because it's not working.

[code] CMSG_SID_AUTH_CHECK packet;
packet.ClientToken = pkt.ClientToken; // Tracking Value
packet.ExeVersion = g_ExeVersion; // Version from BNLS 0x1A
packet.ExeHash = g_ExeHash; // Checksum from BNLS 0x1A
packet.KeyCount = 1; // Only using 1 key, Diablo 2
packet.Spawn = 0; // Only true for STAR and W2BN

packet.KeyLength = pkt.Data[0]; // Unsure if these are right
packet.ProductVal = pkt.Data[1];
packet.PublicVal = pkt.Data[2];
packet.Unknown = pkt.Data[3];
packet.KeyData[0] = pkt.ClientToken; // Same tracking value from above
packet.KeyData[1] = g_ServerToken; // ServerToken from S -> C BNCS 0x50
packet.KeyData[2] = pkt.Data[4];
packet.KeyData[3] = pkt.Data[5];
packet.KeyData[4] = 0; // 0
packet.KeyData[5] = pkt.Data[6];

packet.ExeInfo = g_ExeInfo; // Pointer to the stat string from BNLS 0x1A
packet.Owner = (char*)malloc(4);
strcpy_s(packet.Owner, 4, "abc");[/code]

CMSG_SID_AUTH_CHECK Structure
[code]struct CMSG_SID_AUTH_CHECK {
DWORD ClientToken;
DWORD ExeVersion;
DWORD ExeHash;
DWORD KeyCount;
DWORD Spawn;

// --------------------

DWORD KeyLength;
DWORD ProductVal;
DWORD PublicVal;
DWORD Unknown;
DWORD KeyData[6];

// --------------------

char* ExeInfo;
char* Owner;
};[/code]

[quote author=lord2800 link=topic=18229.msg184714#msg184714 date=1273313482]
[quote author=l)ragon link=topic=18229.msg184709#msg184709 date=1273302826]PvPGN is for failures, only way for you to get real results is by using and abusing the real system.
[/quote]

Of course you don't use PvPGN and say your code works, but it sure does make getting the BNCS sequence down easier. It saved me hours of waiting every time I screwed something innocuous up that took me 30 seconds to fix (and had to wait 5 minutes to test again).
[/quote]
You must be retarded now unless PvPGN has access to blizzards CDKey database, how bright do you think what your saying is when his current problem is with CDKeys.

[code] packet.KeyLength = pkt.Data[0]; // Unsure if these are right
packet.ProductVal = pkt.Data[1];
packet.PublicVal = pkt.Data[2];
packet.Unknown = pkt.Data[3];
packet.KeyData[0] = pkt.ClientToken; // Same tracking value from above
packet.KeyData[1] = g_ServerToken; // ServerToken from S -> C BNCS 0x50
packet.KeyData[2] = pkt.Data[4];
packet.KeyData[3] = pkt.Data[5];
packet.KeyData[4] = 0; // 0
packet.KeyData[5] = pkt.Data[6];[/code]
is where your problem is, the entire data should be 9 DWORDS in length within this section.
I thought BNLS gave you this entire section?

That's 10 in total, not 9 :(

Here's a question, from the page 0x51.

It says [5] Hashed Key Data, an array of five, then below it says that should contain:
[code]The data that should be hashed for 'Hashed Key Data' is:

  1. Client Token
  2. Server Token
  3. Key Product (from decoded CD key)
  4. Key Public (from decoded CD key)
  5. (DWORD) 0
  6. Key Private (from decoded CD key)[/code]

That's 6 not 5, so which is right?

[quote author=Trunning link=topic=18229.msg184722#msg184722 date=1273333992]
Here's a question, from the page 0x51.

It says [5] Hashed Key Data, an array of five, then below it says that should contain:
[code]The data that should be hashed for 'Hashed Key Data' is:

   1. Client Token
   2. Server Token
   3. Key Product (from decoded CD key)
   4. Key Public (from decoded CD key)
   5. (DWORD) 0
   6. Key Private (from decoded CD key)[/code]

That's 6 not 5, so which is right?
[/quote]
No, that is what you are hashing.
the hash returned is 5 DWORDS.

Ok so this should work.

[code]packet.KeyLength = pkt.Data[0];
packet.ProductVal = pkt.Data[1];
packet.PublicVal = pkt.Data[2];
packet.Unknown = pkt.Data[3];
packet.KeyData[0] = pkt.Data[4];
packet.KeyData[1] = pkt.Data[5];
packet.KeyData[2] = pkt.Data[6];
packet.KeyData[3] = pkt.Data[7];
packet.KeyData[4] = pkt.Data[8];[/code]

[quote author=Trunning link=topic=18229.msg184724#msg184724 date=1273334488]
Ok so this should work.

[code]packet.KeyLength = pkt.Data[0];
packet.ProductVal = pkt.Data[1];
packet.PublicVal = pkt.Data[2];
packet.Unknown = pkt.Data[3];
packet.KeyData[0] = pkt.Data[4];
packet.KeyData[1] = pkt.Data[5];
packet.KeyData[2] = pkt.Data[6];
packet.KeyData[3] = pkt.Data[7];
packet.KeyData[4] = pkt.Data[8];[/code]
[/quote]
If your pkt Data dosent include the packet header+result from bnls yes.

Fuck yeah, passed the challenge, thanks Dragon.

Is BNLS 0x08 the right packet to hash my password for 0x3A?

look into using BNLS_HASHDATA for that.

That's the packet I provided lol, so I guess its right then?

[quote author=Trunning link=topic=18229.msg184729#msg184729 date=1273335904]
That's the packet I provided lol, so I guess its right then?
[/quote]yeah

Whenever I send packet 0x3A, I don't get a response.

[code]CMSG_SID_LGOONRESPONSE re;
re.ClientToken = g_Cookie;
re.ServerToken = g_ServerToken;
re.PasswordHash[0] = pack.Data[0];
re.PasswordHash[1] = pack.Data[1];
re.PasswordHash[2] = pack.Data[2];
re.PasswordHash[3] = pack.Data[3];
re.PasswordHash[4] = pack.Data[4];
re.Username = (char*)malloc(13);
strcpy_s(re.Username, 13, "clientlessya");

buffer = (char*)malloc(sizeof(re) + 13);
memcpy(buffer, &re, sizeof(re));
strcpy_s(buffer + sizeof(re), 13, "clientlessya");

bncs_send(sockBNCS, 0x3A, buffer, sizeof(re) + 13);[/code]

Look at your packet log it should be oblivious.
Also, just as a note, it's usually standard practice to treat hash data as a byte[] not a dword array. Basically it'd let you condense 5 lines into 1:
[code]memcpy(&re.PasswordHash[0], &pack.Data[0], 20);[/code] or the like.

Well my packet log looks fine, all I can see is the header being sent, then the rest.

[code]CMSG_SID_LGOONRESPONSE re;
re.ClientToken = g_Cookie;
re.ServerToken = g_ServerToken;
re.PasswordHash[0] = pack.Data[0];
re.PasswordHash[1] = pack.Data[1];
re.PasswordHash[2] = pack.Data[2];
re.PasswordHash[3] = pack.Data[3];
re.PasswordHash[4] = pack.Data[4];
re.Username = (char*)malloc(13);
strcpy_s(re.Username, 13, "clientlessya");

buffer = (char*)malloc(sizeof(re) + 13);
memcpy(buffer, &re, sizeof(re));
strcpy(buffer + sizeof(re), "clientlessya");

bncs_send(sockBNCS, 0x3A, buffer, sizeof(re) + 13);[/code]

Look at the 'rest' you are sending, and compare it to the packet structure.
You'll notice you're sending an extra 4 bytes before the username.

So...

[code]strcpy(buffer + sizeof(re) - 4, "clientlessya");[/code]

This worked after I took off 4 bytes from the malloc().

And I'm getting 0x02 back, so my password is wrong apparently.

[quote author=Trunning link=topic=18229.msg184736#msg184736 date=1273347946]
So...

[code]strcpy(buffer + sizeof(re) - 4, "clientlessya");[/code]

This worked after I took off 4 bytes from the malloc().
[/quote]Yes, now WHY did that work?[quote]And I'm getting 0x02 back, so my password is wrong apparently.[/quote] Apparently, either someone has that account, or you're using the wrong password. Remember the real games lcase the password before hashing.
Also, remember you need to use the same client token as you did with your cdkeys.

I'm using the same Client Token, and the password is lower case.

Post a full packet log, minus the TCP headers please!

I don't know if you wanted everything everything or just this packet.

[code]0000  2f c0 50 2d 4a 8e a9 3e 21 54 57 aa 61 e4 be 7b  /.P-J..>!TW.a..{
0010  99 38 12 cc e6 66 f8 64 59 f9 85 bd 63 6c 69 65  .8...f.dY...clie
0020  6e 74 6c 65 73 73 79 61 00                      ntlessya.[/code]

The BNCS_HEADER is being sent before this.

[code]0000  ff 3a 08 00 02 00 00 00                          .:......[/code]

You have to learn how to dump a complete packet.  Don't separate the header (you didn't even do it right).  A header is BYTE BYTE WORD, and you're separating BYTE BYTE WORD DWORD as the header (that 2 is part of the packet's data).  And "full packet log" means a log of the entire connection.

I'm using the exact same function to send the last packet, but it's being split for god knows why.

Profile a FULL DATA Packet Log. (Thats everything from the packet we actually care about, not the tcp headers)
Everything you send, everything you receive.
ALL Packets.

Probably left some CDKey related stuff there.

[code]0000   01                                               .

0000   00 04 ed 6f a5 60 00 26 18 7f 24 a2 08 00 45 00  ...o.`.&..$...E.
0010   00 62 c4 08 40 00 80 06 e1 1f c0 a8 01 65 3f f1  .b..@........e?.
0020   53 6f 10 bb 17 e0 09 0a 7b 7a 29 99 0d f0 50 18  So......{z)...P.
0030   ff ff 5b 55 00 00 ff 50 3a 00 00 00 00 00 36 38  ..[U...P:.....68
0040   58 49 56 44 32 44 0d 00 00 00 09 04 00 00 c0 a8  XIVD2D..........
0050   01 64 a8 fd ff ff 09 04 00 00 09 04 00 00 55 53  .d............US
0060   41 00 55 6e 69 74 65 64 20 53 74 61 74 65 73 00  A.United States.


0000   ff 25 08 00 e4 b8 00 50                          .%.....P

0000   ff 25 08 00                                      .%..

0000   ff 50 68 00 00 00 00 00 ed 51 b0 3f 51 13 78 00  .Ph......Q.?Q.x.
0010   00 8b 51 03 70 5f c7 01 76 65 72 2d 49 58 38 36  ..Q.p_..ver-IX86
0020   2d 30 2e 6d 70 71 00 43 3d 34 31 31 38 38 36 39  -0.mpq.C=4118869
0030   33 32 35 20 42 3d 33 34 30 39 37 33 35 30 36 38  325 B=3409735068
0040   20 41 3d 33 30 35 37 30 30 38 30 32 36 20 34 20   A=3057008026 4
0050   41 3d 41 2d 53 20 42 3d 42 5e 43 20 43 3d 43 2b  A=A-S B=B^C C=C+
0060   41 20 41 3d 41 2d 42 00                          A A=A-B.

0000   e4 b8 00 50                                      ...P

0000   67 00 1a 04 00 00 00 00 00 00 00 21 f6 e6 4b 00  g..........!..K.
0010   8b 51 03 70 5f c7 01 76 65 72 2d 49 58 38 36 2d  .Q.p_..ver-IX86-
0020   30 2e 6d 70 71 00 43 3d 34 31 31 38 38 36 39 33  0.mpq.C=41188693
0030   32 35 20 42 3d 33 34 30 39 37 33 35 30 36 38 20  25 B=3409735068
0040   41 3d 33 30 35 37 30 30 38 30 32 36 20 34 20 41  A=3057008026 4 A
0050   3d 41 2d 53 20 42 3d 42 5e 43 20 43 3d 43 2b 41  =A-S B=B^C C=C+A
0060   20 41 3d 41 2d 42 00                              A=A-B.

0000   38 00 1a 01 00 00 00 00 0d 00 01 4a 04 6c 1f 67  8..........J.l.g
0010   61 6d 65 2e 65 78 65 20 30 32 2f 30 38 2f 31 30  ame.exe 02/08/10
0020   20 32 33 3a 31 31 3a 30 30 20 35 37 33 34 34 00   23:11:00 57344.
0030   21 f6 e6 4b 0d 00 00 00                          !..K....

Won't include CDKey being sent, and the hash received, but there both here.

0000   ff 51 61 00                                      .Qa.

Packet containing CDKey hash.

0000   ff 51 09 00 00 00 00 00 00                       .Q.......

0000   13 00 0b 04 00 00 00 01 00 00 00 cc cc cc cc 6c  ...............l
0010   6f 6c 00                                         ol.

I believe cc's here because there is no additional information for the result, since it's success.

0000   17 00 0b 21 54 57 aa 61 e4 be 7b 99 38 12 cc e6  ...!TW.a..{.8...
0010   66 f8 64 59 f9 85 bd                             f.dY...

0000   ff 3a 2d 00                                      .:-.

Don't know why the BNCS_HEADER is seperated

0000   94 6d d5 68 ed 51 b0 3f 21 54 57 aa 61 e4 be 7b  .m.h.Q.?!TW.a..{
0010   99 38 12 cc e6 66 f8 64 59 f9 85 bd 63 6c 69 65  .8...f.dY...clie
0020   6e 74 6c 65 73 73 79 61 00                       ntlessya.

0000   ff 3a 08 00 02 00 00 00                          .:......[/code]

[code]
0000  13 00 0b 04 00 00 00 01 00 00 00 cc cc cc cc 6c  ...............l
0010  6f 6c 00                                        ol.

I believe cc's here because there is no additional information for the result, since it's success.[/code][code](DWORD) Size of Data
(DWORD) Flags
(VOID) Data to be hashed.

Optional*:
(DWORD) Client Key (Double Hash Only)
(DWORD) Server Key (Double Hash Only)
(DWORD) Cookie (Cookie Hash Only)
[/code]You're not sending BNLS_HASHDATA properly, No shit it doesn't work.
You Seriously, SERIOUSLY need to learn how to read your own packet logs.
Most the issues you have been having would be obvious if you simply read your logs.

I really can't see what I'm doing wrong there, unless I'm using the wrong flag. Or you mean the cc's? Ok well simple fix there.

[code]CMSG_BNLS_HASHDATA packet;
packet.Size = 4; // Size of the data to be hashed?
packet.Flags = 0x01;

char *buffer = (char*)malloc(sizeof(packet) + 4);
memcpy(buffer, &packet, sizeof(packet));
strcpy_s(buffer + sizeof(packet), 4, "lol");[/code]

Cc's gone, I guess I could make the DWORD Flags a byte, but I can't see how that'll fix this.

[code]0000   0f 00 0b 04 00 00 00 01 00 00 00 6c 6f 6c 00     ...........lol.[/code]

Post your definition of CMSG_BNLS_HASHDATA.
If you arn't completely thick you'll eventually realize where that data is coming from. You've had this issue before.
Also, the headers are being sent separately because of how I wrote the bncs_send sub (see the 2 send() calls!)

Also, you need to double hash the password, not single.

Anyways, with your last post, thats a valid 0x0B packet! Good for you!

You still need to double hash em.

And I seen the 2 sends in the bncs_send(), but why aren't all packets separated then?

Oh and I'm adding the ClientKey and ServerKey now, since I know I have to use double hash.

And ClientKey is a tracking value? And ServerKey = Server Token?
[code]struct CMSG_BNLS_HASHDATA {
DWORD Size;
DWORD Flags;
void *Data;
};[/code]

Because Nigel is clumping things together.
Honestly, you just need to use a data buffer like the rest of us.
You haven't even gotten to the complicated packets with arrays of structs inside them.

The Client Token is a random 32-bit int generated when the connection is established by the client and used for the eintire connection.
The Server Token is sent to you in 0x50.
Like I said before you need to use the same client token as you did when hashing the cdkey.

In my head this makes sense to me, but I'm not sending what I expect.

[code] CMSG_BNLS_HASHDATA packet;
packet.Size = 4;
packet.Flags = 0x02;
packet.Data = (void*)malloc(4);
strcpy_s((char*)packet.Data, 4, "lol");
packet.ClientKey = g_Cookie;
packet.ServerKey = g_ServerToken;

char *buffer = (char*)malloc(sizeof(packet));
memcpy(buffer, &packet, sizeof(DWORD) * 2);
memcpy(buffer + sizeof(DWORD) * 2, packet.Data, 4);
memcpy(buffer + sizeof(DWORD) * 2 + 4, &packet + sizeof(DWORD) * 2, sizeof(DWORD) * 2);[/code]

[code]0000   17 00 0b 04 00 00 00 02 00 00 00 6c 6f 6c 00 cc  ...........lol..
0010   cc cc cc cc cc cc cc                             .......[/code]

Ok I seriously don't see why this isn't being constructed properly. Nor do I know where this uninitialized memory is coming from.

[code] CMSG_BNLS_HASHDATA packet;
packet.Size = 4;
packet.Flags = 0x02;
packet.Data = (void*)malloc(4);
strcpy_s((char*)packet.Data, 4, "lol");
packet.ClientKey = g_Cookie;
packet.ServerKey = g_ServerToken;

int size = sizeof(DWORD) * 4;
char *buffer = (char*)malloc(size);

memcpy(buffer, &packet, 8);
strcpy_s(buffer + 8, 4, "lol");
memcpy(buffer + 12, &packet + 8, 8);
[/code]

[code]0000   17 00 0b 04 00 00 00 02 00 00 00 6c 6f 6c 00 cc  ...........lol..
0010   cc cc cc cc cc cc cc                             .......[/code]

Where are you getting your numbers?

I meant &packet + 8!

Well I know a DWORD is 4 bytes, so I'm copying over the 1st 2 DWORDS then I'm putting my password in the buffer, but 8 bytes along, after the 2 DWORDS, then I'm putting the last 2 DWORDS after that.

Oh shit, I just realized the buffer size isn't including the 4 bytes for the password, gimme a sec now...

[code]CMSG_BNLS_HASHDATA packet;
packet.Size = 4;
packet.Flags = 0x02;
packet.Data = (void*)malloc(4);
strcpy_s((char*)packet.Data, 4, "lol");
packet.ClientKey = g_Cookie;
packet.ServerKey = g_ServerToken;

char *buffer = (char*)malloc(20); // 4 dwords and my password

memcpy(buffer, &packet, 8);
strcpy_s(buffer + 8, 4, "lol");
memcpy(buffer + 12, &packet + 9, 8);[/code]

[code]CMSG_BNLS_HASHDATA packet;
const char *password = "lol";
int pass_len = strlen(password);
packet.Size = pass_len;
packet.Flags = 0x02;
packet.Data = (void*)malloc(pass_len);
strcpy_s((char*)packet.Data, pass_len, password);
packet.ClientKey = g_Cookie;
packet.ServerKey = g_ServerToken;

char *buffer = (char*)malloc(sizeof(packet) - sizeof(void *) + pass_len);
int main_gap = &packet.Data - &packet.Size;
memcpy(buffer, &packet, main_gap);
memcpy(buffer + main_gap, password, pass_len);
memcpy(buffer + main_gap + pass_len, &packet.ClientKey, sizeof(packet.ClientKey) + sizeof(packet.ServerKey));[/code]

[code]int main_gap = &packet.Data - &packet.Size;
error C2040: '-' : 'void **' differs in levels of indirection from 'DWORD *'[/code]

I think you're trying to take away the length of Data from Size, which doesn't make sense.

I'm taking the ADDRESS of Size from the ADDRESS of Data.
That will give me the number of bytes between the two pointer. AE: it's size.
Type cast em to ints and it'll be fine.
Anyways, why are you against packet buffers?
You say you know how memory is laid out, and how to deal with it, But you don't else you wouldn't being having ANY of the issues you are having.
You need to make an exact copy of this memory layout. If Client token = 0x01010101 and Server = 0x02020202
03 00 00 00 02 00 00 00 6C 6F 6C 01 01 01 01 02 02 02 02

I didn't bother thinking of that level, and you missed out on the +1 for pass_len...

Anyway your code is sending...
[code]0000  17 00 0b 04 00 6c 6f 6c 00 50 1e e7 4b 5f 5d 2c  .....lol.P..K_],
0010  70 cd cd cd cd cd cd                            p......[/code]

You're not supposed to include a null byte.

Well I get runtime errors if I don't.

[img]http://img704.imageshack.us/img704/9431/28056482.png[/img]

oh ya, change strcpy to memcpy

Done, sending this though:

[code]0000  17 00 0b 03 00 6c 6f 6c 08 23 e7 4b d4 1a 6a a3  .....lol.#.K..j.
0010  cd cd cd cd cd cd fd                            .......[/code]

Now, from that packet log, what do YOU think the issue is? Heres a hint: It's really fucking obvious.

Something isn't being set properly, I guess that because of the cd's.

Yes, but what?
Read the log. See what is missing, see what is not what it's suposto be!

Well a DWORD is 4 bytes, and there is 6 bytes of cd, so I'm unsure.

Look at more then just the 0xCD's

Fd? That's leading me to believe a DWORD then a WORD, but I need 2 DWORDS...

Read the packet like the server would read it.

Yeah I don't know where you're going now.

Heres an example. I have a packet with the following format:
[code](BYTE) A
(WORD) B
(DWORD) C
(String) D[/code]
And the following is what it looks like in memory (or sending over the wire):
[code]
01 02 03 04 05 06 07 61 62 63 64 65 00
.  .  .  .  .  .  .  a  b  c  d  e  .[/code] 
If I were to read it manually I would get:
[code]A = 0x01
B = 0x0302
C = 0x07060504
D = abcde[/code]
See what I get at?

Not really no.

You said you knew how memory was laid out.
Why do you lie?
Why do you not try to understand things?
Read my post over and over until you realize what I did yo decode ABCD from the packet.
This is a skill is is REQUIRED for network programming.
And it's simple if you just try.

Like you said before you don't explain things well, and I do understand how memory is laid out. Don't assume things...

Ok, How is a DWORD laid out in memory? Give me an example.

Relax lol, like HDX said you need to go over what you have there. set up some break points again and stick your buffer array in watch, see where its getting that mangled up shit data from.

Its Hdx not HDX it's annoying when you do that.
Anyways, it's more important that he knows how to read data as opposed to getting this one packet fixed right now.
I've fixed every single packet hes worked with so far. And he hasn't learned anything yet. So I am going to walk him through the basics.

Ok fine you got me, I understand certain parts of memory, not everything. And I've learned a few things from the 15 pages of my 3 topics.

Do you have some specific reading on memory then?

You just going to sit there a laugh at me, or going to give me some reading to do?

Forums aren't IM services.  Just because Hdx has responded quickly so far doesn't mean he will every time you post.  In fact, you're pretty lucky he's responded.  Most people here aren't as helpful with newbies, and many threads won't get a reply for a day or more.  Chill out.  Use Google like most people here would have to you to do in the first place.  Everyone here learned BNCS/BNLS pretty much on their own, with less help than you're getting.

I have been being nice and trying to find a simple tutorial but I cant so i'm going to write one.
Anyways, just be honest from the start. It makes things a lot easier.

Well I wasn't really lying, I know some stuff, just not everything. I'd say I was being in-accurate, and I'd appreciated you writing one yourself.

You lied, anyways:

Alright, I am not good at explaing things but I will do my best. If the other regulars here want to comment feel free. As I am writing this off the top of my head. It may not be perfect.

Part One: Data Types
On Battle.net every peice of information is encoded as a specific data type. They are most commonly integers. A number without a decimal point. Integer can be signed or unsigned. If a integer is signed it simply means it can be negative.

The easiest way to seperate integer types is to label them by there bits. And if they are signed/unsigned. Here are a few examples:
uint8 - Unsigned 8-bit Int, also known as a BYTE, Range: 0-255
int8 - Signed 8-bit int, Rang: -128 - 128
uint16 - Unsigned 16-bit int, also known as WORD, Range: 0-65,535
int16 - Signed 16-bit int, Range: -32,768 - 32,768
uint32 - Unsigned 32-bit int, also know as DWORD, Range: 0-4,294,967,295
int32 - Signed 32-but int, Range: -2,147,483,648 - 2,147,483,648
uint64 - Unsigned 64-bit int, also know as QWORD, or possibly FILETIME (though this is a special case), Range: 0-18,446,744,073,709,551,615
And so forth.

The other types of data you will see on Battle.net are Strings. In general when you see "String" as the data type they are referring to a 'CStirng' which is an array of bytes, followed by a single null byte. It's also called a Null-terminated String. In vary rare cases you will run into strings that are terminated by another value, this is usually indicated in the packet notes. (Example, D2GS has 0x0A terminated strings)

Memory Layout:
Almost everything on Battle.net is in Littel-endian layout. Which means the least significant byte comes first. This only matters with integers greater then 8 bits.

Lets get to some examples:
8-bit Ints: They are one byte, and are represented as 1 Hex value.
[code]0x01 = 01
0x02 = 02
0x03 = 03 [/code]
Etc...

16-bit Ints: They are 2 bytes, and logically are represented by 2 hex chunks. Remember, Battle.net is Little endian. So the bytes are reversed.
[code]0x0102 = 02 01
0x0103 = 03 01[/code]
And so on.

32-bit Ints: They are 4 bytes, and get 4 hex chunks. Once again, in reverse order.
[code]0x01020304 = 04 03 02 01
0xAABBCCDD = DD CC BB AA[/code]
And so forth.

64-bit Ints: They are 8 bytes, and are just the same as everything else.
[code]0x0102030405060708 = 08 07 06 05 04 03 02 01
0xAABBCCDDEEFF0011 = 11 00 FF EE DD CC BB AA[/code]


So, how can we use this to read packet logs?
Lets say we have a packet which is described as follows:
[code](BYTE) A
(BYTE) B[/code]

When we look at it in the log. We see something like:
[code]00 01[/code]

As I said above, a BYTE is a 8-bit int. Represented by 1 hex value. So A would be the first Hex value:
00 01

Since we have already read a byte, anything else we read, starts AFTER that byte.
So if we were to Read B we would read the 2nd hex value:
00 01

Therefore, our packet is:
[code]A = 0x00
B = 0x01[/code]
And there is no more data remaing.

Now you can expand upon this to read all the different sizes of integer.
Here is another example:
[code](DWORD) A
(WORD) B
(BYTE) D[/code]
With the data of:
[code]01 02 03 04 05 06 07 [/code]

The first thing we read, is a DWORD, which is 4 bytes.
01 02 03 04 05 06 07
And, since it's little-endian, it's reversed. So we end up with a value of: 0x04030201

Next we read a WORD, 2 bytes, and again in reverse order!
01 02 03 04 05 06 07
Which turns into: 0x0605

And yet again, we read a single byte, we can't really reverse the order of 1 thing, so this one's easy:
01 02 03 04 05 06 07
Which turns into: 0x07


Now, the only other thing you need to learn to read, are strings. They are really simple. You read everything untill you hit the terminator.
So if you have a packet as such:
[code]61 62 63 64 65 00
a  b  c  d  e  .[/code]
It's null terminated, so read untill you get to '00'
You end up with 'abcde'

Part 3: Arrays
Arrays are stright forward, they are simply multiple values of the specified type.
So if you see:
[code](DWORD[2]) Data[/code]
Its exactly the same as:
[code](DWORD) Data[0]
(DWORD) Data[1][/code]


So, this isn't a perfect tutorial. But it's fairly basic. So i'm gunna leave with a test!
The packet format is:
[code](DWORD) Registration Version
(DWORD) Registration Authority
(DWORD) Account Number
(DWORD) Registration Token[/code]
And your packet log is:
[code]AB CF 64 72 85 AB DD CC CC 74 00 94 11 BB 34 76[/code]
What would each of the values in the packet be?

Just an interjection while you're on this topic, you should make sure you do things right with endianness the first time around to avoid lots of problems. I never properly did a packet buffer/debuffer, and I used all kinds of hacks in my bots, such as appending a character to a string by doing something like *(unsigned short *)(str + strlen(str)) = '\', which turned it into a disaster when I went to compile for SPARC.

Thats a horrible horrible way to append a character... (code wise)
Anyways, endianess doesn't matter beyond what I explained above right now.

Didn't read the whole thing yet, but I thought I'd point out that FILETIME is a structure of 2 UInt32's, a Hiword and Loword.  You can treat it as a signle UInt64, though if you try to derive a time from it in that form you will get bad results.

Also, DWORD/WORD on BnetDocs are (by convention, apparently) the 16-bit system equivalent, as a WORD on a 32-bit system is 4 bytes, and on a 64-bit system 8 bytes, but in BnetDocs a WORD is only 2 bytes.

Pretty sure I got these right, and that really cleared some things up.

Registration Version  = 0x7264CFAB
Registration Authority = 0xCCDDAB85
Account Number = 0x940074CC
Registration Token         = 0x7634BB11

[quote author=rabbit link=topic=18229.msg184797#msg184797 date=1273466182]
Didn't read the whole thing yet, but I thought I'd point out that FILETIME is a structure of 2 UInt32's, a Hiword and Loword.  You can treat it as a signle UInt64, though if you try to derive a time from it in that form you will get bad results.[/quote]Odd, I've never had issues with passing it as a 64-bit int to the various APIs.  If you mean manually trying to convert it.. ya thats a pain.

[quote]Also, DWORD/WORD on BnetDocs are (by convention, apparently) the 16-bit system equivalent, as a WORD on a 32-bit system is 4 bytes, and on a 64-bit system 8 bytes, but in BnetDocs a WORD is only 2 bytes.[/quote]Thats why I put them in the AKA form, anyways Bnet packet docs have been behind the time for a long time. Personally I think everything should be denoted in (u)int(#) format. It's less ambiguous.
[quote author=Trunning link=topic=18229.msg184799#msg184799 date=1273471626]
Pretty sure I got these right, and that really cleared some things up.

Registration Version  = 0x7264CFAB
Registration Authority = 0xCCDDAB85
Account Number = 0x940074CC
Registration Token         = 0x7634BB11
[/quote]Correct!!!!!
Now heres the kicker.
Look at your packet log again.
And figure out whats wrong with it.
This ones a bit trickier then simply reading the log because the packet is malformed. So you have to put some logical thinking into it.

[code]struct BNLS_HEADER {
WORD Length;
BYTE         ID;
};

struct CMSG_BNLS_HASHDATA {
DWORD Size;
DWORD Flags;
void *Data;
DWORD ClientKey;
DWORD ServerKey;
};[/code]

[code]0000   17 00 0b 03 00 6c 6f 6c 3f ab e7 4b fc 74 ba 85  .....lol?..K.t..
0010   cd cd cd cd cd cd fd                             .......[/code]

Length: 17 00
ID: 0b

Size: 03 00 // ends to early should be 2 more bytes here

And there should be another DWORD flags after it, not the string. Lemme look at the code.

Correct!!!! And there is actually one more error but it should be obvious once you fix the one you found!
Now, how hard was that, with a little understanding of how to read the logs. It makes identifying issues million times easier.

Finally fixed the packet up, now let me confirm it.

[code]0000   17 00 0b 03 00 00 00 02 00 00 00 6c 6f 6c 88 ad  ...........lol..
0010   e7 4b 90 ee 12 9a fd                             .K.....[/code]

Length = 17 00
ID = 0b

Size = 03 00 00 00
Flags = 02 00 00 00
Password = 6c 6f 6c
ClientKey = ad e7 4b 90
ServerKey = ee 12 9a fd

Everything is there, let me test it.

Omg, I logged in fine!

Now do I have to enter chat now, or can I startup mcp and logon to a character, and then enter chat?

And is this still the correct order for mcp? https://davnit.net/bnet/vL/index.php?topic=11383.0

You actually still have an issue.
I would suggest your fix it before moving on.
Look at your packet log, and ask yourself 'where did 88 go?'

And yes, the post your linked to looks correct.

Uh what packet are you referring to? 88 is in the log I posted above. Unless you mean, where was it sent.

[quote author=Trunning link=topic=18229.msg184803#msg184803 date=1273474663]
Finally fixed the packet up, now let me confirm it.

[code]0000   17 00 0b 03 00 00 00 02 00 00 00 6c 6f 6c 88 ad  ...........lol..
0010   e7 4b 90 ee 12 9a fd                             .K.....[/code]

Length = 17 00
ID = 0b

Size = 03 00 00 00
Flags = 02 00 00 00
Password = 6c 6f 6c
ClientKey = ad e7 4b 90 <~~Wrong
ServerKey = ee 12 9a fd <~~Wrong

Everything is there, let me test it.
[/quote]

I was in a rush Mr Negative, hmm.

Length = 17 00
ID = 0b

Size = 03 00 00 00
Flags = 02 00 00 00
Password = 6c 6f 6c
ClientKey = 88 ad e7 4b
ServerKey = 90 ee 12 9a

What's the fd? An extra uninitialized byte?

The fd is from something. When you use malloc() it doesn't actually set the memory to anything, it just leaves what ever happened to be there.
Though, it's  odd it's always been fd.. anyways, Its a simple fix, find it!

Take 1 byte of the allocation, ok well that didn't work hmm.

Well memset didn't set it to zero, so it looks like it's being set somewhere.

I don't think that would actually fix it.
I think it's an issue with your bnls_send parameters.

Yeah it was the size.

[code]0000   16 00 0b 03 00 00 00 02 00 00 00 6c 6f 6c 2d b3  ...........lol-.
0010   e7 4b 67 3c 33 81                                .Kg<3.[/code]

Oh and you've been insisting on me using a packet buffer, care to link me to one. I've searched to forum, without any luck.

I don't have one I can readily link. But you should be able to find iago's. Somewhere on his site: http://www.skullsecurity.org/wiki/

Real quick, when I get to http://www.bnetdocs.org/?op=packet&pid=144.

Do I double hash "password" for the password?

Yes

My title isn't pointing to the right location, I checked my packet log, I'm receiving 3 dwords after the header, and before the string.

[code] BNCS_HEADER head;
head.Sanity = 0xFF;
head.ID = 0x40;
head.Length = sizeof(BNCS_HEADER);

send(sockBNCS, (char*)&head, head.Length, NULL);

char *buf = (char*)malloc(sizeof(BNCS_HEADER));
recv(sockBNCS, buf, sizeof(BNCS_HEADER), NULL);
BNCS_HEADER da;
memcpy(&da, buf, sizeof(BNCS_HEADER));
free(buf);

char *buffer = (char*)malloc(da.Length - sizeof(BNCS_HEADER));
int body_size = da.Length - sizeof(BNCS_HEADER);

char *title = buffer + sizeof(DWORD) * 3;
int title_len = strlen(title) + 1;
char *desc = buffer + sizeof(DWORD) * 3 + title_len;
int desc_len = strlen(desc) + 1;

printf("Title: %s\nDesc: %s\n", title, desc);

free(buffer);[/code]

Are you sure it's not just stuffed packets?

Packet looks fine in wireshark.

Here is the received packet.

[code]0000   ff 40 33 00 00 00 00 00 01 00 00 00 01 00 00 00  .@3.............
0010   55 53 57 65 73 74 00 52 65 61 6c 6d 20 66 6f 72  USWest.Realm for
0020   20 74 68 65 20 55 53 20 57 65 73 74 20 43 6f 61   the US West Coa
0030   73 74 00                                         st.[/code]

After analyzing the packet everything is there.

[code]ff 40 33 00 = Header
00 00 00 00 = Unknown, usually 0
01 00 00 00 = Count
01 00 00 00 = Unknown usually 1

55 53 57 65 73 74 00 = Title
52 65 61 6c 6d 20 66 6f 72 20 74 68 65 20 55 53 20 57 65 73 74 20 43 6f 61 73 74 = Description[/code]

What packet do you think that is?  It's fine.

Its another obvious error.
Follow your flow of code, see what variables are being set to what...
Also, quit double posting, theres an edit button for a reason.

The ID of my header is being set to 64, it should be 40. I have no idea why this is happening.

Ah, it's in decimal, lemme look at the rest of the code.

I honestly don't know what it was, but rewriting my code fixed it.

You forgot to call recv()
You created the buffer, but you never filled it with anything.

Oh that was stupid, and you will never guess what happened. I was failing to send packet 0x3E correctly, so I checked my packet log, seen there was an extra 4 bytes there, and fixed it by myself, so it appears I've learned something.

How can I get the IP Address from the IP DWORD? It says on the page to use ntohs() for the port, but doesn't say about the IP Address.

Each byte is a block, in "standard" order.

Oh and real quick, is it giving me the IP and Port of the Realm Server I'm suppose to connect to or no?

Yes.

Can I get an example on how to convert the DWORD IP to an actual IP Address?

307491135 is the DWORD

3f f1 53 12 are the 4 bytes

63.241.83.18 is the actual IP

[quote author=Trunning link=topic=18229.msg184837#msg184837 date=1273601524]
Can I get an example on how to convert the DWORD IP to an actual IP Address?

307491135 is the DWORD

3f f1 53 12 are the 4 bytes

63.241.83.18 is the actual IP
[/quote]

Each byte is one octet of the IP address. sprintf("%d.%d.%d.%d", byte[0] byte[1], byte[2], byte[3]); would do the trick.

There's 4 DWORDS before the IP DWORD, so 17 through 20 should work, but [17] always prints out -15.

[code]printf("\n%d.%d.%d.%d\n", buffer[17], buffer[18], buffer[19], buffer[20]);[/code]

-15 = F1
Figure it out from there! (Hint: What does F1 =?)

241? What was the -15 to F1 conversion, I thought the 15 was decimal, but that's what 241 is.

-15 as a byte in binary is 11110001
241 as a byte in binary is 11110001
It's just a problem with signed vs unsigned.

Ok then, how do I convert the decimal version to an actual IP in C++?

(unsigned byte)buffer[17]; should work.

It creates a hole lot of errors trying to type cast to "unsigned byte", any idea why?

[code]CString str_ip = inet_ntoa(addr);[/code]

[quote author=l)ragon link=topic=18229.msg184857#msg184857 date=1273652179]
[code]CString str_ip = inet_ntoa(addr);[/code]
[/quote]

Tried this, but it won't let me typecast a string to in_addr or whatever.

[quote author=Hdx link=topic=18229.msg184855#msg184855 date=1273649235]
(unsigned byte)buffer[17]; should work.
[/quote]All bytes are unsigned.  (uint8) buffer[17];

Thanks to Rabbit I fixed the signed / unsigned problem.

Now I'm printing out: 241.83.18.23.

Here are the 4 bytes: 3f f1 53 12

And the real IP based on my conversion: 63.241.83.18

I noticed the "241.83.18" is in both the printed version, and my conversion. So how can I convert it in C++?

I've made no progress with this :(

[code]printf("\n%d.%d.%d.%d\n", buffer[17], buffer[18], buffer[19], buffer[20]);
  241.83.18.23
3f  f1 53 12
63.241.83.18[/code]Seems obvious where the bug is to me..

Oh wow simple.

Fixed that, but now I'm having problems putting the IP in a variable its self. I've tried sprintf, memcpy, strcpy, neither worked. How can I do it properly?