There are a number of people upset about the Quake 1 source code release, because it is allowing cheating in existing games.There will be a sorting out period as people figure out what directions the Quake1 world is going to go in with the new capabilities, but it will still be possible to have cheat free games after a few things get worked out.Here's what needs to be done:You have to assume the server is trusted. Because of the way quake mods work, It has always been possible to have server side cheats along the lines of "if name == mine, scale damage by 75%". You have to trust the server operator.So, the problem then becomes a matter of making sure the clients are all playing with an acceptable version before allowing them to connect to the server. You obviously can't just ask the client, because if it is hacked it can just tell you what you want to hear. Because of the nature of the GPL, you can't just have a hidden part of the code to do verification.What needs to be done is to create two closed source programs that act as executable loaders / verifiers and communication proxies for the client and server. These would need to be produced for each platform the game runs on. Some modifications will need to be done to the open source code to allow it to (optionally) communicate with these proxies.These programs would perform a robust binary digest of the programs they are loading and communicate with their peer in a complex encrypted protocol before allowing the game connection to start. It may be possible to bypass the proxy for normal packets to avoid adding any scheduling or latency issues, but it will need to be involved to some degree to prevent a cheater from hijacking the connection once it is created.The server operator would determine which versions of the game are to be allowed to connect to their server if they wish to enforce proxy protection. The part of the community that wants to be competetive will have to agree to some reasonable schedule of adoption of new versions.Nothing in online games is cheat-proof (there is allways the device driver level of things to hack on), but that would actually be more secure than the game as it originally shipped, because hex edited patches wouldn't work any more. Someone could still in theory hack the closed source programs, but that is the same situation everyone was in with the original game.People can start working on this immediately. There is some prior art in various unix games that would probably be helpfull. It would also be a good idea to find some crypto hackers to review proposed proxy communication strategies.
If enough people want it, I would probably build it for Q2 and Quake2World.
if you build it, they will come..
because hex edited patches wouldn't work any more.
the game Defcon did it in a neat way I thought. It had no specific cheat protection, but it assumed the server was always 100% correct in it's code (like carmack said), if the client didn't match the server when a command was sent, it overwrote the client's command when it was send from the server to the clients. IE the client has a hack for 100 super-fast ICBM's. Doesn't match the server code so it just ignores the client's code & send the "correct" data. I'm not sure why Q2 couldn't do this, the server already has the client code & knows the locations of players, so it can be told players can't move at such a speed, they can't aim so fast, etc.
could a md5 checksum of "safe" client's be made & the server just have some code to check if the client has a valid checksum of a client?
In regards to cheats, I always thought a neat would would be a program that doesn't inject code or write to memory, but a program that plays the game for you. It sends keyboard/mouse commands to the client so there's no actual interacting with the client, the client things it's a standard kb/mouse imput.
Quote from: John Carmackbecause hex edited patches wouldn't work any more.Problem is, there have been Q2 cheats on Windows for over a decade that would escape the detection of a secure launcher mechanism.http://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-ProcesR1ch's anticheat was out of necessity designed to thwart runtime code injection.These days, there's even some proof-of-concept aimbot code floating around that doesn't bother with code injection, and merely uses WriteProccessMemory to directly update memory locations in the client (mouse position and such.) I don't know a way around these except to have the client aggressively relocate key variables.I definitely like the idea of a cross-platform anticheat for Q2. And the secure loader idea might be better than nothing on other operating systems -- but unfortunately it's insufficient for existing cheats on Windows.
Picture the client as a network socket, because that's all the server can see. Client & server each send numbers to one another that are assigned some semantic meaning by the receiving end. The client can lie about any question asked by the server, by sending back the appropriate numbers.
I thought about it on Carmack's scale, and he's right. The client can always spoof messages to the server. At least at driver level. Our only hope is security through obscurity.
Meh, the hacks that write directly to process memory aren't that scary IMO, since they would have to have lengthy offset tables for every client, and every version of the client. As soon as an update rolls out, the author of such a cheat would have to create yet another file that contains new locations for the variables. This would be tedious, and (in most cases) would make the hack of a private nature.Same goes for the infamous Cheat Engine. You can write scripts that read/write from processes and such at a very low level, and eventually make an aimbot. However it's not practical and extremely difficult... unless someone knows a client author's exact build environment, cflags, etc and traces the memory locations at compile o.0
VaeVictis:i find it funny that you even consider grammar a sign of intelligence, that itself is a very uneducated claim
1, How does it compare to R1's anticheat? 2, Is it even needed?As far as question 2, my reasoning is that: How many cheats actually work outside of a Windows environment? Pretty much 0 right? The only issue that users on other platforms face with this is that they are locked out from forced AC servers. Now that is valid reason for a new system since that was an obvious design oversight with what R1 did.HOWEVER, I would argue that anticheat of any kind is a wasted effort, especially for a 12 year old game that people barely play. Hackers WILL find a way to do it no matter what, its the same for piracy. As an example, Ezquake, which is a modern form of Quakeworld initially had a similar system in place but they ditched it because it was a waste of time. Why put all this effort in if it will be for nothing? And especially if the intention is to make it an open thing, I don't fully understand how you plan to keep this open and not have it foiled easily but I'd argue this even more strongly on that point alone.