You could check to see if a specific process is running on the target machine

And why do you think that the attacker would not patch the "get running processes" call to filter out the processes they don't want you to know about?

I'll write the client so that it prevents the player from trying weird stuff

Whatever you do on the client, can be un-done by the attacker, because they control the code running on their computer. If the attacker is only using pre-existing cheat tools, then you can prevent those tools from being effective by knowing what those tools do, and implement specific counter-measures. (Checksums and scrambled values are helpful against tools scanning the process for known values, for example.)

On 6/29/2017 at 5:43 PM, hplus0603 said:

The attacker can decompile whatever code is being run on the client, as the client is run it, no matter how much you obfuscate or encrypt the code. Such measures simply don't matter to a determined attacker, because the code needs to be actually runnable by the CPU, and anyone with the right tools can take that instruction stream and disassemble it.

As for "can decompile" - yes (though more accurate would be to say "can decompile, given sufficient time"). As for "simply don't matter" - I certainly cannot agree with it if speaking about MOGs.

If speaking about single-player games - the cause can be indeed lost, but with MOGs the situation is drastically different.

First - for MOGs it is not about the fact that our game was broken, but about the number of cheaters (who will break the whole game ecosystem if not kept in check, scaring away honest players). Moreover, for MOGs it is not necessary to "run faster than the bear", it is enough to "run faster than the guy next to you". As a result - when dealing with cheaters, every bit counts (this includes Client-Side obscurity).

Way too many serious MOGdev companies did realize it too late - and are spending LOTS of time dealing with this problem now (one publicly available example is DaysZ which even had a talk about it IIRC on GDC2016, but there are LOTS of such efforts out there).

Second - for MOGs we can count on server being always-present-while-playing. This, in turn, allows to attack that "given time" clause in the "can reverse engineer" statement above. Very very roughly - we can automatically change protocols on each build - forcing attackers to break protocol obfuscation on each build; throw in intra-Client obfuscation - and it can become extremely difficult to get past the defences within the 3-4-weeks time (and after the update - the process starts pretty much from scratch). Detailed discussion of this process is going to be a central point of upcoming Vol. VIII of my "Development and Deployment of MOGs" (with chapters of "1st beta" of Vol. VIII scheduled to appear on my ithare.com in October, they should be enough to get the idea; actually - I plan to publish 20-page outline for "Bot Fighting" chapter as early as next Monday, Sep 25).

Overall:

- sure, Authoritative Server is a strict prerequisite for dealing with cheaters. 

- however, just having an Authoritative Server is NOT sufficient, and LOTS of things has to be improved on this way to deal with bots (all kinds of them, from aiming bots to grinding bots, with whatever-we-can-imagine in between). This leads us to such things as encryption (to prevent self-MITM class of attacks which facilitate fundamentally-undetectable proxy bots) - which, in turn, implies hiding a certificate within the Client (hey, this is already security by obscurity!), obfuscation of data structures within the Client to prevent bots from reading the data from RAM easily, and of course, all-popular (but not nearly as efficient-as-advertised if taken alone) "code encryption" (actually, scrambling), debug detection, etc.