0x3A SID_LOGONRESPONSE2

ProtocolBNCS
DirectionsClient → Server and Server → Client
Used bySTARSEXPD2DVD2XP

Logs on to an account with a salted X-SHA-1 password proof.

Client → Server

After SID_AUTH_CHECK passes.

TypeFieldNotesConfidence
UINT32 Client token The same client token sent in SID_AUTH_CHECK. Verified
UINT32 Server token The token from the server's SID_AUTH_INFO. Verified
VOID Password proof (20 bytes) X-SHA-1 of: client token, server token, then X-SHA-1 of the lowercase password. Verified
STRING Account name Verified

Server → Client

TypeFieldNotesConfidence
UINT32 Status See the table below. Verified
STRING Reason Only sent with status 0x06. ⚠️ Single source

Status

ValueMeaningConfidence
0x00Logged on. Verified
0x01No such account. The client offers to create it. Verified
0x02Wrong password. Verified
0x03Account data is damaged. Diablo II only.⚠️ Single source
0x06Account closed. A reason string follows.⚠️ Single source

Remarks

Checking the proof. The server stores X-SHA-1 of the lowercase password. To check a logon, it repeats the client's calculation using the server token it issued itself, never the token the client sends back. Using its own token is what stops an old proof from being replayed.

Worked example. With client token 0xDEADBEEF, server token 0x12345678 and the password password, the proof (as five little-endian words) is 7488ad2d 82dc91a2 8aa43a7c 8d596822 a2920091.

A client that gets a status it doesn't recognise shows a general error and disconnects.

Appears in

Sources and credits

This page is written in our own words. BNETDocs is credited for its research; none of its text is copied. See Credits.

Last edited September 16, 2026 by John Leighow.
Edit on GitHub | Page history