As many of you know, cheating can be an issue in open source games, and many such games have come up with various methods of fighting it. I've come up with a method that, while not effective against all cheats, is effective at stopping certain classes of attacks.
This requires a couple prerequisites:
- An account system, with a unique username and any password
- A clientside launcher program, separate from the game executable
This is how it works:
- Launcher authenticates to the account system with user's info
- Account System generates and compiles a program (referred to as the "verifier"), and sends it to Launcher
- Launcher executes Verifier in a separate process, and assumes its work is done
Verifier is important in two ways, execution and composition.
== Verifier Execution:
Verifier contains in it a randomly generated token. Verifier reads the game exe into memory and creates an SHA-1 hash of the data combined with the randomly generated token (referred to as the ticket). It then sends this hash to Account System, which knows what the hash ought to be. Next, it creates a randomly-named folder and writes the game exe's data there. It executes the new game exe, passing the ticket as an argument (like -ticket "sdf90sdflksdf90sdf09wlk2309"), and finally removes the temporary folder when the program exits.
== Verifier Composition:
Verifier programs are fundamentally "obfuscated" programs. They are compressed (UPX) and contain junk instructions and data, thus they are not easily disassembled. They also have no library dependencies, so traditional DLL-injection is harder.
= Account System
Another important component of the system is the account system. It keeps track of when tickets are generated because tickets have a short lifespan and can only be used once. This mitigates brute force and forgery attacks.
There are, of course, things this scheme doesn't handle:
- Attaching a debugger to the game process afterwards
- High-level DLL-injection (say user32.dll or kernel32.dll)
- VirtualAllocEx/CreateRemoteThread calls on Windows
- Indirect attacks (driver hacks, video buffer scanning, etc.)
Some of these are mitigated by the nature of c/s, if the attack is not fast enough, the client will timeout and they will have to get a new ticket, restart the client, and retry the attack. Others are problems that any native game has (open source or not), therefore I'm not too worried about them.