A mod menu is the most visible cheat a FiveM server deals with: a floating panel that spawns vehicles, hands out weapons, teleports across the map, and pushes money into an inventory. Catching one is not a single trick. It is three detection layers working at the same time, refreshed on a schedule, because the people who write these menus rewrite them the moment a detection lands.
What a mod menu actually is
Before you can detect a mod menu you have to be precise about what it is. On FiveM the term covers a family of internal cheats that run inside the game client and give the player a graphical interface for actions they should never have. Public families like Eulen, Redengine, and HamMafia all ship some version of this: a panel, a feature list, and a loader that gets it running.
The menu itself is the easy part to see. The hard part is how it gets into the process in the first place, and that is where detection starts.
How mod menus get in
There are three common paths a menu uses to reach the game, and each one leaves a different kind of trace.
Lua executors
FiveM runs a lot of game logic in Lua. An executor abuses that by loading attacker-controlled Lua into the running client, so the menu rides on the same scripting layer your legitimate resources use. This is attractive to cheat authors because it does not require touching native game memory directly: the Lua state is already there, already trusted, and already wired to call into game functions.
In-process injection
The heavier approach loads a native module straight into the FiveM process. Once code is running inside the process it can hook functions, patch memory, and draw its own interface using the same rendering path the game uses. This is more powerful than a Lua executor and also noisier, because injecting a module changes the shape of the process in ways an anti-tamper loop can watch for.
NUI DevTools
FiveM user interfaces are built on a browser layer called NUI. That layer ships with developer tooling, and a careless or deliberately misconfigured client can open DevTools against game UI, then use it to read and manipulate the interface from the inside. It is a quieter path than injection, but it still produces signals: the tooling has to attach to something, and that attachment is observable.
Layer one: loader signatures
Every menu needs a loader, the small piece of code that gets the rest of the cheat running. Loaders are the first thing Raven Anticheat looks for, because they are shared across many users of the same public cheat and they have to touch the system in recognizable ways.
Raven Anticheat maintains a signature catalog for known loaders and matches against it client-side. The catalog is not static. Detection updates ship on a one to seven day cadence with a dated public changelog, which means a loader that gets caught on Monday does not get a free week to circulate. When a public family like Redengine pushes a new build, the catalog gets a new entry rather than relying on a stale pattern that no longer matches.
Signature matching is fast and high-confidence when it hits, but on its own it has a known gap: a loader that was rewritten yesterday may not have a signature yet. That gap is exactly why one layer is never enough.
Layer two: runtime integrity of the Lua state
The second layer stops asking what the client looks like and starts asking whether the running game has been tampered with. Raven Anticheat runs runtime integrity checks on the client, including the Lua state that executors and menus depend on, with a heartbeat anti-tamper loop reporting that runtime state to the server on a continuous basis.
The logic here is simple to state and hard to evade. A clean client has a Lua state that behaves a certain way: the functions it exposes, the values it holds, the structure it presents to the rest of the runtime. A menu that has injected itself or loaded attacker Lua leaves that state altered. The heartbeat loop watches for those alterations on a continuous basis rather than scanning once at connect time, so a cheat that loads after the player is already in the server still gets seen.
- It catches menus that have no signature yet, because tampering looks like tampering regardless of which build did it.
- It catches late injection, because the loop never stops checking after the first scan.
- It pairs with the signature layer: a signature confirms which cheat, integrity confirms that something changed at all.
Layer three: server-side event validation
The first two layers live on the client, and anything on the client can in theory be lied to. The third layer does not run on the client at all. Raven Anticheat is dual client plus server-side by default, and the server-side half validates the events a player actually sends.
This matters because a mod menu is, in the end, defined by what it does. It spawns a vehicle the player should not be able to spawn. It fires a give-weapon event that no legitimate gameplay path produces. It teleports, it sets health, it pushes an inventory change the server never authorized. Server-side validation rejects those actions on their merits, independent of whether the client scan caught the menu that produced them.
The practical effect is a floor under your security. Even a menu with a brand new loader and a clever integrity bypass still has to send events to a server that is checking them, and the actions a menu exists to perform are the actions validation is built to refuse.
Why detection has to be continuous
None of these layers is a one-time fix, and the reason is the loaders. The moment a public cheat sees its loader getting caught, the authors rewrite it. A new build ships, the old signature stops matching, and circulation continues under a fresh pattern. This is not a bug in signature detection; it is the normal rhythm of the cheat market.
That rhythm is why the one to seven day cadence exists and why the changelog is dated. Continuous updates are the response to continuous rewrites. The integrity loop and server-side validation hold the line in the windows between signature updates, so a rewritten loader buys the cheat author much less time than it would against a signature-only product. Detection is a standing operation, not a finished feature.
How Raven Mind keeps false positives down
The danger of running three aggressive detection layers is that aggression produces false positives, and a banned legitimate player is its own kind of failure. Raven Mind is the layer that manages that tension. It scores every detection rather than treating each one as an automatic ban.
When a detection fires, Raven Mind replays how the network handled the same signature before. If that pattern has a history of being a real cheat, the call is clear. If the signal is ambiguous, the default is not to ban: the default is to hold and ask. Borderline calls escalate to a Discord review card where a human makes the decision, and the obvious clean cases get cleared without ever reaching an admin queue.
- Clear cheat signature with a banning history: actioned with evidence captured.
- Known benign pattern that has tripped before: cleared automatically, no admin time spent.
- Ambiguous call: held and sent to a review card instead of issuing a ban.
The point is not to soften detection. Real menus still get caught by the three layers underneath. Raven Mind sits on top and makes sure the cost of catching them does not land on a legitimate player who happened to trip an edge case. Confirmed bans also feed the evidenced Global Ban Database that Raven Anticheat shares across servers, so a menu user caught on one server does not start clean on the next.
What this looks like to run
All three layers and the scoring on top run from a single install. Raven Anticheat is one line in server.cfg, ensure rac, with the framework auto-detected across ESX, QBCore, vRP, QBox, and standalone, and the whole setup takes about two minutes. The detection work described here runs under 0.5ms on the FiveM resource monitor at 200 or more players, so the layered approach does not cost you server performance to keep mod menus out.