Unless they hack the server and change the program ;D
Making the client “dumb” removes cheats that falsify data, but it doesn’t prevent things like aimbots and other macro automators. This is usually good enough for most games, but otherwise you’re basically talking about a turing test without the benefit of being able to ask any questions.
I’m sorry but literally anything that’s online is hackable :persecutioncomplex:. No I am not part of Anonymous. All you need to do is 1. feed the server bad data (same thing used in SQL injection) or 2. hack into the server itself. Obviously you can’t do 100% of everything on the server unless you are playing the game on the server itself, which is obviously not feasible for distributed games.
What if you host the server on your computer?
Other people will still connect to the server, and people can still hack you computer…it’s a scary world out here
Hash tables!
Don’t put a value straightly! Follow every ‘=’ and setter with encodeToSomething()! 
I suppose you could send the “key” to the computer and the hash, and have a different one every time…
Q: What does this thread have in common with the random changing of bits thread?
A: Everything.
Solution: Don’t worry about unsolvable problems.
i guess we don’t really need to worry for most scenarios. if you have a competition, just make everyone record a demo.
it’s more along the lines of “insert certain instructions in a certain place. if the client code is changed, the new instructions could reference missing variables, so the client screws itself”. Of course, this doesn’t do anything to prevent wall hacks.
Couldn’t you have the program know exactly how large it is, to the byte and check the size to see if it’s smaller or larger (been changed)
And why wouldn’t that verification code be changed?
Basically nothing. In the past all sorts of compression, encryption, obfuscation etc. have been tried and were circumvented or broken by curious or malevolent people.
They can even build a new client that speaks the same protocol and run that against your server (if they can’t hack your client due to your security measurements).
If you concern is safety and consitency, you must assume that clients are being hacked (or just buggy) and try to have all checks and game logic on server side, not in th access of the client. Only if all your logic is on teh eserver and the client is merely an input/output device you have some safety - but hackers will try to trick the server into unwanted actions by bogus input data thus you must check all input data not only on valid ranges but also if it is valid in the context of the clients state (whcih needs to be modeled/mirrored on the server side to some extend for this).
If you have a game that’s popular enough for people to cheat at, you should be happy - it means you have a fun game that people will likely pay money for. The trick is actually making the game people want to cheat at.