search

NexiusTailer / Nex-AC

Anticheat system
https://pawn.wiki/index.php?/topic/27641-nex-ac/
GNU Lesser General Public License v3.0
215 stars 153 forks source link

Anticheat values should always be compared with the 'actual/real' tick count #176

Closed rt-2 closed 4 years ago

rt-2 commented 4 years ago

Hi, basicaly I had to implement something like this in the version included in my server because it eliminates 95% of the false positive.

So if you have a timer with a 1000ms interval, and let say the maximum distance is 26.0, it will happen that the timer will come back after 1500ms instead of 1000ms. The maximum distance value must then be 26.0 / 1000ms * 1500ms instead of 26.0 in this example.

This is mainly for speed hacks / airbreaks, the timer will not always return after the right amount of time, this was discussed in issue #29 . Since then, I had to implement a script of my own that checks the tick difference when the timer is strigger, compared to what it was supposed to be. I had no choice because I use your anticheat as an auto-kick and I assure you that lots of problem came from there and I eliminated false flags almost entirely.

Obviously this was YEARS ago and Im sure your anticheat is way better in terms of false flags, but I still think that this comparison is very important, or false flags WILL occur. Also you will be able to have way more tight values because it will be calculated way more precisely and you will not have to take into account this type of lag.

rt-2 commented 4 years ago

I am willing to write this part of the code if you are busy, but I want to know what you think about this.

I think timer lag MUST be taken into account, and AFAIK it is not atm (correct me if Im wrong).

NexiusTailer commented 4 years ago

What exactly checks are you talking about (of those which need to be changed)? Now all anticheats inside a single one-second timer have a calculation of speeds/distances depending on the deviation of the interval of this timer.

rt-2 commented 4 years ago

Example: https://github.com/NexiusTailer/Nex-AC/blob/master/src/v1.9.53/nex-ac.inc#L5592 I don't see this, but maybe Im wrong, I see that you check 'ACInfo[playerid][acUpdateTick]' to be sure it doesn't go over 1500, but I think the values there should be 'multiplied'(for lack of a better word) by ACInfo[playerid][acUpdateTick]

NexiusTailer commented 4 years ago

But it doesn't relate to any timers at all. That check is in OnPlayerUpdate and acUpdateTick is a variable which keeps ticks since the last OnPlayerUpdate call (so this is a regular afk check there).

rt-2 commented 4 years ago

Ok Il will check the script better and reopen if needed

rt-2 commented 4 years ago

One problem I found, is that you should use the actual tickcount at the end of the function. This is the only difference I found between our 2 scripts.

I think the 'last tick' MUST be taken at the moment when the timer is called. I think this would help stability.

See https://github.com/NexiusTailer/Nex-AC/pull/178

NexiusTailer commented 4 years ago

No, it wouldn't change anything as I wrote in that PR. You can run a speedtest with a single iteration of running such code like in timer now, and you will see that it probably won't waste even one millisecond.

rt-2 commented 4 years ago

Probably not in perfect conditions, but I am pretty sure that it changes something when a VPS has small lags, or when there is a lot of players, or when more players are hacking.

rt-2 commented 4 years ago

Alright I will add some printf and if I see that you are wrong, I will reopen this issue