We are working on online game, where server is running in Dedicated Server mode. Recently we encountered a problem of a cheating possibility with the use of Cheat Engine (third party software).
In our environment Dedicated Server and Client are running on different machines. On Client side Cheat Engine is starting, attaching to process of our game and accelerating it in 5 times.
- Character movement (made using standard UCharacterMovementComponent) accelerating in 5 times
- Animations with Root Motion accelerating in 5 times.
Movement and animations are accelerating on Client and on Server and the player is running and attacking faster.
A quick look at their site hints at snooping in the memory used by your game. I recommend reading into this paper by IBM on “Hiding symbol visibility”. Even though this one is targeted at IBM’s own compiler collection, I do know that MSVC++ supports similar functionality. Use the paper to find out correct terminology and from there on, google towards your solution. There are several ways to “confuse” cheaters this way. I hope it helps.
We experienced this exact situation in Paragon and Unreal Tournament. A common term for this sort of exploit is “speed hacking”.
We have added time discrepancy detection and resolution (aka speed hack protection) natively to CharacterMovementComponent to help protect against these types of exploits in CL2907678 in //UE4/Main, which is available on GitHub right now if you need it ASAP, or else it is included as a feature in the upcoming 4.12 engine release. You can quickly check if your current version of the engine has the required code by going to BaseGame.ini and looking for “bMovementTimeDiscrepancyDetection” variable - if you see it listed, you have it, otherwise you will need a newer version or integrate the changelist manually.
The following is an overview of how it works and what config variables you can use to tune the prevention to your specific project:
Detection works by the server comparing client ServerMove RPC timestamp deltas against the known server authoritative time delta since the last ServerMove RPC was received and keeping a running tally on this difference. When this time discrepancy reaches a configurable threshold we trigger detection and optionally resolution logic.
Resolution works by overriding future client ServerMove RPC delta times to server time and having a portion of those move deltas be used for “paying back” the stolen time (the total time discrepancy detected) until the time difference has equalized.
Time discrepancy protection is disabled by default, configurable options live in the GameNetworkManager - base values can be found in BaseGame.ini and can be overridden in your project-specific game config file. These options are the following:
bMovementTimeDiscrepancyDetection: Enable detection (triggers warning logs and resolution if enabled)
bMovementTimeDiscrepancyResolution: Enable resolution (correcting clients and making them pay back time)
MovementTimeDiscrepancyMaxTimeMargin: Maximum time client can be ahead before triggering detection/resolution
MovementTimeDiscrepancyMinTimeMargin: Maximum time client can be behind
MovementTimeDiscrepancyResolutionRate: Rate at which to “pay back” stolen time during resolution, defaults to 100%
MovementTimeDiscrepancyDriftAllowance: Accepted drift in clocks between client and server as a percent per second allowed (to help burst packet loss/performance hitches from triggering false positives)
bMovementTimeDiscrepancyForceCorrectionsDuringResolution: Whether to force client updates during resolution, needed for projects that have lenient movement error tolerances or ClientAuthorativePosition enabled
These settings will need to be tuned for your project and represent a starting point for the ongoing battle for online games that is cheat prevention.
Testing this logic out at a base level can be done without a cheat program using the slomo cvar on individual game clients, which is equivalent to what popular cheat programs effectively do. The new p.DebugTimeDiscrepancy cvar enables log spew of time discrepancy state on servers for help in tuning the above values to your project.
Please note that all of this is specifically for protecting against users moving too quickly and root motion happening too quickly. Any project-specific game logic outside of movement that users are able to exploit using these speed cheats will come down to making sure the “final say” is handled by the server, and is a much larger topic.
I hope this helps, thank you.