Exploit (online gaming)

I'll just open the topic and lay the concept here. I won't even give my own share on how many exploits I could possibly relate to infinity model now, instead I'll leave the discussion open giving just the concrete definition from Wikipedia, the free encyclopaedia.

In the realm of online games, an exploit is usually a software bug, hack or bot that contributes to the user's prosperity in a manner not intended by the developers.

What is or is not considered an exploit varies between games and developers. The EULA (End-User License Agreement) typically states what type of gameplay is not acceptable. Thus, some developers may consider AFK gameplay to be an exploit, while others may not.

Known types of exploits in FPS games

* Wall hack The changing of wall properties in first-person shooters. Most wallhacks are used to make a map's walls at least partially transparent, allowing players to see objects lying behind a wall
* Aimbot An aimbot, sometimes called "auto-aim", is software that assists the player in aiming at the target. This gives the user an advantage over unaided players.
* Cham hacks or chams for short which generally replace player models with brightly colored skins, often in neon red/yellow and blue/green colors.
* Bunny hopping or Strafe-jumping requires a very specific combination of mouse and keyboard input. The exact technique involved depends on the game itself; however, most games follow a certain pattern of user actions. Not all players consider this as a damaging exploit. Some FPS Games have maps made just for this trick.

Known types of exploits in real-time strategy games

* Maphack A cheat that enables the player to see more of the map than the game intends them to see. A common feature in multiplayer real-time strategy games is the inability for the player to see outside the visibility range of the individual units and buildings that the player controls.

Known types of exploits in MMORPG

* Speed Hacking/Teleporting/Subterrain Travel - If character position in an MMORPG is determined by the client side (usually not the case), it is possible for players to send out artificial positional data and be instantly transported to any part of the world or used to speed up traveling speed by increasing positional deltas.
* Holes - Some games may contain accidental holes in the map, allowing the player to get under the map. Holes are mostly harmless, although some use them in player vs. player situations to sneak around and get behind their opponent, or attack from below the floor.
* Botting - A player who runs a third party program to control their character. The bot will kill monsters, loot money, mine ore, collect herbs or gain levels automatically without the player having to be in front of the computer.
* Duping - Duplicating, or replicating items or money.
* Game Mechanics Exploits / Bug Exploits - There are also other exploits involving the physics of the game, sometimes in conjunction with items. This includes using wall-walking to get into unfinished areas or abilities to make one's character unattackable by mobs or other players and sometimes are able to attack back.
* Data Mining - Players will try to access files not yet in game and then host them on websites to expose content not yet released (usually new zones, items, and graphics).

Consequences of exploitation

Depending on the EULA and the severity of the exploit, developers may do anything from simply removing the exploited material from the game, to reprimanding the players, or banning their accounts. There are only occasional rare cases of an exploiter being threatened with legal action.


Miscellaneous

* Most companies involved in the development or maintenance of online games forbid their employees from sharing information about known exploits or bugs. Doing so is sometimes considered an exploit but is more often merely a vector by which other exploits are shared.

Delicate topic. I can only give my opinion as I'm not a computer expert as Loraine and Karl, mere a user and very lazy user to be honest. But I have seen my share of exploits all over.
The first line of defence against cheaters has to be technological, with developers looking for ways to break the game and building in appropriate defences from the start.
I remember a good line about this: "If the online component of the game is significant, you need someone thinking like a hacker up front"

Revan Neferis wrote:

Delicate topic. I can only give my opinion as I'm not a computer expert as Loraine and Karl, mere a user and very lazy user to be honest. But I have seen my share of exploits all over.
The first line of defence against cheaters has to be technological, with developers looking for ways to break the game and building in appropriate defences from the start.
I remember a good line about this: "If the online component of the game is significant, you need someone thinking like a hacker up front"

What is needed to be discussed on topics like this:

*An overview of security issues for games and why security is important.

* Discussion of the most serious and common game security problem, why it occurs, and how to fix.

* The notion of a Rich Transaction System

* Anti-Piracy & DRM

* Identity, Anonymity, and Game Commerce

* Cheating & Griefing

* Game Implementation Security

* Network Game Architectures

Revan Neferis wrote:

Delicate topic. I can only give my opinion as I'm not a computer expert as Loraine and Karl, mere a user and very lazy user to be honest. But I have seen my share of exploits all over.
The first line of defence against cheaters has to be technological, with developers looking for ways to break the game and building in appropriate defences from the start.
I remember a good line about this: "If the online component of the game is significant, you need someone thinking like a hacker up front"

The most interesting thing about online game security is not the code itself, but the very design of these systems. We as players also have to ask ourselves: How secure the game will be?
Ok, to speak with simple language, the virtual world that the players interact with is very large and has vast amounts of "state." The problem is to share this state with all of the active users and keep the virtual world coherent. The only logical solution is to "crack off" some of the state and share it with the game programs running on a gamer's PC. That PC ends up controlling local state, which is periodically sync'ed with the game servers.
There's the big problem with this design. A gamer's PC is well outside the trust boundary. Any computation that is being pushed out to the client system is subject to attack by a malicious gamer who wants to cheat using his or her own PC. Much of the code in the book involves poking around in game code on your own PC -- using disassemblers, parsers, etc. Attacks against PC-controlled time and state that blur trust boundaries are complex and very interesting from a software security perspective.

Of course game developers care deeply about security! Nothing makes a game developer angrier than people who cheat and most game developers set out to thwart that kind of thing when they design their games. The question is: how MUCH they care?

First two rules about online cheating:

Rule #1: If you build it, they will come -- to hack and cheat.

Rule #2: hacking attempts increase with the success of your game.

Just how seriously should you as a developer take the possibility of online cheating? If your game is multiplayer only, the success of your entire product is at stake.
As more games are released with online play as an integral component, drawing ever-larger audiences (and the corollary development of online communities and sites based around the game), it becomes ever more important to insure that each online game player experiences what they believe to be a fair and honest experience. I'm reminded of a quote from Greg Costikyan's excellent report, "The Future of Online Gaming"

"An online game's success or failure is largely determined by how the players are treated. In other words, the customer experience -- in this case, the player experience -- is the key driver of online success." Our short version is, "Cheating undermines success."

Need more reasons to take online cheating seriously?
I browse infinity forums and I don't see even one single focus on it.

The sad truth is that the Internet is full of people that love to ruin the online experiences of others. They get off on it. A great many cheaters use hacks, trainers, bots, and whatnot in order to win games. But while some openly try to wreak havoc, many really want to dominate and crush opponents, trying to make other players think they are gods at the game -- not the cheaters they are. The only thing that seems to bother them is getting caught. Beyond that, no ethical dilemmas seem to concern them. The anonymity and artificiality of the Internet seems to encourage a moral vacuum where otherwise nice people often behave in the worst possible way. A big factor in this is a lack of consequences. If a player is caught, so what? Are they fined or punished? No. Are they rejected by the people they played against? Usually, but it's so easy to establish another identity and return to play that discovery and banishment are no barrier to those with ill intent.

Another interesting aspect of online cheating is the rise of alliances or clans or guilds and how cheats get propagated. If a member of a clan hacks a game or obtains a not-readily-available program for cheating, it will often be given to other members of the clan with the understanding that it's for clan use only and to be kept secret. The purpose being, of course, to raise the standing and prestige of the clan. If the cheater is not a clan member, odds are he will keep the secret to himself for a while and not advertise his advantage. The logic here is simple: If anyone goes public with a cheat, a) he will lose his advantage, b) he will probably be identified by his opponents as a cheater, and c) the developer can then patch the game, invalidating the cheat. As a result of this secretive behavior we get to rule number three.

Rule #3: Cheaters actively try to keep developers from learning their cheats.

So how do they discover the hacks and create the programs to cheat at your game? Consider rule number four:

Rule #4: Your game, along with everything on the cheater's computer, is not secure. The files are not secure. Memory is not secure. Services and drivers are not secure.

That's right, you gave them a copy of your game when they purchased it. The hackers have access to the same tools that you had while making the game. They have the compilers, dissemblers, debuggers, and utilities that you have, and a few that you don't. And they are smart people - they are probably more familiar with the Assembly output of an optimized C++ file than you are. The most popular tool among the hackers I surveyed was NuMega's excellent debugger, SoftIce - definitely not a tool for the wimpy. On another day, you just might be trying to hire these people. Many of them possess a true hacker ethic, doing it just to prove it can be done, but more do it specifically to cheat. Either way we get the same result: a compromised game and an advantage to the cheater.

Hacking games is nothing new, it's been going on as long there have been computer games. For single-player games, it has never been an issue, since no matter what a player does with a game, he's only doing it to himself (and therefore must be happy about it). What's new is bringing the results of the hacking to other players, who never wanted or asked for it.

I've lost count of the number of developers I've encountered who thought that because something they designed was complicated and nobody else had the documentation, it was secure from prying eyes and hands. This is not true, as I learned the hard way.
This is a perfect time to introduce rule number five. Yes, I've borrowed it from cryptography, but it applies equally well here.

Rule #5: Obscurity is not security.

Sometimes we do things, such as leaving debug information in the game's executable, that make the hacker's job easier. In the end, we cannot prevent most cheating. But we can make it tough. We don't want effective cheating to be a matter of just patching six bytes in a file. Ideally we want hacking a game to be so much work that it approaches the level of having to completely rewrite the game -- something that goes outside the realm of any reasonableness on the hacker's part.

One of biggest things we often do that makes it easier for a hacker, and thus harder on us, is include Easter eggs and cheat codes in the single-player portion of our games. Considered to be practically a requirement, they expose extralegal capabilities of our game engines and make it much easier for the hackers to locate the data and code that controls that functionality.

In our world there are what we call cheating classifications:

Reflex augmentation
Authoritative clients
Information exposure
Compromised servers
Bugs and design loopholes

All must be looked into it.
Environmental weaknesses

Could you specify and detail those modes Loraine?

Parfum Exotiqué wrote:

First two rules about online cheating:

Rule #1: If you build it, they will come -- to hack and cheat.

Rule #2: hacking attempts increase with the success of your game.

You can make it fairly difficult to compromise, but the more successful the game is the more incentive people have to hack it. The problem with persistent worlds is once they are compromised it is very difficult to un-compromise them without a wipe or some other traumatic event. Very often the effects are allowed to persist which also increases the incentive to hack.

Revan Neferis wrote:

Could you specify and detail those modes Loraine?

Of course mistress.

The first type of cheat is reflex augmentation, which is when a computer program replaces human reaction to produce superior results. This type of cheating is really only applicable to games where reflexes and reaction times matter, and thus is most applicable to action games.
One way to inhibit this form of cheating is to encrypt the command packets so that the proxies can't decode them. But there are limits to the extent that encryption can be used on communications. Most FPS games can send and receive a couple of kilobytes of data or more per player per second, and have to allow for lost and out-of-order packets. The encryption therefore has to be fast enough not to impact frame rate, and a given packet's encryption can not be dependent on any other packet unless guaranteed delivery is used. And once the encryption is cracked, the game is vulnerable until the encryption is revised, which usually involves issuing a patch. Then the hacking starts over.
Another way to make life more difficult for the proxy creator is to make the command syntax dynamic.
Though reflex augmentation seems to be exclusive to FPS games, the vulnerability extends to any game where quick reflexes can make a difference and game communications can be sniffed.

The next major class of cheats is exploiting authoritative clients. This is when one player's modified copy of an online game tells all the other players that a definitive game event has occurred. Examples of the communications would be "player 1 hit player 2 with the death-look spell for 200 points of damage," "player 2 has 10,000 hit points," and so on. The other players' games accept these as fact without challenging them and update their copy of the game simulation accordingly.
In this case, a hacked client can be created in many ways: The executables can be patched to behave differently, the game data files can be modified to change the game properties on the hacked client, or the network communication packets can be compromised. In any case, the result is the same - the game sends modified commands to the other players who blindly accept them. Games are especially vulnerable to this type of exploit when they are based on a single-player game engine that has been extended to support online multiplay in the most direct (read: quickest to develop) manner.
Fortunately there are several steps that a game developer can take to eliminate most problems with authoritative clients. A first step is to install a mechanism in the game that verifies that each player is using the same program and data files. This means going out and computing a CRC or similar identifier for all the data in question, not just relying on a value stored in the file or the file size. A nice side benefit is that this method also detects out-of-date files during the development process.
For peer-to-peer games, cheating can be made difficult by changing from a game engine that issues commands to one that issues command requests. It's a subtle distinction but one that requires engineering changes throughout the game. It also requires that each player's machine run a full copy of the game simulation, operating in lockstep with the other players.
Preventing a dishonest command from being accepted on an honest player's machine is only half the task. The game also has to be able to determine whether someone is playing the same game and if not, it must do something about it. For instance, when a received command request is rejected for reasons that should have prevented it from being issued in the first place (remember, the issuer is supposed to have checked it for validity before passing it to the other players), all other players should assume that a cheater is in their midst, and take some sort of action.
Often though, due to design issues (such as posting command requests to a future turn), it is not possible to thoroughly ensure that all command requests passed to other players won't be rejected if a player is being honest. A good way to deal with this is to add synchronization checking to the game.

The next major class of cheats is what I've dubbed "information exposure." The principle is simple: On a compromised client, the player is given access or visibility to hidden information. The fundamental difference between this and authoritative clients is that information exposure does not alter communications with the other players. Any commands sent by the cheater are normal game commands - the difference is that the cheater acts upon superior information.

The first-person-shooter cheats of modified maps and models arguably fall under this classification, as they let cheating players see things that they normally wouldn't be able to (in the case of modified maps), or see them more easily (in the case of a modified player model that glows in the dark). Any game whose game play relies on some information being hidden from a player has a lot to lose to these types of cheats.
The real-time strategy (RTS) genre suffers severely from this. The most obvious being hacks that remove the "fog of war" and "unexplored map" areas from the display. With a fully visible map, the cheating player can watch what other players are planning and head them off at the pass, so to speak.
There are a couple of ways the hacker accomplishes this. The hacker may go after the variables that control the display characteristics of the map. With the help of a good debugger and single-player cheat codes to reveal the whole map, finding the locations in memory that control the map display is fairly simple. Then either the game .EXE file is modified to initialize those map control values differently, or a program is made that attaches to the game's memory space and modifies the variable values while the game is running. To combat this, the values of those variables should be regularly reported to other players in the form of a checksum or CRC code. Unfortunately, that only raises the stakes; the hackers then just attack the code that reads those control values (easy enough to find quickly), inverting or NOP'ing out the instructions that act upon them.

Additional techniques are needed to detect the hacked game view. There are a couple of ways to take advantage of the fact that the full game simulation is run on all clients. One way is to borrow a technique from the "authoritative client" section and check each command request for the side effects of a hacked map on one of the players. We specifically ask the game simulation, which is separate from the screen display, the question, "Can that player see the object he just clicked on?" In doing this we are assuming ahead of time that such hacks will be attempted, making sure we consider the side effects by which they might be detected. Once again, easing up on checks of the player's own machine is very useful. The next time the game performs a synchronization check, all the other players will agree that the cheating client is "out of synch" with the rest of the game and can deal with him accordingly.

I'll write more about the missing ones tomorrow mistress. But important:

There is no such thing as a harmless cheat or exploit. Cheaters are incredibly inventive at figuring out how to get the most out of any loophole or exploit.

Of course you must be asking me: Who Do You Trust Baby?

In client-server games, because so much is controlled by the server, the game is only as good as the trust placed in the server and those who run it.

Thank you dear, this is very good information altogether.