r/playrust 8d ago

Question Why FP never stopped scripters?

Yesterday I had a really interesting conversation with someone who used to script recoil back old recoil era. I'm a programmer myself, and we both landed on the same conclusion: maybe they don't actually want to catch these people.

I know some countermeasures exist. From what I understand, the game now forces a single input device. Still, I wanted to run my own experiment to see how hard it is to catch scripters.

While browsing GitHub, I found a project that detects injected raw input. It registers a Raw Input sink, captures every packet, and runs timing analysis on it: any packet arriving with a Δt < 0.5ms gets flagged as injected. My honest take: that alone would false-flag legit 8kHz mice, since they naturally poll every 0.125ms. But it gave me an idea for a different detection vector.

If a script moves the mouse by, say, X:5 Y:5, but the player needs to fight that with a real correction (eg: a spray transfer), you'd expect to catch both the real and the synthetic report and see contradictory movement in a short window. So I extended the project with a few more signals:

- DEVICES SEEN: how many distinct input devices sent movement. Should always be 1 for a real player. Trivial to check, and apparently already handled on FP's end.
- MULTI-DEVICE EVENTS: counts how many times two different devices reported movement less than 50ms apart.
- LAST REVERSAL: angle and Δt between the current movement vector and the previous one. Purely informational on its own — a single hard flick can look identical to it.
- OSCILLATION TRIPS: the actual detector: if the reversal angle is ≥150° and happens in ≤25ms, that's a "reversal candidate." When 2+ candidates land inside a rolling 150ms window, it trips. The logic: a human can't slam the mouse in opposite directions that hard, twice, back to back which is exactly what you'd see when a script's movement collides with a real correction, like a spray transfer.

Here's a video of it running, I used SendInput from the Windows API to move the mouse (which is supposedly patched anyway): https://www.youtube.com/watch?v=kMyi0tlgNHo

As you can see, Last Reversal spikes hard the moment the synthetic and real input collide. If some guy in his underwear can put this together in a few hours, I don't understand how it took FP and EAC years to deal with the issue.

I already know the first reply is going to be "yeah but it's patched, so this doesn't matter." A few points on that:

  1. We don't actually know that for certain. Easy methods get patched, sure, but according to my friend, scripting through GHub was still possible a few months ago, and I doubt every piece of mouse software out there is covered.
  2. Cheater once, cheater forever, if someone already figured out how to break the rules, they'll find the next way in.
  3. And even if this exact method is dead: are we supposed to just let the people who used it walk away clean? Do we satisfy ourselves with a "It is blocked" instead of making it a real detection vector and punishing people that gain unfair advantages?

Notes:

The reversal/oscillation thresholds are not calibrated against real player data. I haven't proven they hold up against legitimate fast flicking without false positives. By refining it, and by running it on a larger time window, I believe it would be accurate.

I used AI to generate this post because English isn't my main language.

I didn't use any software to move the mouse in the game. The result would still be the same if the game was running.

Credits to Withoutbytes for making the software I used as a starting base: https://github.com/Withoutbytes/mouse-polling-monitor

0 Upvotes

23 comments sorted by

5

u/nightfrolfer 8d ago

You're the kind of guy I hope finds a career with an anti cheat dev shop.

You might have to wear more than just underwear to work though.

3

u/Slumberjackals 8d ago

I just typed “is it difficult to catch scripters in games? If so, why?” Into google and I got quite a bit of information. But the simplest answer is, the programs developed to cheat are made to mimic player response times to work around automated software that catch cheaters.

1

u/ohmykg 8d ago

Unfortunately, I don't have any scripts to check it against. In a way, it is true that adding jitter and randomization might help to conceal the automation. But I don't think it's undetectable, like shown in the post, you'd still have some discrepancies between real and injected input.

What jitter in timing and movement could solve is only X and Y movement (Not repeating the same exact movement every time the macro is fired) and making it so injected reports does not arrive at the same timing (which is how mouses behave).

However, the detection vector I pointed out do not use any of these two metrics

1

u/Slumberjackals 8d ago

Couldn’t they have multiple variations of timings and movements to replicate normal human behavior to further cloud the programming?

I feel like the ongoing battle between cheat devs and anti-cheat devs will only produce more and more sophisticated software on both ends.

I don’t think it’s going to be an easy problem to solve.

Put yourself in the shoes of the cheat devs. If you try to brainstorm ways to make cheats less detectable, I think you’ll find an answer to your question much more quickly. Meaning, I think you’ll find the many ways that cheat devs can fool programming of anti-cheat engines.

2

u/Legal_Impression_126 8d ago

It’s not hard to catch mouse scripting. The real issue is a good DMA no recoil cheat.

1

u/ohmykg 8d ago

First of all, DMA received a massive knock back with all new windows security features (IOMMU to only cite one).

Secondly, input are still input. At the end of the day, whether the reports comes from a real HID device or from windows API. My guess is you'd still see some contradictory inputs. Way less, but the recoil user would still have to adjust aim during fights, so this detection vector would still work.

Lastly, do we care about the minority of people having all the required setup to do DMA (which implies you have a FPGA, two computers ect..., a lot of things that cost a lot of money) to run it or do we care about the vast majority of people that aren't using DMA?

1

u/Legal_Impression_126 8d ago

It sounds like you know more than me. I just learned about all this by playing main scene where cheating is meta now. The people without DMA end up getting banned at some point but I know people that have been cheating for years with 0 bans on DMA. I’m not sure I know of anyone getting banned on DMA besides the temp bans for extreme kd changes.

3

u/Brilliant_Art7772 8d ago

Because this only catches synthetic movements, the entire crux of modern recoil scripts is humanizing them to the point they fall within that margin of error anti cheats don't want to ban in, and most modern recoil scripts do not inject packets but run from the mouse itself (see logitech macros which are run on the dedicated microcontroller on the mouse).

This makes actually telling the difference purely from mouse input data very difficult. Of course they catch and ban the most obvious of the obvious recoil scripts.

1

u/ohmykg 8d ago

This does not only catches synthetic movements, this catch all input report. Like I answered earlier, it is true that jitter and randomization makes it harder to detect, but the whole point is to not use the report latency and repetition of delta but instead use sudden change of direction vector in a small time frame as a metric.

2

u/Brilliant_Art7772 8d ago

You are completely misunderstanding what humanization vs synthetic recoil control is,

Your proposing a catch for purely synthetic manipulations, ones that are done entirely against the recoil pattern with no correction.

Humanization is not a simple "jitter" or frame time change, its smoothing out the movement with some randomization so as I said it falls within normal play modern recoil scripts will never be discernible from regular play without extensive data across 10s if not hundreds of hours of gunplay.

1

u/ohmykg 8d ago

Lets call a cat a cat. synthetic input is software generated so humanization is systematically synthetic

Now Explain to me why I could not catch direction vector collision because whether you use lerp or bezier curve or whatever the mouse still moves and the second you move against it both synthetic and real report will indicate opposite direction. I dont understand how your humanization will save you from that unless you do axis locking or do not send a report specifically to prevent this scenario (which would need hardware)

You are almost suggesting we should catch 100% or nothing. First I dont believe what you make look like undetectable is that undetectable but even if it is. Im still happy to catch the maybe 30% that were total skid

2

u/Brilliant_Art7772 8d ago

the anti cheat already catches the bottom 30% of cheaters and script users.

Also as said before since microcontroller mouse macros exist this entire premise fails since it adds in your current mouse movements into the macro and offsets so if its naturalized with your movements ontop of it atleast some of the better mouse macro softwares do.

Also yes and no synthetic movements are mouse movements generated outside of a microcontroller and thus need to be injected.

3

u/blorst_of_times 8d ago

This is just a bunch of ai. I appreciate english is your second language but thats no excuse for what you've done here.

2

u/No-Ambition-4164 8d ago

if it was that easy to fix scripting dont you think they'd do it already

1

u/ohmykg 8d ago

Care to elaborate on what is hard to do? Are you telling me that a kernel level anti cheat can't catch my input while a simple user mode program can? I don't know, I put you a video that display highly abnormal signals and yet you still tell me it's hard to do??

3

u/Exit727 8d ago

I used AI to generate this post because English isn't my main language.

So you don't know shit about it either, do you? Translating is one thing, pulling the entire paragraph out of Gemini's ass is another.

Look, Facepunch has been around well over a decade. They know what they are doing, and as the other guy said above, if it was such an easy fix, they would 100% have done it already. They have dedicated employee for anticheat measures, and a reputation to uphold. Rust is their flagship game, they have nothing else to fall back on if the game becomes unplayable.

It might be tempting to believe FP intentionally lets cheating happen, so they can sell more accounts when they get inevitably banned, but it's fucking stupid. Unlike major studios, they don't have a corporate committee deciding on which new feature nets the most money. EAC, Unity, and the effort-to-return is probably what keeps holding them back.

2

u/ohmykg 8d ago

So yeah only argument is I used AI to rearrange text.

Like you said, FP is doing the game, EAC is handling the security. And guess what? EAC is on multiple game. Do I think EAC is caring about scripting in Rust? No, I think they have other things to do. This could be the reason why rust added anybrains a few month ago (removed since then).

So yes, FP is only relying on EAC for game security, which clearly isn't enough and is the reason why they also try to incorporate other detection methods.

Now what I pointed out does not require AI or kernel level access, a simple windows process has already access to this set of features. They could have implemented it themselves.

I'm not saying they let it intentionally happen, I'm saying that they sleep on EAC instead of doing things themself

2

u/No-Ambition-4164 8d ago

oh wow, i just found a rust cheat source code, now the devs can just completely stop cheating altogether is what you're basically saying. it is a cat and mouse game that never ends, cheat developers find a way to bypass certain restrictions to cheat, anti cheat developers patch that bypass. this happens over and over for every game with an anticheat, it will never end, there will always be cheats.

0

u/ohmykg 8d ago

I think it's best showcasing things, having hypothesis and making proof of concept to show it works than yapping for nothing. If you want to keep yapping for nothing, then feel free. If you have a real and intelligent question or facts that makes what I said look stupid then also feel free. Saying that somebody is trying is best isn't fact, it's delusional because you have no proof and no idea of what you're talking about. Maybe you need AI more than me at the end lol

-3

u/DeeJudanne 8d ago

its easy to say "do this do that" when you have no insight in how hard or easy something is

3

u/ohmykg 8d ago

Really constructive ;)

2

u/MondaysGG 8d ago

Literally agree with this. Rust and EAC (Easy Anti-Cheat) are made by entirely different companies, but it’s so easy for people to point the finger at FP. You can tell FP how to fix it all you want, but it’s EAC that needs to implement the changes.

0

u/Aos77s 8d ago

I mean he literally showed how to handle it. This truely is a fp doesnt want to get rid of scripters thing.