[Yashas]

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 deep neural networks and support vector machines for further detailed analysis. The AI machinery investigates the samples and decides if the feat achieved is humanly possible or not by 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.

Overview:

The entire process can be divided into two sections based on the type of technology 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.

Usage:

building plugin from source (Linux):

1. install gcc-8, g++8, gcc-8-multilib, g++-8-multilib, cmake
2. clone the sampml repository
3. change directory to `examples/anti-aimbot/plugin`
4. create and enter `build` directory
5. generate build files using `cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=gcc-8 -DCMAKE_CXX_COMPILER=g++-8`
6. build plugin using `cmake --build . -- -j <number of threads>`

building plugin from source (Windows):

1. clone the sampml repository
2. open `examples/anti-aimbot/plugin` directory in Visual Studio 2017
3. click on CMake->Build

installing:

1. move the plugin binary to the `plugins` directory
2. create a new directory `anti-aimbot` in the `plugins` directory
3. create a new directory `models` in `plugins/anti-aimbot` directory
4. copy three model files from `examples/anti-aimbot/training/models` to the models folder
5. [optional] create config.cfg in the `anti-aimbot` directory

configuring the plugin:

name	default	description
thread_pool_size	4	number of threads that can be used for detectors
rf_model_file	plugins/anti-aimbot/models/rf_classifier.dat	number of threads that can be used for detectors
svm_model_file	plugins/anti-aimbot/models/svm_classifier.dat	number of threads that can be used for detectors
dnn_model_file	plugins/anti-aimbot/models/dnn_classifier.dat	number of threads that can be used for detectors

Example `config.cfg`:

Code:

thread_pool_size 2
dnn_model_file plugins/anti-aimbot/models/dnn2_classifier.dat

submitting 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

[outdated] Detailed Demo (18th December 2018)
- the latest version is significantly more accurate than the results shown above

[SyS]

amazing

[DIRTYBYT3]

nice!

[coool]

Cool. This will decrease aimbot.

[cuber]

Been following it's development since day 1, decent efforts shown.

[f0Re3t]

compiled the plugin, but for some reason it does not work
the submit_vector function always returns 0, why?

[Yashas]

Quote:

Originally Posted by f0Re3t compiled the plugin, but for some reason it does not work the submit_vector function always returns 0, why?

The return value is the error status.
- 0 indicates that the shot vector was processed
- 1 indicates that a sample was generated (takes many shots to generate a sample)
* you can expect the callback to be triggered soon once `submit_vector` returns 1
- -1 if there was an error

The use of aimbot cannot be decided by a single shot. It requires a collection of shots. The `submit_vector` keeps submitting every shot information to the plugin. The plugin will process and will invoke a callback when it believes it has a result to share.

Please read the `obtaining the result` section.

[f0Re3t]

Quote:

Originally Posted by Yashas The return value is the error status. - 0 indicates that the shot vector was processed - 1 indicates that a sample was generated (takes many shots to generate a sample) * you can expect the callback to be triggered soon once `submit_vector` returns 1 - -1 if there was an error The use of aimbot cannot be decided by a single shot. It requires a collection of shots. The `submit_vector` keeps submitting every shot information to the plugin. The plugin will process and will invoke a callback when it believes it has a result to share. Please read the `obtaining the result` section.

I read the whole topic and did it right.
it was made a lot of shots, but the plugin did not give results
the shots were analogous to what is shown in the video

[Yashas]

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

[f0Re3t]

Quote:

Originally Posted by Yashas 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. TLR: - it's difficult to get the callback triggered without using an aimbot - 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 - 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

thank you for explaining the detailed operation of the system
is it possible to teach And? if so, what is required

[Yashas]

Quote:

Originally Posted by f0Re3t thank you for explaining the detailed operation of the system is it possible to teach And? if so, what is required

teach what?

All the training files are available in the repository and the sampml library has a simplified SVM and RF. It can be used for anything.

There is also a standalone tester, i.e. you can collect player statistics and save them into files (as shown in one of the example filterscripts) and then run the detector on it.

[Tamer]

Very nice, back in the day I had the thought of building an AI based aimbot detector for my server, however I wasn't literate on machine learning and neural networks and now my server is closed. If it were still open, I'd have lots of useful data coming out of from my server since we had lots of professional players and also so many aimbotters, the system could be trained for hours if not days.

I think this is one of the best works ever released, good job.

[waysemir]

Really nice.

[Chaser98]

I'd love to eventually see deagle aimbot detection. Keep up the good work dude, please don't stop!

[dotSILENT]

I haven't checked into the code, but I'd like to point out one possible scenario where I think a problem could appear:
1. Player id 0 is using aimbot
2. submit_vector is called for player id 0 and the analysis begins
3. Player id 0 leaves
4. New player connects and gets assigned ID 0, same as the cheating player
5. OnPlayerSuspectedForAimbot is being called for ID 0 with the results of the cheating player that isn't on the server anymore, but a new (clean) player has taken his slot, the server bans/kicks the legit player for the results of some different player that already left.

I'm not sure if that's possible, maybe you thought about it, but if not then I think there needs to be some sort of unqiue identification for the player, so even if the same ID is used, the results won't get mixed between 2 different players if the first one leaves. Or, just cancel the analysis if the player has left the server.

[Yashas]

Yes, that's an issue but it's extremely rare.

For that to happen, all the following incidents need to happen:
1. The transformation process decided to generate a sample just before the player quits (it takes around 2-10s to generate a sample)
2. The detectors will return the data in less than a second. Hence, the next player must join pretty quickly.
3. The player who joins next should get the same player id

You can add a check to ensure that the player has been in the server for at least 10 seconds.

Even by remote chance it happened, it should be ignored. Only repeated warnings should be taken seriously.

TL;DR: the cost of taking care of that extremely rare situation outweighs the benefits

[ch1ps]

This looks incredible

[Admireal]

Anyone share the built version?

[SeeNN]

Very nice.

[DmitriyShift]

will a link address download the plugin?