Archived

This topic is now archived and is closed to further replies.

Defeating memory editors

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I hope this is the right forum to place this message in. I am wondering if there are any other efficient methods to defeat memory editors (a program where people can change the values of variables at their discretion). The only way I know of blocking this in a multiplayer game is to make everything server side so the client just acts as a terminal while the server does everything except getting the user input. Are there any other solutions to stopping this? Thanks

Share this post


Link to post
Share on other sites
Unfortunately no, it''s fundamentally impossible to maintain the integrity of anything you put on the client machine. You have it right, the only way to maintain the integrity of the game as a whole is to put all the logic and state on the server side and make the client an input and drawing console.

Even then there are ways to exploit the client, such as the counterstrike driver hacks that make walls transparent.


--
Eric

Share this post


Link to post
Share on other sites
but the funny thing in the hl/cs hacks is that you dont need to use modified drivers. you simply hook the client.dll (ok not simple to do, thanks to crc checks and the like) which gives you access to all the player positions that the client knows about in a prefectly accurate driver indepenedent (read direct3d, opengl, or software renderer) way of displaying players behind walls and "helping" the player send input to the server (aiming, autofire and such). of course legitimate resons include, winamp players, irc clients, and other non cheat things that draw to the screen. there is only ONE way to ensure the client does not install cheats or use exploits. never let the client connect in the first place. because data he dont retrieve is data he cant modify for cheating purposes. best bet, let the admins deal with some of it. try to make your code a bit bloated when dealing with memory, try to encrypt stuff, try to figure out if things loaded in yoru address space should not be there. unfortunatly all these things only slow the hacker down. this is because you MUST trust the os and the player to some extent. since the os can even lie to you (by saying certain apps are not running or that certain files dont exist) through the use of hook system dlls which firther makes things difficult. dont mget me wrong though, this applies to any os that you can use. including linux and windows. though windows makes things a bit more difficult because it is not oen source nor as well documented as linux. this does not say linux is not a secure os, because it is fomr a network perspective or someone trying to log in remotly. but if the person has root acces, they can simply recompile the os to suit their needs.

long story short, there is no gaurunteed way to ensure no hacks at all expcept by never releasing the software.

Share this post


Link to post
Share on other sites
Actually, a really smart server would make sure it never sent the position of a player to another player if there was an opaque object between them. A driver hack can''t help you if the graphics system doesn''t render the players hidden behind walls.

-Daedalus

Share this post


Link to post
Share on other sites
I had a very simple system which would use things like checksums and stuff internally, but to make things a lot more difficult, the variable which stored the checksum could store 1 of three different checksums, with the correct checksum type being stored in another variable (unencrypted). What this meant was that a conventional program couldn''t change a value (because this would change the checksum), but if all three checksums were figured out, then there would still be a matter of finding the variable which told it which one to use. Basically, the person had to know what they were doing.

Also, having checksums which "overlap" in the game loop, since the checksum has to be recalculated and checked at some stage, there is a tiny window of opportunity

Trying is the first step towards failure.

Share this post


Link to post
Share on other sites
Daedalus- true, but it''s unrealistic to think the server can calculate the potentially visible set for every client at every moment. Even if it could, a quick client movement would cause things to pop suddenly into view out of nowhere. Obviously undesirable for a game.

A couple of other people have mentioned checksums or encryption to secure the client. Internal checksums and other cruft do absolutely nothing to improve the security of your application. It inconveniences you, adds many more places for you to make a mistake and introduce a bug, doesn''t impede a good hacker at all, and can have only negative effects on the end user''s experience. Not only is it not worth trying to secure your software''s internals, it''s counterproductive to do so unless your software is stored on a dedicated, secure hardware device (assuming such a thing existed).


--
Eric

Share this post


Link to post
Share on other sites
Problem is, it''s far from trivial to calculate exactly whether something is visible or not. Just think about a situation where the other player is behind some kind of grating.

I don''t agree that checksums are worthless. There should be at least some protection. Apart from that, it''s quite a good preparation for an additional - and in the long run better - method to prevent or detect cheats:

Use external programs.

Those programs could periodically check whether the running game executable (in memory!) is still sane and unmodified. The external program could use exactly the same techniques that are used by the cheating tools to defeat them. To be really efficient, it''d have to work based on small codelets (just a few hundred bytes) which are dynamically downloaded and installed. That way, you can quickly react to new cheats and defeat them (either preventing or detecting them to kick the cheater).

Now if a cheater were to circumvent the games own checksumming algorithm you''d know that something''s wrong. The game''s internal checksumming would stop people from truly accidently showing cheating behaviour (like going online with modified models).

cu,
Prefect

Share this post


Link to post
Share on other sites
Convict@Large you are so smart. maybe all games should use that system. oh wait a second, every mulitplayer game worth its bandwidth does. the problem lies in the fact that in tribes2 the level to player size ratio is larger so players behind walls are less likly to be in the potential visible set. though the fact remains, aimhacks work quite well due to the distance one can see in the game.

checksume are not toatly useless. the trick is not to try and prevent all hacks, but make it a much of a pain as possible for the hacker. simple checksums will prevent 80-90% of so called hackers to create cheats. granted only one cheat needs to be avaiblible publicly for ppl with no skills to use it. the harder you make the hack to create, the less likly multiple groups will release hacks and less likly they will become widespread.

use external programs? that is the WORST method of cheat protection. external programs, just like your game, can be patched. look at pb, it was hacked reguarly. granted they only released updates once week if even at that pace. it did keep more ppl from cheating, but then again it was more thrilling to cheat on a pb server since most ppl though you could not cheat on them. the screen shot feature was useless, in fact it created a major problem since they had too allow voodoo2/voodoo1 video cards to work with the game. this meant no screen capturing would work correctly in an extrenal program unless you did some fancy tricks (which obviusly they could not get to work since i dont think the screen shot feature ever went out of beta). hackers used this as an advantage, simple send screen shots back to the server that looked like they were taken on a voodoo2 board, (which in some cases meant just denying the screen shot request) and you would not have to worry. though the tried and true method was to just hook directdraw (since thats how pb took its screen shots) and turn off visible cheats on your screen, after pb took the shot, you turned your cheats back on.

external programs also have the overhead of having to use windows functions to check things as well as use extra cpu and extra bacndwidth. the windows functions for readin memory of another app are a bit slow, and can esily bring a fast system to its knees (this is why pb "lagged" players). this overhead reduces enjoyment for legit players and leads to very cumbersome interface to the game itself (why do you think the pb team decided to quit after valve denied them the access (and money) they wanted to continue on the project).

this is not to say that all external methods are bad, it is to say that they are more difficult and dont work as well as is the same work was applied to the actual game. in fact, how will your extrenal program detect that it has been patched? or even better that windows is returning the real running apps/memory that you are trying to check and not some fake stuff that the hacker knows yoru progam wants to see.

it all comes down to trying to make it hard for the hacker to create things and then when he gets it working you change things to make him have to do all the work over again. unlike you however, he is allowed to modify system files (like the kernal32.dll) and do other low level tricks you cant do simply because you would be breaking the law (searching the harddrive for instance without consent is breach of privacy). NOBODY in there right mind woudl install ANY software that would modify system critical files just to play a game in a "cheat free" enviroment.

just for a pondering, go see the 13th floor. its not based on cheating or games, but on the idea of simulating a world on a computer. and how you truly dont know what goes on, beyond what the world tells you. for instance, how do you handle cheat detection on hardware that is being emulated? now at the hardware level the hacker has control fo the system and controls EVERY aspect of what your game is allowed to do, all without yoru knowledge (the OS level hacks are one step below using hardware emulation). dont think hackers wont resort to hardware emulation either, espicealy with free x86 emulators like bochs starting incorporate VMWare style emulation that uses the hardware cpu to decode and handle instructions.

cheat prevention sound difficult and it is. you should really try finding some cheat development forums and read up on what your up against.

Share this post


Link to post
Share on other sites
If you have to, a simple solution apart from checksums to prevent modifications on memory, is to try a very low level (or atleast fast) encrypytion of the data.
Lets say everything is a long, just store it playerx=retrx*2+1. Unless they dissassemble your code, they may atleast crack a headache figuring out what the hell you did.



Beer - the love catalyst
good ol'' homepage

Share this post


Link to post
Share on other sites
its just how you implied that tribes2 method of sending data to the client somehow made see through wall cheats worthless. they can be useful in close quarters of the base, ie to look around corners and such. NEVER try to imply a cheat will be worthless because of how gameplay is delt with. if there are very few walls to hide behind, naturally a see through wall cheat will be rather worthless, but not because the method of sending data, but more of the fact in essence there are no walls ppl can hide behind.

please explain which popular commercial games at which players would bother trying to cheat at, dont use some form of PVS (potential visible set) system. i would like to be enlightened (seriously, i dont know of any game that does not use this as a bandwidth optimization except for maybe homebrewn games that are done by single person and are in very early stages of development meant for lan play only).

Share this post


Link to post
Share on other sites
my game uses various methods, for example, the packet id''s are different for every game, shooting a weapon can be 10, but it can be 20 as well next game... then there''s encryption.. and if I notice cheaters sometime (I still need to finish the game..) then I will also implent a CRC system...


Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by a person
its just how you implied that tribes2 method of sending data to the client somehow made see through wall cheats worthless. they can be useful in close quarters of the base, ie to look around corners and such. NEVER try to imply a cheat will be worthless because of how gameplay is delt with.


Tribes 2 uses portals, though. If they''re getting zero (or very low) overdraw, then wallhacks would definately not be very useful. Of course, the player could rewrite parts of the rendering pipeline, but then you might as well worry about him writing a whole new client against your network protocol.

Share this post


Link to post
Share on other sites
ok, so they compare each model to the world geometry before drawing as well? in any case it dont matter, many advanced hacks hook the actually client game dll which recieves the information on where things are (for client side effects that would need this information).

tribes 2 may not be as vunerable to this as hl/quake+ are, but that would mean a less expandable game client side wise (no special radar and such). a hooked client side api gets all the info teh client gets regardless if it actually gets drawn. a

i am not super familar with how tribes handles drawing models, but i am pretty sure the engine does not do checks to see if the model is being blocked by geometry since drawing with the zbuffer would be faster and more accurate. otherwise the engine would have to check at an almost per polygon level to decide whether to draw the model. so when the model gets close to a corner (ie a pixel of the model could be seen) the model or a larget part then that pixel will be sent to the card for drawing. maybe the player wont get the huge advantage as in hl/quake+ but a second or so is ussually enough to give the cheater enough to advert trouble coming arounf a corner. (especially if the person happens to just be camping there waiting). its much more cpu friendly not do try and do all those traces to see if the model is patrially visible or not.

you give the game companies too much credit when they say they get zero overdraw or close to it. they ussually mean for the static level geometry and not the dynamic geometry. if it was so easy to drop dynamic models from view, dont you think valve would have done this a while ago (in fact they said they did and see through wall cheats woudl no longer work). the truth is that they did optimize the model drawing, and you had less of a viewing advantage (though most levels were not even affected to due the inability to complitly remove a model easily from rendering without affecting quality), but not to the point where the cheat became even remotly useless.

btw, early cheats for quake were actually proxies that modified the packets to allow for auto aiming and such. the hackers reversed engineered the packets and were able to figure enough to write such a bot.

ajoling: just becareful the gamer dont find teh algorithm (which they have access to the code) and use it. i suggest at each update changing stuff to help keep ppl guessing. just try not to be too bandwidth intensive with your system.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by a person


i am not super familar with how tribes handles drawing models, but i am pretty sure the engine does not do checks to see if the model is being blocked by geometry since drawing with the zbuffer would be faster and more accurate. otherwise the engine would have to check at an almost per polygon level to decide whether to draw the model. so when the model gets close to a corner (ie a pixel of the model could be seen) the model or a larget part then that pixel will be sent to the card for drawing. maybe the player wont get the huge advantage as in hl/quake+ but a second or so is ussually enough to give the cheater enough to advert trouble coming arounf a corner. (especially if the person happens to just be camping there waiting). its much more cpu friendly not do try and do all those traces to see if the model is patrially visible or not.



Line of sight testing against bounding boxes or hitboxes really isn''t that bad computationally. If you were going to go that route, you could even just draw an arm or something when that''s box peeks around a corner. (Would be easy in tribes, since it uses segmented player models anyway.) Try getting a headshot aimed against a disembodied arm.I don''t know if their engine actually does this, though. Anyway, doing so would cut out driver hacks, though not client code hacking. But I never said that it would.

Client hacking is _always_ a problem, especially if you are going to write a moddable game. If you aren''t going to let players modify the game, though...

Share this post


Link to post
Share on other sites
If any of you want to take a look at the tribes2 engine, go here:

http://www.garagegames.com/

and buy a license for the source code. It''s $100 and you get 95% of the tribes2 engine, including the entire network component which is the most impressive.

The documentation is VERY poor, almost non-existant, but it''s worth the $100.

Share this post


Link to post
Share on other sites