Been done, been moaned at in the press for being intrusive, been worked around trivially with rootkit techniques.Perhaps if on startup the game would make a short record of the current processes running on the computer, and analyze them to detect if any are attempting to edit the game's process. If nothing's detected, then nothing will happen. However, as long as the game is running, if another process is started up, the game will immediately analyze it and make sure it is not accessing data from the game (exceptions will have to be made on things like antivirus software), and if it seems harmless enough, then the game will continue without a hiccup, as if nothing happened.
In almost all modern games it is the SERVER doing the hitbox detection and not the client. In that case the client does not need to know about any hitbox at all.What would happen under circumstances where you shoot people who are not visible? Around the corner splash damage, through-wall shots, etc. You still need hitboxes there despite not being visible.
But if there's latency you need a hack for this problem anyway as it's trivial for two people to occupy the same space.Client still does hitbox collision detection when doing predicted movement. Can't have predicted movements allowing players to move through each other... looks kind of wrong. It may not be the same hitbox used for detecting weapon hits but it's still a hit box and is likely to be bigger and simpler then the weapon hit box if they differ.
The hacker would simply store the commands to the previous frames and re-render the requested frame without cheats and hack the timestamp as needed.Well, all what needs to be done, is to ask client for copy of screen data that had already been rendered before it received the request.
The requests and image data can be time stamped by server and driver. The driver can store some amount of previously rendered frames. We don't need to look back in time further then half ping time. With reasonable framerate and ping, this would amount to a handful of frames.
Yes, size of image data makes practical solution harder, but not impossible (as I said: scissor it, scale down, skip n-th frame, etc.)
Sure, the hacker can artificially increase perceived ping, and even disable wallhacks for a single frame. However, a client who seems to experience strange lag spikes occuring in coincidence with the server's request, could be easily marked as suspicious.
The hacker would simply store the commands to the previous frames and re-render the requested frame without cheats and hack the timestamp as needed.
The hack would just change the time stamp to whatever it needs to be to look new. The video driver surely isn't going to be sending off the screenshot, so you're counting on game code to do the sending, and we've already assumed it's been compromised.The driver timestamps screenshots when it stores them, not when it retrieves them. If hacker's re-rendered old scene for the screenshot, as you are describing, it would get older time stamp then the legit one.
The good news for the hacker is that with something the size of a full-resolution screenshot, the average ping is goint to be a many times longer than it would be normally.As I said previously, the difference would be about interval of ping. In worst case, the fake screenshot it would arrive to the server with relative age twice older then expected. The server, by keeping statistics of client's ping before the request, can detect this.
Memory isn't really the biggest constraint here.This is a tradeoff: we want the server to request as old screenshots as possible, but we also want the driver to not waste too much memory for the screenshot history storage.
How well would that work in complex environments?For wall hacks and other information leakage issues, one can burn server resources, compute fine-grained visibility per client, and occlude information from the prying eyes of hacked clients (by not sending information giving the position of enemy entities if they are not visible)
That system could be circumvented by an aimbot that the player can activate only at certain times. I guess over-eager cheaters would be caught, but who's to say if that last-second victory shot was just lucky or a cheat?For aimbots, there isn't really a good solution. One could use statistical methods to analyze the distribution of hit locations and accuracy as compared to a large number of human sample players and look for tell tale signs in the distribution, or one could download aimbot hacks, run them through a number of sample trials, and compute the hit distribution, and then use this as a "fingerprint" that is provided to other servers to detect hackers.
Although, to be truly effective, they'd probably have to make the aimbot less accurate as well, which would make it less of a threat. I wouldn't care if a n00b used aimbots if it was only as good as the very best human players. I'd care if it was better than the best human players could ever be.
Wall-hacks could be curtailed, but unless the resolution of visibility calculations is about as fine as a GPU's Z-reject, it's possible to occlude too much information. Maybe an enemy's shoulder is poking outside a door frame. The danger of having that information hidden would depend on just how intensively the visibility information is processed by the server.
That system could be circumvented by an aimbot that the player can activate only at certain times. I guess over-eager cheaters would be caught, but who's to say if that last-second victory shot was just lucky or a cheat?
Using a so-called "representative" test set would also be problematic, because it would have to span a population of players who range from very bad to almost aim-bot good.
Dynamically updated values are problematic because they can become biased to one extreme or the other, and are vulnerable to sudden changes in overall accuracy.
If the Bayesian filters are adjusted according to a given game's players, then a cheater could actually exploit it. If the filters think a given level of accuracy that is x% above average is enough to flag a cheat, then a cheater could just play very badly and get the better players kicked.
There are countermeasures and counter-counter measures, but I'd probably leave any final determination of cheating up to the guy running the server.
You are making assumption that the driver shoots itself in a foot. We are talking about driver that uses cryptography to protect the image data from modifications. Why do you think the driver would refrain itself from applying the same protection to the time stamp? It's against logic.The hack would just change the time stamp to whatever it needs to be to look new. The video driver surely isn't going to be sending off the screenshot, so you're counting on game code to do the sending, and we've already assumed it's been compromised.
I've already adressed it. There are many possible ways to reduce size of the image data, and you don't need to upload them in one, continuous burst.The good news for the hacker is that with something the size of a full-resolution screenshot, the average ping is goint to be a many times longer than it would be normally.
It takes a lot longer to download a multi-megabyte file than it takes to render the frame in question.
You didn't quite understand. The time of arrival at server doesn't affect the embedded timestamp. The server can estimate expected timestamp before it even makes the request, so it isn't affected either.The margin of error for the server to reject a frame may be only a few percent, and anything can make a legitimate upload take just a little longer than usual.
Again, you insist on assuming the dumbest possible implementation and ignoring obvious better options.Memory isn't really the biggest constraint here.
Getting a file the size of a full frame buffer to upload, analyzing the image, and having the server recieve all this data and do all this work for multiple players who are all sending multi-megabyte files at the same time is the biggest problem.
You are making assumption that the driver shoots itself in a foot. We are talking about driver that uses cryptography to protect the image data from modifications.
Agreed.In the absense of hardware trusted computing, no software tamper resistant mechanism is resilient to hacking. Cryptography is irrelevent. I cracked games on the commodore 64 that used cycle-timed decryption/reencryption bootloaders, so that only 1 instruction was ever in plaintext and only "just in time" when the PC was pointing at that address. That was 20 years ago. Cryptography does jack shit when I have access to step through the decryption routine.
YESAgreed.
About the only thing that would remove the ability to cheat would be DRM hardware but can anyone see that being an accepted approach?
But the XBOX wasn't really a full hardware solution. It still used a standard CPU so unencrypted code still existed outside of the CPU.YES
Heard of the xbox lots of people bought that hardware. They'll buy it for PC too just you wait and see.
All this happens locally, so it's circumventable.You are making assumption that the driver shoots itself in a foot. We are talking about driver that uses cryptography to protect the image data from modifications. Why do you think the driver would refrain itself from applying the same protection to the time stamp? It's against logic.
I'm also interested in how long you think it takes to encrypt a multi-megabyte file, then compress it, and then upload it.I've already adressed it. There are many possible ways to reduce size of the image data, and you don't need to upload them in one, continuous burst.
So it all rides on a time-stamp the server has to assume wasn't just created to look valid. The server can't reliably estimate a timestamp either. System timers aren't that precise. A good hack could quite possibly fit within the same millisecond or very close to it.You didn't quite understand. The time of arrival at server doesn't affect the embedded timestamp. The server can estimate expected timestamp before it even makes the request, so it isn't affected either.
Again, you insist on assuming the dumbest possible implementation and ignoring obvious better options.
How do you decide what parts of the framebuffer are relevant?You don't need to upload full framebuffer.
Unless you plan on analyzing only every couple thousand frames, multiple players will be evaluated concurrently. There's a lot of data being thrown around, and you haven't explained just how often it should be examined, or how you expect it to be examined.You don't need to analyse nor receive data from multiple players at the same time.
Analyzing the image can have fast early-exit (subtract 2 images and compare result against threshold, using occlusion query)