Well, this is the hard part.
As long as the client knows that a model is behind a wall, but does not draw it because there is a wall there, its "easy" to add a wallhack - simply because the client *knows* something is there

The server could do Line of sight check, and decide not to send models that are behind walls, for example, which would make wallhacks like that impossible. There are other concerns, here, because in modern high end games you might see shadows/hear sound from specifict positions as well.

If you look at the big fps games out there, none of them has managed to solve this problem yet. But if you are not making a game for the big players out there, this might not be an issue to you at all. Its quite possible that noone will make cheats for your game anyway.

For mmo's this is "simpler" since they have rpg systems that decide the outcome of combat, which hopefully is calculated by your server.

To reiterate what has been said in this thread many times already: To prevent cheating, the server needs to do the calculations. (and even then it can be tricked: speedhacks etc)

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that?[/quote]

[/font]

You fix it through design, not through technical counter-measures.
Design the game so cheating doesn't give you an edge. Co-op is great for this!
Design the game so that cheaters end up match-making to other cheaters.
Have a premium service where you have admins on all the time, and can request random screen shots from clients (like punkbuster) -- doesn't mean clients can't fake out screen shots, but it's harder to do well.
I really like it if you can design so griefers play other griefers, cheaters play other cheaters, and friendly noobs play other friendly noobs...

[color=#282828][font=helvetica,arial,verdana,tahoma,sans-serif]

if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that?

[/font]

You fix it through design, not through technical counter-measures.
Design the game so cheating doesn't give you an edge. Co-op is great for this!
Design the game so that cheaters end up match-making to other cheaters.
Have a premium service where you have admins on all the time, and can request random screen shots from clients (like punkbuster) -- doesn't mean clients can't fake out screen shots, but it's harder to do well.
I really like it if you can design so griefers play other griefers, cheaters play other cheaters, and friendly noobs play other friendly noobs...
[/quote]

Heh and you call MY stuff 'fancy mechanisms'. Changing the whole game from something you might want it to be to be something else....

@wodinoneeye: All your fancy mechanisms don't mean nothing. Your server will receive packets from the greater internet, and has to make decisions based on those packets. I can form packets any way I want. Perhaps I patch your client. Perhaps I write my own client. Perhaps I point my Windows box at a Linux box for its gateway, and modify the packets in flight. Perhaps I run your game in a virtual machine inside my Windows box and use the virtual network redirect to patch the packet stream. There is no way you can detect this and separate "touched" packets from "untouched" packets, because I can just inspect your client and inspect your packet stream and figure out how to generate correct packets. And once one person has figured this out, every person can download it on the internet.
The *only* defense against cheating is to not trust the client, and enforce all game state and rules on the server.
This is assuming your game is popular enough that anyone cares to cheat, of course. If you have no players, you have no cheater problem :-)

The problem is that for it to work most of the mechanism has to be done to protect the next part that covers all the holes (it IS a complex solution).

You can 'touch' the packet traffic anyway you want, but if you dont know what to properly send (to read them to modify) then you are stopped.

For the full solution, the essence is that the client code and the transmitted data formats keeps changing faster than the hacker can keep up with the changes -- cant hand change the hack and any automated hack patcher would not get done before the encryption was changing again (whether they intercept packets or mutate the client or whatever).

(Did I not mention that the scrambler methods are sent as a blocks of machine code and is inserted into the executable ??? -- its not some ordinal to a method dictionary already in the client -- client is patched constantly with code snippets that are constantly regenerated/randomized on the server -- its a moving target)

I recall one issue that might be the deal breaker -- read/write/execute permissions on program segments might not be workable (especially if they crank up security to nazi levels on the newer OSs) That self modifying code issue might be simply solvable with reloading DLLs (that would also give the hacker a leg-up on auto hacking it though)

In a 'Just Make it Harder' partial solution -- having the right parts of the game executable customized automaticly 'on the fly' prevents static cheats from propagating (distribution to scriptkiddees). The wouldbe cheaters would be required to have have a complex hacker rig to break this system.

Simply reloading a modified client every time you start the game would go a long way (with sufficient differeneces in data transfer encodings each rebuild) . Just change the data chunk identification to different ordinals (simultaneously on client & server) would do alot to obfuscate data and break hacks.

Constant on-the-fly Spot Checks on chunks of the game executable (back to the server) would force a more complex hacked solution -- which would require the hacker to service spot checks requests with data from a well maintaining a 'pristine' (possibly constantly patched) executabe image as well as his hacked one actually running.

This again is still ALREADY with proper server side validation, but many cheats like aim-bots arent stopped by those.

YES much of this is overkill (its only for a game after all) and was really extended for Peer to Peer processing (which if also for a game lead to 'who cares' )

So for file validation this looks like the way to go. Step 1 is to make sure users are all running the correct version. I get the server side ruling all, but if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that? It clearly gives him an advantage because he can see you coming from anywhere. Hash checks would stop that for the people who don't know how to redirect network traffic but know how to model and replace a file, but even server side validation can't detect that's happening if they are able to intercept the network traffic and send the right hash code. Is there really any way to handle that? My game won't have that specific problem but I know I've seen cheats like that in counter-strike before.

Like some are saying you could make it harder on a hacker by doing all sorts of crazy stuff, but it does add time to your development and will introduce bugs.

You could do PART of my grand scheme and maintain some in-memory data (cypher block) that also is queried along with your file hashes etc, --- to make what the hacker has to send back that much more complex a response to (they have to now emulate it all in their interceptor while a kosher installation just does it directly within the game executable) -- just to make it ALOT harder.

EVERY packet sent back to the server might have a mini payload (even just a few bytes of overhead) with some different data pulled from that cypher block (offset+databytes from cypher) do this enough and the delays (intercept+digest+hack+send) involved might make their hacked game unplayable...

The cypher block would be partially based on the client version (or the executables bytes itself) and partially on some 'on the fly' data (user specific random) sent from the server periodicly (with the corresponding data on the server session maintained to be checked against)

The wouldbe cheaters would be required to have have a complex hacker rig to break this system.

Lol @ 'complicated hacker rig'. Your typical hacking rig is GDB, Wireshark and Vim, plus a few more specific pieces depending on the exact task at hand - but it's all free and open-source software that is probably sitting on your hard drive as we speak...

[quote name='wodinoneeye' timestamp='1328271695' post='4909127']
The wouldbe cheaters would be required to have have a complex hacker rig to break this system.

Lol @ 'complicated hacker rig'. Your typical hacking rig is GDB, Wireshark and Vim, plus a few more specific pieces depending on the exact task at hand - but it's all free and open-source software that is probably sitting on your hard drive as we speak...
[/quote]

Ive said it several times 'you want to make it harder'.... How many ordinary users know how to set those things up let alone make them work in an automated fashion for even the simplest parts of my solution (changing things frequently enough that the hackers have to constantly rebuild their hack mechanisms)

When some would-be cheater can just download something provided by the experts, install it and run the provided hacks, its easy and THEY are the majority of the cheaters.
Now harden the system and suddenly only the experts (what percentage do you think theyare??) can do it (and they cant distribute it fast enough to the script kiddees ) Some 'experts' might take it on as a constant challenge but even they likely will give up and move on to some other less bothersome cheat-easy game.

Suddenly cheaters are hardly there and THAT is the goal.

You are not the first GDNet'er to go down this particular rabbit hole, by the way. Ysaneya beat you to it by 6 years, and the debate there would be well worth your time to read.

How many ordinary users know how to set those things up let alone make them work in an automated fashion for even the simplest parts of my solution (changing things frequently enough that the hackers have to constantly rebuild their hack mechanisms)

You are suggesting that your software will download a small module each time, and this module will perform the checks and authenticate the results with the server, right? That way you can change the module regularly, to outdate older hacks.

So my hack would also download the module, and run it, just like your software does, and let it authenticate with your server. How will that work with a patched executable? Because I will be running your module in a sandbox, and giving it the original executable to work with, instead of my patched one.

This method of hacking is completely impossible to defend against (well, excepting TPM, but nobody wants that), because it works by showing the security/DRM checker exactly what it wants to see - and there is no way to detect this kind of spoofing (again, except for TPM).