Packet 0x77 Information

[UserLoser.]

BnetD/PVPGN coding isn't always correct and isn't a great source for information on Battle.net

[Kp]

in bnetd packet.c/packet.h
packet_append_ntstring()
and
packet_append_string(),

bnetd is almost legendary for their bad coding and misunderstanding of protocol.  Learning anything from them is almost always a mistake.

[Soar]

Unfortunately I'm one of the coders in pvpgn team.
Actually we don't think we know somewhat less about bnet protocols than you do.

At least we know a lot of special values in some packets that vL bnetdocs doesn't give out.

Also we now don't think the FF is the only start signal of bnet protocol, F7 is also a start signal which exists in War3 ladder/tournament packets. So packets IDs are seen as short in our project (0x??FF and 0x??F7)

[UserLoser.]

At least we know a lot of special values in some packets that vL bnetdocs doesn't give out.

I'm pretty sure they know everything you guys have, and more... There's more than what you see with your access on BnetDocs

[Skywing]

Unfortunately I'm one of the coders in pvpgn team.
Actually we don't think we know somewhat less about bnet protocols than you do.

At least we know a lot of special values in some packets that vL bnetdocs doesn't give out.

Also we now don't think the FF is the only start signal of bnet protocol, F7 is also a start signal which exists in War3 ladder/tournament packets. So packets IDs are seen as short in our project (0x??FF and 0x??F7)

At least for battle.snp games, the magic FF is definitely treated seperately from the message id.  The game does something like this:

Code Select Expand

for(*p = buf; p != buf+bufused && *p != 0xff; p++) ;
if(p == buf+bufused) abort;
/* handle msg and adjust buf/bufused based on length in message header */

..when receiving messages from the server.  Additionally, note that the FF is hardcoded inside of SendServerMessage and not specified by the caller.

Are you sure you're not thinking of the War3 in-game protocol for magic being F7?

[Soar]

Yep, I know they have the hash algorithm of war3 password.
That's the only thing we don't know.

Btw, I didn't mean the lack of packet IDs in bnetdocs, but the values in some packts, I'm sure that we know more than vL does. i.e, create account S->C result value, it can be about 8 or 9 return values(just like too many punctuation narrowed, username have banned words and such such), but vL only know part of them.

I know vL only give out the packets that used for bot dev,

[Skywing]

Yep, I know they have the hash algorithm of war3 password.
That's the only thing we don't know.

Btw, I didn't mean the lack of packet IDs in bnetdocs, but the values in some packts, I'm sure that we know more than vL does. i.e, create account S->C result value, it can be about 8 or 9 return values(just like too many punctuation narrowed, username have banned words and such such), but vL only know part of them.

I know vL only give out the packets that used for bot dev,

That depends on which create account message you are using.
AFAIK, there are 2 used statuses for SID_CREATEACCOUNT, 6 used statuses for SID_CREATEACCOUNT2 (which for a very short period of time included a suggested, unused account name until Blizzard removed this for performance reasons; I think my client was the only program that ever took advantage of this [Diablo II didn't, and at the time was the only Blizzard program that used this message]), and 8 used statuses for SID_AUTH_ACCOUNTCREATE.

Update on magic values for B.net headers:
It looks like the War3 b.net client will disconnect if it receives a message with magic other than 0xFF:

Code Select Expand

.text:6F37DAD7 loc_6F37DAD7:                           ; CODE XREF: sub_6F37DA10+33j
.text:6F37DAD7                 mov     edi, [ebp+arg_8]
.text:6F37DADA                 cmp     edi, 4
.text:6F37DADD                 jb      short incomplete_header
.text:6F37DADF                 mov     ebx, [ecx]
.text:6F37DAE1                 cmp     bl, 0FFh
.text:6F37DAE4                 mov     edx, ecx
.text:6F37DAE6                 mov     [ebp+var_20], ebx
.text:6F37DAE9                 jnz     short bad_message_abort_connection ; bad magic
.text:6F37DAEB                 mov     ax, word ptr [ebp+var_20+2]
.text:6F37DAEF                 cmp     ax, 4
.text:6F37DAF3                 jb      short bad_message_abort_connection ; length < sizeof(header)
.text:6F37DAF5                 cmp     ax, 1000h
.text:6F37DAF9                 jnb     short bad_message_abort_connection ; length > MAX_MESSAGE_SIZE


I see nothing handling magic 0xF7 (for BNCS messages).  I know that magic 0xF7 is used for the in-game protocol, however.

[Soar]

mostly right, but you missed that there're 3 createaccount packets, the latest 1 is for War3/W3xp only, which has the different result handling value than that of SID_CREATEACCOUNT2

btw, 0x??F7 is not used in bot dev, that's only a game preparing packet. In bot dev, FF could be think as the only magic handling

[UserLoser.]

mostly right, but you missed that there're 3 createaccount packets, the latest 1 is for War3/W3xp only, which has the different result handling value than that of SID_CREATEACCOUNT2

He didn't miss the 3rd one

and 8 used statuses for SID_AUTH_ACCOUNTCREATE.

That's one problem - BnetD/PVPGN doesn't use the real names of the packets

[Arta]

My main reason for starting work on TestBNCS was the total inadequacy of BnetD/Pvpgn. I'll just leave it at that, for now.

[Soar]

That's one problem - BnetD/PVPGN doesn't use the real names of the packets

hehe, this sounds strange, no one made a standard that the packet name is SID_xxxx or CLIENT_xxx/SERVER_xxx
we only know the packet id, packet name is defined by ourselves to descript its usage only.

[Soar]

That depends on which create account message you are using.
AFAIK, there are 2 used statuses for SID_CREATEACCOUNT, 6 used statuses for SID_CREATEACCOUNT2 (which for a very short period of time included a suggested, unused account name until Blizzard removed this for performance reasons; I think my client was the only program that ever took advantage of this [Diablo II didn't, and at the time was the only Blizzard program that used this message]), and 8 used statuses for SID_AUTH_ACCOUNTCREATE.

I checked pvpgn bnet protocol file just now, there are 9 used statuses for SID_CREATEACCOUNT2 (SERVER_CREATEACCTREPLY2 in pvpgn)
it's only sent from D2 1.03~1.10.

[Arta]

hehe, this sounds strange, no one made a standard that the packet name is SID_xxxx or CLIENT_xxx/SERVER_xxx

err.. yeah they did. The SID_* constants are the names Blizzard use for their packets. They were kind enough to leave them in Battle.snp in previous versions of Starcraft. The most recent ones aren't known (Friends & Clan packets), since the official names have now been removed from all the clients, so far as we know.

[UserLoser.]

I checked pvpgn bnet protocol file just now, there are 9 used statuses for SID_CREATEACCOUNT2 (SERVER_CREATEACCTREPLY2 in pvpgn)
it's only sent from D2 1.03~1.10.

And what are these 9?

[Skywing]

That depends on which create account message you are using.
AFAIK, there are 2 used statuses for SID_CREATEACCOUNT, 6 used statuses for SID_CREATEACCOUNT2 (which for a very short period of time included a suggested, unused account name until Blizzard removed this for performance reasons; I think my client was the only program that ever took advantage of this [Diablo II didn't, and at the time was the only Blizzard program that used this message]), and 8 used statuses for SID_AUTH_ACCOUNTCREATE.

I checked pvpgn bnet protocol file just now, there are 9 used statuses for SID_CREATEACCOUNT2 (SERVER_CREATEACCTREPLY2 in pvpgn)
it's only sent from D2 1.03~1.10.

Note that I said used statuses.  The other statuses never occur (when using Battle.net).  For instance, 7 name contains adjacent punctuation is entirely superseded by 2 name contains reserved characters.  To the best of my knowledge, these unused statuses have never appeared "in the wild" on Battle.net.