Take the 2-minute tour ×
Arqade is a question and answer site for passionate videogamers on all platforms. It's 100% free, no registration required.

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.

~Scott

share|improve this question
3  
I'm going to wager that this is beyond our scope. –  Raven Dreamer Nov 14 '10 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 '10 at 20:47

3 Answers 3

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. :(

share|improve this answer
    
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 '10 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 '10 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... –  Tom Wijsman Nov 14 '10 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 '10 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 '10 at 1:37

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.

share|improve this answer
    
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 '10 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? –  Raven Dreamer Nov 15 '10 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 '10 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). –  dbemerlin Nov 16 '10 at 9:41

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.

share|improve this answer
    
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 '10 at 2:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.