The interesting thing, of course, is that all the hacks I am going to talk about are actually not hacking the virtual world at all; they instead attack the client, which is your window into the world, and also your waldo, your means of exercising control over what happens in that world. And that’s because…
The client is in the hands of the enemy.
You’ve probably heard that before — I wasn’t the first one to say it, but it constantly gets misattributed to me. That particular phrasing may have originated with Kelton Flinn, but I am sure many of us came up with it independently.
The first thing to realize is that encryption of the data stream isn’t going to stop anyone serious.
Here’s the diagrammatic way to look at it.
- You generate data.
- You put it in a packet.
- You encrypt the packet.
- You send it over the wire.
- It gets to a user’s computer.
- The client reads the encrypted packet.
- The client decrypts the packet.
- The client does something.
Really, anything after “it gets to a user’s computer” is in the hands of the enemy. So that means that you are encrypting the packets, handing the user a decrypter called a client, and thinking that encryption helps.
The hackers can choose to do is read the incoming packets out of client memory after decryption, instead of sniffing the stream directly. But really, all this does is raise the bar a bit on the hacking skills required.
To top it off, encryption can be slow, if you’re talking a real-time sort of situation. You may not want to spend the time in encrypting if you need a fast response.
Packet stream sniffing: getting more info than you should
This one was a problem early on in EverQuest and is still an issue in many FPSes. In short, you should not rely on the client to filter information. Assume that anything that comes down the wire is visible to them. We speak of “culling” the data that is sent down, basically reducing the set. Even on the client, we do culling, so that we don’t draw everything in the dataset the client knows about. In an FPS, you typically cannot do a lot of server-side culling — everyone on the map is “visible” to the client, because everyone is moving so fast that you can’t really do any line of sight culling on the server.
In EQ, the way this manifested was every mob in the zone was sent to the client. This meant a hack could make a minimap that showed every mob. You could see repops at a distance. But wait, it gets worse. You could also see everything they carried. So you could cherry-pick the good loot in advance.
Packet filtering: dropping stuff you shouldn’t
Sometimes the server tells you things you just don’t want to hear. One such thing might be “no, you can’t go there.” This is the classic wall hack. Usually, you move, and do a local client-side collision check. You also send off a request to the server for your movement, so that the server can verify whether you can go there (after all, you might have — horrors — hacked your client to not do collision checks). The server will send back a “no, you are still over here” message, resulting in being rubberbanded back to where you were.
Unless you simply ignore that message, and merrily keep going. This will allow you to explore all of the static dataset that your client has loaded. You won’t see any newly streamed objects in the right place, of course, because as far as the server is concerned, you didn’t move.
Simply dropping packets can be pretty powerful if the engineers were sloppy and relied on the client to correct itself after being told it was naughty. A common way you can use this to greater advantage relies on the fact that we often do let the client be semi-autonomous about movement. You can move around on the client with far more granularity and with much more rapid changes in direction than you can on the server. Instead of tracking your every move, we instead subsample it, basically. We rely on simple metrics like “you can’t move that far that fast” to verify whether or not you are in fact cheating in your movement.
But if you collided with something, were told to bounce back, but then moved to a position on the other side of the wall, the next movement might fall within acceptable parameters, and then you may have moved through the wall.
Packet altering: changing what you hear
Alternatively, you could actually alter the packet before it gets interpreted. This basically lets you get the client to dance to your tune. Maybe you want a nice big waypoint on top of your quest target. Maybe you want to change what zone the client thinks it is loading you into in order to let you tour somewhere you normally cannot get to.
Representation altering: changing what you see
Messing with the data stream isn’t the only thing within your power. Lots of folks in FPSes did things to change the visibility level of what was around them. Replace all the walls with transparent textures, and you will have a much better idea of where everyone is. Replace small meshes with big ones, or camo-colored textures with bright pink ones, and everything gets easier to spot.
Of course, why give yourself the work? Just have the client automatically send back responses instantly when it gets a particular packet or message. This form of automated triggers is, of course, a key element in building bots. In an FPS, autoaim is an example. The accuracy of something happening with a trigger is far far higher than what it is when a mere human is at the wheel.
A lot of times, the servers aren’t hardened properly against receiving more commands in a given span of time than they expect. Letting the client handle cooldown timers would be an example of a mistake like this; if you can control the upstream, you can bypass the cooldowns.
The Warden and other tricks
Of course, there’s countermeasures. The countermeasure used by Blizzard (and by Steam, for that matter) is to run a separate process that monitors whether the main app is being messed with. This is a common practice in Korea as well, and there’s FPS servers that require you to run Punkbuster, etc. From the WoW TOS:
# WHEN RUNNING, THE PROGRAM MAY MONITOR YOUR COMPUTER’S RANDOM ACCESS MEMORY (RAM) AND/OR CPU PROCESSES FOR UNAUTHORIZED THIRD PARTY PROGRAMS RUNNING CONCURRENTLY WITH WORLD OF WARCRAFT. AN “UNAUTHORIZED THIRD PARTY PROGRAM” AS USED HEREIN SHALL BE DEFINED AS ANY THIRD PARTY SOFTWARE, INCLUDING WITHOUT LIMITATION ANY “ADDON” OR “MOD,” THAT IN BLIZZARD’S SOLE DETERMINATION: (i) ENABLES OR FACILITATES CHEATING OF ANY TYPE; (ii) ALLOWS USERS TO MODIFY OR HACK THE WORLD OF WARCRAFT INTERFACE, ENVIRONMENT, AND/OR EXPERIENCE IN ANY WAY NOT EXPRESSLY AUTHORIZED BY BLIZZARD; OR (iii) INTERCEPTS, “MINES,” OR OTHERWISE COLLECTS INFORMATION FROM OR THROUGH THE PROGRAM. IN THE EVENT THAT THE PROGRAM DETECTS AN UNAUTHORIZED THIRD PARTY PROGRAM, BLIZZARD MAY (a) COMMUNICATE INFORMATION BACK TO BLIZZARD, INCLUDING WITHOUT LIMITATION YOUR ACCOUNT NAME, DETAILS ABOUT THE UNAUTHORIZED THIRD PARTY PROGRAM DETECTED, AND THE TIME AND DATE THE UNAUTHORIZED THIRD PARTY PROGRAM WAS DETECTED; AND/OR (b) EXERCISE ANY OR ALL OF ITS RIGHTS UNDER SECTION 6 OF THIS AGREEMENT, WITH OR WITHOUT PRIOR NOTICE TO THE USER.
How does it do this? Well, actually, by using many of the same techniques as described above. Basically, it kind of hacks you. It checks to see if stuff is running in WoW’s memory space. It checks the title bars of any window you have open and compares the text of that window title (hashed) against a blacklist of cheating programs titlebars (also hashed). And it actually checks some of the code of every program you have running and checks to see if that code is on its blacklist too.
Needless to say, the Warden is also in the hands of the enemy; although I wouldn’t have the slightest clue on how to do it, you could theoretically either hack the Warden itself, or hack the apps that the Warden is checking, so that they display false or different information. At that point, it’s an arms race.
There’s already programs to watch the Warden watching you, for example. And Blizzard’s response was to make a bunch of different versions of Warden, so it’s harder to find and watch; and also to — surprise, encrypt the stuff sent back. Of course, you could go back to square one, packet sniff, and filter out the Warden reports… la di da. Or make the cheat app polymorphic itself. Or…
It’s all very Orwellian — but players seem to value a game environment with less cheats more than they value their privacy, though admittedly, freaking out over an app reading window titlebars and then not actually telling anyone about it unless it finds a match may seem a bit paranoid. Then again, what if someone hacked a popular WoW fansite or guide site and stuck a banned string in the titlebar? Could happen…
In the end, you just cannot trust the client. Everything Warden protects against fundamentally needs to be guarded against on the server. In the Web world, you just have to assume that the browser could be any damn thing at all — after all, I could write a simple web browser in about five minutes. And in the future, we may well have to design our games with this sort of capability in mind.
Take the example of the small herb to harvest. The hacks described would do things like auto-detect that the herb is around, auto-collect it, pick it out of a crowded area. The “game” lies in it being hard to find or see. In the security world, this is called “security through obscurity,” and it’s generally assumed to be a waste of time. (This also raises the question of why we are building games out of something like herb-finding.) The secure way is for the client to not even know. Have real herbs and fake herbs use the exact same client-side representation in every way. Only the server knows the difference.
We don’t generally do this because, well, we want to have static data and dynamic data we stream. We want to be able to precache most of the world, and only stream down the stuff that can change, like herbs you can pick up. It’s cheaper in bandwidth, by a lot; it offers better performance; you get much faster load times.
In other words, we create these vulnerabilities for ourselves because, well, we want to trust the client.
In the end, the most hack-free virtual world is likely to be the one with completely open source clients, completely public and open protocols, and no attempts to cheat by having the client do any heavy lifting. In fact, WoW itself has taken very big strides towards this with their open UI system, which enables officially sanctioned plug-ins which do quite a lot of the things that were formerly done by hacks. The reason this will likely be safer is simply because when the terminal is dumb, you are forced to put the smarts on the server — and the server is a lot easier to make secure.
The challenges, however, are not small if you want to really go whole hog and make everything driven by the server. Everything would need to be streamed. Everything sent to the server would need to be verified. And game designers would have to assume they could not rely at all on anything in the visuals as a gameplay mechanic, nor on anything related to speed of cognitive processes (e.g., time spent “figuring something out” would not be a good mechanic, since many things could be offloaded to the client, providing instant reaction times). It would all make for a far more asynchronous world.
But that design constraint might also push towards designing cleverer gameplay, rather than gameplay that can be completely undone by knowing where stuff is, picking important stuff out from the crap, and going clicky-clicky on something fast enough.
A pipe-dream? Probably. We loves us our herb-hunting, our big graphics, our lagless client-side movement, and we seem quite willing to put up with being spied on in exchange for knowing that only bad-ass hackers are cheating, instead of damn near everyone. đ