Your client should just be a dummy terminal, that renders and accepts input (a few other minor things such as predictions, etc). The server should control EVERYTHING and the client should just render it.

Other problems such as radars, etc are inevitable and will happen in any online game, although there are many ways to minimize this from happening.

There are a couple of areas where cheating is possible.
1) Information cheats
If you are in multiplayer game you obviously need to send information to players about other players. A client could look at this data and use it to figure out the exact location of players, items. I think this was a cheat that was available for Everquest. It would send information about *alll items* to a client in a sector. This could then be used in something like aim bots or 'treasure finders'.

One way ( which we use in our project ) to solve this is to limit the things that are sent to player. So they are only sent information about things they are close to. So for example, a magic ring may have a '10 metre' radius. So you'd have to be that close to it before the server will even send information about it to the client. This, of course, does not solve all problems but helps.

Second information cheat types can be stuff like lighting. For our game, maps are stored client side. A smart client could figure out a way to turn of lighting effects therefore make spells like blindness useless. To solve this we can come up with better spells with effects that the client cannot get around.

2) Calculation cheats.
This is where the client tries to 'fool' the server into doing something the client should not be able to. For example, changing stack counts on items or sending a 'hit target for 5 damage' when it should really be one.

You are already along the correct track for this. You have to have the server validate this. In our project we have a seperate process that monitors data like this. So it can do random checks or GM's will be able to flag a player for closer monitoring.

Some other ways to cheat are finding possible ways of crashing the server. This often results in some things being in bad states where data that was cached did not get a chance to be written out. This is how I can imagine one way item dupes could occur.

Another way to track things ( after the fact though ) is through data mining. This is where you take a look at all the data in your database and try to spot trends. If you see some guy gain 100k of experience in one day he is most likely cheating.

----------
Andrew

Quote:Original post by Toolmaker
MapleStory V0.07 is currently using a way to prevent other processes from writing to it's memory. I have no idea how this is done(And interested in it), but the game seems to quit when another process writes to memory.

Before everyone starts monkeying around and rate me down for hacking, I'm not working on a cheat for Maple, nor will I. I haven't tried it. This information came from a certain person who was trying to bypass the ridiculous language filter(Saying "That it ...." will result in cursing, because you said t it = tit.)

This is also something you sohuld look for. Processes that are attached your client or trying to write to it's memory. I think there's a way to enumarate all attached processes.

Toolmaker

]

There is a way to enumerate through all attached processes, but what would you look for exactly? I think that AIM automatically attaches a dll that helps in their check to see if you're idle or not.

The 'simplest' way to prevent the main kind of cheating people are bringing up here is to make it so the server "doubts" everything the client sends it, as everyone is saying. Basically the server only sends totally necessary info to the client (to minimize things like hacked-graphics-driver wallhacks in FPS games...in this case don't send *all* the level data, just what the client needs), and everything it gets back from the client it verifies for reality. For example, you should never update a client's position solely based on what the client reports to the server is its new position and/or velocity etc. Instead you have the server do all the same checks the client does locally for prediction - eg for collisions, and you also check to make sure that at current speed/heading/whatever the client could feasibly reach the spot he's claiming to be at.

It's not just server *verification* though, as you mentioned about things like the gold. Ideally, a large part of it is not even allowing the client to legally change his stats/gold/etc at all, even via requests. Since the server should know everything that's going on in the world (like when a client runs over an item or whatever), the client shouldn't be able to send this info. For things like when the client can choose whether or not to pick up an item, it should send a generic "pickup whatever I'm standing on" request with no specifics, and the server should then figure out what, if anything, the client can pick up.

A lot of the problems with duping and things are probably glitches in the server code, so that the system I'm describing was partially broken. A guess as to why they didn't setup red flags like you mentioned is because if that code worked, the red flags wouldn't be necessary. If you want redundancy you can setup a system like that, but it might get chaotic trying to keep track of *everything*.

A last note - if you want actual oversight like you mentioned, you might as well just have the clients (or the server) create snapshots of all the pertinent stats every so often, and then you can have an automated system parse them looking for anomolies. But a cheating client could theoretically fabricate the snapshots too (unless they're server-side only), and it might be hard to tell whether many things are cheating or not...

Modify all this to suit your needs...but there's virtually *always* some cheating, no matter what you do.

*EDIT* about the processes stuff - I suppose that's a good measure if it works, but it won't stop a determined hacker who knows what he's doing. You could hack the exe and rewrite the assembly/binary (this can even be done at runtime), and bypass/get rid of that security stuff... There are measures to help against that, but you can hack those too, and on and on. Basically there's always a way to do something to a local exe, and all it takes is one person figuring it out and releasing something that uses it...

Quote:Original post by Toolmaker
... but the game seems to quit when another process writes to memory.
...
This is also something you sohuld look for. Processes that are attached your client or trying to write to it's memory. I think there's a way to enumarate all attached processes.

Toolmaker

Complete, total, and utter waste of time. This was proved pointless approximately 7 years ago when Diablo was hacked using ?softICE? and live memory debugging. If someone has the time/inclination/energy to try hacking like that, they'll sooner or later find softICE and friends.

Here's the hacker solution (you can pass on to your friend if you like)

1. Find the memory you want to change
2. Change it
3. Step through the program letting it "discover" the interference
4. Identify the code that did the discovery
5. Disable it.
6. Go back to 1-2, and this time you won't be stopped

...or variations on that, depending on how many checks the program does. In general, someone who writes self-protecting code doesn't really understand basic security theory and probably ought to get a different job doing something they're competent at instead.

There are things that are worth doing just to slow down the hackers, but for any successful game you just want to either protect it, or not - this half-arsed crap just increases development time (+cost) without making the game any more secure.

redmilamber

Often times in the game industry it is more important to simply try to slow down the piraters and cheaters than it is to actually try and stop them (which is nearly impossible).

Quote:Original post by furthermore
Often times in the game industry it is more important to simply try to slow down the piraters and cheaters than it is to actually try and stop them (which is nearly impossible).

With "traditional" store-front games, yes.

However, pirating can be overcome by having the game pay 2 play (with the internet being an integral component of the game) or otherwise not directly funded by the distribution of the software itself - (like most MMOs, although it will probably have to be a MMO in order to succeed)

And cheaters can be overcome by:

1) Not letting the client be authoritative in any manner (command/response style, for example - the player dosn't say "I mined 8 gold", only that "I want unit XYZ to mine the goldmine ABC", and then the server returning "Unit XYZ got to ___ ... you mined 8 gold" - and the player dosn't say "I start building a tower here", the player says "I WANT to start building a tower here", and then the server can either return "You start building a tower THERE" or "You don't have enough cash to build a tower there".

2) Not giving the client information it shouldn't have. In an RTS, if there's nobody by the enemy base, the server shouldn't send data about the enemy's buildings. The reason that map hacks work in Warcraft 3 is because each client allways knows everything about the game.

3) Making it prohibitively expensive to decrypt information it has been sent due to it possibly being relevant very soon - or to be even more diabloical, also send false positives in the encrypted information (these would be valid data that's bogus - they would never be legitimately decrypted (server never would provide keys) but could be viewed by a map hack (oh no!!! he allready has an army of tanks??!? I'm screwed!!!).