# hack prevention in games

This topic is 4370 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
What type of game is this? Different security measures often need to be used depending on the type of game running, there is no silver bullet when it comes to security (i swear iv read that sentence about a million times before...)

For a large online game normally i would expect details such as health to be stored server side, so that it cannot be so easily altered. Allowing the client to take care of its own health points seems a bit strange to me - unless in an environment where cheating doesnt really matter (say a small multiplayer FPS with half a dozen players on a LAN)

Your solution could be do-able, but there would be a tradeoff between its effectiveness and the amount of extra processing required on the server side. I've spent a fair amount of time reading articles discussing problems like these - but im so tired im having problems trying to recall them lol =/

##### Share on other sites
Aliens vs. Predator 2 is the game. it is a very popular game still and at any given time there are probably 100+ players in different servers. so i expected the security to be very good. but i was playing yesterday and saw some really 'neat', for lack of a better word, hacks where people were able to fly and change characters instantly. infinite machine gun rockets was a new trick i've never seen before either.

that's why it sparked my interest because i am a programmer, not advanced enough to make multiplayer games, but i know the concepts of security at least.

##### Share on other sites
Punkbuster does a similar thing:
Quote:
 Real-time scanning of memory by PB Client on players' computers searching for known hacks/cheats
but without the server-side scans.

Your idea does sound good in theory, but a couple of things to think about:

The server software and the client software will not have the same data in the same memory locations

Assuming the above is solvable, you still have lag issues to contend with. Imagine this scenario - Server requests a client to perform a memory check, then notifies the same client of new . The client recieves the memory check request before the updates & so it replies with the old values. So now the values stored by the the two computers *potentially* don't match. If the client blindly sent the memory data to the server without a request a hack could be used to fake the values, but even if one wasn't being used the chances of the data being the same at any particular moment on both machines are slim.

It is also an increase in network traffic from the extra memory checks and also possibly because more information has to be stored on the server about each client - I can't imagine FPSes normally send the health, weapons & ammo info to the server as it's of little use to anyone but the client normally - the kind of data being sent would probably be things like 'player death', animation id etc. Not much use to a cheater.

I'm not saying these issues can't be solved, but I think only scanning the client for known hacks is a better option simply because you don't have to bother in the first place :)

##### Share on other sites
Quote:
 Original post by chuck22is there any way to prevent this? i was thinking about it and i thought of the possibility of a random memory address scanner. what it would do is compare a random memory address from the client to the value on the server's address and see if they are the same. if they are not, the player is booted. it wouldn't make these checks in real time. maybe once every 15 seconds it chooses a random address from each of the players in the server. maybe the program would randomly choose between a given list of addresses that contained values for: health, weapons, ammo, characters, and other popular variables.i was just wondering if this was possible or if it is a do-able solution?

I have a short answer for you. To make the comparion bewteen the health value on the server and the health value on the client machine, the server has to know the correct health value. It it knows it, why would it consider that the client value is better than its value? This is true for every variable you cited.

The key to limit cheating is to do store everything on the server and to never trust the client - it the client never tells you 'I've killed this guy', it tells you 'I fired in that direction'. The server looks i the player can fire in this direction (maybe ha has no ammo left), compute the shoot and tell the client wether he hit somethign or not.

Of course, it adds a lot of work to the server (collision detection, client values tracking and so on) but it makes cheating far more difficult.

Regards,

##### Share on other sites
Quote:
 Original post by Emmanuel DelogetThe key to limit cheating is to do store everything on the server and to never trust the client - it the client never tells you 'I've killed this guy', it tells you 'I fired in that direction'. The server looks i the player can fire in this direction (maybe ha has no ammo left), compute the shoot and tell the client wether he hit somethign or not.

To expand further on this point (Emmanuel said it better), you're effectively left with a thin client as a lot of extra processing work is transferred to the server. It's a perfectly valid design in some circumstances but in the case of anything real-time across a high-latency network (i.e. the net) it's preferable to reduce server load & do as much as possible on the client.

##### Share on other sites
I'll give you a hint to creating such a system: once this is something like what the code is:
Map currentmap = server.GetMap("themap");//...Profile currentprofile = server.MakeSureProfileIsInactiveAndGetProfile("superprofile", "thispassword");//...Direction dir = DirectionBasedOnMouse(mousex, mousey);if(FireClicked())   if(server.AskIfCanFire())      if(server.DidFireHit())          ShowThatYouHit();      else          ShowThatNoHit();

You are on the right track.

##### Share on other sites
If you still want to store and process the data client-sided, maybe to reduce lag, maybe because there is no server, then consider storing critical data in mutiple places, encrypted with different algorithms. If one of the places is changed you still got multiple others to restore it.
However this would only influence memory hacks, not the couple of other cheats possible.

##### Share on other sites
Quote:
 I can't imagine FPSes normally send the health, weapons & ammo info to the server as it's of little use to anyone but the client normally

I don't think this is true. Quake II certainly stores all this information on the server, and since other games (Unreal Tournament for sure) will let you see your team-mates health, other players' weapons and so on I'm sure the server stores all this stuff.

For a FPS, there are almost always few enough players that it makes sense just to store everything on the server, even discounting the ease of cheating when the client has data.

##### Share on other sites
The client should merely be a dumb terminal rendering polygons, everything important should be dealth with by the server.

##### Share on other sites
if you want to keep things on the client as far as calculations are concerned what you can do is detect at least changes in values that are outside the expected range.

For example if the health of a character suddenly jumped by more than can be accounted for by his stats and skills, that's an indication there's cheating involved.
If you have some form of health potions you'd also have to check whether those were used of course.

So you get a timeline of (at say 1 second intervals):
- read health from client
- compare value with previous value
- if (difference > MAX_DIFFERENCE) kill client for cheating
- else store value as previous value

Do that for every attribute you think it's worth checking.
And as said do all weapons/skill effect determination serverside based on the values you have stored for those effects on the server.
That should prevent users from building maxi-mega kill-o-zap guns with millions of hitpoints of damage over a wide area.

##### Share on other sites
Quote:
 Original post by jwentingif you want to keep things on the client as far as calculations are concerned what you can do is detect at least changes in values that are outside the expected range.- if (difference > MAX_DIFFERENCE) kill client for cheating

that's a good idea.

haha and then just kill them for cheating. i like it. as far as checking it every second, wouldn't that take up more memory than what is wanted? i think time intervals of 30 seconds to one minute are justifiable. at most, a cheater can cheat for less than a minute until he is caught and then booted.

##### Share on other sites
Quote:
Original post by Bob Janova
Quote:
 I can't imagine FPSes normally send the health, weapons & ammo info to the server as it's of little use to anyone but the client normally

I don't think this is true. Quake II certainly stores all this information on the server, and since other games (Unreal Tournament for sure) will let you see your team-mates health, other players' weapons and so on I'm sure the server stores all this stuff.

It makes more sense to me to have client-client communication handle things like health updates. As for weapons, I would have expect that info be be handled with 'animation to play' requests

##### Share on other sites
I would find it really scary if a game had any client-client communication at all.
I don't want other players to be able to find my ip, starting a DOS attack every time I fragged their sorry little ass ;)
I really hope that online games has all communications going via the server and I strongly support the ones proclaiming that the clients should just be stupid "media players" (with some limited input), just reflecting a view of the server state.
In practice this is much harder since the clients needs some sort of prediction wich often involves physics and collision detection and other simulations.

Just my 2c

##### Share on other sites
There are a number of possible and very useful cheats that aren't getting addressed here, that are entirely clientside.

In particular, cheats that provide the player more information than they should have. HUDs that show opponent locations are very useful and still very much a cheat. Client side visual mods that allow the player to see opponents through walls/obstructions. Client side mods that will fire the weapon automatically when an opponent is in close proximity to the targetting reticle. Advanced ones will even track opponent trajectory and properly lead the target for weapons that are not instant hit. These type of cheats are very useful with high damage one shot weapons like Quakes railgun or sniper rifles.

The way these cheats work is to run as a seperate process that hooks into the game process itself. The way to fight these kind of cheats is to have the client search for these processes and if it finds one, drop connection with the server. It's not exactly that easy, because you have to know what to look for. I don't believe there is a way to generally tell if something is hooked into your game process, so you have to look for a specific process, which of course means you have to have identified the cheat and it's source first.

Go to the DirectX forums and look at the Useful Threads Sticky. There are several pointers to instructions on just how to hook into the DirectX APIs, which is the first step to creating these kinds of cheats. You've gotta know how these cheats work before you can defeat them.

##### Share on other sites
There is a way to determine if someone is hooked into your process, but you have to open up all processes in the system to determine who is doing what. It's not efficient, but if you wanted to rule out hooks as a method of cheating then it is completely possible to update this list every minute or two.

##### Share on other sites
Quote:
Original post by chuck22
Quote:
 Original post by jwentingif you want to keep things on the client as far as calculations are concerned what you can do is detect at least changes in values that are outside the expected range.- if (difference > MAX_DIFFERENCE) kill client for cheating

that's a good idea.

haha and then just kill them for cheating. i like it. as far as checking it every second, wouldn't that take up more memory than what is wanted? i think time intervals of 30 seconds to one minute are justifiable. at most, a cheater can cheat for less than a minute until he is caught and then booted.

A lot can happen in that amount of time, probably more than you can detect using a simple system like this.
For example if someone gains 500 points of health in that time period, it could be because he cheated and upped his health, but it can also be he drank 5 100-point potions which he since replenished in his inventory from a stash he found somewhere in a cave.
You'd never know unless you checked the entire world to see if there were the requisite number of potions removed and that noone has them.

I used a second only as an example anyway. You'd effectively run the check when you have some CPU cycles left over. That could be every second or every 5 seconds depending on server load, but do keep in mind what can happen during the interval...

##### Share on other sites
Quote:
 Original post by jRaskellIn particular, cheats that provide the player more information than they should have. HUDs that show opponent locations are very useful and still very much a cheat. Client side visual mods that allow the player to see opponents through walls/obstructions. Client side mods that will fire the weapon automatically when an opponent is in close proximity to the targetting reticle. Advanced ones will even track opponent trajectory and properly lead the target for weapons that are not instant hit. These type of cheats are very useful with high damage one shot weapons like Quakes railgun or sniper rifles.

By having everything the client knows determined by the server that can be avoided.
If the client can't see something, he just never gets sent that information.
He for example gets information about monster locations only when those monsters are visible to him (in the same room, or maybe they can be heard through a wall or seen through a window/door).
From that moment on the client may do what he wants to. If he cheats and remembers where a monster was when bypassing it he may be in for a rough surprise if it's since moved when he returns...

##### Share on other sites
That's true, but if you're doing all the vis-checking on the server for say 20 players you use up an awful lot of processing power. It basically means you need a dedicated server and your game couldn't run well on a LAN, which is really bad for FPSs as that's where a lot of their multiplayer is done.

##### Share on other sites
You should pick up a book called Policing Online Games: http://www.wayner.org/books/pog/

Though it is thin and looks unprofessional on the cover, it is a splendid book on all the tribulations that befall the online gamedev: client/server synching, secure communication, digital signatures, online currency - the kit. It's cheap, too.

##### Share on other sites
if you need 1000 CPU cycles to do your checks for each player and you have 30 players that's 30.000 CPU cycles per check.
At current CPU speeds of 3 GHz and up that's (roughly) 3E4/3E9 = 3E-5 seconds for the checks.
That's about 10 microseconds out of every second of CPU time.
Even when using 100.000 CPU cycles you're only using 1/000 of your CPU capacity for those checks.

That's a lot of time left over for other things, the host would likely at that number of connections notice no more than the slightest performance drop.
And given that most multiplayer games hosted in a P2P system are limited to 4-8 players (because the rest of the calculations involved take a lot more time) you could go to half a million CPU cycles per second per client decicated to anti-cheating code and still use only that 1/1000 of the CPU.

##### Share on other sites
Quote:
 Original post by jwentingBy having everything the client knows determined by the server that can be avoided.If the client can't see something, he just never gets sent that information.He for example gets information about monster locations only when those monsters are visible to him (in the same room, or maybe they can be heard through a wall or seen through a window/door).From that moment on the client may do what he wants to. If he cheats and remembers where a monster was when bypassing it he may be in for a rough surprise if it's since moved when he returns...

From what I've seen, many FPSes tend to run as something along the lines of the client running an independent simulation that just happens to be synchronized every tick with the server's simulation, accepting the server's state without question. When communication to the server is lagged, the client runs its simulation as it expects to run given the last received state. This allows for a more graceful handling of lag or other connection issues.

This decreases the load on the server by having it handle only state information, not rendering or visibility checking, and the overall load on the network. Of course, as a side effect of this, information hacks work wonders.

While there are prioritizations to updates (distant players' states are updated less frequently), they are still updated. Less popping issues and allows for non-network based state changes. Say you have deformable terrain, which is handled client-side only. Player Y digs a hole, but player X is on the other side of the map and can't see it. By still updating player Y, you can still effect this, and player X will fall into the pit iff he wanders to the other side of the map.

Even if you were to handle visibility checks by the server and only update states for visible monsters, this still does nothing for aimbots. Aimbots don't always operate by hooking into game memory and checking for player positions - some of them are trained to look for specific textures instead, reacting when the texture hits the reticule zone.

Then, if you have a decent sound system in your game, the bot could be coded to listen for certain sounds to be played back. When they are, it will do a fast look around - since most FPSes are coded with the Walking-On-Ice-With-No-Friction syndrome, the bot will be able to do a complete scan in a nigh infinitely small amount of time.

Moving everything to the server won't save you, which is why you'll be better off trying to find a happy medium of load handling.

##### Share on other sites
not saying the server should do rendering. But the server tells the client there's a Yellow Goblin at coordinates x,y,z that's facing in direction r.
The client then renders that goblin.

Bots can be excluded by making sure each client only can have one location for himself. If he sends out a bot he no longer can move himself nor see anything, nor shoot anything.

##### Share on other sites
that still doesn't rule out a different type of aimbot. for example in the game i mentioned above, there is a weapon that aims for you and all you have to do is hold the trigger down. it has a motion-sensitive aimer, but it also has other weaknesses to balance it out. i've seen aimbots that steal the 'aimer' from this gun and put it on something like a sniper by editing the memory.

##### Share on other sites
Quote:
 Original post by jwentingnot saying the server should do rendering. But the server tells the client there's a Yellow Goblin at coordinates x,y,z that's facing in direction r.The client then renders that goblin.Bots can be excluded by making sure each client only can have one location for himself. If he sends out a bot he no longer can move himself nor see anything, nor shoot anything.

If you'd really read my post, you'd see I'd mentioned that there are aimbots that don't work by location. They simply scan the current frame for a texture that matches textures which are fed to the bot. Generally these are player textures, or further hacked textures which makes players stand out - pink suits and such.

You also have the even simpler bots which take the server's update packets for an entity, calculate the angle to the entity, turn the player to that entity, and then adjust based on the angle the entity is facing and velocity it's travelling. This allows for bots that lead and so forth. This is all done using memory and variables that are necessary for the game to function. There's nothing to limit here that would aid you in fixing this. The main way around this is with something that scans for applications hooked into the client. Unfortunately, you can't check based on the bot's movement because they generally interface by using commands that are valid to the game to actually move and fire - so it all seems legit in the log.

I'm not sure what you mean by "one location for himself". Bots aren't independent entities in the game, they generally externally hooked applications that interface with the client player's memory, which means they use the main player character. There's nothing different that other clients can distinguish - you can only see that he has amazing aim.