Anti-Cheat Interfaces

Understand the prerequisites, network architecture, platform components, and more involved in implementing Anti-Cheat in your EOS product.

9 mins to read

The Anti-Cheat Interfaces require EOS SDK 1.12 or higher.

There are two interfaces: the Anti-Cheat Client Interface and the Anti-Cheat Server Interface.

  • The Anti-Cheat Client Interface only supports Windows, macOS, ChromeOS, and Linux 64-bit operating systems. It does not support virtual machines (VM).
  • The Anti-Cheat Server Interface supports all platforms, including VM.

(The Anti-Cheat Interfaces are also known as Easy Anti-Cheat.)

You can use the Anti-Cheat Interfaces to help reduce cheating in online multiplayer play. They provide tools to start your game client in an anti-cheat protected mode which is then validated by either a game server (using the Anti-Cheat Server Interface) or another game client (using the Anti-Cheat Client Interface). These interfaces are not digital rights management (DRM) or code obfuscation tools and are not useful for offline or solo play.

The anti-cheat interfaces provide two kinds of protection:

  • Cheat prevention to passively prevent common cheating techniques such as reading and writing the game process memory using straightforward methods.
  • Cheat detection to identify accounts using more specialized methods to manipulate the game so that you can then apply sanctions to them.

To use the Anti-Cheat interface(s), you must:

  1. Review and adhere to the Development Prerequisites.
  2. Determine your network architecture and client policy type.
  3. Configure your client module, anti-cheat integrity tool, and Anti-Cheat Bootstrapper executable.
  4. (Windows Only) Configure the Windows Service Installer.
  5. Integrate the Anti-Cheat interfaces with your game code:
    1. Establish user identity with the Connect Interface.
    2. Register callbacks for Client-Server or Peer-to-Peer mode.
    3. Set up protected session notifications.
  6. Confirm the Anti-Cheat interfaces are working properly by going through the Integration Checklist.

Development prerequisites

For the anti-cheat services to be effective, they must go on top of a solid game foundation that follows security best practices and actively addresses game issues as they arise.

Game architecture

We highly recommend using dedicated game servers with authority over as much of the game state as possible.

For example, cheats allowing players to fly, teleport, or move extremely fast can usually be completely prevented at the game architecture level by giving game servers authority over player positions and movement.

Game exploits

Game logic errors, bugs, or edge cases are often discovered and exploited by players. However, anti-cheat understands the game code to be working as written and cannot solve these issues. As the game developer, you must fix these problems as you continue to develop and new exploits are discovered.

Game level Anti-Cheat

Your own development team can prevent and detect cheating at the game level using their knowledge of game-specific details. Games targeted by cheat sellers see major benefit from having a small development team to address game issues, complemented by the anti-cheat service.

Player reports

It is critical to implement the Reports Interface to allow players to submit reports when they believe another player in the same game session is cheating. This provides valuable context and feedback on the effectiveness of the anti-cheat protection in each game.

Player progression management

The anti-cheat service cannot effectively protect offline or solo play scenarios where progress is later synced to the game’s servers.

Game network architecture

The Anti-Cheat interfaces support different modes for a variety of game network architectures. While the Anti-Cheat Client interface supports each of these game networks, the Anti-Cheat Server interface works specifically for dedicated servers (client-server mode).

Dedicated server (Client-Server mode)

Use this mode with an authoritative game server, and implement both the Anti-Cheat Client and Server interfaces.

Communication flow of the Client-Server mode of network architecture

The operator of an individual game server can intentionally disable or disconnect the anti-cheat within their server by manipulating network connections or through other methods. This is an accepted risk for games that support community operated servers. To mitigate this risk, the user interface may differentiate between “official” and “unofficial” game servers.

You must match your client protected sessions with game server calls so that the client calls EOS_AntiCheatClient_BeginSession just before joining a game and triggering the game server to call EOS_AntiCheatServer_RegisterClient.

Peer-to-Peer mesh (Peer-to-Peer mode)

Use this mode with a full-mesh layout where each game client exchanges network messages with every other game client, but none of them has full authority over the game session.

Communication flow of the Peer-to-Peer mode of network architecture

In this mode, the Anti-Cheat Server interface is not used. Instead, each player uses the Anti-Cheat Client interface to verify that the others have anti-cheat protection active.

Call the EOS_AntiCheatClient_RegisterPeer function for each peer that participates in the same game session as the local user.

Listen server

When a single player acts as an authoritative game host for a game session, you must use either Peer-to-Peer or Client-Server mode.

Communication flow of the Listen Server mode of network architecture

With Peer-to-Peer mode:

  • The authoritative game host client should validate every player in the game session by registering each one as a peer and exchanging data as appropriate.
    • If a removal action required callback is triggered for a peer, the authoritative game host should kick that player from the game session.
  • Non-authoritative game clients should validate the game host client only by registering that specific client as a peer and exchanging data as appropriate.
    • If a removal action required callback is triggered for the game host, the non-authoritative client should disconnect and display an appropriate error message.

With Client-Server mode:

  • A simpler approach, but the authoritative game host client has a more privileged role with potential for abuse. In particular, a malicious authoritative game host client can intentionally block the anti-cheat from working in their session. If this is a concern, you should use the Peer-to-Peer mode implementation instead.
  • Implementation is the same as for dedicated servers, except that the logged-in local player must be specified in the call to EOS_AntiCheatServer_BeginSession.

Client credentials and policy configuration

When configuring your client credentials for the Anti-Cheat interfaces, consider your network architecture and use case.

For the Anti-Cheat Client interface, you should use the predefined GameClient policy type. The User Required flag should always be enabled for game clients.

For the Anti-Cheat Server interface and a game using only trusted official servers, you should use the predefined TrustedServer policy type and keep the credential secret.

The following policy actions are available:

authenticateForLocalUser Required Allows the client credential holder to authenticate itself with the anti-cheat backend using either the Client-Server or Peer-to-Peer anti-cheat client modes

authenticateForAnyUser Only use this policy action when the client hosts a listen server using the Client-Server mode. Allows the client credential holder to authenticate other users using the Anti-Cheat Server Interface

sendTrustedGamePlayDataForAnyUser Only use this policy action for a trusted, official dedicated server. Never use or publish for a game client or community hosted game server. Allows the client credential holder to submit anti-cheat gameplay data for any user, and should only be used with trusted official dedicated servers that you are confident cannot be tampered with.

Platform components

Using the Anti-Cheat interfaces requires distributing some binaries to game clients, included in the EOS SDK package. In the EOS SDK zip file, browse to SDK > Tools > EOS_AntiCheatTools. Files in the dist subdirectory should only be distributed to players as part of the game client. The other files are for development use only, and should not be distributed. You must update the platform component files in use every time you update to a new version of the EOS SDK.

Windows

The Anti-Cheat Client only supports 64-bit Windows versions. 32-bit games are supported as long as the operating system itself has been installed with 64-bit support.

ComponentFile NameDescription
Service InstallerEasyAntiCheat_EOS_Setup.exe(Required) Used to install, repair, or uninstall the Anti-Cheat Windows service
Anti-Cheat Bootstrapperstart_protected_game.exePrepares the anti-cheat and starts the game process with normal anti-cheat client protection available
ServiceEasyAntiCheat_EOS.exeA Windows service executable that allows the anti-cheat to initialize its other components

Windows 'dist' Subdirectory Structure

Windows service installer

For Windows, you must configure an anti-cheat system service to install and uninstall with your game. This requires the Windows user to have admin rights while installing the game, but does not require admin rights to start the game later. When an anti-cheat protected game starts, the anti-cheat bootstrapper automatically starts the Windows service. When the game exits, the Windows service automatically stops.

Configuration
  1. Obtain your ProductId from your Developer Portal.
  2. Configure your installer to run the following commands:
    • EasyAntiCheat_EOS_Setup.exe install <Your ProductId>
    • EasyAntiCheat_EOS_Setup.exe uninstall <Your ProductId>
  3. If successful, the process exit code of this command is 0. A non-zero process exit code indicates failure.
Store-specific prerequisites
Epic Games Store

Refer to the Epic Games Store documentation provided to you.

Steam

Refer to the Steamworks Installscript documentation. Typically, you define a “Run Process” block to trigger the service install operation and a “Run Process On Uninstall” block to trigger the service uninstall operation.

Steam Installscript functionality may not be available on platforms other than Windows.

Mac

ComponentFile NameDescription
Anti-Cheat Bootstrapperstart_protected_game.appPrepares the anti-cheat and starts the game process with normal anti-cheat client protection available

Mac dist Subdirectory Structure

Linux

ComponentFile NameDescription
Anti-Cheat Bootstrapperstart_protected_gamePrepares the anti-cheat and starts the game process with normal anti-cheat client protection available

Linux dist Subdirectory Structure

Linux Wine/Proton support

It is possible to run many Windows games on Linux using the Wine or Proton compatibility layers and the anti-cheat client protection can support this configuration. To enable support for your game, you must be using SDK version 1.14 or greater and activate a client module for the Linux platform.

Players running the game using Wine or Proton will use the Linux client module, so you should test and activate client module updates for Linux regularly in addition to Windows.

Console support

Console platforms generally rely on hardware security features to prevent arbitrary code execution, which is a prerequisite for most types of cheats. Because these platform-specific security features cover most needs, anti-cheat client protection is not offered for consoles. The Anti-Cheat Client interface in Peer-to-Peer mode can be used to support cross-platform play.

To support cross-platform play between PC and console users, you must first determine whether a player is using a platform that does not require client protection when they join a protected game session. This check must not rely on the player’s game client being untampered. Having the game client send a message indicating the platform it is using is not enough since a malicious user could manipulate the value to avoid anti-cheat enforcement.

The EOS Connect interface provides EOS ID Tokens which include a device type field that can be used to securely verify when a player is running the game from common consoles. To support other platforms you must consult the platform vendor’s own documentation and find a way to do a robust check with a platform ticket or token that the game client generates and the game server, backend, or peer player independently verifies. When these checks validate a user is on a console platform that does not require anti-cheat client protection, the client can be registered with anti-cheat using the EOS_ACCCT_UnprotectedClient flag to exempt the client from anti-cheat client checks. This allows them to still participate in Peer-to-Peer mode sessions with protected PC players or be referenced in server-side anti-cheat gameplay data collection.

For more information about ID Tokens, please refer to EOS ID Tokens or, for Epic Accounts, EAS ID Tokens.