Mobile Fake detection

[zXLiMiT-ToTAL]

I did new tests and found that when the (mobile) player shoots at another player from a short distance it doesn't falsely detect, but when the (mobile) player shoots at a greater distance, it falsely detects.

[Nex-AC debug] AC ammo: 982, ammo: 986, weaponid: 25 [Nex-AC debug] AC ammo: 996, ammo: 997, weaponid: 25

[Nex-AC debug] Weaponid: 25, reload time: 1, state: 1 [Nex-AC debug] Weaponid: 25, reload time: 0, state: 1 [Nex-AC debug] Weaponid: 25, reload time: 1, state: 1 [Nex-AC debug] Weaponid: 25, reload time: 0, state: 1 [Nex-AC debug] Weaponid: 25, reload time: 0, state: 1

[NexiusTailer]

Well, your mobile client again sent a few shots with rate of 0-1 ms between them (while normal shot rate for shotgun is about 800+ ms), and it also again sent the same ammo as before the shot, although the fired shots should have taken away that amount of ammo which is equal to the number of shots fired. Solve these mobile client problems with its developer.

[zXLiMiT-ToTAL]

Sometimes, when tested the player (who is shooting) is far away from the player (who is taking damage), it happens that the weapons already mentioned go to 0 or 1 making it detect, probably problems on the mobile itself, and like the SA-MP Launcher, it's not official, and it hasn't been updated for a long time (looking at the play store description). You in the future in version 2.0 of NEX-AC do not intend to "try" to make a certain compatibility? The future of samp is mobile.

Changing the subject: Another problem for both mobile and pc with include easy Dialog

https://github.com/Awsomedude/easyDialog

If placed below nex-ac it gives two errors on the line

error 035: argument type mismatch (argument 4) error 035: argument type mismatch (argument 4)

If put above, compile normally, but falsely detect.

//49 AC dialog: -1, dialogid: 32700, listitem: 1.

[NexiusTailer]

probably problems on the mobile itself, and like the SA-MP Launcher, it's not official, and it hasn't been updated for a long time (looking at the play store description). You in the future in version 2.0 of NEX-AC do not intend to "try" to make a certain compatibility?

Yeah, the problem itself in certain samp android implementations, so send your feedback to the certain developers of these implementations as it's not a deal of anyone else like me. It won't be possible to make compatibility with the fact that it just sends invalid data, this is not a specific behavior feature.

Another problem for both mobile and pc with include easy Dialog

https://github.com/Awsomedude/easyDialog

The first problem is obviously const parameters for some native samp functions which don't have that (some constant params from Dialog_Open passed to non-constant in ShowPlayerDialog). The second problem is that this include replaces the formal dialog ID with the same value (32700) for any actual dialog ID, keeping these IDs in its own variables. I think you can disable anti-dialog hack in anticheat (which probably blocks OnDialogResponse and this way players click it so many times, then get kicked by anti-flood) as anti-dialog hack should be implemented such way in this include. And ofc, anticheat should be included before this dependency.

[zXLiMiT-ToTAL]

Another problem: Sob31t O3v3r L1gth v3 when activated god-mode (porcomod) the anti cheat does not detect, is this the default anti cheat that only detects god-mode that disables the native functions or is it a problem?

[NexiusTailer]

The anticheat does have anti-godmode, but only from bullets (when player damage another player via bullet weapon shot, triggering OnPlayerWeaponShot callback). Other damage, for example "environmental" (from fire, collision, drowning, explosions etc) couldn't be detected as there is only one source (victim's client) who tells the server that the damage has been done to him, so when he blocks OnPlayerTakeDamage event, nobody else could report about that and there is none events for anticheat to detect it.

For fully "blocking" godmode I can advise a serverside damage system like weapon-config, which is still cannot detect and block godmode from local "environment" damage, but does detect and prevent any health cheats and GMs in any player-to-player damage (including RPG, flamethrower, grenades, knifes, chainsaws etc).

[zXLiMiT-ToTAL]

Something is wrong with Anti cheat is detecting cheat:

AC veh health: 990.576660, veh health: 1000.000000, veh: 1, playerid: 0

public OnVehicleDamageStatusUpdate(vehicleid, playerid)
{
    RepairVehicle(vehicleid);
    SetVehicleHealth(vehicleid, 1000.0);
    return 1;
}

To reproduce the test, hit the vehicle a few times!

[NexiusTailer]

Something is wrong with Anti cheat is detecting cheat:

AC veh health: 990.576660, veh health: 1000.000000, veh: 1, playerid: 0

public OnVehicleDamageStatusUpdate(vehicleid, playerid) { RepairVehicle(vehicleid); SetVehicleHealth(vehicleid, 1000.0); return 1; }

To reproduce the test, hit the vehicle a few times!

I can't reproduce anything like this on the reference (PC) 0.3.7 client.

[zXLiMiT-ToTAL]

The problem is not just on mobile, and so on PC when using the code above.

AC veh health: 996.090454, veh health: 1000.000000, veh: 1, playerid: 0

[NexiusTailer]

There's no any similar problems when I try to reproduce that.

[zXLiMiT-ToTAL]

I tested only with the code, and the anti cheat detected false positive.

[Nex-AC debug] AC veh health: 991.336730, veh health: 1000.000000, veh: 1, playerid: 0

Try retesting with this code:

Create a vehicle and then use /godcar

#include <a_samp>
#include <Pawn.RakNet>
#include <streamer>
#include <sscanf2>
#include <nex-ac>
#include <Pawn.CMD>

#pragma warning disable 214
#pragma warning disable 239

new PlayerV[MAX_PLAYERS];
new PlayerG[MAX_PLAYERS];

public OnPlayerConnect(playerid)
{
    PlayerV[playerid] = -1;
    PlayerG[playerid]= 0;
    return 1;
}

public OnGameModeInit()
{
    return 1;
}

public OnGameModeExit()
{
    return 1;
}

CMD:godcar(playerid)
{
    PlayerG[playerid] = 1;
    return 1;
}

CMD:vehicle(playerid)
{
    new Float: x;
    new Float: y;
    new Float: z;
    new Float: angle;
    GetPlayerPos(playerid, x, y, z);
    GetPlayerFacingAngle(playerid, angle);
    PlayerV[playerid] = CreateVehicle(436, x, y, z, angle, 0, 0, -1);
    PutPlayerInVehicle(playerid, PlayerV[playerid], 0);
    return 1;
}
public OnVehicleDamageStatusUpdate(vehicleid, playerid)
{
    if(PlayerG[playerid] == 1)
    {
        RepairVehicle(vehicleid);
        SetVehicleHealth(vehicleid, 1000.0);
    }
    return 1;
}

forward OnCheatDetected(playerid, const ip_address[], type, code);
public OnCheatDetected(playerid, const ip_address[], type, code)
{
    if(type) BlockIpAddress(ip_address, 0);
    else
    {
        new str[156];
        format(str, sizeof(str), "%d player was kicked", playerid);
        //SendClientMessageToAll(COLOR_dark, str);
        SendClientMessageToAll(-1, str);

        Kick(playerid);
    }
    return 1;
}

[zXLiMiT-ToTAL]

Any solution to the problem? This is happening on the PC.

[NexiusTailer]

There's no any problem trying to test this on a local server, as well as on any other with this code example. The vehicle gets repaired as it should be without any detection.

[zXLiMiT-ToTAL]

It takes time to detect, and you have to damage the vehicle around the map several times until it falsely detects.

Hint: "Scrape" the vehicle on the wall for a few seconds falsely detects.

This isn't a problem in the code, because it's not logical to happen this with just what is above.

Operating system used linux.

[NexiusTailer]

I know how to do tests, so I'm obviously did right that a few times before I confirmed that no any problems arise. Anyway, even if you have huge player packetloss, lagging server, etc. that could cause something to go wrong, you still won't be kicked for this code by default, as a default action for that code is to just re-apply the last "valid" vehicle health.

[zXLiMiT-ToTAL]

Okay, I redid the tests here, and it turned out that at low speed it is falsely detecting.

When the vehicle "scrapes" somewhere with low speed detected:

With high speed, apparently it's OK sometimes.

[Nex-AC debug] AC veh health: 998.576171, veh health: 1000.000000, veh: 1, playerid: 0

I know you know how to do tests, it's from 2015 producing the ANTI-CHEAT, more apparently the problem is in the nex-ac.

Let's try to "work" together to try to solve this problem.

[NexiusTailer]

I know you know how to do tests, it's from 2015 producing the ANTI-CHEAT, more apparently the problem is in the nex-ac.

No, I think it's more apparently the problem is somewhere in your code or in network connection, considering that (as you already said) anticheat has been in development since 2015 and it is much more stable than most of today's releases.

So, try to log server tickrate and player's packetloss from the netstats functions.

[zXLiMiT-ToTAL]

Using #"only" the code sent above the anti cheat falsely detects.

[Nex-AC debug] AC veh health: 983.684387, veh health: 1000.000000, veh: 3, playerid: 1 ping: 151 packet loss: 0.00 tickrate: 64

Error disassembly video: https://streamable.com/fkybaj

[zXLiMiT-ToTAL]

Anything to be done?

[NexiusTailer]

Well, do you have kick as a punishment? As I've said before:

Anyway, even if you have huge player packetloss, lagging server, etc. that could cause something to go wrong, you still won't be kicked for this code by default, as a default action for that code is to just re-apply the last "valid" vehicle health.

and even considering this is not packetloss nor bad internet connection problem judging by the logs, this anticheat code has SetVehicleHealth(vehicle, its last real health) as a "punishment" by default, not kick.

Btw I think now it’s actually not so important even to look for the final cause of this particular problem (it’s definitely not on the anticheat side), because in any worse cases, for example, when cheaters will try to fix their vehicle immediately after exiting and the real anticheat detection will fall only on the player who next gets into this vehicle, you'll still need to change this punishment to re-setting vehicle health to the last valid in the end. Look at the default punishments list for custom OnCheatDetection callback and make these changes according to diffs you have now for anti-vehicle health hack. Any default punishments which now is set not on a kick were made for a reason.