question

sammy89 avatar image
sammy89 asked

does playfab replace Anti-Cheat Toolkit (plugin) for unity?

Do I need both?

If I allow player to post player statistics (thereby potentialy enabling cheaters) would the anti-cheat toolkit be good enough to stop cheaters?

Thanks

Player DataLeaderboards and Statistics
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Sarah Zhang avatar image
Sarah Zhang answered

If you allowed clients to post player statistics, it means players can use the Client API UpdatePlayerStatistics to post their statistics.

For clarification, PlayFab Client APIs are designed for players to get or set data directly, we won’t design anti-cheat tools for the Client API. For anti-cheat reasons, we recommend you prohibit clients from posting statistics, and only allow servers to post them. Specifically, you can call the Server API UpdatePlayerStatistics on CloudScript using Azure Functions(CSAF) and let players call the Entity API ExecuteFunction to trigger the corresponding Azure Functions. If so, you can do the custom anti-cheat verification in the Azure Functions on your own. Please check the documentation - PlayFab CloudScript using Azure Functions - PlayFab | Microsoft Docs to learn more about CSAF.

Please note, only when you are doing the developer testing or your game is not sensitive to the competition between players, can you consider allowing clients to post statistics. The documentation - Using player statistics, specifically the note of this section - Client API also clarified this point that if your game has any competitive play aspect, we would recommend that you never post statistics from the client

2 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

sammy89 avatar image sammy89 commented ·

thanks for your quick answer.

Thing is, cloud scripts seem complicated and I can't find a highscore table example online.

So are you saying that anti-cheat toolkit would not be able to stop cheaters if i'm using player statistics?

0 Likes 0 ·
Sarah Zhang avatar image Sarah Zhang sammy89 commented ·

For clarification, if you use the Client API, you can't prevent cheating. And PlayFab doesn't provide the "anti-cheat" toolkit natively. Could you please clarify where the "anti-cheat" toolkit comes from?

As this blog - Announcing CloudScript using Azure Functions is now GA (playfab.com) said, the CloudScript Classic currently won't be provided for the newly created titles. And now we recommend you use the CloudScritp using Azure Functions, please check out our overview video and quickstart guide for more information. If you meet the specific difficulties when you use the PlayFab Server API on Azure Functions, please feel free to post the questions in current forum.

0 Likes 0 ·
dorizzdt avatar image
dorizzdt answered

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.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Error rendering WebPanel (widgets/consolidation-widget.ftl): org.hibernate.hql.internal.ast.QuerySyntaxException: AvailableConsolidation is not mapped [from AvailableConsolidation up where up.node = :node]