Hi,

Has anyone figured out the TCP protocol Blizzard uses for Starcraft Broodwar's Battle.net?

I would like to be able to query for things like:
(1) the current list of games
(2) whether a given username is available
(3) most popular games

It looks like even after the upgrade, Blizzard is using TCP. It would have been a lot easier if they switched to HTTP :[

I have tried using Wireshark to examine the packets but I've really no idea what I'm doing. Any pointers to doing this? Or perhaps someone here has a TCP client that they could kindly share.

HTTP almost always runs over TCP.

What you mean, is that they're not using HTTP, they're using some other protocol, likely custom-built.

Heinermann is likely able to answer this in more detail, but part of the b.net communication also runs over UDP (which is why you have to open this 6112 UDP in your firewall). So if you wanna monitor it you gotta include UDP and TCP.

While the new UI is controlled by webcode (Corbo fiddled around with it, but I'm not sure if he said http or java script), the actual communication doesn't have to run over port 80, which is usually associated with http traffic, or even contain http.

Anyways, if you have no idea what you're doing, some basic networking info:
TCP and UDP are transport protocols. They define the way your computer talks to another computer to exchange information.
TCP always expects a reception confirmation when something got sent, while UDP doesn't care if the info got lost or not, it just sends. The header fields help you track of the order of packets and which "conversation" they are part of (sequence number). Often there is not just 1 long stream of sends and receives, but multiple parallel connections.
The information you exchange is the data field (Bits 160+ - or higher if data offset >5) within these TCP- or UDP-packets. This information could be anything really. A browser expects http data, an upload tool ftp data, and who knows how the b.net client structures their data. It's entirely dependent on how the application is programmed, which is why this is called the application layer.

Now that you know where to look and what to look for. Good luck.

The protocol now uses TLS to transmit data that is serialized with Protobuf. I'm not aware of any efforts towards documenting the protocol as of now.

Okay that makes what I said pretty useless because TLS encrypts the data before you can capture it with Wireshark. So while you can still inspect the TCP packets the data part will look like random noise.

https://redux.bnetdocs.org/ - some documentation
https://github.com/jjf28/PacketReader - my personal programmatic packet reader

I haven't really looked into sc packets in particular.

So how would I go about figuring out how the data is encrypted through what encryption algorithm? Is there a guide for reverse engineering a TCP/UDP protocol?

I can make new requests if I record them alongside Wireshark or whatever, and I can see how the packets change. Couldn't I gather enough of these to make informative guesses about the protocol and eventually figure it out?

Basically you'd need to employ a man-in-the-middle attack, and find the encryption key for the session, or get sc to drop TLS encryption (probably not possible). Either are advanced hacking techniques I can't help you with. These your options: https://en.wikipedia.org/wiki/Transport_Layer_Security#Attacks_against_TLS.2FSSL


That's not how encryption works. Just change 1 bit and the whole block of information is completely different.


I linked to a quite thorough wikipedia entry:

Even if a MitM could be deployed, a custom-build algorithm would render the attack useless. As with a lot of business class applications, there is always some limited visibility into the comms. For example, skype uses a proprietary algorithm, so even with an SSL/TLS inspection, these efforts are useless. But I do agree, for now MitM would likely be your best bet. If it is a custom alg, you'll need to reverse-engineer

Basically if you're asking questions such as "Is there a guide for reverse engineering a TCP/UDP protocol?" then you really don't have the skills to do what you're wanting to do.

Attaining those skills is going to require a lot of effort and time on your part. Like, hundreds of hours. I'm not saying this to scare you off, but just to give you a realistic understanding of what it is you're attempting to do, from the position of a novice. You're not going to be able to work this stuff out all by yourself in a weekend or two (unless you're a genius).

I can't tell you what's new in 1.18 - I've been out of the SC scene for like 6 years now.

There are a ton of vulnerabilities in the protocol. I'll post about them at some point. I've drafted an email to Blizzard detailing the methods I used for hacks like the Genocider, Control Other People's Units (yes, I had this one), etc.

As for actual documentation of the protocol, I did make that public at some point. Again, grain of salt as I don't know what's changed in 1.18 and quite frankly I won't look through it. I'll release it after Blizzard has ample time to patch up vulnerabilities (assuming they haven't already)

Did Blizzard intentionally make their API over TCP/UDP and not HTTP to prevent people from easily using it? For example I can go to any website or phone app, and usually you can quickly figure out their web API and start using it. Do they just use this for legacy reasons?


I'm not a genius but I'm not a novice either. I program and code for a living, and I also use machine learning daily. I guess I'm asking for a guide for people with a Computer Science background. Since Allah figured out their (old) protocol, it's clearly doable without having to get a PhD in encryption/mathematics or spending "hundreds of hours."

The protocol should be open source and documented and this is something I don't like Blizzard for. I believe basic query on game list, friends list, etc. should be available through a friendly HTTP API.


How did you figure out the protocol to do these things? Is your background in Computer Science? What kind of tools / research / programs did you use to figure these things out? Just looking for a good starting point.

Edit: Perhaps it would be easier to somehow be able to call out to the functions Blizzard uses when sending requests than trying to figure out an encryption scheme. If that's possible then I should be looking at how to access this from the Starcraft code.

You really shouldn't take this as an offense but at face value. What he says is absolutely correct and has nothing to do with your skill, background or intelligence. Cracking encryption is one of the greatest challenges there are in computer science. People spend their whole lives doing that and still can't get past every security measure on a whim (which is a good thing!).

The problem is we can't properly outline the complexity and relationships for you since you seem to have no experience whatsoever (a novice) in the networking field. Again, this isn't meant condescending in any way, you just do unrelated stuff. And to realize where or how to start (not to solve your problem!) you'll have to invest several days or weeks (depending on how much time you're willing to commit) just learning the basics of how communication between computers work. In my country this part alone (+ some general computer stuff and state of industry) is an apprenticeship that takes at least 2 years.
Before you can't properly put terms like "transport protocol", "application layer" and "MitM attack" in correlation there's no way we can get you started on your actual quest or explain to you why they "use tcp instead of http".



Basically the old protocol wasn't encrypted, so Allah could do exactly what you want to do with 1.18. now: Read the communication and try to figure out the protocol from there. Or he learned the protocol from the source code, which has been reverse engineered for the most part.

With 1.18 Blizzard introduced encryption to the communication so you can't capture and analyze it anymore. More importantly the encryption makes it infinitely harder to employ the attacks that Allah mentioned. Possibly in direct response to his research.

HTTP is not the only (or even preferable) application layer protocol. Try writing an HTTP parser in a low level language like C and you will understand.


Welcome to the club.


Your Edit is on the right path. Network-level analysis is not the only way to reverse engineer protocols (and is very infeasible with encryption as was mentioned). Delve into the assembly sea and gradually glean semantics (or use tools to do that for you, or even write your own tools, etc).

Thankfully Nude said everything I was going to say so I won't repeat it, although this point here is a little off the mark in respect to my comment. I was assuming that with a MITM attack, it'd still take you hundreds of hours to understand everything about the protocol starting from a novice position.

The key point being understanding 'everything' about the protocol and how it works. If you are only interested in a small set of functionality, such as how game lists are populated or whatever and don't care at all about how the networking is implemented for live games etc, then you wouldn't need as much time - simply because your scope of inquiry is reduced.

Not for that reason, but they're clearly okay with not sharing the spec.
More likely reason. Also, whatever they're doing with TCP is probably more efficient and has less overhead because they don't really care about a lot of the things in HTTP requests/reponses.
This, too. Especially considering HTTP is over TCP (which itself is over IP). The spec for HTTP just happens to be public, but it's still using TCP.

Sethmachine, maybe you're just not familiar with how website networking works. The terms SSL and TLS implies HTTPS (not HTTP), which is practically always over TCP. In this case, there's no UDP or HTTP.