question

hmm

There is an alternative to this problem depending on the context of the game. If its just a solo player fighting NPC/AI and checking the scoreboard then realistically there is no protection here as you can easily create false positives on skill/attributes.

However, if its a multiplayer solution whereby two or more players are duking it out for titles then well you can invoke a witness, offender and victim approach.

Let's take the premise of a playerA using a cheat to jump higher than normal - say 2m above the threshold expected.

In order for that player to be successful in execution of their cheat, they would need to first inform all clients via replication of their xyz coords.

This means, that playerB see's the at playerA has jumped abnormally high, because on their client its tripped a few alarms around height/jump checks. They immediately become a witness to the behaviour and inform the server with a silent "vote of no confidence".

let's say playerA also spawns in a weapon or damage. Let's say that the hacker in question was smart enough to send the fake packet to the server but not actually replicate.

Again, the problem here is the rogue client has to convince both victims and witnesses that there was a linear progression to that damage / usage of a weapon moment.

So for example playerB sends a confirmation to the Azure Function with "I just saw playerC killed by playerA with AK47 and here is my snapshot of events leading up to this" and playerC sends packet to Azure Function "I was just killed by playerA with AK47 and here is my snapshot of events leading up to this" and then of course playerA sends packet to azure function "I just killed playerC with AK47 and here is my snapshot of events leading up to this"

The key issue here is the server has to agree up front "where did you get that AK47?" and secondly the player snapshot of events can be a simple validation process whereby the function iterates through a batch packet and sniffs out a few simple ruleset checks such as "range of shot, how many shots etc" and done so in a fire and forget process.

The point here is the hacker has to always convince a victim and witness that they are telling the truth and assuming that your victim/witness haven't been susceptible to memory injection or breaches in the client they will always be truth full over time.

Over a mult-session period a pattern will emerge whereby the at playerA fellow is constantly been flagged as being untruthful, resulting in a perm ban based of pure data analysis (no emotion).

I use this exact same approach on my RUST servers, and so far its worked out with a 90% success rate in Facepunch bans on the offenders.

I've also implemented the process with a GTA5 server and it too has caught cheating as with that particular solution, the client is nearly always being tampered with an no secure I/O wrappers like anti-cheat to prevent it.

Using Azure Function route you also don't necessarily need to pay a high tax in database lookups for this either, as these snapshots you send to it batch forms are easily iterated through with a simple ruleset each iteration applied (square root checks, inventory loot add/remove validations, damage analysis etc). Furthermore you aren't in a transaction state, meaning its purely fire-and-forget, as it can validate once the moment has passed.

As the key here is you're not going to catch them real-time as it exactly happens. It may take Xseconds / xMins to establish a baseline of pattern before you ban them. As again the more victims/witness silently report in the more the pattern emerges over time.

Perfection is a cheaters Achilles heel.

,

hmm

There is an alternative to this problem depending on the context of the game. If its just a solo player fighting NPC/AI and checking the scoreboard then realistically there is no protection here as you can easily create false positives on skill/attributes.

However, if its a multiplayer solution whereby two or more players are duking it out for titles then well you can invoke a witness, offender and victim approach.

Let's take the premise of a playerA using a cheat to jump higher than normal - say 2m above the threshold expected.

In order for that player to be successful in execution of their cheat, they would need to first inform all clients via replication of their xyz coords.

This means, that playerB see's the at playerA has jumped abnormally high, because on their client its tripped a few alarms around height/jump checks. They immediately become a witness to the behaviour and inform the server with a silent "vote of no confidence".

let's say playerA also spawns in a weapon or damage. Let's say that the hacker in question was smart enough to send the fake packet to the server but not actually replicate.

Again, the problem here is the rogue client has to convince both victims and witnesses that there was a linear progression to that damage / usage of a weapon moment.

So for example playerB sends a confirmation to the Azure Function with "I just saw playerC killed by playerA with AK47 and here is my snapshot of events leading up to this" and playerC sends packet to Azure Function "I was just killed by playerA with AK47 and here is my snapshot of events leading up to this" and then of course playerA sends packet to azure function "I just killed playerC with AK47 and here is my snapshot of events leading up to this"

The key issue here is the server has to agree up front "where did you get that AK47?" and secondly the player snapshot of events can be a simple validation process whereby the function iterates through a batch packet and sniffs out a few simple ruleset checks such as "range of shot, how many shots etc" and done so in a fire and forget process.

The point here is the hacker has to always convince a victim and witness that they are telling the truth and assuming that your victim/witness haven't been susceptible to memory injection or breaches in the client they will always be truth full over time.

Over a mult-session period a pattern will emerge whereby the at playerA fellow is constantly been flagged as being untruthful, resulting in a perm ban based of pure data analysis (no emotion).

I use this exact same approach on my RUST servers, and so far its worked out with a 90% success rate in Facepunch bans on the offenders.

I've also implemented the process with a GTA5 server and it too has caught cheating as with that particular solution, the client is nearly always being tampered with an no secure I/O wrappers like anti-cheat to prevent it.

Using Azure Function route you also don't necessarily need to pay a high tax in database lookups for this either, as these snapshots you send to it batch forms are easily iterated through with a simple ruleset each iteration applied (square root checks, inventory loot add/remove validations, damage analysis etc). Furthermore you aren't in a transaction state, meaning its purely fire-and-forget, as it can validate once the moment has passed.

As the key here is you're not going to catch them real-time as it exactly happens. It may take Xseconds / xMins to establish a baseline of pattern before you ban them. As again the more victims/witness silently report in the more the pattern emerges over time.

Perfection is a cheaters Achilles heel.