SID_AUTH_CHECK
| Protocol | BNCS |
|---|---|
| Directions | Client → Server and Server → Client |
| Used by |      
|
The client proves its game version and CD keys. The server accepts or rejects them.
Client → Server
After the server's SID_AUTH_INFO, once the client has run the version check.
| Type | Field | Notes | Confidence |
|---|---|---|---|
UINT32 |
Client token | A random value chosen by the client for this session. | ✅ Verified |
UINT32 |
EXE version | The game executable's version. | ✅ Verified |
UINT32 |
EXE hash | The result of running the version-check formula over the game files. | ✅ Verified |
UINT32 |
Number of CD keys | 1 for most games. 2 for expansions that also need the original game's key. |
✅ Verified |
UINT32 |
Spawn | 1 for a spawned (limited) installation, otherwise 0. |
✅ Verified |
| For each CD key | |||
UINT32 |
Key length | Number of characters in the key. | ✅ Verified |
UINT32 |
Product value | Decoded from the key. | ✅ Verified |
UINT32 |
Public value | Decoded from the key. | ✅ Verified |
UINT32 |
Unused | 0. |
✅ Verified |
VOID |
Key hash (20 bytes) | Mixed with both tokens, so it is different every session. It cannot identify a key; use the product and public values for that. | ✅ Verified |
STRING |
EXE information | The executable's name, date and size. | ✅ Verified |
STRING |
Key owner | The name entered when the game was installed. | ✅ Verified |
Server → Client
| Type | Field | Notes | Confidence |
|---|---|---|---|
UINT32 |
Result | See the table below. | ✅ Verified |
STRING |
Additional information | Depends on the result: a patch file name for an old version, or who is using a key. | ⚠️ Single source |
Results
| Value | Meaning | Confidence |
|---|---|---|
0x000 | Passed. The client continues to the account logon. | ✅ Verified |
0x100 | Game version too old. The additional information names a patch MPQ, and the client shows an upgrade message. | ✅ Verified |
0x101 | Game version not valid. | ⚠️ Single source |
0x102 | Game version too new. | ⚠️ Single source |
0x200 | CD key not valid. | ⚠️ Single source |
0x201 | CD key already in use. The additional information names who is using it. | ⚠️ Single source |
0x202 | CD key banned. | ⚠️ Single source |
0x203 | CD key is for a different game. | ⚠️ Single source |
0x210 – 0x213 | The same four key problems (not valid, in use, banned, wrong game), for the expansion's key. | ⚠️ Single source |
Remarks
Where the CD-key block goes. The per-key block comes before the EXE information string. This order was confirmed from a real client's single-key logon. The two-key layout used by expansions follows the same pattern but hasn't been captured yet.
Recognising a key. Because the key hash changes every session, a server that wants to allow only one session per CD key has to compare the product and public values instead.
Appears in
Sources and credits
- Command Center: bnetccd session handling: request layout captured from a real client on September 9, 2026
- BNETDocs, SID_AUTH_CHECK (client to server): documented by the original BNETDocs contributors, and edited 7 times since.
- BNETDocs, SID_AUTH_CHECK (server to client): documented by LordVader, and edited 8 times since.
This page is written in our own words. BNETDocs is credited for its research; none of its text is copied. See Credits.