After receiving the CD-Key hash and version hash from BNLS, I send it to Battle.net in 0x51 (obviously).  I am building packet 0x51 with the following data inserted in the following order (after the 4-byte header obviously).

Client Token: 82e6879f
EXE Version: 1010103
EXE Hash: 820e4386
Number of keys in this packet: 1
Using Spawn (32-bit): 0
Hashed CD-Key Data:
        Key Length: d
        Product: 1
        CD-Key Value 1: 521e3d
        Unknown (0): 0
        Hashed CD-Key Data:
                d826f449
                e77d27f9
                540a2ebd
                bf497529
                3d96c7a2
Version Check: Starcraft.exe 05/26/04 00:46:00 1048576
CD-Key Owner: ModBot

(Yes, I am aware that you are able to figure out my CD-Key in ~<1-4 ms with this information).

After I send 0x51 I get back 0x101 from Battle.net & TestBNCS (Invalid Version).  According to Arta who was debugging my connection on TestBNCS, my hash value for the version was way off.  However, I am simply using the hash values I get back from BNLS, and I have double checked many times to make sure I am properly parsing the data I get back, and sending data in the right order, etc.

Here was an example (of many) when I connected to TestBNCS:
[debg] 14/11/2004 16:51:58: [68.189.60.21:4624] Processing packet 0x51
[debg] 14/11/2004 16:51:58: Got:  820E4386
[debg] 14/11/2004 16:51:58: Want: 81066C13

Anyways, if someone could help me figure out this problem message me on AIM at SoROwNz or MSN at mephisto@zodiaclegends.com.  Thanks in advance to those who can help.  Also, if anyone has had problems similar to this, please explain what you did to fix them here.  :)

[debg] 14/11/2004 16:51:58: Got:  820E4386
[debg] 14/11/2004 16:51:58: Want: 81066C13

Packet log your BNET and BNLS connections, and make sure the data is being transferred exactly.  You could have somewhere in your code where the information becomes a little mutated(I've had this problem before with certain types of sockets).

Post the control string that produced the result shown.  Without it, there's no way for us to validate which of you is correct, or to do any analysis of how far off you might be.

Ended up he was sending a bad dll version file number to BNLS.  Let's say the file was "IX86ver1.mpq", he was sending 0x31 ('1') instead of 0x1

[quote author=UserLoser link=topic=9543.msg88838#msg88838 date=1100453828]
Ended up he was sending a bad dll version file number to BNLS.  Let's say the file was "IX86ver1.mpq", he was sending 0x31 ('1') instead of 0x1
[/quote]

For those who didn't understand what UserLoser just said and may experience this problem in the future:
I was taking the string "IX86ver1.mpq" and sending '1' (VersionFile[7]) and type casting that to an unsigned long.  Well, in ASCII, '1' = 0x31.  So I was really sending 0x31 instead of 0x1, which is obviously not a value 0-7.  Perhaps BNLS should do a check on the version digit to make sure that it's sent a value 0-7, not 31 or something like I did.  That way it'd perhaps make it easier to debug problems like these, since I thought everything I sent was fine.  Also, another suggestion for BNLS would be to provide a string at the end of each packet explaining an error.

[quote author=Mephisto link=topic=9543.msg88839#msg88839 date=1100454252]
[quote author=UserLoser link=topic=9543.msg88838#msg88838 date=1100453828]
Ended up he was sending a bad dll version file number to BNLS.  Let's say the file was "IX86ver1.mpq", he was sending 0x31 ('1') instead of 0x1
[/quote]

For those who didn't understand what UserLoser just said and may experience this problem in the future:
I was taking the string "IX86ver1.mpq" and sending '1' (VersionFile[7]) and type casting that to an unsigned long.  Well, in ASCII, '1' = 0x31.  So I was really sending 0x31 instead of 0x1, which is obviously not a value 1-7.  Perhaps BNLS should do a check on the version digit to make sure that it's sent a value 0-7, not 31 or something like I did.  That way it'd perhaps make it easier to debug problems like these, since I thought everything I sent was fine.  Also, another suggestion for BNLS would be to provide a string at the end of each packet explaining an error.
[/quote]

That's what packet logging is for. It would allow you to see that you are sending it incorrectly...

[quote author=Minus link=topic=9543.msg88846#msg88846 date=1100460441]
[quote author=Mephisto link=topic=9543.msg88839#msg88839 date=1100454252]
[quote author=UserLoser link=topic=9543.msg88838#msg88838 date=1100453828]
Ended up he was sending a bad dll version file number to BNLS.  Let's say the file was "IX86ver1.mpq", he was sending 0x31 ('1') instead of 0x1
[/quote]

For those who didn't understand what UserLoser just said and may experience this problem in the future:
I was taking the string "IX86ver1.mpq" and sending '1' (VersionFile[7]) and type casting that to an unsigned long.  Well, in ASCII, '1' = 0x31.  So I was really sending 0x31 instead of 0x1, which is obviously not a value 1-7.  Perhaps BNLS should do a check on the version digit to make sure that it's sent a value 0-7, not 31 or something like I did.  That way it'd perhaps make it easier to debug problems like these, since I thought everything I sent was fine.  Also, another suggestion for BNLS would be to provide a string at the end of each packet explaining an error.
[/quote]

That's what packet logging is for. It would allow you to see that you are sending it incorrectly...
[/quote]

Yes, I know...

Mephisto: Kp alerted me of your finding. Thanks for the testing - you've found a bug in BNLS.

The bug: BNLS doesn't check whether the "DLL version" parameter is valid. Instead of returning a "failure" reply when the parameter is invalid, it returns a "success" reply with some miscalculated values.

I looked at the source and it is not possible to crash BNLS by exploiting this bug, therefore it's a minor bug. It might be fixed sometime sooner or later.