Cheat detection methods

by wolfric on 05/21/2011 22:47, 32 messages, last message: 08/31/2011 07:17, 11264 views, last view: 05/18/2024 12:25

So some stuff in cube 2 will get detected like running too fast or jumping too fast. Other stuff like low gravity, edit mode, aim/trigger bots/ respawn hacks etc are not.

I was wondering if anyone wanted to brainstorm on methods to detect these (even if those methods could potentially make the server a little more heavy weight).

I've seen detections implemented for the edit hack and the respawn hack. Could these ideas be integrated into the main server code?

Some of these detection methods might take up too much processing power especially as your userbase grows. What about having some of these checks not actively checking everyone at once. So if you have pretty heavy methods of checking, you just cycle through a list of players and test a random new player each time.


For the trigger/aim bot, i can think of a few however none you could get around or potentially have a false positive here and there. You could do statistics on where the person is aiming vs how long they have been aiming before they shoot each time. I was toying with the idea of drawing a fake player in front of the player and seeing if they fired on it. Either by having a map specifically set up that you couldn't see behind a certain area or having a model that is just blank (that only the server can send in this case, normal players can't have it).

Gravity/flying: I'm not even sure how much knowledge the server has of the map. If the server does, then it might be easier to detect this sort of thing but otherwise you wouldn't know if they were flying or just in a large pool of water.

Speed hacking: again, same as before, does the server actually have any knowledge of the map? As those ..bumpers? that bump you up into the air could lead to false positives.

   Board Index   

#1: ..

by degrave3 on 05/22/2011 15:08

Correct cheat detection is just impossible on server side.

reply to this message

#2: ..

by Papriko on 05/22/2011 17:05

Speed Hacking might be detectable. When I remember right, the server knows where ents are on the map.
It should be possible to detect when you accelerate abnormally strong and compare that with the locations and directions of jumppads. Afterwards it could be compared with the strength of an explosion or a rifle jump or something. When it matches, okay.

When the stuff above works, then probably also gravity and flying. You just need to know the location of water in addition.

reply to this message

#3: Re: ..

by Sub-Zero on 05/22/2011 19:50, refers to #1

Wrong, you could re-work all the server side stuff to where it can be, but its too much of a pain in the ass, that no one will do it.

@wolfric and papriko, i do happen to have a hack detection mod on my computer, but its so untrustworthy that i never released it. things such as, instant respawn, teleportation/speed hack can be detected by the teleportation detection (however if you or the other person has really bad lag, or even lag enough passed 300 ping, it may say they teleported. also i have a detect "bad aim" which looks for when people don't really aim, but also can be conflicted by lag. hence the reason i cannot release it because none of it can accurately work unless people's ping are down, and even if someone pulls off a show without aim, it still may not be a hack, which is why i am always careful of what i see.

overall, a hacksheild can be implemented, but its such a pain in the ass, the best way to rid the hackers is to rid the source code. and even then, you'll have a few hackers here and there.

a third option is to release a hacked client on the sauer homepage that is separated from the real sauer, that way hakers can't F with us as much since they don't have it.

reply to this message

#4: ..

by wolfric on 05/23/2011 16:18

It's not about making it 100% hack proof but getting closer to it.

Of course a little leeway is a good thing. If in ctf, obviously an instant respawn is a hack, if you have it about 0.5-1 second too fast, i'd even let that slide depending on the ping or game. I guess you could just sample a bunch of clients and see what they normally give out.

On the speed,jump hack. There are limits of course, If however you jump from one side of the map to the other within a few seconds, it's obviously hacking.

@Sub-Zero Really disagree with you there. I'm glad the game is open source. I've seen lots of great mods (ranging from stuff on cube 2 to complete remakes) and i'm very much pro open source. Sure that might be fine for let's say leagues or competitions where they release a binary 20 mins before the game or something but the whole reason i play cube 2 is BECAUSE it's open source.

Also, you should release your work as a "alpha" work. If people saw there was already work done, they might just play around with what you've got and add to it.

Trigger/aim botting would be the hardest, someone COULD (although not likely) but just THAT good. I'm doing exams at the moment, but it's something i wouldn't mind playing around with further over the summer.

reply to this message

#5: Re: ..

by Razgriz on 05/23/2011 21:41, refers to #4

A good way to prevent trigger bots would be to force consistent keystroke checks. In more detail:

The plan is really simple, the execution may be not. However, such bots rely on "weird" methods to track players and shoot when applicable. All you have to do is to force the game to accept a call for shooting only when the specific key is pressed. In simpler words, if you ain't clicking, you ain't shooting.

In response, the client could deny all shooting actions, and also report to the server that it has been compromised so as to kick the client out. This could backfire, since a call like that would probably be easy to block out from being sent in the first place, but supposing the block-all-attacks client-side measure is robust enough to withstand simple hacking attempts, it's probable that it will discourage many young coders from making triggerbots.

The same way an aimbot could be prevented, supposing the camera would only move when the mouse is moving in accordance as well.

--

There are still details to think about, but that's pretty much the bulk of that problem, and a partial solution.

reply to this message

#6: ..

by wolfric on 05/23/2011 22:54

No any methods HAVE to be server side.
You could easily just remove that check client side.

reply to this message

#7: Re: ..

by Razgriz on 05/24/2011 15:48, refers to #6

Fooling the server is easy, plus it would probably be easier to nullify any checks done by it, supposing the functions that contact the server back have been altered. If you can make the client \"break\" should a bot be used, then you can pretty much join the countermeasures with the ones you made for the server.

The point is, clients connecting over the internet lag. The connection is not perfect, and there is no small amount of people who use that lag to their advantage when it comes to evading detection. Lagproof methods are your best bet if you want the most effective detection.

reply to this message

#8: Re: ..

by peeler on 05/24/2011 17:45, refers to #7

What makes you think that tricking server-side checks is easier than simply removing client-side checks and recompiling? The only way you can make client-side cheat detection even slightly difficult to defeat is by obfuscation, which would be very much against the spirit of an open-source game.

reply to this message

#9: ..

by degrave3 on 05/24/2011 21:31

Current master system is best way to fight against cheaters for open source game.

reply to this message

#10: Re: ..

by Razgriz on 05/24/2011 23:15, refers to #8

really, making client-side protection is fucking USELESS if it's easy to remove, and it doesn't take much brains for anyone to figure that out. No cookies for you.

For an efficient system, you'd have to rig the whole game. I remember a games coder who had participated in the making of Spyro 3's protection system created an article explaining what had be done in order to create such a bulletproof protection that took crackers more than 2 months to find a countermeasure that would work. And we're not talking about skimpy first-time coders trying their luck here.

http://www.gamasutra.com/view/feature/3030/keeping_the_pirates_at_bay.php

reply to this message

#11: Re: ..

by peeler on 05/25/2011 00:08, refers to #10

Let me get this straight.

First you suggest a vaguely defined client-side method of cheat detection. You suggest only the type of violations to be detected, not the way in which this additional cheat protection code would be made any more secure than the rest of the client.

I reply that such a detection method would be just as vulnerable as the existing code, and mention that only through obfuscation could it be even marginally effective.

You reply, rather angrily, that you are aware of this problem and that it should be rectified by making the protection difficult to remove.

Ok, so at least we're on the same page here. But you *can't* make the client difficult to modify in an open source game. The article you linked is mostly about obfuscation - they mention making the code especially difficult to debug, having it behave in unexpected ways when breakpoints are used. Good luck finding contributors to a project when that project is designed to be as difficult as possible to change. Some of the techniques mentioned are just completely irrelevant when the source code is available - for example, inlining checksum calls certainly makes them more difficult to find and modify when hacking decompiled binaries, but is transparent in the original source.

The types of protection seen there are also ineffective in the long term. They don't secure anything, they just slow down the hackers. That's all that's needed for a commercial single-player game, since most of the sales are going to be made within the first couple months anyway. Obviously, that's not the case for a multiplayer game, let alone a free one - the goal is to stop cheaters in their tracks for as long as legitimate players still enjoy the game.

What's more, even if the client was made closed source, the network protocol is always going to be visible, and checks as you've suggested that assert the correct keyboard/mouse inputs are actually being provided for each action can always be subverted by a proxy program that adds in false hit messages.

The player-enforced anticheat Sauerbraten has now via the master system is a simple and suitable solution given the size of the community. But if someone *was* going to implement more sophisticated, automated cheat detection, it would have to be done on the server.

reply to this message

#12: ..

by Razgriz on 05/25/2011 00:40

It wasn't my point to suggest a definite protection system, nor to follow that article step by step, since that won't earn us anything. I'm not an actual coder either, so i won't really know what would be actually effective until someone proves me wrong, and so my only contribution is to suggest possible ways that might help others more knowledgeable to brainstorm the issue.

On another case, as the article says, stopping crackers is impossible, and slowing them down, as you said, won't work in a multiplayer game. But, you could, somehow -- details i do not know of, break the game should something not match up. It is not necessary to go into as much depth as those guys went, but i think a few principles are perhaps up for adoption. There isn't need for the whole game to be rigged, rather than a few wanted portions that are to be remain untouched by common people; dev modifications only.

How to make code secure? Perhaps it's somewhat explained in the article. Perhaps there is no way. But supposing you do the process of bypassing or removing the protection a long and hard one, and at the same time let the server know when a client is compromised, then you've scored points.

However, i've seen options (not in the game) about input. Some of which are direct hardware reading or through Windows messages. How could mouse messages be bypassed, supposing direct hardware calls were read? Is that even possible to tell the truth, are there compatibility issues? I've read things but not many details on the matter..

--

Server side protection offers some better chances, but then again there are pending issues, and i believe it wouldn't be hard to reject or return false calls to its checks by a modified client.

reply to this message

#13: Re: ..

by Sub-Zero on 05/26/2011 00:50, refers to #12

aside from the fact your all making the same stupid mistake and also writing a book (since its last few posts have been larger then billy joe bob\'s incest family)

lets think like smart people and take our heads out of our butts (image in-closed for viewing: http://evolutionforum.info/yabbfiles/Attachments/head_up_your_ass2_002.jpg) (once again i say this because none of you think about how it should work, not like this is going to happen anyways) a 3-way hack shield, 2 server side hack shield\'s, and one server side.

the server checks all clients.

one of the client side\'s checks the client

the other client side one checks other clients.

like i said, stop herp derping

reply to this message

#14: Re: ..

by Razgriz on 05/26/2011 09:27, refers to #13

Perhaps you should do the same, for it's not a good idea to have each client constantly scan one another to search for any discrepancies. Apart from the fact that doing such would take time over the internet, the load would also take its toll on all players connected. It's a no go.

reply to this message

#15: ..

by wolfric on 05/27/2011 14:00

Razgriz... scan players? bandwidth?
Think you're getting the wrong end of the stick here. This isn't like physical battle ships scanning each other in real life.

You only connect to the server. You're not talking to the clients directly.

The server sends you information on all the other players on the map such as where they are where they're aiming etc.

You can use the distributed power of the clients computing to run sort of checks on them to see if their actions seem rather odd (like they just jumped 100 meters into the air in the blink of an eye without touching a jump pad etc)

reply to this message

#16: ..

by wolfric on 05/27/2011 14:02

Sorry for double post, didn't mean to post the first one so soon hadn't finished writing.

Sub-Zero: spot on.

Has anyone played around with any of hopmods cheat detection scripts? Or any others for that fact? Any false positives etc?

reply to this message

#17: ..

by Hanack on 05/31/2011 14:38

wolfric: on nooblounge we have a mostly successfully working speedhack detection. It's based on statistic methods and it's fault tolerant against lagging, jumppads and teleporters. Effective cheat detection should definitively be done on server-side.

reply to this message

#18: ..

by mefisto on 06/12/2011 04:50

Let's define the problem a little better. You can divide cheats into two classes: Easy to detect either by humans or machines, and hard to detect.

Easy to detect:
Float cheets, speedhacks, editmode, most maphacks

Hard to detect:
Wallhacks, aimbots, autoshoots

In my opinion, the hacks that are easy to detect are solved reasonably well already. The auth system combined with the automatic detection systems present in most popular sever mods take care of them acceptably well.

It's the hard to detect hacks that are the real problem. To deal with them on the client side is pretty impractical, because you have to choose one:

1. Client-side protection
2. Open source game

I think that server side protection may be possible for hard to detect. However I don't think it should be open source. It would be very hard for the server to detect these types of cheats, and it would probably be pretty easy to defeat that protection if attackers knew how the mechanism works. So I would say that anything that's done on this should be done behind closed doors.

reply to this message

#19: Re: ..

by Sub-Zero on 06/13/2011 02:46, refers to #18

wrong. aimbot\'s are easy to detect, and so are triggerbots. and if you are a good hacker, you can know how to not be seen with floating hacks, ect. you are so wrong, it makes my head want to burst.

and server\'s cheat detection mods only work oh so well. if you read what i posted above on number 13:

\"the server checks all clients.

one of the client side\'s checks the client

the other client side one checks other clients.\"

please read the current post\'s.

reply to this message

#20: Re: ..

by Razgriz on 06/13/2011 12:53, refers to #19

So your suggestion is recurring global client integrity checks? I could think of a few reasons why that would a problem but i'm not feeling all that comfortable with your attitude when on a forum.

So i'll post a few "tags" that will indicate my thoughts.

CRC, hack, size, lag, amount, intervals, clients, chances, multiple, server

reply to this message

   Board Index