[Dan..]

Hello guys!

I want to start a community-based anticheat. I've been brainstorming for the past days on the structure of the anticheat and I came with two ideas:

1. Part of the gamemode (a library that must be included in the gamemode).
The anticheat is being injected directly into the gamemode, where it hooks callbacks and natives. There will be a include file available for other scripts (filterscripts) that alter data used by the anticheat to determine if a player is or isn't cheating. Practically, every (important) native call from a script is redirected to the gamemode.

Pros:

• since more than 50% of the game is based on the gamemode, this should be faster as a big part of the game is handled locally
• the load of the gamemode increases

Cons:

• callbacks require hooking (it gets messy)

2. Standalone filterscript.
The anticheat is a standalone filterscript. There will be a include file available for other scripts (gamemode and filterscripts) that alter data handled by the anticheat. Practically, every (important) native call from a script is redirected to the Anticheat filterscript.

Pros:

• can be easily reloaded while the gameserver is online
• it's better organized

Cons:

• no callback hooks, but native hooks must access remote data

---

Feel free to correct me and submit your suggestion!

Thank you!

[MP2]

The obvious choice would be to integrate it into the gamemode. Trying to get communication between the GM (where most of the stuff like health is set) to a FS would be a hassle and not worth it, with no benefits.

[KiNG3]

I've tried to make anticheats via filterscript.....

Wasted over 3 hours making it work, when I coulda just integrated it... stupid mee xD

[cessil]

I briefly mentioned how I did it in the anti cheat tips thread.
An include that you'd create for every compiled script that edits players position, money etc. which would serve as a way to store everything you'd need for the anticheat filterscript
so if you've read this thread
https://sampforum.blast.hk/showthread.php?tid=220089
then it'd save things like what a players position should be, if it's synced, what weapons they should have...
I use pvars for ease

then in the filterscript you know can just read pvars to see what a player should have in their weapons or how much money they're meant to have.

This makes everything a lot easier to use, all the scripts need is an include and that's it, and the anticheat was a filterscript because I needed to make small changes all the time to make things more or less accurate. I don't see any unique downsides to this other than foreseeing what you'll need in the include

[Dan..]

Quote:

Originally Posted by MP2 The obvious choice would be to integrate it into the gamemode. Trying to get communication between the GM (where most of the stuff like health is set) to a FS would be a hassle and not worth it, with no benefits.

Dynamic reloading (no gmx required) and better organization, these are two major pros I can think of..

Quote:

Originally Posted by KiNG3 I've tried to make anticheats via filterscript..... Wasted over 3 hours making it work, when I coulda just integrated it... stupid mee xD

I don't have I'll have any problems implementing the code (that's very humble of me).

Quote:

Originally Posted by cessil I briefly mentioned how I did it in the anti cheat tips thread. An include that you'd create for every compiled script that edits players position, money etc. which would serve as a way to store everything you'd need for the anticheat filterscript so if you've read this thread https://sampforum.blast.hk/showthread.php?tid=220089 then it'd save things like what a players position should be, if it's synced, what weapons they should have... I use pvars for ease then in the filterscript you know can just read pvars to see what a player should have in their weapons or how much money they're meant to have. This makes everything a lot easier to use, all the scripts need is an include and that's it, and the anticheat was a filterscript because I needed to make small changes all the time to make things more or less accurate. I don't see any unique downsides to this other than foreseeing what you'll need in the include

I read your thread over and over again. It is a good source of information. However, I wouldn't like to use PVars, but a script with some kind of getters and setters to access fields inside it.

---

Anyway, I found a structure to combine those two ideas of mine. I'm looking forward to implement it. I hope to finish writing the basics of it and release it, in the following weeks integrating new anti-cheat methods.

[Dan..]

Quote:

Originally Posted by Y_Less Could I suggest looking in to y_master - it covers a lot of what you want in (IMHO) quite nice wrappers to allow cross-script scripting. At the very least it would save you the trouble of writing a lot of the boilerplate and repetitive communication code.

I found another easy way to do what I wanted. I guess y_master would just increase the complexity of the code. Also, I'm trying to use as little libraries as possible. I'll probably just use your foreach lib.

[cessil]

Quote:

Originally Posted by Dan.. I read your thread over and over again. It is a good source of information. However, I wouldn't like to use PVars, but a script with some kind of getters and setters to access fields inside it.

why? pvars are what you're looking for, instead of re-creating them why wouldn't you use them?

[Dan..]

Quote:

Originally Posted by cessil why? pvars are what you're looking for, instead of re-creating them why wouldn't you use them?

I can implement different validation rules inside getters. Using PVars means that I have to validate data everytime I alter it. I don't like this. Maybe if the idea I'm going to use doesn't turn out well, I'm going to use PVars.

[Dan..]

I have started working on this (@github). I'm looking forward for your suggestions!

[Y_Less]

Quote:

* Y_Less - very thorough research

, thanks!

Anyway, I would still recommend using y_master - I used to do what you're doing here and developed that to prevent duplication (because I got royally frustrated with writing everything twice):

pawn Код:

#if defined AC_SLAVE
    AC_STOCK AC_GetPlayerMoney(playerid) {
        return CallRemoteFunction(#AC_GetPlayerMoney, "i", playerid);
    }
    #if defined _ALS_GetPlayerMoney
        #undef GetPlayerMoney
    #else
        #define _ALS_GetPlayerMoney
    #endif
    #define GetPlayerMoney AC_GetPlayerMoney
#else
    AC_PUBLIC AC_GetPlayerMoney(playerid) {
        if (IsPlayerConnected(playerid)) {
            new bad_money = U_GetPlayerMoney(playerid);
            return bad_money < AC_players[playerid][AC_pMoney] ? bad_money : AC_players[playerid][AC_pMoney];
        }
        return 0;
    }
    #if defined _ALS_GetPlayerMoney
        #undef GetPlayerMoney
    #else
        #define _ALS_GetPlayerMoney
    #endif
    #define GetPlayerMoney AC_GetPlayerMoney
#endif

Becomes:

pawn Код:

foreign AC_GetPlayerMoney(playerid);
global AC_GetPlayerMoney(playerid) {
    if (IsPlayerConnected(playerid)) {
        new bad_money = U_GetPlayerMoney(playerid);
        return bad_money < AC_players[playerid][AC_pMoney] ? bad_money : AC_players[playerid][AC_pMoney];
    }
    return 0;
}
#if defined _ALS_GetPlayerMoney
    #undef GetPlayerMoney
#else
    #define _ALS_GetPlayerMoney
#endif
#define GetPlayerMoney AC_GetPlayerMoney

Only one declaration of the function, with the compiler adding and removing calls as appropriate.

Other than that, the layout looks good and thoroughly organised!

Also, I don't tend to rely on using the "FILTERSCRIPT" macro as people are rubbish at using it:

pawn Код:

new bool:AC_FILTERSCRIPT = false;

public OnFilterScriptInit()
{
    AC_FILTERSCRIPT = true;
    AC_OnScriptInit();
}

public OnGameModeInit()
{
    if (!AC_FILTERSCRIPT) AC_OnScriptInit();
}

[Dan..]

Quote:

Originally Posted by Y_Less Anyway, I would still recommend using y_master - I used to do what you're doing here and developed that to prevent duplication (because I got royally frustrated with writing everything twice): pawn Code: #if defined AC_SLAVE     AC_STOCK AC_GetPlayerMoney(playerid) {         return CallRemoteFunction(#AC_GetPlayerMoney, "i", playerid);     }     #if defined _ALS_GetPlayerMoney         #undef GetPlayerMoney     #else         #define _ALS_GetPlayerMoney     #endif     #define GetPlayerMoney AC_GetPlayerMoney #else     AC_PUBLIC AC_GetPlayerMoney(playerid) {         if (IsPlayerConnected(playerid)) {             new bad_money = U_GetPlayerMoney(playerid);             return bad_money < AC_players[playerid][AC_pMoney] ? bad_money : AC_players[playerid][AC_pMoney];         }         return 0;     }     #if defined _ALS_GetPlayerMoney         #undef GetPlayerMoney     #else         #define _ALS_GetPlayerMoney     #endif     #define GetPlayerMoney AC_GetPlayerMoney #endif

Including y_master means I have to include whole YSI and that's not something I'd really like to do (increases the size of the project much more than needed). Writing code in that way I realised I can do it like this (which looks a little better):

pawn Code:

#if defined AC_SLAVE
    AC_STOCK AC_GetPlayerMoney(playerid) {
        return CallRemoteFunction(#AC_GetPlayerMoney, "i", playerid);
    }
#else
    AC_PUBLIC AC_GetPlayerMoney(playerid) {
        if (IsPlayerConnected(playerid)) {
            new bad_money = U_GetPlayerMoney(playerid);
            return bad_money < AC_players[playerid][AC_pMoney] ? bad_money : AC_players[playerid][AC_pMoney];
        }
        return 0;
    }
#endif
#if defined _ALS_GetPlayerMoney
    #undef GetPlayerMoney
#else
    #define _ALS_GetPlayerMoney
#endif
#define GetPlayerMoney AC_GetPlayerMoney

Quote:

Originally Posted by Y_Less Also, I don't tend to rely on using the "FILTERSCRIPT" macro as people are rubbish at using it: pawn Code: new bool:AC_FILTERSCRIPT = false; public OnFilterScriptInit() {     AC_FILTERSCRIPT = true;     AC_OnScriptInit(); } public OnGameModeInit() {     if (!AC_FILTERSCRIPT) AC_OnScriptInit(); }

Whoever uses it must declare AC_MASTER or AC_SLAVE since now. This way I'm sure everything is fine and they aren't confused by master and slave scripts.

[Y_Less]

Not really - YSI libraries are quite independent. y_master uses y_hooks and y_utils mainly.

[Dan..]

Updated it. Still not using y_master, but it's much better organized (imo). :-"

[Y_Less]

That's fine - despite appearances I wasn't actually bothered if you did or not - I just know from personal experience that it can get hard to maintain.

[Dan..]

Quote:

Originally Posted by Y_Less That's fine - despite appearances I wasn't actually bothered if you did or not - I just know from personal experience that it can get hard to maintain.

I decided to structure my code this way so it won't be too hard to mantain. I knew that it will get messy at some point.

[Edvin]

I'm very curious how you'll make the m0d SA detection. I used the filterscript, with "GetPlayerCameraFrontVector" (i don't know who was the creator) to detect m0d SA, but doesn't worked... I'm really very curious what method you'll find xD

[Lordzy]

Quote:

Originally Posted by Edvin I'm very curious how you'll make the m0d SA detection. I used the filterscript, with "GetPlayerCameraFrontVector" (i don't know who was the creator) to detect m0d SA, but doesn't worked... I'm really very curious what method you'll find xD

The creator was Mean and it worked with the previous versions of that cheat.

[Edvin]

Quote:

Originally Posted by Lordz™ The creator was Mean and it worked with the previous versions of that cheat.

Yes, that's why i'm curious xD

[Gigi-The-Beast]

Quote:

Originally Posted by Edvin I'm very curious how you'll make the m0d SA detection. I used the filterscript, with "GetPlayerCameraFrontVector" (i don't know who was the creator) to detect m0d SA, but doesn't worked... I'm really very curious what method you'll find xD

It works...
I've developed my method for detection and it is 100% accurate. It is quite easy.

[Yiin]

Quote:

Originally Posted by Gigi-The-Beast It works... I've developed my method for detection and it is 100% accurate. It is quite easy.

if you play with camera position, then it is very easy to bypass this protection.