Match information in Starcraft 2 via packet capture?

Solution 1:

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.
}}}
CLASS 2

----------------------------------------------------
== 0x35 - Zerg Bldg Morph ==
{{{
    WORD wUnitType;
}}}
CLASS 2

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.

Solution 2:

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.