hack prevention in games

Started by
24 comments, last by jwenting 18 years, 1 month ago
i was reading an article the other day about a multiplayer game that i play in my free time. the article explained the game's attempts to rule out cheaters during gameplay. it said that when a player joined a server the server would first check all of the game files on the client side and compare them to the game files on the server side. it does this because the game includes modding tools that gives the user easy access to change the game. if the server detects a mod then the player is not allowed to join. the article said this was a good method for starters, but once the player has joined the server then this method can't be used (in real time) because it would cause extreme lag. so a player is free to download a memory editing tool and edit the game's memory during play and change certain values, ie. health. is 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?
Advertisement
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 =/
"Leave it to the computer programmers to shorten the "Year 2000 Millennium Bug" to "Y2K." Isn't that what caused this problem in the first place?"
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.
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 :)
"I must not fear. Fear is the mindkiller. Fear is the little death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past me I will turn to see fear's path. Where the fear has gone there will be nothing. Only I will remain." ~Frank Herbert, DuneMy slice of the web
Quote:Original post by chuck22
is 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,
Quote:Original post by Emmanuel Deloget
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.


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.
"I must not fear. Fear is the mindkiller. Fear is the little death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past me I will turn to see fear's path. Where the fear has gone there will be nothing. Only I will remain." ~Frank Herbert, DuneMy slice of the web
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.
I program in my sleep,but when I sleep I use the partition in my head that doesnt have g++ or the .net library, so im kinda screwed.
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.
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.
The client should merely be a dumb terminal rendering polygons, everything important should be dealth with by the server.
ToDoList.GrowthRate = WorkRate*2, it's more efficient to not work.

This topic is closed to new replies.

Advertisement