C>S 0x51 SID_AUTH_CHECK

Transport Layer:Transmission Control Protocol (TCP)
Application Layer:Battle.net v1 TCP Messages (SID)
Message Id:0x51
Message Name:SID_AUTH_CHECK
Direction:Client to Server
Used By:Starcraft Original, Starcraft Broodwar
Diablo II, Diablo II Lord of Destruction
Warcraft III Reign of Chaos, Warcraft III The Frozen Throne
Message Format:
(does not include protocol header)		 
(UINT32) Client Token
(UINT32) Version
(UINT32) Checksum
(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

Sends the results from the CheckRevision() operation as well as CD key information to the server for verification. Parameters for this operation are returned in SID_AUTH_INFO. For more information on this operation, see the CheckRevision document.

  • Client Token: a random value generated by the client and used for key and password hashing. Once generated this value should not change for the duration of the session.
  • Version: The "version" value returned by the CheckRevision() function.
  • Checksum: The "checksum" value returned by the CheckRevision() function. This is the primary value used in determining if the check fails or not.

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 format and value of the EXE Information string is dependent on the specific MPQ provided in SID_AUTH_INFO. It is returned as the "info" value from the CheckRevision() function.

* 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: Anonymous

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.