How to hack an MMO
Given the recent hack to the blog, and also given the recent news of the decompiled Eve Online client, it seemed like a good time to go over some of the ways in which a virtual world gets hacked.
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.
Triggering
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.
Spamming
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. 😉
49 Responses to “How to hack an MMO”
Sorry, the comment form is closed at this time.
News items Have you ever wanted to walk through walls in MMO? How about telepathically sense the locations of all the good drops in a zone, or make invisible things very, very visible? Ablog postby game designer Raph Koster (of Ultima Online and now Metaplace fame) will tell you how! Admittedly, Koster doesn’t really go into much detail. Also, he’s trying to help developers avoid hacking problems, not giving inside secret tips to hackers. It’s
del.icio.us/emory Apr 18Raph’s Website � How to hack an MMOThere�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
to the library and experienced the Dewey Decimal System. He looked up all of his sources online and did a lot of cut-and-paste for his papers. For some reason, this was acceptable to his teachers…. I think the first thing I’d be doing during graHow to hack an MMOGiven the recent hack to the blog, and also given the recent news of the decompiled Eve Online client, it seemed like a good time to go over some of the ways in which a virtual world gets hacked. The interesting thing, of course, is that all the hacks
Still is a problem, they still send down tons of data, but you could never see everything they were carrying, only their wielded items (and just the graphic it displayed) and sometimes if they were carrying a light source.
Yup, all good and so hard to get people to understand these facts. Players are always, “But its on a computer what are you lazy? just make cheating impossible!”
Personally I’ve pretty much come down to the idea that an audit type system is the only thing that makes sense.
Which is more of a social fix. Don’t try and make cheating impossible, just make it detectable. This is easier and cheaper.
Don’t even try and detect it in real time. Just take replays and audit them for cheats at a later date should people complain or due to obvious triggers. Again easier and cheaper.
Make the response to cheats more of a social slap on the wrist. Don’t take it to seriously, just slap them down take away points, prizes, humiliate them etc. It never makes any sense to even take away their account (unless you plan to sell them a new one).
Apart from anything else trying to build a world where you can’t do anything wrong is a bit dull.
I’ve been toying with the idea of removing the need for much of a central server. Turning it more into a central audit system that solidifies when necessary the otherwise shared hallucination. Most people are not cheats after all and as long as you have plans to roll back and undo actions I’m confident you can get away with peer to peer data exchanges. Much of the auditing can even be done client side, with clients flagging other clients as suspicious.
The total client side cpu power will always dwarf the server side.
It just takes some clever game design.
For me, after playing the game as intended for awhile, the meta-game of hacking and automating it, is far more interesting than the original gameplay. Programmers, by definition, are keen on automating boring, repetitous and dumb tasks. This unfortunately describes 75% of most online game gameplay. The one who endures the boredom longer and spends the most time in the game gets the biggest rewards.
So how do you prevent cheating? Reward actual skill over forbearance, make the core gameplay interesting enough so players will feel they are missing out if they are cheating. No one sends a bot to see a movie for him…
Also, make the interface of the game as streamlined as possible. Lots of the hacks/cheats are actually workarounds for shortcomings in the interface.
Then again, one of my clients is http://www.zynamics.com so I’m kinda biased 😉
Anyways, good post – kind regards,
Sören
A small note: FPS games have performed a lot of culling, starting with Quake. ID used a concept called a vismap, or a visibility map. Basically, the map designer calculated in advance which parts of the map are visible from each location. However, the main reason for calculating vismaps was not to deter cheaters, but to speed up rendering. There’s no reason whatsoever to render that wall five corridors and seven rooms away from you, because there’s no way you could see it. All the server needed to do was to put the vismap to a new use and check whether players were in areas that could not be seen by the other players.
As Raph says, people move very fast in FPS games. What may be invisible in one frame may become visible in the next, and in the high-stakes Quake 3 Arena world, frames matter. Also, you have to consider the worst-case scenario. Keeping things fast and responsive when you can’t see anyone doesn’t help when all the players in the game are in the same room, blasting away at each other.
Static items can be filtered properly, however. For example, all the weapon and ammo pick-ups. The server doesn’t need to tell you what they are up to until your client is in danger of seeing them.
Interesting thing about the resource-collection example that Raph uses: contrast LotRO and WoW craft collection with SWG craft collection.
I am almost positive that I once saw a hack client that showed the contents of the mobs’ drops, and that later it switched to not spawning the drops until the mob was killed. It may have been during the beta, though. (We were at Origin then, and someone on the UO2 team was analyzing the packet stream? I don’t quite recall).
Designers shouldn’t be.
Right, good point. I said:
In the case of what you’re describing — vismaps and other forms of block culling are not all that helpful for deterring cheating, since “all the players that matter” is who you want to operate the hack against anyway. 🙂
I know you know this, but for the sake of others reading the thread:
The way to think about is this — you have a static dataset (the map) and a dynamic, quickly moving dataset (objects like players, pickups, bullets).
The map is pre-cached, which means that the client knows ALL of it — it can make automaps if it wants, it can tell you the best paths, it can hack the art. But it can also optimize what to render.
The dynamic stuff has the potential to move very fast, so the server tells you where all of it is at any time. After all, it might round a corner, or you might round a corner. This doesn’t mean the client is rendering it, but it does mean it knows about it. That is why I put “visible” in quotes.
The renderer then does render culling, which is decide which items to draw. A hacker can change how stuff renders, and given the fact that the client knows where everyone is, it can do things like draw outlines of them on the hud, letting you “see” through walls. Or autoaim at them, lining up the shot before they come out from behind the wall.
Something like a vismap doesn’t do complex dynamic culling; instead, it says “this guy is basically in a different building” or “this guy is basically at the other end of a long twisty hallway” — there’s no way for the other guy to come into visibility in any reasonable period of time. So the map gets chopped up into network update areas. “When in room A, tell me about room B dynamic stuff, but not room C stuff.” This is basically the same as EQ not telling you about stuff in the next zone, etc.
The only total solution is to do line of sight network culling, but that is both CPU-intensive, and also would require a round-trip to the server, which makes it impossibly slow. Most MMOs settle for radial network culling.
[…] Raph Koster gives you a brief tutorial on how to hack MMOs. […]
Raph>The dynamic stuff has the potential to move very fast, so the server tells you where all of it is at any time
It’s possible to send this information in an encrypted form, but only send the decryption key when the client is entitled to see it. It doesn’t have to be heavy duty encryption, just enough to make trying every key in a split second impractical.
I first saw this proposed on MUD-DEV, but haven’t seen it used in action. I suspect that even a single UDP exchange with the server may introduce too much lag. Using something similar for precached client-side material ought to be viable, though. The decryption algorithm may be in the hands of the enemy, but that doesn’t mean the decryption key has to be.
Richard
Very true — I had forgotten that came up on MUD-Dev, actually. But yes, a token exchange of hashes or keys in classic key exchange style could be done.
I don’t think that for real-time apps an on-the-fly key exchange is practical — the roundtrip time could be too much. But it’s worth exploring in the fashion you suggest.
A vismap can’t prevent you from tracking a player who’s just about to run into the room you’re in, but it can prevent the server from telling you that he picked up an important powerup from the previous room.
That decryption-keys-sent-on-demand sounds interesting. However, the preloaded encrypted packet needs to be padded to a predetermined size and it’s transmission time needs to be randomized. While you may not be able to decode the contents, the act of transmitting encrypted data can be telling in itself. If you always receive a packet of a certain size 2 seconds before a dragon appears, you’ll soon learn to hide whenever that happens.
These are serious problems now, but will they not eventually go away as bandwidth and server hardware get better?
Do you think that the demands of things we want to do are growing faster or slower than the abilities of the physical infrastructure?
These are serious problems now, but will they not eventually go away as bandwidth and server hardware get better?
They can, but most of these improvements are being put to use in driving bigger and better features, rather than locking down security. It’s a resource allocation thing, and security doesn’t make you any money. It just keeps you from losing too much.
Notice how every proposed solution so far has an implied argument of “This doesn’t take much effort.” And every vulnerability comes from, “This makes a better experience.”
The other option is to pre-load multiple data sets or assets and then simply point to the right one when needed.
In many cases you can stop tampering by using a keyed hash function (or MAC) instead of encryption. This has the benefit that the server can “cheat” and not check the MAC code all of the time (coincidentally, I’m coding one of these right now).
My personal maxim when writing business software for internal use over a LAN or Intranet: You can try to monkey-proof your software but a monkey is still a monkey.
We had a large application designed for internal use and since we controlled all aspects of that use, we could make arbitrary statements like “This site requires MS Internet Explorer version x.x or higher” or “Screen resolutions of xxxxx by xxxxx or higher are required to view this page”. It saved a lot of time in testing and customizing. Later, someone got the bright idea that certain outside clients and vendors should have access. “uh oh”
And that doesn’t even begin to get into the area of open public access where people are going to deliberately trying to break your software just for fun. I can’t imagine having to handle that kind of problem without having full time people on staff who are dedicated experts. What a nightmare.
Security in general does require a specific mindset. You have to keep asking yourself: “How this can be subverted?” and “What damage could I do with this?” Once you get into that mindset, all else follows.
With respect to sending encrypted data to the client speculatively, to be decrypted only when it becomes appropriate, it seems to me that it can be useful to cache potentially relevant data on the client. For example, the stealther problem in Dark Age of Camelot. There’s a whole pile of data that you need to send to the client to get it to adequately represent a figure in a graphical MMO like DAoC – race, custom appearance options, visible equipment – but you don’t want to “tip off” the client that there’s an invisible assassin nearby until you are sure the client has detected the stealther (Camelot uses a simple binary system for stealther detection, such that if you haven’t detected the sneak it’s supposedly completely undetectable). If you hold off on that bundle until the client has successfully made their “detection test” then it’s possible that there isn’t the bandwidth available to bring the client up to speed fast enough. In Camelot, with enough Stealth skill, you could bring the detection radius down to a very short distance indeed – crucial when trying to stick a knife in someone’s back. Pre-sending unencrypted data could give a compromised client some information you would not like to present to an unmodified client – the appearance, allegiance and perhaps the name and Realm Rank of the would-be assailant. Sending it early but encrypted sounds like an effective compromise technique. You can disguise it by filling otherwise unused bandwidth with nonsense that you never ask the client to decrypt. The missing data, position, speed and animation, should hopefully form a small enough packet it will not introduce any significant latency by itself.
Perhaps we could get an overview of how Metaplace fits into this topic?
In Metaplace, the packet stream is completely open, and the client is completely stupid. So you are forced to verify everything on the server and do everything on the server. In alpha, we have had a couple of hacks related to spamming and to triggers, and both were because of inadequately secured scripts on the worldbuilder’s part.
Raph was correct about EQ. Early on they *did* spawn loot with the mobs and ShowEQ (the major EQ hacking program back then) showed you that loot. Then Verant got smart and made mobs only spawn loot when killed.
Another wonderful aspect of the way they used to do it was that rogues could pickpocket loot off of mobs leaving them empty when actually killed!
The occasional quest mob would drop his head when you killed him — rogues could pickpocket those too. Pretty funny.
This went away pretty early, possibly even pre-Kunark but I can’t quite remember now.
And fwiw, I never ran the program but some good friends did.
Raph…
That’s twice now. 😛
Richard: It doesn’t have to be heavy duty encryption, just enough to make trying every key in a split second impractical.
There is no reason to not use heavy-duty encryption on the client side, but I suppose it could be heavy for the server for real time data. However, you might get away with just encrypting the most vital information. For instance if you set up compression streams then you might separate IDs into it’s own stream and only encrypt that stream. (Separating information into their own streams tends to give better compression ratios, so it makes sense to do it for two reasons..). If you have say 20 clients subscribing to the same area you get away with spending 5% of the alloted time per client on compression, which might make it an acceptable overhead….
*shrugs*
Eolirin,
Fine. 😛 I fixed it.
Ola,
Actually, it’s usually the client load of decryption that has been an issue, in the past anyway.
Cool topic. I’m curious, what are some of the ways the server know’s that my client, and not another, is sending the data? What prevents my neighbor from impersonating my client and telling the server I’m doing something I’m not?
Raph, I and the English language thank you. 🙂
Raph, you need to push a lot of data for that to be a problem. Here is a random page which suggests that cryptos takes less than 100 cycles per byte. A modern CPU can do billions of cycles per second…
You might be thinking of public key encryption? Authentication rather than pure symetric encryption? Like SSL? I still think the server is on the loosing end, but I could be wrong.
(Turns out SSL only uses public key for setup and symmetric ciphers for encryption?)
@Solok – the cryptographic system would have a unique key for each client (SSL does this as a default). Therefore, unless the client willingly shares its key with another, the server can tell them apart and it is cryptographically hard for a client to spoof another.
@Ola Fosheim Grøstad – people rarely use public key for regular encryption, they use it for establishing a key because it is so computationally intensive.
@Raph – It would seem surprising to have the computation problem for encryption on the client side. After all, they only have to encrypt one data stream while the server has to encrypt N times the data streams (one for each client with whatever computational overhead is associated with each).
$Richard – Actually with encryption, the hardest problem is to protect data for a second. Also, it is distressing as to how willing people are to work at attacking these systems.
#Michael – “Not Losing You Money” may be the difference between success and failure. There have been several online games that have been brought to their knees by security problems.. security (or lack thereof) is part of the game experience.
The last game architecture you describe already exists and it’s a quite successful MMO, especially if you consider it’s a no-monthly-fee MMO. This is Guild Wars, created by ArenaNet (with 3 guys from the battle.net platform originally used by Blizzard) and distributed by NCsoft. The client only has the static files (textures, maps, etc.) and they’re updated by streaming in the background (the whole thing with 3 campaigns and one extension is in one file and around 3.5Go so as not to cause problems with filesystems). All the dynamic stuff (movements, game mechanics, account & characters information) is on the server, sent when appropriate to the client. The only hack on the untrusted client is modification of the UI, and there’s only been one major hack on the server side (which allowed duping of items), with small hacks that give a very small in-game advantage.
BTW there’s an interesting book on the topic, but mainly focused on WoW: “Exploiting Online Games” by Hoglund and McGraw (http://www.exploitingonlinegames.com/). My personal theory is that these security attacks are only a “first level” of attacks and it’s getting more difficult for hackers to invent new ones. The next wave will be, like in real-life, more social engineering approaches, exploiting the game mechanics and the virtual economies.
[…] Cheating might be of less concern to social software than to games (although there are exceptions, take Digg for example). For those interested in more about this, Raph Koster recently posted an elaborate examination of hacking and cheating in MMOGs. […]
#Michael – “Not Losing You Money” may be the difference between success and failure. There have been several online games that have been brought to their knees by security problems.. security (or lack thereof) is part of the game experience.
I fully agree. That’s why people care about it. But it’s also why people don’t care too much about it.
Security is not a feature. It’s like a server. You spend money to get it, because you need it, but you get as little as you can get by with, because having extra doesn’t actually do anything. Servers are part of the game experience, too: without them, you have no game. But no one is going to buy fifty extra servers unless they’re actually going to be using them. A couple extra spares? Maybe. A little extra security? Sure. But a game is not a bank. Well… not yet.
I’m usually more directly impacted by system exploiting than hard hacking. Any kind of community wide comparative measures that can be exploited for gain raises the bar of the standard. Ladder PvP systems like the early WoW rank system. People start figuring out the mutually beneficial workarounds that beat the intended mutually exclusive system, a few weeks later there’s hundreds of people using the same trick to stay ‘caught up’. So there’s me, sliding backwards in ranks despite all my hard work because legitimate honor gains are far slower than that earned by exploiters.
This doesn’t have to involve PvP combat, plenty of PvE pursuits involve elements of comparison to your peers’ performance. The exploiting of rewards that enhance your character’s attributes or performance in some area becoming widespread again rasies the bar of standards. This could result in ‘cheaters’ being picked over you for content further down the line since they have more to offer a group in terms of stat mods or whatever system affects the performing of their role.
I don’t think there is a warden on the OS X version of WoW.
I checked.
Warden is not actually a separate process, if you’re going by the Windows definition of the word. It’s just a chunk of code that gets sent down. It’s much closer (in fact and abstraction) to a DLL that the game loads.
The basic premise is mostly correct: you just can’t trust the client. But I wouldn’t throw away encryption completely, since it still has value. You can’t trust it to be the magical weapon to solve every problem, but it’s still important. Just like locking your door won’t keep out a determined intruder… but it will keep out a casual intruder.
I disagree with the premise of an open-source client having any bearing on what people do with the software that the developer does not like. Finding something to exploit in the client is extremely hard work without the source. Any benefit derived from more eyes on the source will be handily wiped out by… more eyes on the source.
“Representation altering: changing what you see”. Even with my limited computer experience, this was something that was always relativley easy to “hack”. By turning off gibs in the original Team Fortress, the only corpses you would see were actually spies laying on the ground. Or people would use skins they thought were hard to see, but locally I would have that file name assigned to a fluorescent Bozo the Clown skin instead.
But the problem is, at some point you have to let the client adjust the way their monitor displays the image. We don’t all see colors the same way, monitors have different refresh rates, we prefer different brightnesses, etc. How do you keep people from seeing ninjas in the shadows when all they have to do is turn up the gamma?
[…] blog post by game designer Raph Koster (of Ultima Online and now Metaplace fame) will tell you how! […]
[…] client does something. Th� v? ?? C�c b?n c� th? tham kh?o th�ng tin chi ti?t : https://www.raphkoster.com/2008/04/17…o-hack-an-mmo/ […]
[…] framerates, and that it won’t trigger anti-cheating tools like Punkbuster or World of Warcraft’s Warden.The product is currently in its beta test phase. You can sign up for the beta or update […]
[…] some discussion earlier wondering why on earth I’d put all the user request parameters in the URL.https://www.raphkoster.com/2008/04/17/ho … ck-an-mmo/If you’re logged in to the game, you can basically visit any zone just by manipulating the URL. If […]
[…] How to hack an MMO April 17th, 2008 (Visited 5387 times) Tags: cheating, everquest, hacking, laws of online world design, vw design, vw tech, WoW […]
[…] spawn location…) into the client. as Raph Koster is fond of reminding ppl, the game client "is in the hands of the enemy": every time a dev offloads an operation onto the client, in order to save CPU cycles for AI […]
[…] Unless there are egregiously bad security problems with the DDO protocol, hacking packets on your end should only change the way things look on your end. See my previous post “How to hack an MMO.” […]
[…] I don’t claim to know if OnLive’s specific tech will work or not, but I would like to talk about the implications of this potential shift to server-based games. (Even if OnLive doesn’t make it work, clearly this technology will arrive at some point.) Of course, we already have server-based games – World of Warcraft runs on numerous servers spread around the world, with appropriate bits of game info set to thin clients running on local machines. However, a client is still a tricky piece of software, and as Raph Koster like to remind us, “The client is in the hands of the enemy.” […]
[…] this will continue to happen. It will get worse, every hour of every day, until changed/fixed. Those better than I have said it before and often… In the end, you just cannot trust the client. And if you don't know who Raph Koster is, … well, […]
[…] I don’t claim to know if OnLive’s specific tech will work or not, but I would like to talk about the implications of this potential shift to server-based games. (Even if OnLive doesn’t make it work, clearly this technology will arrive at some point.) Of course, we already have server-based games – World of Warcraft runs on numerous servers spread around the world, with appropriate bits of game info set to thin clients running on local machines. However, a client is still a tricky piece of software, and as Raph Koster like to remind us, “The client is in the hands of the enemy.” […]
[…] we should do some investigate on Warden . It's a unequivocally engaging dispute given a laws of online universe design […]