[0x51] Invalid Version... What's Wrong?

[Ryan Marcus]

No matter what I do, I continue to get an invalid version error from 0x51. I am almost completely sure its not formatting.


The 0x51 packet, sent to BNCS:

Send data (106 bytes).
<0000003B< FF 51 6A 00  00 00 00 48  09 03 01 01  A5 EA 8F E1  .Qj....H........
<0000004B< 01 00 00 00  00 00 00 00  82 26 31 0D  00 00 01 00  .........&1.....
<0000005B< 00 75 38 90  00 00 00 00  8A E1 2B 1C  03 77 89 B2  .u8.......+..w..
<0000006B< A5 AE B3 A7  CD 77 1E C3  FD B5 8B 15  73 74 61 72  .....w......star
<0000007B< 63 72 61 66  74 2E 65 78  65 20 30 38  2F 30 37 2F  craft.exe 08/07/
<0000008B< 30 35 20 31  32 3A 30 36  3A 34 32 20  31 30 39 33  05 12:06:42 1093
<0000009B< 36 33 32 00  4C 75 78 65  72 00                     632.Luxer.

The JBLS response for VersionCheck:

Receive data (55 bytes).
>000000AE> 37 00 09 01  00 00 00 09  03 01 01 A5  EA 8F E1 73  7..............s
>000000BE> 74 61 72 63  72 61 66 74  2E 65 78 65  20 30 38 2F  tarcraft.exe 08/
>000000CE> 30 37 2F 30  35 20 31 32  3A 30 36 3A  34 32 20 31  07/05 12:06:42 1
>000000DE> 30 39 33 36  33 32 00                               093632.

BnetDocs page for 0x51:

(DWORD)          Client Token
(DWORD)          EXE Version
(DWORD)          EXE Hash
(DWORD)          Number of keys in this packet
(BOOLEAN)        Using Spawn (32-bit)

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

(STRING)         Exe Information
(STRING)         CD Key owner name 

BnetDocs page for the BNLS response to VersionCheck:

(BOOLEAN)        Success 

If Success is TRUE:

(DWORD)          Version.
(DWORD)          Checksum.
(STRING)         Version check stat string.

Thanks in advance for any help!

[Soul Taker]

I don't see you sending a key length.  It also looks like something is messed up after the spawn boolean.

[Ryan Marcus]

The key length is after the spawn boolean, right?

I thought BNLS sent the key length with it, because the docs say 9 DWORDS. If one is not the length, what is it?

And what do you mean "something"?

Thanks for the reply, SoulTaker, and thanks in advance for any future replies.

[shout]

No matter what I do, I continue to get an invalid version error from 0x51. I am almost completely sure its not formatting.


The 0x51 packet, sent to BNCS:

Send data (106 bytes).
<0000003B< FF 51 6A 00  00 00 00 48  09 03 01 01  A5 EA 8F E1  .Qj....H........
<0000004B< 01 00 00 00  00 00 00 00  82 26 31 0D  00 00 01 00  .........&1.....
<0000005B< 00 75 38 90  00 00 00 00  8A E1 2B 1C  03 77 89 B2  .u8.......+..w..
<0000006B< A5 AE B3 A7  CD 77 1E C3  FD B5 8B 15  73 74 61 72  .....w......star
<0000007B< 63 72 61 66  74 2E 65 78  65 20 30 38  2F 30 37 2F  craft.exe 08/07/
<0000008B< 30 35 20 31  32 3A 30 36  3A 34 32 20  31 30 39 33  05 12:06:42 1093
<0000009B< 36 33 32 00  4C 75 78 65  72 00                     632.Luxer.

BnetDocs page for 0x51:

(DWORD)          Client Token
(DWORD)          EXE Version
(DWORD)          EXE Hash
(DWORD)          Number of keys in this packet
(BOOLEAN)        Using Spawn (32-bit)

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

(STRING)         Exe Information
(STRING)         CD Key owner name 

BnetDocs page for the BNLS response to VersionCheck:

(BOOLEAN)        Success 

If Success is TRUE:

(DWORD)          Version.
(DWORD)          Checksum.
(STRING)         Version check stat string.

Thanks in advance for any help!

Lets break down your packet.

Code Select Expand


FF 51 6A 00 Header
00 00 00 48 Client Token
09 03 01 01 Exe Ver
EA 8F E1 73 Check Revision
01 00 00 00 Number of keys
00 00 00 00 Spawn
(stuff)


[Ryan Marcus]

No matter what I do, I continue to get an invalid version error from 0x51. I am almost completely sure its not formatting.


The 0x51 packet, sent to BNCS:

Send data (106 bytes).
<0000003B< FF 51 6A 00  00 00 00 48  09 03 01 01  A5 EA 8F E1  .Qj....H........
<0000004B< 01 00 00 00  00 00 00 00  82 26 31 0D  00 00 01 00  .........&1.....
<0000005B< 00 75 38 90  00 00 00 00  8A E1 2B 1C  03 77 89 B2  .u8.......+..w..
<0000006B< A5 AE B3 A7  CD 77 1E C3  FD B5 8B 15  73 74 61 72  .....w......star
<0000007B< 63 72 61 66  74 2E 65 78  65 20 30 38  2F 30 37 2F  craft.exe 08/07/
<0000008B< 30 35 20 31  32 3A 30 36  3A 34 32 20  31 30 39 33  05 12:06:42 1093
<0000009B< 36 33 32 00  4C 75 78 65  72 00                     632.Luxer.

BnetDocs page for 0x51:

(DWORD)          Client Token
(DWORD)          EXE Version
(DWORD)          EXE Hash
(DWORD)          Number of keys in this packet
(BOOLEAN)        Using Spawn (32-bit)

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

(STRING)         Exe Information
(STRING)         CD Key owner name 

BnetDocs page for the BNLS response to VersionCheck:

(BOOLEAN)        Success 

If Success is TRUE:

(DWORD)          Version.
(DWORD)          Checksum.
(STRING)         Version check stat string.

Thanks in advance for any help!

Lets break down your packet.

Code Select Expand


FF 51 6A 00 Header
00 00 00 48 Client Token
09 03 01 01 Exe Ver
EA 8F E1 73 Check Revision
01 00 00 00 Number of keys
00 00 00 00 Spawn
(stuff)


That looks correct to me.... A boolean is just a DWORD with a 0 for false and a 1 for true, right?

[l2k-Shadow]

In this case, yes... it is not always like that though.

[shout]

I think you CDKey decoding is incorrect.

221324930 is your key length :/
0x100 is your product... ect...

[Ryan Marcus]

I think you CDKey decoding is incorrect.

221324930 is your key length :/
0x100 is your product... ect...

Hmm.. It should be fine because I am using BNLS. And even if, the response would not be invalid version, it would be invalid CDKey, right?

[shout]

I think you CDKey decoding is incorrect.

221324930 is your key length :/
0x100 is your product... ect...

Hmm.. It should be fine because I am using BNLS. And even if, the response would not be invalid version, it would be invalid CDKey, right?

I guess so...

If you send BNLS extra crap it will include it in the length of the key but not always result in an incorrect hash.

[raylu]

Wait, you're sending 82 26 31 0D for the key length. Yes, BNLS does send 9 DWords, but no where in the BNLS response do I see 82 26 31 0D.

[Ryan Marcus]

Wait, you're sending 82 26 31 0D for the key length. Yes, BNLS does send 9 DWords, but no where in the BNLS response do I see 82 26 31 0D.

Thats because I am not stupid enough to post that BNLS packet because it has my CDKey in it

But it should not matter

Its telling me there is an invalid version not an invalid CDKey.

Would it give me invalid version if I gave it an invalid key length?

Also, is the key length the length of the original key, the decoded key, or the hashed key, so I can calculate it myself and check what BNLS is saying.

[PaiD]

length of your original key

[raylu]

The BNLS response contains the hash of your CDKey...so no one will know your CDkey.

[Kp]

so no one will know your CDkey.

That's not entirely accurate.  Although the cdkey is returned in hashed form, most of Blizzard's cdkey algorithms have sufficiently poor spread that it's computationally feasible to derive the secret value by exhaustive search once the hash is known.  Starcraft has a mere 1000 possibilities for the secret value.