I am a computer enthusiast with a passion for the Internet. I am also the lead developer and site owner of the BNETDocs site. If you decide to contact me, please mention BNETDocs.
|Member for||14 years, 6 months, 19 days|
- Added some missing packets
- Asia Scheduled Maintenance
- BNET.cc - Battle.net Wiki
- BNETDocs General Status Update
- BNETDocs General Status Update for August
- BNETDocs Phoenix is now live!
- BNETDocs and Cloudflare's Memory Leak (#Cloudbleed)
- Battle.net Scheduled Maintenance
- Battle.net Scheduled Maintenance for StarCraft Patch 1.18
- Battle.net Server Upgrade - 14 August 2018
- Battle.net Server Upgrade/Maintenance
- Beta servers are online again?
- Blizzard Nukes Popular HTML5 Version of StarCraft Game
- Blizzard Sues Bot Maker For Copyright Infringement
- Blizzard Sues Overwatch “Cheat” Maker For Copyright Infringement
- Blizzard will be updating Starcraft too!
- Bnetdocs ownership and a security intrusion from earlier
- Classic Battle.net Illy account update
- Diablo II 1.14a Patch
- Diablo II 1.14b Maintenance Release
- Diablo II 1.14c Patch and Ladder Reset Announcement
- Diablo II 1.14d Patch
- Diablo III BETA Client Leaked
- Discord Server!
- Europe Scheduled Maintenance
- I've disabled Cloudflare and started using Let's Encrypt
- Just an update as to whats happening with BNLS
- Legacy Battle.net Upgrade
- Minor updates
- Missing pages added
- More updates on the security intrusion
- New WarCraft III Patch
- News has been turned on
- Packet status
- Password Resets
- Performance updates
- Regular news...
- Server Checker
- Server Moved
- Server Status Re-enabled
- Server Updater Script Down Indefinitely
- Site Redesign and New Features
- Sorry about that...
- StarCraft II Beta is now closed
- StarCraft: Brood War Patch 1.18 Patch Notes
- Starcraft II Beta Phase 2 Open
- Starcraft II Starter Edition
- Starcraft Patch 1.16.1
- Starcraft Patch 126.96.36.19999 Notes
- U.S. West down for maintenance
- USEast Scheduled Maintenance
- USEast/Azeroth Maintenance - Clan Data Rollback
- USEast/Azeroth Scheduled Downtime
- USWest Scheduled Maintenance
- Update from Jailout2000
- Updates Needed?
- WarCraft III Update
- WarCraft III Update
- WarCraft III Warden Update
- Warcraft 3 United Discord Affiliation
- Warcraft III 1.27a MSVCR120.dll Error
- Warcraft III 1.27a Patch
- Warcraft III Invitational
- Warcraft III Patch 188.8.131.5200
- Warcraft III Patch 184.108.40.20622
- Warcraft III Remastered Announcement Rumored
- We're still here...
- Why is BNETDocs in read-only mode?
- Work in progress
- emNet is back!
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.
@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
I feel like the real purpose for this message is to:
- Ensure both
W3XPkeys show as in-use on Battle.net.
- Allow Battle.net to treat this client as
W3XPas 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.
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.
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.
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.
(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
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..
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).
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.
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 :)
Do you have proof that any Blizzard client still uses this packet, or in fact that Battle.net still sends this?
Added a couple functions for encoding/decoding 13-digit keys in REALbasic. May be helpful, or maybe not...
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.
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.
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.
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:
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.
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.
How is the reversing of B.net 2.0 going anyway? I haven't heard anything since the Beta.
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.
Hah. eu.logon.battle.net is down right now. Excellent work =P
EDIT: And it is back online now...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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?
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.
If anyone knows of any other System keys that return something, please comment.
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.
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.
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.
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?
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.
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.
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.
@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 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.
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.
- New lines are either
- 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
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.
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.