[BUG]: StrafeBoost Exploit

[huisos43]

👉👈 Contact Details (optional)

https://www.pochta.ru

🤔 What happened?

Hello, ancient Greeks!

Pred-message

I recently played on a public server that has all sorts of fps-limit plugins that cap FPS to a maximum of 200. A cheater joined and flew across the entire map at incredible speed, his strafe boost reaching significantly higher than at 200 FPS.
I observed this from spectator mode, and the server displayed the cheater's 200 FPS, with no hints of bypassing the fps-limit plugins.

Checking in own server

Also, a similar cheater joined my Portuguese kz server. I thoroughly checked to make sure it wasn't bypassing the fps-limit plugins or skip-frameing. I checked everything I could: cvars, cmd->msec, the number of clc_move calls, the number of PPS from the incoming IP. Everything matched the results of regular players playing at 100 FPS, but again, his strafe boost didn't match the 100 FPS boost.

Trying detect problem

I settled on the option of possibly exploiting the game's processing itself, and installed ReGameDll to check exactly what was happening in the PM_AirMove and PM_AirAccelerate functions.

I came across something strange in this function from these cheaters. If you're familiar with the Half-Life 2 situation (backward bunny hopping and acceleration), something similar is happening here.

How u known these cheaters:

1. The camera didn't strafe (there was no movement with cmd->viewangles)
2. There was a huge boost from strafes that didn't correspond to the FPS.

When checking the values ​​in the above functions (PM_AirMove, PM_AirAccelerate), these player`s angles were closer to 360 degrees (not 180), meaning they were strafeing backwards.
The problem was solved in the usual way—simply normalizing the angles, these cheaters stopped boosting their strafe speeds.

My guesses

I don't fully understand how the entire calculation in the PM_AirAccelerate function works, but it's possible it's related to a bug from Half-Life 2 that no one noticed.
My guess is that when the "Y angle overflowed," the "real_t currentSpeed" variable was giving too low a value, causing the subsequent algorithm to heavily boost these cheaters.

I could be wrong about a complete fix by normalizing angles; cheaters might brute-force that same maximum 180-360 angle so that the subsequent algorithm with "currentSpeed" produces the lowest result and the end-result be same (very high boost).

⚠️ Meta-information

Protocol version 48
Exe version 1.1.2.7/Stdio (cstrike)
ReHLDS version: 3.14.0.857-dev
Build date: 19:52:21 Mar 27 2025 (4002)
Build from: https://github.com/rehlds/ReHLDS/commit/89958d3

ReGameDLL version: 5.28.0.0-dev
Build date: 18:47:07 Feb 04 2026
Build from:

Metamod-r v1.3.0.149, API (5:13)
Metamod-r build: 11:31:17 Apr 23 2024
Metamod-r from: https://github.com/theAsmodai/metamod-r/commit/603a257

Currently loaded plugins:
      description   stat pend  file                       vers            src  load  unload
 [ 1] AMX Mod X     RUN   -    amxmodx_mm_i386.so         v1.10.0.5474    ini  Start ANY
 [ 2] Reunion       RUN   -    reunion_mm_i386.so         v0.2.0.25       ini  Start Never
 [ 3] Revoice       RUN   -    revoice_mm_i386.so         v0.1.0.34       ini  Start Never
 [ 4] ReSemiclip    RUN   -    resemiclip_mm_i386.so      v2.4.3          ini  Chlvl ANY
 [ 5] FakeMeta      RUN   -    fakemeta_amxx_i386.so      v1.10.0.5474    pl1  ANY   ANY
 [ 6] hackdetector  RUN   -    hackdetector_amxx_i386.so  v0.15.328.lite  pl1  ANY   ANY
 [ 7] GeoIP         RUN   -    geoip_amxx_i386.so         v1.10.0.5474    pl1  ANY   ANY
 [ 8] Ham Sandwich  RUN   -    hamsandwich_amxx_i386.so   v1.10.0.5474    pl1  ANY   ANY
 [ 9] Fun           RUN   -    fun_amxx_i386.so           v1.10.0.5474    pl1  ANY   ANY
 [10] CStrike       RUN   -    cstrike_amxx_i386.so       v1.10.0.5474    pl1  ANY   ANY
10 plugins, 10 running

Linux

📄 Relevant log output

[T4lk]

nothing to do with regamedll, sending fake cvar to server under fps limit, can't fps limit server side very hard cause client can report bogus stuff, and just strafe hack

https://github.com/oxiKKK/oxware/blob/main/src/cheat/features/movement/StrafeHack.cpp

[huisos43]

nothing to do with regamedll, sending fake cvar to server under fps limit, can't fps limit server side very hard cause client can report bogus stuff, and just strafe hack

https://github.com/oxiKKK/oxware/blob/main/src/cheat/features/movement/StrafeHack.cpp

I don't understand what you're talking about.
I wrote about checking a cheater to ensure they aren't bypassing fps-limit plugins (and it`s true, cheater(-s) not bypassing fps-limit plugins).

Cheaters use an exploit located in the ReGameDll PM_AirAccelerate() function -

ReGameDLL_CS/regamedll/pm_shared/pm_shared.cpp

Line 1336 in 4dddce6

void EXT_FUNC __API_HOOK(PM_AirAccelerate)(vec_t *wishdir, float wishspeed, float accel)

Look closely at the code algorithm to the currentSpeed variable -

ReGameDLL_CS/regamedll/pm_shared/pm_shared.cpp

Line 1356 in 4dddce6

addspeed = wishspd - currentspeed;

As I understand it, if var currentSpeed ​​is low (closer to 0), then you will get a much greater boost from strafe per frame coming from the client (cheater) than your regular cheat algorithm that uses perpendiculars - https://github.com/oxiKKK/oxware/blob/main/src/cheat/features/movement/StrafeHack.cpp

I tested the oxware cheat, when starting ragestrafeing, the currentSpeed var is as close as possible to wishSpeed (30 | 30), and I am writing to you that cheaters using the exploit have a significantly different ratio of currentSpeed and wishSpeed (30 | 0), which gives a HUGE boost when strafe from the first frame

If you write "this calculation is reverse-engineered from the original mp.dll," I don't argue, but this broken ratio (30 | 0) shouldn't exist because it's exploitation.

You should have noticed that for regular cheats and the one you cited as an example (oxware), this ratio is equal to the normal (30 | 30) and gradually decreases, which provides a smooth transition from a smaller to a larger speed increase per frame received from the client (cheater). However, if you bruteforce angles closer to 180-360 degrees, which aren't normalized, this causes exploitation of this ratio between currentSpeed and wishSpeed. From the first frame, it will be equal to (30 | 0), there is no smooth transition, and the huge speed increases immediately after the client (cheater) sending a frame.

[RauliTop]

When checking the values ​​in the above functions (PM_AirMove, PM_AirAccelerate), these player`s angles were closer to 360 degrees (not 180), meaning they were strafeing backwards. The problem was solved in the usual way—simply normalizing the angles, these cheaters stopped boosting their strafe speeds.

You can share the code you used, to help other people checking this exploit.

[huisos43]

When checking the values ​​in the above functions (PM_AirMove, PM_AirAccelerate), these player`s angles were closer to 360 degrees (not 180), meaning they were strafeing backwards. The problem was solved in the usual way—simply normalizing the angles, these cheaters stopped boosting their strafe speeds.

You can share the code you used, to help other people checking this exploit.

I'm not a coder, I just wrote what I know.

Writing code here for cheaters to use is not the best idea. To test this exploit, you only need to bruteforce the angles for strafe. You will notice that values ​​closer to 180-360 (not normalized) give currentSpeed ​​0 and your boost from strafe in each frame received from the client to the server will be huge.

[RauliTop]

I'm not a coder, I just wrote what I know.

Writing code here for cheaters to use is not the best idea. To test this exploit, you only need to bruteforce the angles for strafe. You will notice that values ​​closer to 180-360 (not normalized) give currentSpeed ​​0 and your boost from strafe in each frame received from the client to the server will be huge.

What's the meaning of your posts?
You came here, posted some exploits with crappy explanations and you probably go away few days later.

If you really want to help community, you already know what have to do.

[huisos43]

What's the meaning of your posts?

meaning iam sexy, u dont see my photo?

You came here, posted some exploits with crappy explanations and you probably go away few days later.

if is it, why u tell this offtop message? but nope, i`am sit down in there and not going away.

If you really want to help community, you already know what have to do.

there's a big difference between the cheater and defender communities, and you're asking me to do work that I did exclusively for myself, asking me to do a PR, then you'd find a vulnerability there and ridicule my PR, but here's the catch - if I wanted, these exploits would have already been fixed a month ago with my one fat, big PR, but in the end, I can give you something else fat and big with yogurt.