+ open.mp forum (https://forum.open.mp)
-- Forum: SA-MP (https://forum.open.mp/forumdisplay.php?fid=3)
--- Forum: Releases (https://forum.open.mp/forumdisplay.php?fid=13)
---- Forum: Plugins (https://forum.open.mp/forumdisplay.php?fid=32)
---- Thread: [Plugin] Aimbot detector using Artifical Intelligence (/showthread.php?tid=152)
Aimbot detector using Artifical Intelligence - Yashas - 2019-04-14
AntiAimbot
Version: E1 (experimental version)
DISCLAIMER:
- the plugin is still experimental and has undergone rigorous testing on artificial servers but hasn't been tested on a real server with a large player base
- works for M4/AK47/MP5 only
AntiAimbot is an aimbot detector which uses a combination of empirical methods and artificial intelligence to accurately identify players using any form of aim assist. Empirical methods such as high ratio on moving players are used to efficiently suspect players of using aimbot. The samples of players suspected of using aim assist tools are forwarded to a combination of AI machinery consisting of mainly a neural network and a support vector machine for further detailed analysis. The AI machinery investigates the samples and decides if the feat achieved is humanly possible or not by "probably" (they are all black boxes) analyzing how quickly the aim moves, how synchronized the aim was with the motion of the victim, how fast the player reacts to changes and many such features.
The latest version is significantly more accurate than the version used in the vdeio.
Overview:
The entire process can be divided into two sections based on the type of used: empirical methods and artificial intelligence methods. The empirical methods are used to quickly suspect the possibility of an aim assist software being used while the artificial intelligence based methods are used to analyze the suspected samples more rigorously.
The AI-based detectors are trained to identify possible use of aim assist accurately when possible, i.e. they give negatives when they aren't sure. Given enough time, they will mostly detect the use of aim assist.
Quote:The submitted vectors go through a lot of stages.
stages of data flow:
data collection: a script collects shot vectors
pre-filter: carries out checks to eliminate unreliable shot vectors
transform: transforms shot vectors to a form suitable for feature extraction
pooling: pool together a variable number of transformed vectors to form a complete sample
extract features: extract features from the vector pool
post-filter: carry out basic empirical checks on the sample to check reliability and possible use of aim-assist; if suspicious, forward it to the AI machinery
detectors: run through different detectors and average the result
Some of the pre-filter conditions are:
- must use a M4/AK47/MP5 (other weapons are disabled because of their unreliability)
- the victim must be moving
- and many more
If a shot fails any of these conditions, the entire running pool is rejected and starts afresh.
After pooling many shots together, it goes through another filter. The filter decides if there is enough information that can be extracted from the pool; if not, it continues to collect more shot. Once there is enough useful information, it checks for reliability and estimates the use of aimbot, for example, by checking the pool's ratio (required to be high for last X number of shots where X is between 7 and 20).
It's only after this step the sample is said to be fully complete. This is when `submit_vector` returns 1. This sample is put in a queue for processing. The detectors are running in different threads. They pick a sample from the input queue, investigate it, dump it to the output queue. In the server's next tick cycle, results are pulled out of the output queue and the callback is triggered for each sample.
Hence, the callback is triggered only when there was enough suspicion and after it was processed by the AI machinery.
TL;DR:
- callback is triggered only when there is some suspicion, i.e. when the empirical methods suggest the use of aimbot
* however, the AI machinery can reverse the decision and say this may not have been an aimbot
- it's difficult to get the callback triggered without using an aimbot because most samples are rejected empirical methods
- callback is triggered every minute or so when an aimbot is used
* the callback being triggered does not imply that aimbot was used; you need to check the probabilities
Usage:
building plugin from source (Linux):
- install gcc-8, g, gcc-8-multilib, g8-multilib, cmake
- clone the sampml repository
- change directory to `examples/anti-aimbot/plugin`
- create and enter `build` directory
- generate build files using `cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=gcc-8 -DCMAKE_CXX_COMPILER=g8`
- build plugin using `cmake --build . -- -j <number of threads>`
- clone the sampml repository
- open `examples/anti-aimbot/plugin` directory in Visual Studio 2017
- click on CMake->Build
- move the plugin binary to the `plugins` directory
- create a new directory `anti-aimbot` in the `plugins` directory
- create a new directory `models` in `plugins/anti-aimbot` directory
- copy three model files from `examples/anti-aimbot/training/models` to the models folder
- [optional] create config.cfg in the `anti-aimbot` directory
thread_pool_size: number of threads that can be used for detectors (default: 4)
rf_model_file: random forest model file (default: plugins/anti-aimbot/models/rf_classifier.dat)
svm_model_file: svm model file (default: plugins/anti-aimbot/models/svm_classifier.dat)
dnn_model_file: dnn model file (default: plugins/anti-aimbot/models/dnn_classifier.dat)
Example `config.cfg`:
Code:
thread_pool_size 2
dnn_model_file plugins/anti-aimbot/models/dnn2_classifier.datsubmitting a shot vector:
Code:
stock CollectDataOPWS(data[E_SHOT_VECTOR], playerid, weaponid, hittype, hitid, Float:fX, Float:fY, Float:fZ)
native submit_vector(playerid, data[E_SHOT_VECTOR]);Code:
#include <aimbot_dc.inc>
public OnPlayerWeaponShot(playerid, weaponid, hittype, hitid, Float:fX, Float:fY, Float:fZ)
{
??????? new data[E_SHOT_VECTOR];
??????? CollectDataOPWS(data, playerid, weaponid, hittype, hitid, fX, fY, fZ);
?? ?submit_vector(playerid, data);
??? ?return 1;
}obtaining results:
Code:
forward OnPlayerSuspectedForAimbot(playerid, Float:probabilities[3], time[3]);Code:
#include <aimbot_dc.inc>
public OnPlayerSuspectedForAimbot(playerid, Float:probabilities[3], time[3])
{
??? /* results are sent after a few seconds; hence, check if the player is still connected */
??? if(!IsPlayerConnected(playerid))
??????? return 1;
??? static enum {
??????? COLOR_RED = 0xFF0000FF,
??????? COLOR_GREEN = 0x00FF00FF,
??? };
??? new str[144], name[MAX_PLAYER_NAME];
??? GetPlayerName(playerid, name, sizeof(name));
??? /*
??? ** there are three independent detectors
??? ** - random forest
??? ** - support vector machine
??? ** - deep neural network
??? **
??? ** `probabilities` contains the outputs of the detectors in the aforementioned order
??? ** `time` contains the CPU microseconds used by each of the detectors in the aforementioned order
??? **
??? ** the average of the probabilities can be used to get an overall estimate
??? ** choose a cutoff above which the result is considered to be an aimbot sample
??? ** the code below sends a message for all samples
??? */?? ?
??? const Float:cutoff = 0.6;
??? new Float:avg = (probabilities[0] probabilities[1] probabilities[2])/3;
??? format(str, sizeof(str), "%s(%d) >> RF: %.2f (%dus) SVM: %.2f (%dus), DNN: %.2f (%dus)",
?? ? ?? ??? ??? ??? ??? ??? ?name, playerid,
?? ? ?? ??? ??? ??? ??? ??? ?probabilities[0], time[0],
?? ? ?? ??? ??? ??? ??? ??? ?probabilities[1], time[1],
?? ? ??? ??? ??? ??? ??? ??? ?probabilities[2], time[2]);
?? ? ??? ??? ??? ??? ??? ??? ?
??? new color = ((avg > cutoff) ? COLOR_RED : COLOR_GREEN);
??? SendClientMessageToAll(color, str);
?? ?
??? format(str, sizeof(str), "Average: %.2f (%s)", avg, ((avg > cutoff) ? ("MOSTLY USING AIMBOT") : ("MAY NOT BE USING AIMBOT")));
??? SendClientMessageToAll(color, str);
}Links:
GitHub Repository
Contributing & Support Requests
discord server for:
- research & development
- support requests
- contributing
Looking for people to test the plugin on real servers and provide feedback. Only three skin aimbots were used for training and hence the detectors might fail for specific cases which I expect to be reported. You can get the training summary on Travis or AppVeyor.
Credits:
Over dozen people were involved in testing an collecting data. I'd like to mention the top contributors:
- Helium
- Variable/H2O
- Luzziz
RE: Aimbot detector using Artifical Intelligence - JonasP - 2019-04-15
How's the performance hit on the server?
Any plans to expand into other weapons?
It would be interesting to try this out and give the data to admins so they could monitor various situations but most firefights here happen with shotguns, deagles, snipers, combat shotguns, fire extinguishers. C-bug is also used pretty much always. So I'm wondering if there is a possibility that this plugin will receive updates and include these weapons take cbug and cslide into account.
Also, generally interested as I'm completely inexperienced in AI:
Does it build some sort of model around a specific playerid or for all players and then looks at the odd results?
If a player disconnects and reconnects to a new playerid, does the AI need to spend time relearning about that player? Because if it builds data for specific playerids maybe it would be possible to collect that data and save it so that when the player joins the next day it just loads that data and continues learning about him instead of having to learn everything from zero again?
RE: Aimbot detector using Artifical Intelligence - Yashas - 2019-04-17
(2019-04-15, 05:52 PM)JonasP Wrote: How's the performance hit on the server?
The networks and the models are quite small and take few tens of microseconds per detection on my computer. I had anticipated complications (which didn't happen) and prematurely adding threading support. Most of the computation work happens in different threads which you can configure. Hence, the SAMP server is never blocked by the plugin.
In a nutshell, the performance hit is near zero. You can do 25,000 detections every second.
(2019-04-15, 05:52 PM)JonasP Wrote: Any plans to expand into other weapons?
Yes, but I don't want to add a zillion weapons and let all fail. The weapons with high fire rate make it relatively easier to detect aimbots. Hence, I started off with those.
(2019-04-15, 05:52 PM)JonasP Wrote: It would be interesting to try this out and give the data to admins so they could monitor various situations but most firefights here happen with shotguns, deagles, snipers, combat shotguns, fire extinguishers. C-bug is also used pretty much always. So I'm wondering if there is a possibility that this plugin will receive updates and include these weapons take cbug and cslide into account.
After hundreds of man-hours of research, I am reasonably certain that it's difficult to detect aimbots when used with slow firing weapons such as desert. I need to experiment much more before making a detector for deagle or shotgun.
I have made some progress with sniper but haven't published it yet.
The focus currently is on to get the detectors to work really well on M4/AK/MP5.
(2019-04-15, 05:52 PM)JonasP Wrote: Does it build some sort of model around a specific playerid or for all players and then looks at the odd results?
If a player disconnects and reconnects to a new playerid, does the AI need to spend time relearning about that player? Because if it builds data for specific playerids maybe it would be possible to collect that data and save it so that when the player joins the next day it just loads that data and continues learning about him instead of having to learn everything from zero again?
There is a common model for all the weapons and for all the player. The models were trained using dataset from around ten people with varying skills. Three skin aimbots were used for training. Hence, I speculate that there will be situations where super skilled players or weirdos make the detectors throw out false positives. It's speculation. It never happened when it was tested by several people but this should be taken with a grain of salt because the same people who were testing were also the ones who gave the training data.
I have been waiting for people to use and report issues which no one has done yet. I can't do much without getting feedback. I don't own a server and cannot test it.