Why don't GPUs assist in preventing online cheating (hacking) in games?

[Brimstone]

For hackers the display is the computer. Without additional visual information displayed hacks are pointless and easily detected. A hack that causes a gun to do more damage is pointless and should be easily detected. The devestating hacks that seem to plague online games like Counter-Strike give players more information to make near perfect decisions.


Why can't GPU's moniter the pattern of pixels displayed and compare it to a norm? For example a person with a type of wall hack is going to have more translucent pixels being displayed compared to a person that doesn't.

Lets say hackers get sophisticated on only start to turn on their cheats for a few seconds at a time, well it should be easy to detect abnormal spikes in the type of pixels rendered.

The pixel rendering pattern should be different from a non-hacked game.



I'm not suggesting that the GPU data automatically leads to declaring a hack, but it seems to me the data could be used as a red flag to raise concern that something suspicous is going on and further investigation is warrented.

 

[Tim Murray]

Because the cost is prohibitively expensive (computationally), the bandwidth requirements between CPU and GPU are insane, and you wouldn't be able to differentiate between a hacker and someone who's using a custom UI.

 

[Geeforcer]

Benefit to the potential purchaser of a video card = 0.
Drawback to the aforementioned potential customer = Degraded perforce due to the overhead

No video card company is going to spend money developing a "feature" that will, if anything, hurt their sales.

 

[Humus]

Well, you could use occlusion queries. Or some other hardware counters. It's should have little to no impact on performance. I think the bigger problem is that if the hacker could find a way to disable the depth test for a wall hack, then surely they'd be able to override these checks as well.

 

[Bouncing Zabaglione Bros.]

Would have little to no impact on a lot of hacks out there such as aimbots, doctored skins, removal of smoke/fog, speedhacks, etc.

 

[Brimstone]

Would have little to no impact on a lot of hacks out there such as aimbots, doctored skins, removal of smoke/fog, speedhacks, etc.

For a game like a RTS like Starcraft aimbots have no impact. A player being able to circumvent "the fog of war" by map hacking thus showing the entire map is a huge advantage. When a person map hacks like this, the GPU is rendering those pixels.

I'm not suggesting that a hacking can be prevented by GPU analysis. I'm just speculating/wondering if things could be done to make the GPU a valuable tool to game developers when it comes to hacks. Especially those that are dependent on displaying information to the hacker. That display pattern will leave a different pixel footprint.


As far as aimbots, I'm suprised some type of encrypted mouse and keyboard hasn't be created to insure legitimate output. Sort of a mouse made with a security chip inside that can be verivied by a server connection. A security chipped mouse and keyboard combo designed specificaly for gaming. When you log into the game you have the option of filtering out all non security chipped keyboards and mice players.

 

[rwolf]

For a game like a RTS like Starcraft aimbots have no impact. A player being able to circumvent "the fog of war" by map hacking thus showing the entire map is a huge advantage. When a person map hacks like this, the GPU is rendering those pixels.

I'm not suggesting that a hacking can be prevented by GPU analysis. I'm just speculating/wondering if things could be done to make the GPU a valuable tool to game developers when it comes to hacks. Especially those that are dependent on displaying information to the hacker. That display pattern will leave a different pixel footprint.


As far as aimbots, I'm suprised some type of encrypted mouse and keyboard hasn't be created to insure legitimate output. Sort of a mouse made with a security chip inside that can be verivied by a server connection. A security chipped mouse and keyboard combo designed specificaly for gaming. When you log into the game you have the option of filtering out all non security chipped keyboards and mice players.

http://www.dailytech.com/article.aspx?newsid=4624

Your wish is granted. I have made it so. See link.

 

[CouldntResist]

What we need is a mechanism for making certified screenshots, done with cooperation with the gfx driver. Consider this:

1. game server:
(at random moment) "I command you, client #1337, to make screenshot NOW"

2. client #1337:
calls g_pDirectAntiHack11->MakeScreenshot(&ppBuffer, &dwSize)

3. client #1337's DirectAntiHack11 module:
makes copy of the diplayed surface, then compresses, encrypts, and returns it.

4. client #1337:
"Ok server, here's your screenshot" (sends contents of the buffer)

5. game server:
receives the screenshot, decrypts it, and compares with expected image (which it can simulate, knowing #1337's settings). If the images differ too much, the server alerts PunkBuster ninjas to investigate the case.


The "DirectAntiHack11" API could be agreement between Ati + Nvidia + PunkBuster (no need to ask MS, who would obviously make it Vista exclusive )

We want to prevent the hacker from reverse engineering encryption algorithm/keys. Therefore, the "DirectAntiHack11" should be buried deep in gfx drivers. Like, use some data stored in card's BIOS. The driver could also scramble the image data using some GPU program, which never leaves the card (it can't be supplied by client code)

More sophisticated technique would be when the server generates randomized small checking procedure and/or scrambling shader, which is sent to clients. The hacker can disassemble code all he wants, but what if the code fragment is changed, say, every 30 minutes?

Since screenshot data can be quite big, we might want to scissor it to some region(s) of interest (again, at the will of server). Additionally, we might postpone transfer of the data till the round ends and next level is loaded, or when the player in question is waiting for respawn.

 

[Fruitfrenzy]

As posted previously all of these suggestions will cost hardware and driver developers time and money without offering anything in return.

Private APIs could possibly work but they require implementation and testing which requires time and money. Not many companies have so much spare resource that they can afford to do this kind of thing when no one is willing to pay for it.

 

[Dio]

What we need is a mechanism for making certified screenshots, done with cooperation with the gfx driver. Consider this:

1. game server:
(at random moment) "I command you, client #1337, to make screenshot NOW"

2. client #1337:
calls g_pDirectAntiHack11->MakeScreenshot(&ppBuffer, &dwSize)

3. client #1337's DirectAntiHack11 module:
makes copy of the diplayed surface, then compresses, encrypts, and returns it.

4. client #1337:
"Ok server, here's your screenshot" (sends contents of the buffer)

5. game server:
receives the screenshot, decrypts it, and compares with expected image (which it can simulate, knowing #1337's settings). If the images differ too much, the server alerts PunkBuster ninjas to investigate the case.

The problem with any technique such as this is the chain of trust.

If your software stack is not completely trusted from top-to-bottom then you can't prevent cheating. For example, in the example given above, the client can easily turn off its optimisations for one frame and then return the screenshot unless you can trust the client, but since the client machine verifies the client, you can't verify the client. If you see what I mean. Only a known-incorruptible component can verify the client, but in the ecosystem of a PC, that probably implies all kernel-mode components need to be trusted...

A completely trusted software stack is impossible until at least TPA rollout (which is something I'm far from convinced is a good thing), and even then only a single compromised component might allow the potential compromise of any component running at a lower security privilege.

Or put it another way: while viruses exist and games can have copy protection removed, it will always be possible to cheat, and anyone predicting that viruses can be eliminated or copy protection will triumph is, to say the least, an optimist. The best that can be done is to raise the barrier (to infection, to copying, to cheating).

Which is not to say that some screengrab method is not feasible... but I don't think it helps to do it on the server instead.

I haven't even considered the hit of sending a 2560x1600 (even compressed) image back to the server either .

Same argument goes for the security-chipped keyboards and mice as well.

 

[Sxotty]

It is a terrible idea. The GPU should not do this. It would inevitably have bugs and screw up things that should work, not to mention make it so developers would have things messed up. Maybe they could have two driver versions or something, but that is a waste.

Play with people that dont cheat.

 

[CouldntResist]

The problem with any technique such as this is the chain of trust.

If your software stack is not completely trusted from top-to-bottom then you can't prevent cheating. For example, in the example given above, the client can easily turn off its optimisations for one frame and then return the screenshot unless you can trust the client, but since the client machine verifies the client, you can't verify the client. If you see what I mean. Only a known-incorruptible component can verify the client, but in the ecosystem of a PC, that probably implies all kernel-mode components need to be trusted...

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.


Anyway, these are merely details, the key element is gfx driver support.

I was once looking at PunkBuster's log (trying to make Americas Army work), and I was under impression that it already performs some screenshot analysis. If the checks are done on the client side, they can be neutralized by hacker. If the checks are done on the server side, hacker can forge screenshot. However, if the screenshot is "digitally signed" by the driver, it's impossible.

The only way I can imagine to circumvent it, would be if hacker had 2 computers, and replicated all rendering commands on the twin, through LAN. One comp would run "legit" client (with hacker ignoring its display), and the other would display wallhacked view.

A completely trusted software stack is impossible until at least TPA rollout (which is something I'm far from convinced is a good thing), and even then only a single compromised component might allow the potential compromise of any component running at a lower security privilege.

The TPA/Palladium/NGSCB/LaGrande/its-for-your-good-honest-(TM) would do the job, but it's highly controversial. Besides, tt's like dropping a hydrogen bomb on a small village.

 

[Dio]

I agree with your last comment; which is why I think it's not worth it. The problem's exactly the same for virus scaners, which is effectively what Punkbuster, VAC etc. do - look for known attack signatures. However, the online games at least have the advantage that with centralised servers like Steam, they can permanently lock out an account.

The history of the AV industry shows that complete defence based on heuristic-based scanning is impossible and it is similarly impossible to do so in the anti-cheat community.

 

[CouldntResist]

As posted previously all of these suggestions will cost hardware and driver developers time and money without offering anything in return.

It would help to sustain the market for their $600 cards. Hacking on PCs is orders of magnitude easier than on consoles.

One might as well say that hiring playboy model in order to make a bunch of useless demos doesn't offering anything in return, yet Nvidia does it

Private APIs could possibly work but they require implementation and testing which requires time and money. Not many companies have so much spare resource that they can afford to do this kind of thing when no one is willing to pay for it.

I don't know about ATi, but Nvidia already provides a "private API" - it exposes some card/driver fuctionality which doesn't belong to neither D3D nor OGL. The only necessery step further than this, would be agreement between IHVs. I also doubt a small API for making "digitally signed" screenshots would be anything but a drop in a sea, in terms of costs and support.

 

[3dilettante]

For a game like a RTS like Starcraft aimbots have no impact. A player being able to circumvent "the fog of war" by map hacking thus showing the entire map is a huge advantage. When a person map hacks like this, the GPU is rendering those pixels.

A GPU is rendering from a list of commands and data supplied from the CPU. It knows absolutely nothing about how a certain set of pixels was calculated and whether they would be valid given the rules the CPU is charged with enforcing.

There's nothing in the data that says the user didn't actually explore that area properly. There is no game-world data, no game history, no record of player input.

That display pattern will leave a different pixel footprint.

So does displaying the next frame. It's like guessing whether a person likes spaghetti based on the fact his house has bricks. There is no data path that can be followed.

As far as aimbots, I'm suprised some type of encrypted mouse and keyboard hasn't be created to insure legitimate output. Sort of a mouse made with a security chip inside that can be verivied by a server connection. A security chipped mouse and keyboard combo designed specificaly for gaming. When you log into the game you have the option of filtering out all non security chipped keyboards and mice players.

What good is that? That can easily be emulated, or the secure device's inputs will be preempted. Aim bots don't change what the mouse or keyboard input, and that's all that the encryption can protect against.

 

[Ryan D]

It would be an interesting thing to have - but I'm sure that it would decrease performance during gameplay. Now, from personal experience playing against hackers in games like CSS and UT2004, I know how annoying they can be. But the truth is that there are hundreds, even thousands of other servers out there that you can go play on.

I have a different anti-cheat method, though. 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.

I do not know how much CPU it would take to analyze any processes that are run during gameplay, but if it doesn't take too much, it's a possibility (I think).

 

[CouldntResist]

It would be an interesting thing to have - but I'm sure that it would decrease performance during gameplay.

Let's say you sacrifice 5% of video memory for screenshots storage. Also, each frame you run a post processing shader, cost of which is fraction of cost of bloom filter.

Finally, there comes cost of transfer from client's video memory to server. Fortunately, you don't have to do it every frame.

So, decrease of performance - yes, but not a big one.

What good is that? That can easily be emulated, or the secure device's inputs will be preempted. Aim bots don't change what the mouse or keyboard input, and that's all that the encryption can protect against.

If aimbot wants to aim, then it must send to server mouse movement data different from those that the mouse actually produces. However, if server required the data it receives are digitally signed by the mouse driver, any modifications done by the aimbot would be useless, as for game it only matters what happens on the server.

Unfortunatelly, this can't be done without changes in Direct Input.

 

[DemoCoder]

The assumption of this thread is that cheating is a graphics problem. It's not. It's a problem of leaked information. Today, "wallhacks" work because the servers depend on clients to properly sort and occlude things which should be occluded from the user client's POV. However, even if the client properly implements this (no wallhack), the information is present in the network protocol and external logic (outside rendering) can use this information for aiming, advanced warning, "eyes in the back of your head", illegal radar, et al. In a game like counter-strike for example, I don't even necessarily need a wallhack to have a massive advantage. Simply showing on radar, or via overlay, where someone is camping (who for all intents and purposes should be invisible), is a massive advantage. It doesn't need to show exactly, just knowledge that an enemy is near, and a compass direction is enough.

For example, if hacking into the CS network stream allowed another program to overlay a reticle with little arrows that light up in compass directions showing enemy locations (who are hiding), I would cleanup. On many maps, I'd know which path to the bombsite is unguarded for example, in the initial rush.

There are CS hacks out there which used audio positional data in the network stream to shot you predicted movement and location of enemies from footstep information that you would not normally be able to hear, even at maximum volume.


Although it would be very computationally expensive, the only truly secure non-wallhackable "omniscient" information system would require the network protocol to be unconditionally secure (not through obsecurity), which would essentially require the server to compute fine-grained visibility information for each client on the server, and only send information to clients which is predicted to be visible to clients in current, or upcoming ticks.

There would no wallhack, or map hacks possible with such an uber-server, since you would never receive positional data for enemies which are occluded, however it would still not stop aimbot hacks which can use either visible and known enemy positions (from the network protocol), or, which worse case, take a screenshot of the current frame and use image recognition techniques to compute the position of enemies (some CS aimbots did this, by coloring the enemy helmets with unshared fullbrite red/green/blue helmets, and then searched the framebuffer for pixels with these colors to get headshots)

Eliminating aimbots would require 1) preventing access to the network protocol or internal datastructures of the game client which know the position of enemies in view and 2) preventing framebuffer techniques which use screenshots + image processing to compute enemy locations.

However, even assuming software/hardware techniques existed to do this, sophisticated hacks would use VGA/DVI capture, or, highspeed webcams to just screenshot the framebuffer optically, feed this into the cheat program, and adjust mouse accordingly.

I don't think the "trusted mouse hardware" approach will work from a marketing/customer perspective, just like the movie industry couldn't require HDMI/HDCP to be used for HD movies and backed off implementation of the ICT + allowed HD component video.

 

[RejZoR]

So what would happen when user all the sudden gets artefacts because of heat or something? Bam, kicked (or even better, banned) out of the game, preferably in the middle of clanwar...

 

[3dilettante]

Let's say you sacrifice 5% of video memory for screenshots storage. Also, each frame you run a post processing shader, cost of which is fraction of cost of bloom filter.

Finally, there comes cost of transfer from client's video memory to server. Fortunately, you don't have to do it every frame.

Analysis of screen shots would require some serious computation work on the part of the server. Even doing it for one player would be seriously difficult.
You can't just compare screen shots and say they're different, since the frame will be different if the player's not standing still in a completely dark room.

I'd also comment that sending a multi-megabyte frame buffer to the server for every player is going to send pings sky-high.

If aimbot wants to aim, then it must send to server mouse movement data different from those that the mouse actually produces. However, if server required the data it receives are digitally signed by the mouse driver, any modifications done by the aimbot would be useless, as for game it only matters what happens on the server.

The server is not fed mouse input directly. Input is interpreted by the local instance and updates are sent to the server. The data is going through the CPU, which is all that is needed to expose the server to software trickery.

Failing that, it would probably take a week for someone to design a program to spoof the server, and all that leaves us is a permanently slower game connection.