Add configurable ping-flood speedhack detection (PingFloodMax)

[canerksk]

Adds a 30-second sliding window detector on packet 0x73 (ping) to catch clients running at abnormal speeds. ClassicUO sends one ping per second (~30/window); exceeding PingFloodMax triggers a warning log and kicks the client.

New sphere.ini option: PingFloodMax=50 (0 = disabled).

[Jhobean]

Interresting feature! It should prevent crappy player of flooding the server.

Why you talk about speedhack detection on the comment? Using speedhack send extra ping request?

[canerksk]

Interresting feature! It should prevent crappy player of flooding the server.

Why you talk about speedhack detection on the comment? Using speedhack send extra ping request?

Yes, ClassicUO's game loop is built on XNA/FNA.

Time.Ticks = (uint)gameTime.TotalGameTime.TotalMilliseconds;
In FNA, gameTime uses QueryPerformanceCounter. When Cheat Engine hooks this, the chain breaks like this:

Cheat Engine: 2x speed
QPC returns a fake value
FNA gameTime progresses 2x faster
Time.Ticks increases 2x faster
The 400ms delay in WalkerManager actually passes in 200ms
2x more movement packets are sent per second
Server packet flood → queue fills → ping flood

Please also try Default ClassicUO and Sphere-X;

https://www.cheatengine.org/downloads.php

[Jhobean]

Good to know thx!

What I noticed when implemented speedhack detection on sphere was the difficulty to detect speedhack 1.1 or 1.2. the problem is we aleays get false positive when a player have a shitty ping/ingernet connection.

By the way I like this new feature because it can permit admin to be more agile.

[51812180-gif]

Critical Vulnerability in Anti-Speedhack Detection (PR #1589)

The current implementation has a fundamental flaw that makes it largely ineffective against sophisticated speedhack usage.

The Problem:

The detection mechanism uses a 30-second sliding window to count ping packets. However, this approach can be easily bypassed through "time compensation attacks":

• A player can accelerate (e.g., 4x speed) for a few critical seconds during PvP combat
• Then immediately decelerate (e.g., 0.25x speed) for an extended period to "compensate" and bring the average back within normal thresholds
• Since the 30-second window averages out the traffic, the total packet count appears normal even though the player gained significant unfair advantage during key moments

Example Attack Scenario:

• First 25 seconds: Normal speed (25 pings)
• Next 3 seconds: 4x acceleration (12 pings instead of 3)
• Last 2 seconds: 0.25x deceleration (0.5 pings instead of 2)
• Total in 30s window: ~37.5 pings — still within acceptable range!

Why This Is Critical:

In PvP scenarios, even 2-3 seconds of accelerated movement can determine the outcome of a fight. The current system cannot detect short bursts of speedhacking followed by compensatory slowdowns.

Conclusion:

This detection method is basically ineffective because:

1. Players can freely use speedhacks as long as they compensate with slowdowns
2. A 30-second window is far too long — it allows extensive manipulation
3. The server cannot distinguish between intentional slowdowns and legitimate network lag

Recommendation: Implement multi-timescale detection (1s, 5s, 30s windows simultaneously) and monitor sudden rate-of-change spikes, not just total counts.

[GladieUO]

Critical Vulnerability in Anti-Speedhack Detection (PR #1589)

The current implementation has a fundamental flaw that makes it largely ineffective against sophisticated speedhack usage.

The Problem:

The detection mechanism uses a 30-second sliding window to count ping packets. However, this approach can be easily bypassed through "time compensation attacks":

• A player can accelerate (e.g., 4x speed) for a few critical seconds during PvP combat
• Then immediately decelerate (e.g., 0.25x speed) for an extended period to "compensate" and bring the average back within normal thresholds
• Since the 30-second window averages out the traffic, the total packet count appears normal even though the player gained significant unfair advantage during key moments

Example Attack Scenario:

• First 25 seconds: Normal speed (25 pings)
• Next 3 seconds: 4x acceleration (12 pings instead of 3)
• Last 2 seconds: 0.25x deceleration (0.5 pings instead of 2)
• Total in 30s window: ~37.5 pings — still within acceptable range!

Why This Is Critical:

In PvP scenarios, even 2-3 seconds of accelerated movement can determine the outcome of a fight. The current system cannot detect short bursts of speedhacking followed by compensatory slowdowns.

Conclusion:

This detection method is basically ineffective because:

1. Players can freely use speedhacks as long as they compensate with slowdowns
2. A 30-second window is far too long — it allows extensive manipulation
3. The server cannot distinguish between intentional slowdowns and legitimate network lag

Recommendation: Implement multi-timescale detection (1s, 5s, 30s windows simultaneously) and monitor sudden rate-of-change spikes, not just total counts.

This is valid concern, and the sphere.ini setting to change the 30s to prefered value would be good.
However all you mentioned would mean A) players know there 30 seconds window, and they know the window started now, and ends in next 30s B) they would have to slow down to 0,25x for some time, which is also a big disadventage as fduring the 30 seconds, the PvP fight might still we ongoing.

[canerksk]

This change is not a fundamental security measure, but rather an additional measure to those already in place. It should not be used as a standalone measure; it can be supported by other measures.