Anti-Cheat?
Sneakpeek
Join Date: 2007-06-20 Member: 61321Members
Join Date: 2007-06-20 Member: 61321Members
What are UnknownWorld's plans for Anti-Cheat in NS2?
I have never seen this been discussed anywhere, altough I might have missed it.
Will you be using VAC, PunkBuster, creating your own or perhaps none at all?
Another concern is lua hacks.
Will there be any protection against creating bad client side lua mods?
In Garry's Mod for example, which uses lua just like NS2 does, some people have actually made client side aimbots entirely in lua alone.
Discuss.
I have never seen this been discussed anywhere, altough I might have missed it.
Will you be using VAC, PunkBuster, creating your own or perhaps none at all?
Another concern is lua hacks.
Will there be any protection against creating bad client side lua mods?
In Garry's Mod for example, which uses lua just like NS2 does, some people have actually made client side aimbots entirely in lua alone.
Discuss.
Comments
Mostly about moaning about illusion called cheaters but theres another thread yea.
We don't need NS2 to install a root kit. It's annoying and I've had too many games intercept visual studio as a hacking program. Screw you, I'm doing homework.
Anti cheat can go a long ways with simply not allowing the client to execute arbitrary lua not provided by the server as well as providing file consistency checking so models cannot be replaced to assist aim bot and textures cant be replaced to provide wall hacks.
That way making a wallhack will be impossible because the hack has no way of getting information about enemies behind walls, because that information is simply not sent to the hackers client.
They use exactly this method to counter maphacks in Heroes of Newerth (a standalone game based of DotA on Warcraft 3).
Information about enemies that are not visible to the player are simply not sent to the client, and therefore maphacks are impossible to create.
Codewise it goes something like this:
if(is enemy visible on clients screen?)
{
send information to client
}
else
{
if(does the client have motion tracking/scent of fear?)
{
send information to client
}
else
{
dont send any information
}
}
Aimbots are impossible to block as far as I know, but I have a suggestion for how to detect one.
You check if a players angles turns very fast from one point to another and "snaps" onto a target.
Say if you are changing your crosshair from A to B.
It would go something like this.
"x" represents where the mouse stops/updates along the way
A - - x - - x - - - - - - x - - - - - x - - - - B
Nobody can make a perfect turn from A to B without having the mouse having a few "stops" along the way
Where an aimbot would go like this instantly with no stops along the way:
A - - - - - - - - - - - - - - - - - - - - - - - - B
Also, if the players crosshair "snaps" onto a players hitbox after making an instant turn like that, you can be pretty sure he is using an aimbot.
This could of course produce false bans on rare occasions, so my suggestion would be to check for this type of "instant turn and snap on target" atleast 3-5 times before you ban someone.
I realise there are ways to bypass this, such as having a "smooth" aimbot that doesnt instantly turn to the target, but hey, its better than nothing I quess.
Speedhacks shouldnt be too hard to detect either.
You simply check if someone moved from point A to B faster than they should have.
Say someone has a 250 unit/second movement speed.
If that person suddenly moves 1000 units in 1 second without any movement speed increase (blink, leap, func_push or func_teleport etc) you should be alarmed.
I believe they use this method in World of Warcraft actually if I recall correctly.
That way making a wallhack will be impossible because the hack has no way of getting information about enemies behind walls, because that information is simply not sent to the hackers client.<!--QuoteEnd--></div><!--QuoteEEnd-->
Horrible way to handle wallhacks. The client NEEDS to know when someone gets close to a corner, what happens if someone is running around a corner, NOT rendering anything in the next room since they can't see the players yet, then that person gets launched by an explosion into that room. They go from being around the corner to being in the room in a VERY short period of time, using your method, the players in the room the person just got launched into would suddenly go from not there, to there, it would look like they teleport into place. You might be fine with that, but lets not reinvent the wheel on best practices when it comes to when and how to render players.
<!--quoteo(post=1793641:date=Aug 12 2010, 03:44 AM:name=Sneakpeek)--><div class='quotetop'>QUOTE (Sneakpeek @ Aug 12 2010, 03:44 AM) <a href="index.php?act=findpost&pid=1793641"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Aimbots are impossible to block as far as I know, but I have a suggestion for how to detect one.
You check if a players angles turns very fast from one point to another and "snaps" onto a target.
Say if you are changing your crosshair from A to B.
It would go something like this.
"x" represents where the mouse stops/updates along the way
A - - x - - x - - - - - - x - - - - - x - - - - B
Nobody can make a perfect turn from A to B without having the mouse having a few "stops" along the way
Where an aimbot would go like this instantly with no stops along the way:
A - - - - - - - - - - - - - - - - - - - - - - - - B
Also, if the players crosshair "snaps" onto a players hitbox after making an instant turn like that, you can be pretty sure he is using an aimbot.
This could of course produce false bans on rare occasions, so my suggestion would be to check for this type of "instant turn and snap on target" atleast 3-5 times before you ban someone.
I realise there are ways to bypass this, such as having a "smooth" aimbot that doesnt instantly turn to the target, but hey, its better than nothing I quess.<!--QuoteEnd--></div><!--QuoteEEnd-->I disagree with this, when I aim, I do so generally in one smooth movement. I do not have any stops along the way, the mouse goes from point A to point B at a consistent speed without any hitches. There is also twitch aiming which is essentially aimbot-like behavior, you go from not aiming at the target, to aiming and firing at the target in one very short amount of time (less then half a second). Your idea would essentially flag everyone who twitch-aims, or people who even get lucky twitch shots as aimbotters.
Plus, aimbots can be written to snap to a random variance.....you can code one to snap within 2-3 units of the target and randomize it each time. Meaning a good aimbot can and will miss, making it more difficult to tell the person is using it.
The easiest way to spot a dumb aimbotter is to watch how they aim. If they snap dead on a target every time, or track the target without issue (an unpredictable target is impossible to fully and accurately track 100% of the time), then they are aimbotting. A smart aimbotter is almost impossible to detect without antihack software that detects the program they are running.
But again, just because someone can twitch-aim, doesn't mean they are aimbotting.
That being said, I hope and am quite sure that UWE has a good solution for anti-hacking, UWE is not a random team of people that have decided to build their first game and see how it goes, they have at least some experience with this sort of thing, and given that hacking is a problem in almost all popular FPS games, I am positive they have given it at least some thought.
Unrelated but I wish VAC was a 2 year, not a permanent ban. It would relieve the major fear of VAC. If a cheater can only do something every 2 years per copy of the game then so be it. Not that I am banned, but that April 1 incident scared me black.
It installs as a service and run every time you start windows, consuming resources. No, I don't like it. If you make it start when the game start, then there is no problem, but not always. Is like with VAC, if I don't start Steam (or a game, not sure how it start) is not loaded.
Like in the good old days, when there was no anti-cheat programs, the admins got alerted on a player that could be cheating, they spect and then ban (or not, if it's clean). And other players can make a demo and report it on the forum of that community server.
I also saw an Admin slaping a cheater until he left the server, was so funny. Both sides stop playing an enjoyed the show.
Also, with some communities really mature, you can share a common ban list, so if you get banned in one server you are banned on all the servers that use this list. Of course in this case you need demos of the said cheater so all the admins can review it.
Which leads me to something I would like to see in the server, the admins can spect a player but is not shown in the list, so no one could know if they are specting or not, this way you can easily catch them.
someone hided in a vent is not visible but can emit a lot of sounds.
_For speedhack, i agree, that's a good solution.
_A good aimbot is impossible to track. Because a smart player won't use it all the time. (10% of manual/fail aiming is enough to prove themself not cheating at the eyes of naive admins).
_A good way to fight cheats is :
1) Infinite ban of the steam account.
2) Increase the price of the game (for example halflife was 5$... so weren't worried about being banned, they just had to buy another for 5$..... but make the game 60$ it will be different, they will think twice before cheating and being banned).
To fight against cheat in general : Do most of work serverside.
To fight against aimbots : get the client to work with encrypted data in memory. So it's not easy to modify memory data with a third party program.
the server send the position of player in encrypted data, used for position calcul and restitution only. And use a totally different buffer / system for the mouse. So the cheat will have a hard time to find the position of ennemy in memory and paste it in the mouse buffer.
Say one is coding a fps with aliens thta can cloak, then they could override the code that send position of players to the client, so only ppl with > 0 alpha gets sent.
This would stop any client side addon from seeing cloaked ppl.
Say one is coding a fps mod where people cant fight, but cna make entities and then set their alpha. A mingebag could join and spam invisible entitys, causing a huge load on the server.
If the client would not get to know that those invisible entities exist, the prediction will go dodgy if they collide with it, and admins cant use a "x-ray" addon to see where the props are and who spawned them.
Only problem is that it would have to let the lua ovverride kinda deep and important engine parts (or involve overriding the lua get functions for the client).
tl;dr
I think that stopping clientside hacks for ns2 on the engine level would just limit other mods.
I used a bad example about srv telling/not telling where entitys are (if srv dont tell client but you want it to, you could just send the data as usermessages/datastreams).