[This post was originally published as part of my developer blog back in late 2006. Back then I was reverse engineering network protocols for educational purposes. I found a flaw in the World of Warcraft encryption scheme that allowed me to tap into the network stream. The results presented here explains how to exploit this weakness as well as how to prevent it. Enjoy.]
When logging onto WoW the client and server computes an identical private key as part of the SRP6 authentication. This key is 40 bytes in length and is used as a session token as well as keystream. In an attempt to locate this key in client memory, I was unsuccessful. But recently I've figured out a way to subvert the encryption.
I've seen a lot of people making packet captures of serve/client traffic and trying to analyze the raw data. But as you might already know, the header of each message is encrypted. This encryption however, is flawed. While subverting the stream is simple in theory, it's a bit tricky to implement in practice.
The problem is that the underlying network layer (TCP) does not provide a reliable way to determine the actual length of application layer data. And since TCP itself is quite a hassle to handle, the process of keeping track of sequence numbers is frustrating. On top of this, the guesses used to crack the encryption becomes even more of a problem when the server bursts data (multiple packets per segment). The game will of course handle this correctly but the tap will not be in-sync.
The idea is based upon a more complex approach where the tap examines every piece of pushed TCP data and for each guess parts of the keystream. As soon as a continuous keystream is found we cycle the entire keystream to synchronize the cipher (in theory, the keystream is too short). This step does not take time, does not involve intense computations and it's a very neat way to being able to tap into the network stream (this works for any computer with a promiscuous network interface in the same collision domain).
Each packet uses a header which stores the actual length of packet. Since the client piggy backs each packet with the PSH flag we can use the TCP/IP headers to calculate the actual length value. This is how we guess the key stream. What's even worse is that the client sends 6 byte encrypted headers while the server uses 4 bytes. This will effectively allow us to cycle the keystream in no more than 20 packets. The problem is that we can guess parts of the plaintext. A quick and dirty solution here is to just pad every other packet or so with 1-3 bytes.
However, if you think about what you gain this system (despite being completely broken) still has some benefits. Even if you have complete control over the TCP stream, you can not just inject data it's more difficult than that. Either the client (will most likely crash) or server will de-sync and terminate the compromised connection but it's not impossible to act as a man-in-the-middle.
While Blizzard clearly states that the creation of third-party applications that enable players to gain an unfair advantage is strictly forbidden. This will not in any way make it possible to gain such an advantage. It will however allow you to read all in-game languages. The benefit of this is that an external application can log your play or more precisely see what you see and even further record your actions and later replay those actions.
While working on this I had an idea that could enable replay capabilities. I never finished reverse engineering the protocol but I knew enough about the game internals to impersonate a server. This effectively allowed me to pretend that the client was playing the game, while in fact you where watching a replay of some previously logged session. You can't interact with this session but you can re-experience any event as if you where playing the game, allowing you to freely move around and examine every angle of the situation.
