Caaaaarrrrlll's avatar

Caaaaarrrrlll Staff

Member for 18 years, 8 months, 5 days User #63

I'm the lead developer and site owner. Please mention BNETDocs when choosing to DM me.

Documents 10

Packets 45

Show all 45 packets

News posts 70

Show all 70 news posts

Servers 15

Show all 15 servers

Comments 98

On a packet ·

I've clarified that this is only used for Diablo II, other products send SID_STOPADV (if last remaining player) and SID_ENTERCHAT after leaving a game.

On a packet ·

I've fixed the flipped result field.

On a packet ·

Updated to include link to known keys.

On a packet ·

Updated

Show 93 older comments
On a packet ·

Updated format and remarks for clarification and readability.

On a document ·

Currently this document details version 2 of this protocol. I would like to have an improvement in the next iteration of this protocol, so that general flags and supported games/products that are currently part of the server's description, become its own UINT32 field instead.

Each bit in the field could represent one of the products/games that PvPGN (or other custom servers) support. It would also alleviate the need for an "ALL" flag, since that would be re-invented to be just flipping all bits to 1.

Below is a mock of what I'd interpret the UINT32 bitmask to look like, were it to be implemented how I vision it.

  • 0x00000001 Diablo (DRTL)
  • 0x00000002 Diablo Shareware (DSHR)
  • 0x00000004 Diablo II (D2DV)
  • 0x00000008 Diablo II LoD (D2XP)
  • 0x00000010 Starcraft (STAR)
  • 0x00000020 Starcraft Broodwar (SEXP)
  • 0x00000040 Starcraft Japan (JSTR)
  • 0x00000080 Starcraft Shareware (SSHR)
  • 0x00000100 Warcraft II (W2BN)
  • 0x00000200 Warcraft III Demo (W3DM)
  • 0x00000400 Warcraft III RoC (WAR3)
  • 0x00000800 Warcraft III TFT (W3XP)
  • 0x00001000 Chat Gateway (CHAT)
  • 0x00002000 Full Ladder
  • 0x00004000 Open Realm (D2DV/D2XP)
  • 0x00008000 Closed Realm (D2DV/D2XP)
  • 0x0000FFFF All (everything's supported)

Also note that this current set of bits fits nicely into a UINT16, but a 16-bit unsigned integer would not allow for future flags to be added in the same version of this packet, therefore a 32-bit unsigned integer may prove beneficial in the next iteration.

On a news post ·

The original patch notes were spread over three forum posts. I've combined them here.

On a document ·

Updated WAR3/W3XP to version 1.30.0.9900 (0x1E).

On a packet ·

From cen:

@BNETDocs Staff message by h3rmit, forwarding

W3GS_REQJOIN has proved to be inaccurately documented in 1.29
https://bnetdocs.org/packet/446/w3gs-reqjoin
it is 1 byte more in 1.29
and I found what it is: wrong documentation
the (UINT32) Unknown they describe is not fixed-length
A client sends this to the host to enter the game lobby.
so, (UINT32) Unknown is  2 bytes in 1.29 if he is to be believed, maybe that will give a hint to what this unknown is
On a document ·

Updated WAR3/W3XP to version 1.29.0.9055 (0x1D).

On a document ·

Chat gateway protocol was disabled in 2005.

On a document ·

Info looks good. I'll add the code to the reference. Thanks galaxyhaxz!

On a packet ·

It is possible to use %f# instead of usernames where # is the number from your friends list. This works with /w, /f, and basically any place you'd use a username. See the bottom of this page (archived copy) for more info.

On a packet ·

Updated profile\description to include its maximum length.

On a document ·

Added WoW: Wrath of the Lich King Beta key from @Kaylin

On a packet ·

Updated document formatting to Markdown syntax.

On a document ·

Version bytes have been updated for WAR3/W3XP to 0x1C and STAR/SEXP to 0xD6.

On a packet ·

I feel like the real purpose for this message is to:

  1. Ensure both WAR3 and W3XP keys show as in-use on Battle.net.
  2. Allow Battle.net to treat this client as WAR3 rather than W3XP as it was originally to trigger both keys being in-use.

In short, it feels like Blizzard wants the Frozen Throne key to show as in-use even when playing Reign of Chaos.

On a packet ·

Yes, I requested a Blizzard developer to fix the buffer overflow last month and they did.

Ribose, do you have a packet dump you can share to confirm that there's still an extra null byte? I'm seeing the proper syntax: FF 07 09 00 02 00 00 00 00

Perhaps the documentation here could be clarified such that the STRING is always present irrespective of the result code.

On a document ·

I've modernized this document using Markdown syntax.

On a news post ·

Illy's are now enabled on USEast.

On a packet ·

Hi Kaylin, I've imported your email as a comment.

Thanks!

On a news post ·

Updated the mirror links to the new paths.

On a document ·

I have added the sample code as attachments to this document.

On a document ·

I have added the sample code as attachments to this document.

On a document ·

Changes to documents, news posts, packets, and servers are now being tracked, as part of the new BNETDocs Phoenix website.

This includes timestamps and content of before and after. :)

I will see about adding that information to the page template so it's easily viewable.

On a packet ·

Received this while creating BAADF00D@Asia:

0000 ff 3d 0b 00 00 00 00 00 00 00 20 .=........

ff 3d 0b 00 - Packet header
00 00 00 00 - Result success
00 - No name suggestion; string is empty
00 20 - What is this? Extra data similar to one of the other OLS packets (raw memory)?

On a document ·

useast.battle.net and ustest.battle.net now share the same IPs. The USTest/Stratholme realm no longer exists and both domains point to the USEast/Azeroth realm. The realm as of the time of this comment is connected to the other three realms via /users and other commands.

On a packet ·

(This is an old comment which was later clarified, the following may no longer be valid.)

JSTR clients on the IX86 platform receive an empty CheckRevision Formula from official Battle.net, with MPQ set to ver-IX86-0.mpq.

Packet Dump from Wireshark:

00000000  01 ff 50 3a 00 00 00 00  00 36 38 58 49 52 54 53 ..P:.... .68XIRTS
00000010  4a d3 00 00 00 00 00 00  00 c0 a8 00 17 2c 01 00 J....... .....,..
00000020  00 09 04 00 00 09 04 00  00 55 53 41 00 55 6e 69 ........ .USA.Uni
00000030  74 65 64 20 53 74 61 74  65 73 00                ted Stat es.
00000000  ff 25 08 00 de 37 ef 58                          .%...7.X 
00000008  ff 50 28 00 00 00 00 00  a1 8b c6 b7 ee 15 08 00 .P(..... ........
00000018  00 8b 51 03 70 5f c7 01  76 65 72 2d 49 58 38 36 ..Q.p_.. ver-IX86
00000028  2d 30 2e 6d 70 71 00 00                          -0.mpq..
On a document ·

Added.

On a document ·

Isn't there a 12th code?

On a document ·

Why would the protocol version be 0x100 (256)? They probably are using big endian instead of little endian, and the version is probably 0x01 (1).

On a document ·

I have my precious code on my hard drive in REALbasic project files. If pastebin goes down, I can just re-upload it. I never delete good code.

On a document ·

I have the pastebin links I post set to never expire, and they're tied to my pastebin account.

I can, at my own will, edit or delete them, without having to make a new pastebin link.

Plus pastebin provides a neat syntax highlighting for 100s of languages :)

On a packet ·

Do you have proof that any Blizzard client still uses this packet, or in fact that Battle.net still sends this?

On a document ·

Added a couple functions for encoding/decoding 13-digit keys in REALbasic. May be helpful, or maybe not...

On a packet ·

Renamed Friend Type to Status and Friend Status to Location.

Also made sure Status and Location were correct, as previously thought to be incorrect by idiat.

On a packet ·

FooLOps 1.9.9 does not handle this packet. When you attempt to make someone a Chieftain, look at the last byte for success/fail and compare it to the Clan Message Codes under Related.

On a packet ·

Added all of these codes to the list.

On a document ·

Updated WAR3/W3XP verbytes to 0x1A.

On a document ·

Updated document as per Heinermann's documenting.

On a packet ·

Added 0x07 and described each reason code.

On a document ·

Yeah I found it out a while back ago when I was making my RBNETD software and was implementing the ol' Telnet protocol but couldn't find a way for SID_MESSAGEBOX through Telnet; this led me to find the format Blizzard was using for the packet ID's in Telnet.

Not sure if someone else actually knew about this or not, but I didn't find it anywhere so I felt compelled to document it.

On a document ·

Added.

On a packet ·

Added the note.

On a document ·

Updated.

On a packet ·

Updated according to Herinermann's documentation and Frost's documentation.

Thank you for your contributions.

On a packet ·

Updated according to Frost's documentation as well as the information here.

Thank you for your contributions.

On a document ·

@ZergMasterl: Fixed.

I also cleaned up the actual document a bit so that there are less blank lines everywhere.

<strong>EDIT:</strong> I cannot see why 0x04 would be up there, I've tried using it on more than one server and it just gets me disconnected (just like any other protocol byte does that is not listed above). However, 0x06 does do something, but I cannot figure out what at this point.

I have concluded this about 0x06:

CONNECT
Client -> 0x06
Server -> DWORD (Server Token?)
Client -> DWORD (Client Token?)
Server -> 20-bytes (BSHA-1 hash?)

Then I get disconnected for doing anything further. If anyone wants to add to what I have, you're more than welcome to. I also do not receive anything periodically from protocol 0x06, and nor do I ever get IP banned (ever), or disconnected for sitting idle.

On a document ·

I updated Hdx's Java-code donation so that it is hosted here at BnetDocs instead of pastebin.

It'd be nice if it could be displayed as neatly as the CPP version by DevCode.

On a document ·

/time also works.

Remember that you have to be on the demo.war3.battle.net server.

On a document ·

How is the reversing of B.net 2.0 going anyway? I haven't heard anything since the Beta.

On a document ·

Yeah exodus is just an alias, that is why I questioned having it up there, or if I did have it up there, would it be with the rest of the servers or on its own "redirect panel" which bnls.dementedminds.net used for a little while. I removed the panel because as Kyro told me in an IM that the server was dead and removed from his network.

But yes, I think exodus should remain there until it dies off. It just fits for now.

On a document ·

Hah. eu.logon.battle.net is down right now. Excellent work =P

EDIT: And it is back online now...

On a document ·

Okay, I'll edit the file soon. =)

EDIT: Try that on for a size. It's completely dynamic too, all we have to do is specify a "version" for each server and the website will do the rest of the work. It uses a SQL 'GROUP BY' statement, so servers are grouped based on their new version column. Also, I couldn't decide if I should leave exodus as a server, or give it its own "redirecter status" panel, so I just left it as is. In the actual database, it is supposedly an alias/redirecter though.

On a document ·

Interesting. Well I added each server to the servers on the right panel, and each one gets checked every 5 minutes by my checker I wrote. Exodus is an alias to USWest, but it doesn't show it here for some reason.

On a document ·

NICE! I was looking for the B.net 2.0 servers a while back and could not find ANYTHING about them, not even on the Blizzard forums or the Galaxy Editor's hotfix for map submissions.

On a document ·

Nice reference. I give props to the VB.NET examples. Although I must add, where is the StarCraft II Wings of Liberty Demo Product Key? I only see the Beta and what looks like Retail versions.

On a document ·

Hmmm... Diablo I can have a SID_UDPPINGRESPONSE (0x14) too... or at least, I think? I get a UDP plug when using it, and when I send 0x14, I don't.

On a document ·

Interesting enough, I sent DTST in a SID_AUTH_INFO and got disconnected, but not IP banned... I could instantly reconnect after it disconnected me. It did not give me any error codes or anything, it just simply disconnected me for sending DTST as the product, nothing else followed.

On a side note, you can send DRTL and DSHR in SID_AUTH_INFO and you will receive SID_AUTH_INFO from Battle.net. The packet you receive will tell you to use BSHA-1 and you will receive something like lockdown-IX86-1.mpq as your CheckRevision file. I have been told that when you use DRTL, DSHR, SSHR, or any game that does not use CD-Keys, you send SID_AUTH_CHECK without any CD-Keys appended to the packet (everything EXCEPT the CD-Key part of the packet), and Battle.net will treat that as proper communication and will not disconnect you, surprisingly enough. I will be testing this soon with my own bot later, and I will hopefully add (incorrect?) documentation for it here on BnetDocs later.

On a packet ·

If anyone's curious as to why this happens, it is most likely because the programmer who was responsible for programming the packet forgot to initialize the buffer correctly.

So if they do not use the buffer (i.e. set the buffer to X value), then you'll receive whatever is in that buffer (at that spot in memory); however, had they initialized it properly, you would of received normal data (a null-terminator and nothing after it).

On a side-note, I believe PvPGN does this properly, someone correct me if I'm wrong. In other words, if you connect to an unofficial server, there is a good chance that the programmer who made that server (the most popular server software being PvPGN) initialized their buffer correctly and therefore you will not receive the extra data.

To further add to Hdx's comment: it would be nearly impossible for you to gain anything by reading the extra data; any data you may receive from it is always random (since it's from memory already being used). And is it also impossible to construct anything useful from it because of the data being random. So while it may look interesting or you may recognize some data that appears, there's no point to actually use the extra data you receive.

On a packet ·

In most cases you can safely ignore the Account name and just use the Unique name, but you may find it useful later, such as when editing your own profile and comparing the names to see if it is your profile or someone else's. Battle.net will allow you to change your profile, even if you're editing it from Kyro#2 (for example), but it will not show the profile data if you have the #2 (or anything other than Account name). So, again, account name is useful for some things, but usually it can be ignored.

On a document ·

Diablo 3 will not be seen on Classic Battle.net. In other words, the product id for Diablo 3 and StarCraft II will not be seen in any icons.bni, or in any classic game. They will only be seen in newer games that are compatible with Battle.net v2.

If it really is Diablo 3, Blizzard has something to surprise the community with and hasn't announced it yet.

On a document ·

Updated D2DV/D2XP verbyte to 0x0D.

@Heinermann: That product is indeed there. Further testing would have to be done to see what product it really is. I would take an educated guess that DTST stands for Diablo Test (Client).

On a document ·

Why would the unknown be padding and not part of the header length making it a DWORD? It makes no sense for it to be padding if this is a header.

On a packet ·

Where's your packet logs for these Event ID's?

On a document ·

That looks about right.

On a packet ·

I registered my Starcraft on the Battle.net website and the server doesn't send me 0x101 when I try to use my key. Do you have any proof?

On a packet ·

Just to further comment on this packet, I just used Starcraft Broodwar and saw that only 5 of the System keys actually return data when I use my name.

System\Account Created
System\Last Logoff
System\Last Logon
System\Time Logged
System\Username

If anyone knows of any other System keys that return something, please comment.

On a packet ·

@idiat: Added the note.
@Sixen: Added the keys.

On a packet ·

For the n00bs: The Client session key is the Client token, and the Server session key is the Server token. Use your brain now, c'mon.

On a packet ·

Actually, no it's <strong>not</strong> separated by 0x0D 0x00.

It is separated by null-terminators (0x00). You should keep reading until you come across an empty string, or a double 0x00. Of course, you can always keep reading until you reach the end of the packet length, then removing the last channel (if empty), which works also.

On a packet ·

If you send any flags except those above, you will not get any chat events back for it (meaning you did not join the channel).

If you send first join or forced join with the channel being the one you are in currently, Battle.net will make you join the channel you were in last. If you were not in a channel last, you will join The Void.

On a document ·

@Myself: Fixed that, copied most of it from the older one. The STAR/SEXP/WAR3/W3XP are taken from actual logs I have on my local computer.

@Vector: Added links to all of the packets, I agree - it helps.

On a packet ·

You would think Blizzard would actually have the Key Value be VOID, not STRING. Shame I cannot test that to see if it really is a VOID, because Battle.net does not use this anymore.

Allowing access to the Windows registry without checking what is requested first is always a security risk, even if the data being requested is not changed. Does anyone know what Battle.net used to use this for? What values (paths and keys) it told the client to send the value of?

On a document ·

The statstring format for Starcraft needs to be updated... I made my bot send the SID_STARTADVEX3 following these specifications and it had the blank info come up.

Now, that is not saying I do not have a working statstring, because I do. I may find time later on to update this with my working statstring, and ansichart's findings.

On a packet ·

Updated, to a comment that's 2 years old lol.

On a packet ·

For those who do not use the old BNLS, and instead use JBLS/VBLS or something equalivant, you will probably want to know that there are more ID's than just those.

0x09: Diablo Retail
0x0A: Diablo Shareware
0x0B: Starcraft Shareware

When I do not have a product that matches any of those, I just use 0x00, but you probably will not get a matching VerByte if you do.

On a packet ·

The product ID can use W2BN / WarCraft II BNE. I saw MirageBot by Chriso using it when I network-logged it, and it works just fine as of June 8th, 2009. All I am saying is, W2BN does not have to use the older version (CLIENTID packets), and that it can use this newer version (SID_AUTH_INFO, SID_AUTH_CHECK, SID_LOGONRESPONSE2, SID_ENTERCHAT).

In an interesting topic, I wonder (have not tested) if it is possible to supply CHAT to the product ID, instead of an actual binary client like STAR or WAR3. If you could do this, then the ol' Chat-icon that was seen back before 2005 may still be able to be seen around the Battle.net.

On a document ·

I have fixed the issue. :)

On a packet ·

@LordVader: Unique name is the name that everyone see's on Battle.net. Account name is the account you used to login. There is no difference if no one is on your account with you, but if someone is then this would be different than the account name (a #2 and so on would be appended).

On a packet ·

On Starcraft Broodwar, I theorize that this is sent by the server if you never send any data back to Battle.net when Battle.net expects you to. How I theorize this? I debugged Starcraft, and made it 'Pause'. I resumed it and Battle.net had sent SID_PING multiple times. It never sent SID_PING ever again until I paused for about 10-20 seconds then resumed.

If you do not send any data back to Battle.net after a certain period of time, but Battle.net knows you WERE sending data, Battle.net will send this packet to you.

On a packet ·

Ripple Chat Bot is awesome for this...
Open RCB, connect, enter a channel or something...
Press Ctrl+P to open the Packet Builder.

  • Packet ID: 22
  • String: The client ID your using (I used NB2W, while using Diablo II)
  • DWORD: Anything you want... (I used 79 which is 4F)
  • NTString: A game that's currently online (find one with /games).
  • NTString: The password, leave blank if no password.
    Press Send and then type "/whoami", or look at the channel you were in and notice your not in it.

I have messed with this packet enough to know that, the first DWORD must be a valid game ID (doesn't have to be your current client) and the second DWORD can be anything you wish (0-255).

I assume these:

  • The first DWORD is used to tell other clients that you are or are not playing the same game id as they are.
  • The second DWORD is used to tell other clients that you are or are not playing the same game version as they are.
On a document ·

Telnet/Chat:

  • New lines are either 0x0A or 0x0D
  • When you send a message with multiple lines, it sends it like a queue without a wait, so don't flood offline by doing this
  • For a full list of packets, contact me
* Connect.
C>S: 0x03 (Telnet)
C>S: 0x04 (Login)
C>S: New line
S>C: "Enter your account name and password."
S>C: New line
S>C: "Username: "
C>S: "Jailout2000"
C>S: New line
S>C: "Password: "
C>S: "Password"
C>S: New line
S>C: "Connection from [127.0.0.1]"
S>C: New line

From here on, each packet will be on a new line, and will be regular ascii strings, not surrounded by quotes and not ending with a null-terminator

S>C: 2010 NAME Jailout2000
S>C: 1007 CHANNEL "Public Chat 1"
- Server will send 1001 USER to you for each user in the channel -
S>C: 1001 USER Jailout2000 0010 [CHAT]
- Server will send 1002 JOIN to everyone in the channel except you -
C>S: /join Public Chat 100
S>C: 1007 CHANNEL "Public Chat 100"
S>C: 1001 USER Jailout2000 0010 [CHAT]
S>C: 1005 TALK Jailout2000 0010 "It's just me in this channel."

I know Telnet was deprecated and can no longer be used, but what the heck, why not add it? You never know when someone will want to implement it... :P

On a packet ·

It would be cool to make Ripple Chat Bot enter a game... but the Packet Builder it has restricts that in a way that's not cool.

On a document ·

If the map name has a 0x0D or a 0x0A, then others will not be able to join.
They will receive a "Unable to join game." message from Battle.net and the information screen will be blank.
(Tested on Starcraft Broodwar)

Im going to play safe and assume that this is because Starcraft cannot parse the invalid statstring.