Show Posts
1
Quake / Re: Open source, cross-platform anticheat
« on: April 15, 2013, 10:02:29 PM »
Hello,
I felt I had to comment on this too as jdolan mentioned my name in the first post.
It's a good thing everyone are pondering about the possible security problems with the system as it is essential to know the potential weaknesses of it before writing a single line of code. Even when (if we ever start working on it) it is finished, we must know all ways to bypass it as it will define the level of security we have.
That said, in my opinion the only function of the "anticheat" would be to validate that the actual client executable that is executed is one of the officially released ones. Meaning there is no antihack measures in it at all because it would require substantial amount of work and obfuscation to keep it somewhat secure from hackers.
So, what I would like to see is just that, a guarantee the client source is not modified (source based hacks) and that the client is not a known cheat client, simple binary hashing with SHA-XYZ is enough. Bonus points for content hashing too.
The purpose of all this is to make it impossible for a less skilled programmer to bypass it. Requiring in-memory patching/injection to cheat is something that I consider outside the context of a simple verification tool. I think Valve's VAC works a bit like this by verifying the data is valid when connecting to a server even though it most definitely has more sophisticated anticheat measures too.
Big issue that has been already said is trusting the environment. I think the only way to work around that is to force the game itself to do all IO through the tool itself. That way file loading can be trusted as it goes through the anticheat and it can hash the files on-the-fly from fread() calls by the game. Doing this is quite simple on Windows and Linux, possibly on other platforms too.
One problem that I haven't yet figured out completely in my own head is how to verify and launch the client executable in a trusted way. We must consider IO to be hooked and untrusted. Doing that (hooking/proxying) is very simple on both mentioned platform with either DLL overrides on windows or LD_PRELOAD or LD_LIBRARY_PATH on Linux.
One way to solve this the client executable needs to be loaded through that untrusted IO, verified in-memory, then launched - from memory. This would mean we need to implement our own PE loading mechanism (there are examples on the net) for Windows and the same for ELF just to support two platforms. Is it worth it? Are there any better approaches to launch the client?
Overall, in my opinion, the environment must be considered untrusted to get even the slightest level of security and everything we need must be statically linked to have some sort of integrity.
Finally, at this point, I don't yet see it being secure enough as long as I can (theoretically) bypass it without even opening the debugger. I hope we can figure all these things out and get it implemented. Before that, it must go through many skilled programmers and hackers to determine bypassing is NOT trivial.
I felt I had to comment on this too as jdolan mentioned my name in the first post.
It's a good thing everyone are pondering about the possible security problems with the system as it is essential to know the potential weaknesses of it before writing a single line of code. Even when (if we ever start working on it) it is finished, we must know all ways to bypass it as it will define the level of security we have.
That said, in my opinion the only function of the "anticheat" would be to validate that the actual client executable that is executed is one of the officially released ones. Meaning there is no antihack measures in it at all because it would require substantial amount of work and obfuscation to keep it somewhat secure from hackers.
So, what I would like to see is just that, a guarantee the client source is not modified (source based hacks) and that the client is not a known cheat client, simple binary hashing with SHA-XYZ is enough. Bonus points for content hashing too.
The purpose of all this is to make it impossible for a less skilled programmer to bypass it. Requiring in-memory patching/injection to cheat is something that I consider outside the context of a simple verification tool. I think Valve's VAC works a bit like this by verifying the data is valid when connecting to a server even though it most definitely has more sophisticated anticheat measures too.
Big issue that has been already said is trusting the environment. I think the only way to work around that is to force the game itself to do all IO through the tool itself. That way file loading can be trusted as it goes through the anticheat and it can hash the files on-the-fly from fread() calls by the game. Doing this is quite simple on Windows and Linux, possibly on other platforms too.
One problem that I haven't yet figured out completely in my own head is how to verify and launch the client executable in a trusted way. We must consider IO to be hooked and untrusted. Doing that (hooking/proxying) is very simple on both mentioned platform with either DLL overrides on windows or LD_PRELOAD or LD_LIBRARY_PATH on Linux.
One way to solve this the client executable needs to be loaded through that untrusted IO, verified in-memory, then launched - from memory. This would mean we need to implement our own PE loading mechanism (there are examples on the net) for Windows and the same for ELF just to support two platforms. Is it worth it? Are there any better approaches to launch the client?
Overall, in my opinion, the environment must be considered untrusted to get even the slightest level of security and everything we need must be statically linked to have some sort of integrity.
Finally, at this point, I don't yet see it being secure enough as long as I can (theoretically) bypass it without even opening the debugger. I hope we can figure all these things out and get it implemented. Before that, it must go through many skilled programmers and hackers to determine bypassing is NOT trivial.