I'm writing a small application to track some additional statistics not provided within Starcraft 2 (e.g. current daily point increase/decrease, distribution of matches such as those won in the first 5 minutes, etc...). The problem is that there is some information that isn't available on the battle.net webpage. Ideally, I'd parse all of the information directly from this website, but things like length the game ran and opponents aren't provided on the web version.

So, I've been looking into capturing packets on a client machine to see if there is a way I can extract this data as a user is playing sc2. I'm not entirely sure this is going to work, because as I've seen thus far, the packets are either encrypted, or simply not readable.

I just wanted to see if others had thoughts on how I might go about this. Also, the software is going to be GPL licensed, so if you're interested in helping out, let me know.


  • 3
    I'm going to wager that this is beyond our scope. Nov 14, 2010 at 20:01
  • 2
    While I don't think this question is completely inappropriate for this site, I do think you may have more success with the question on gamedev.stackexchange.com
    – Mag Roader
    Nov 14, 2010 at 20:47

3 Answers 3


I also agree this is a poor approach, but since you piqued my curiosity, I went and installed wireshark.

Here is an average SC2 packet:

User Datagram Protocal, Src Port: 50542, Dst Port: bnetgame (1119)
Length: 32
Data (24 bytes)
Data: 76ed0100077ce965cd7e4018cc8040001e92508e0fa0cd00

I remember that the original Starcraft had the option of using the IPX protocol as an alternative to TCP, so I guess I shouldn't be surprised that they rolled their own protocal for Starcraft 2. What's more the average packet size in my sample was 60bytes, which with overhead means you're getting 24 bytes of data. Without a good insight in to how they do sequencing, any sort of parallel data being transmitted on that connection is going to be hard to reassemble.

At this point they don't even need encryption, their chopping scheme for transmitting smaller packets will act as obfuscation.

Since efficient network transfer of data is a bit of a hobby of mine, I decided to dig deeper.

Storm UDP Protocol
This protocol is defined and processed by functions within Storm.dll and is used for numerous games - namely, Diablo 1, Warcraft II: BNE, Starcraft, and Starcraft: Brood War.
(WORD)      Checksum
(WORD)      Header Length
(WORD)      Seq1
(WORD)      Seq2
(BYTE)      CLS
(BYTE)      Command
(BYTE)      PlayerID
(BYTE)      Resend

I take back my original assessment, you can definitely identify the sequence pretty easily. What's more It looks like you can break apart the messages fairly easily. The concern then becomes extracting information from the 4-8 Bytes of data in the messages.

So let's look at that data.

== 0x36 - Stim Pack ==
  // No parameters.

== 0x35 - Zerg Bldg Morph ==
    WORD wUnitType;

Fascinating. Apparently SC2 is transmitting the same codes you find in a replay over the BattleNet. So breaking apart a replay is the same as using a packet capture. Your only real decision should then become: Do you need the data in real time? If you don't then using replays will be easier than disassembling the data from tshark.

  • Hm, definitely interesting. So, in the example that you gave, can you tell what the command actually was? I've looked over these documents, and used wireshark at a time when I knew what I was doing (e.g. looking at a specific match). It captured packets, but I can't seem to tell from the packets captured what the actual command was in the packet.
    – jwir3
    Nov 15, 2010 at 2:03

A much better approach would be to look at the replays of the games (which are automatically saved in you account folder). Those replays contain a lot of useful information like the game length and opponents and the format they are using is fairly well known. There are quite a few projects for libraries that parse these replay files, for example this one.

You could also use a premade tool like sc2gears which provides a lot of statistical analysis based on your replay files.

  • Yeah, my only reason for going through the packet-sniffing approach was because I wanted an approach where I might be able to accomplish the same result without a user having to save and store their recorded games into an application. So, in other words, as long as the app was running, it would grab their statistics for them. (I have some fairly non-computer saavy friends, lol).
    – jwir3
    Nov 15, 2010 at 0:55
  • 1
    Well, 10 or so replays are automatically saved by default -- can you work something with that? Set it up to detect the game's end and then sniff the newly minted replay? Nov 15, 2010 at 1:16
  • @Raven: Yes, I probably could. That's a good suggestion. I just thought there might be an easier way. :) Really, I'm not looking for all of the in-game data that SC2Gears is looking at - I'm really only interested in the final outcome of games. I just would like a little more information than what is given on the battle.net website. Basically, all I really want are two things that aren't listed on the web: 1) Character information about matches (who did I play against and with )? 2) The length of the match.
    – jwir3
    Nov 15, 2010 at 2:02
  • sc2gears can store replays in a specified folder automatically, so it already has all the information you want. I really do not see the point in creating a seperate tool that does less than that by more aggressive means (for example, personally i don't want any third-person program to watch my sc2 traffic).
    – user1978
    Nov 16, 2010 at 9:41

My 2 cents:

As in any multiplayer game (and especially one as immensely popular as Starcraft 2) cheating is an issue that the game developers actively combat. As such, I'm ready to bet that the packets are AT LEAST encrypted, and there are a lot of other safeguards in place to prevent people from doing just what you're trying to.

It's probably possible to arrange with Blizzard to get your hands on all the necessary documentation, SDKs and whatnotelse, but it'll most likely take a big stack of NDA's (so forget about GPL) and a bigger stack of money.

Sorry. :(

  • I kind of figured this would be a difficult problem. Although, what I'm trying to do isn't cheating. I just want a more thorough way of tracking stats.
    – jwir3
    Nov 14, 2010 at 21:48
  • Plus, it seems like if every packet were encrypted, this would really bog down performance - at least for things like statistics that come from the server and are, in essence, read-only. I mean, you can't change the outcome of a game simply by looking at the packet received that tells you what the outcome was.
    – jwir3
    Nov 14, 2010 at 21:50
  • 1
    @jwir3: If the right encryption is chosen, it wouldn't bog down performance that much. The decision between a system with a security leak or a system with a small overhead is made fast... Nov 14, 2010 at 22:07
  • 1
    @jwir3 - Indeed, symmetric encryption (like Rijndael aka AES) is quite performant. How else could you download files through HTTPS with practically the same speed as unencrypted HTTP? And although you mean well, the data coming from the server can still be used in a malicious way - for example you could show the locations of enemy buildings and troops even though they are within your fog of war. OK, so that's a guess about the data coming through, maybe you can't do exactly that, but you get the idea. Even read-only data can be used for cheating.
    – Vilx-
    Nov 14, 2010 at 22:29
  • @Vilx: actually, yeah you could. Since each computer has to maintain a complete simulation of everything going on in the game (including what and where the enemy units are), you could see that).
    – RCIX
    Nov 22, 2010 at 1:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .