x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

[Closed] Client speed hack

I've been reading CharacterMovementComponent.cpp for a while (nice read, btw) but haven't found anything that would prevent client from pretending that it moves with increased time speed compared to real time. For example, client could always use x2 delta time (thus, resulting in x2 move distances).

Am I wrong and there is some code that protects from this?

Product Version: Not Selected
Tags:
more ▼

asked May 31 '16 at 06:47 PM in Using UE4

avatar image

Answers.Archive STAFF
1.9k 197 306 678

avatar image Answers.Archive STAFF May 31 '16 at 06:47 PM

The server should correct for any illegal movement causing them to bounce around. This isn't necessarily a good thing though. Unreal Tournament implements it's own version of speed hack detection where it pauses player updates until the server catches up to where it thinks the client is (at least that is my understanding). Paragon just recently encountered a version of this exploit and is doing work to block and detect this. I'll add those folks that addressed this to this ticket so they can add any extra info

avatar image Answers.Archive STAFF May 31 '16 at 06:47 PM

Your assessment is correct.

As Joe says, UT implements speedhack detection and prevention, and Paragon very recently (a few days ago) brought that over. We are currently iterating on it (testing against real-world cheat programs) and will integrate it over to mainline once we've cut down on the false positives.

Current implementation compares the time delta of timestamps reported through ServerMove RPCs to time passed on the server and makes the client "pay back" any significant deviation by forcing future MoveAutonomous calls to have near-zero tick time (until the server has caught up).

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

The question has been closed May 31 '16 at 06:48 PM by AndrewHurley for the following reason:

The question is answered, right answer was accepted


1 answer: sort voted first

Speed hack detection and protection is available at the engine level in CharacterMovementComponent (although disabled by default) as of CL2907678 in //UE4/Main, which is available in the master branch on GitHub right now. This should make it into 4.12 release.

The following is the changelist description, containing a short description and the options for enabling it:

Character Movement Time Discrepancy Protection

  • Added time discrepancy detection and resolution logic to CharacterMovementComponent, meant for protecting networked games against client time manipulation (speed hacks)

  • Detection works by the server comparing client ServerMove RPC timestamp deltas against the known server authoritative time delta since last ServerMove was received over time, and when that discrepancy reaches a configurable threshold we trigger detection and optionally resolution code. Resolution works by overriding future client ServerMove RPCs 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.

  • Disabled by default, options live in GameNetworkManager and are the following:
    • bMovementTimeDiscrepancyDetection: Enable detection

    • bMovementTimeDiscrepancyResolution: Enable resolution

    • 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

  • Added ClientErrorUpdateRateLimit GameNetworkManager parameter as a way of limiting client error update rates. Previously AGameNetworkManager::WithinUpdateDelayBounds only dynamically triggered based on the ratio between CLIENTADJUSTUPDATECOST and a player's CurrentNetSpeed, now it can (optionally) be made more explicit. When enabled, this reduces burden on the server of sending enormous number of updates to clients with extremely high FPS (300+ FPS)

  • Added the above settings to BaseGame.ini, cleaned up deprecated GameNetworkManager parameters

  • Detection and resolution logic lives within UCharacterMovementComponent::ProcessClientTimeStampForTimeDiscrepancy(). This triggers virtual UCharacterMovementComponent::OnTimeDiscrepancyDetected() for project-specific alerts/handling.

  • Added several new variables to FNetworkPredictionData_Server_Character for time discrepancy purposes, and cleaned up existing comments.

  • Renamed MaxResponseTime in prediction data to MaxMoveDeltaTime to reflect what that variable has actually been doing for a few years now (previous comments/naming confused it with MAXCLIENTUPDATEINTERVAL), deprecated MaxResponseTime so projects have an easier transition, added GameNetworkManager::MaxMoveDeltaTime config variable for setting the default value per-project.

  • Made several pre-existing GameNetworkManager variables configurable in ini files and exposed in BaseGame.ini for better discoverability

  • Did a fix-up pass on global and actor time dilation usage in CharacterMovementComponent - there were several instances where AActor::CustomTimeDilation was being double-applied or misused, tested both global slomo and CustomTimeDilation thoroughly to ensure movement code and time discrepancy detection/resolution handles it correctly

  • Changed ServerMoveOld to use same DeltaTime calculation/tracking as ServerMove RPC does so that they're consistent and so time discrepancy detection works with both.

  • Added virtual UCharacterMovementComponent::OnClientTimeStampResetDetected() function so that if projects have specific need for knowing when client time stamps occur there's an easy way to access that information. Use case for this would be wanting to track how often clients attempt to reset their time stamps, another possible avenue for exploitation.

  • Added p.DebugTimeDiscrepancy cvar for enabling log spew of time discrepancy state on servers

Let me know if you have any questions or run into issues enabling it for your project. It should work out of the box as soon as you enable detection and resolution in DefaultGame.ini, see BaseGame.ini [/Script/Engine.GameNetworkManager] section. Default DraftAllowance is set at 0% so that there's no forgiveness for initial testing purposes, but for a live game I would recommend bumping that up to cut back on false positives.

more ▼

answered May 31 '16 at 06:47 PM

avatar image

Answers.Archive STAFF
1.9k 197 306 678

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question