BNETDocs
C>S 0x51 SID_AUTH_CHECK
Message Id:0x51
Message Name:SID_AUTH_CHECK
Direction:Client to Server
Used By:Diablo II, Diablo II Lord of Destruction
Starcraft Broodwar, Starcraft Original
Warcraft III The Frozen Throne, Warcraft III Reign of Chaos
Format:

(UINT32) Client Token
(UINT32) EXE Version
(UINT32) EXE Hash
(UINT32) Number of CD-keys in this packet
(UINT32) Spawn Key (1 is TRUE, 0 is FALSE) **

For each Key:
   (UINT32)     Key length
   (UINT32)     Key Product value 
   (UINT32)     Key Public value
   (UINT32)     Unknown (0)
    (UINT8)[20] Hashed Key Data

(STRING) EXE Information
(STRING) Key owner name *

Remarks

Contains the EXE Version and Hash as reported by CheckRevision() and CDKey values.

  • Client Token: a random value generated by the client and used for key and password hashing.
  • EXE Version: The Major.Minor.Revision.Build number of the EXE, with bytes in that order. This can be set to 0 on official servers, as only the EXE hash is checked.
  • EXE Hash: The checksum value calculated by the ValueString returned in SID_AUTH_INFO.

The data that should be hashed for Hashed Key Data is:

  • For 13/16 character keys (hashed using BSHA1):
    1. (UINT32) Client Token
    2. (UINT32) Server Token
    3. (UINT32) Key Product value (from decoded CD key)
    4. (UINT32) Key Public value (from decoded CD key)
    5. (UINT32) 0
    6. (UINT32) Key Private value (from decoded CD key)
  • For 26 character keys (hashed using standard SHA1):
    1. (UINT32) Client Token
    2. (UINT32) Server Token
    3. (UINT32) Key Product value (from decoded CD key)
    4. (UINT32) Key Public value (from decoded CD key)
    5. (UINT8)[10] Key Private value (from decoded CD key)

The data that should be used for EXE Information should be separated by one space, in the format of:

  1. EXE Name (ex. war3.exe)
  2. Last Modified Date (ex. 08/16/09)
  3. Last Modified Time (ex. 19:21:59)
  4. Filesize in bytes (ex. 471040)

An example of a valid string would be: war3.exe 08/16/09 19:21:59 471040 This can be set to null or any other value on official servers, as only the EXE Hash is checked.

* The CD Key owner name must be no greater than 15 characters, otherwise it becomes trimmed by Battle.net.

** Spawn value can only be TRUE for STAR, JSTR, and W2BN. Any other game will cause unexpected results.

| Edited:
Comments
Kaylin

While this comment applies to every message that contains a hash it is especially pertinent to the authentication check message used by WC3/D2/SC because the distinction is more obvious. Hashes are not sequences of dwords. A hash is a bit-string. This means (Dword) Hashed Key Data[5] is in fact (Byte) Hashed Key Data[20]. I make the distinction here because both bsha and sha1 are used with this message. Specifically the 26-character product codes use sha1 and the 13/16 character product codes uses bsha. Implementations of bsha and sha1 are available across the internet so I won't explain them in detail here. It is important to note that while sha1 is represented in big endian, bsha is little endian. If you presume the output of these functions are dwords not bit strings you may not send the correct data since the BNCS protocol is itself little-endian. VERY IMPORTANT: When I say Dword Input for some variable passed to these functions you're going to have to put the least significant byte of that dword into the least significant byte of the internal state for bsha, and into the most significant byte for sha1 and so on in order to get the correct output.

In addition the hashed key data is not the same for the different key sizes. Note: I refer to dwords here because while the output is a bit string the internal state is indeed a set of dwords. The hashed data for bsha is as above, which I shall repeat here so the distinction between the 26-char keys is clear. Remember bsha is little endian so the least significant byte of the first resulting dword of the final internal state is the first byte of output.

Input for 16/13 character product key hashes:

(Dword) Client Nonce (Client Token)
(Dword) Server Nonce (Server Token)
(Dword) Product
(Dword) Public
(Dword) Zero
(Dword) Private

Now, the 26-character keys use sha1 NOT bsha. Note, sha1 is big-endian internally. The most significant byte of the first resulting dword of the final internal state should be sent across the wire first etc. (because hash outputs aren't dwords).

(Dword) Client Nonce
(Dword) Server Nonce
(Dword) Product
(Dword) Public
(Byte) Private[10]

Note the difference: there is no zero dword in the input to the hash function.

l)ragon

As a reminder, for the clients that have no cdkeys the (For each Key) feild is empty, and the Number of keys reflects this aswell.