RedM mod menus: how they load, and how you see one without knowing its name
What a mod menu really does on a RedM server, the three signals that give it away without any blacklist or known name, and what no anticheat will ever see.
A mod menu does not announce itself. It appears in no resource list, it raises no error at startup, and the player using it behaves normally for three quarters of his session. When you finally notice, it is usually because another player filmed something impossible. This article explains where the menu gets in, what it gives the person paying for it, and which signals identify it - without ever needing to know what it is called.
Where the menu gets in
The first stage is an external program. It launches before or during the game, opens the process, and writes its own code into the game's memory space. From that instant the menu is no longer software sitting next to the game: it is inside it, with the same rights over the game that the game has over itself. It can call engine functions, read your client Lua once it has arrived on the machine, and hand control back without anything having visibly stopped. Serious loaders are protected - packed binaries, game functions resolved through their debug symbols - precisely so this step leaves no readable trace.
The second stage is the interesting one for us, because it touches your server. To run Lua with the rights of a resource - and therefore be able to trigger your network events, call your exports, pass for your own code - the menu hijacks a resource that is already running. It pushes its own values into that resource's global space, then its code wakes up in there as if it had always belonged. One real case we observed: the menu drops four variables (a user id, a token, a key) into the global table of a legitimate resource, before its own obfuscation layer even starts. Those four variables are its door handle, and they are also its behavioural signature.
There is a third route, a much louder one: starting a resource of your own. That requires access to the server, not to the client. If a menu is running as a declared resource, your problem is not a cheater, it is a member of staff.
Once it is inside, here is what the buyer gets:
Character state: invincibility, infinite ammunition, walking through walls, speed. These are engine function calls, free once you are on the inside.
Spawning: peds, horses, vehicles, objects, in bursts. This is the visible nuisance, the one your community complains to you about.
Your network events: the menu reads your client scripts, extracts the server event names, and replays them with whatever arguments it likes. This is by far the most expensive one for you - money, items, roles - and it does not look like cheating in the logs, it looks like your own economy.
Dumping: reading and exfiltrating your resources. The menu is not only trying to cheat, it is trying to copy your server.
Why a blacklist of names is worthless
The natural reaction is to keep a list: known menu names, suspicious resource names, event names, file hashes. It catches the first version, for a week. Then the author renames things. Some menus explicitly advertise a "change the name" button, others draw a random name at every launch, and the values dropped into the global space are generated on the fly. A blacklist does not describe a capability, it describes a spelling - and spelling is the cheapest thing in the world to change.
Three signals that do not depend on the name
1. The anonymous caller. On RedM every engine function call comes from a context. When the calling code belongs to a running resource, the engine knows which one. When it is injected code, there is no resource to name: the caller is unknown. The principle fits in one sentence: it is not the function being called that is suspicious, it is the fact that no resource claims it. Creating a horse, setting invincibility, going invisible - a roleplay server does all three all day long, but always from an identifiable script.
That signal alone would do damage, so we temper it: we require separate observations before an alert leaves, we ignore a tolerance window while the player is loading in - where the engine itself calls without a context - and the black screen of a fast travel temporarily disarms the "state" family. The values stay in-house: published, they become the margin the menu tucks itself into.
Withheld/Detection thresholds are never published: a value that is known is a value a cheat is tuned just underneath.
2. Writing into another resource's global space. This is the loading gesture itself. A resource does not write into another resource's global table: that is not how resources talk to each other, and no roleplay framework has any reason to do it. So we watch for that write. On our side it is swallowed: the value is accepted in appearance, then handed back corrupted while keeping the same shape, so the loader believes it succeeded and collapses further down the line - and the original token goes up into the case file. That token is not anonymous: it is the account that paid for the menu.
3. Mass reading of resource files. A dump does not hide very well: it reads a lot, fast, and it reads things no script ever opens in game. We measure the burst rather than the file, and we plant files that have no reason to be read - a legitimate script ignores them, a dumper swallows them with the rest and names itself. The limit is clear and we state it: this guard lives inside the game, so it sees the dumps that go through the game. A tool that copies your cache off the disk, outside the process, will never meet it. The only real answer to that one is contractual, not technical.
What this family of detection does not see
Everything above assumes the cheat talks to the engine. A fully external cheat does not: it reads the game memory from another process, sometimes from a second machine, it calls no function, it writes into no Lua state, and it merely draws on your screen or moves your mouse. None of our three signals fire, and no anticheat running inside the game can claim otherwise. A read-only ESP is in the same position: it changes nothing, so it contradicts itself nowhere.
What remains then is the effect: a shot following a trajectory no human produces, an aim that jumps and freezes, knowledge of positions the player should not have. You are no longer detecting the program, you are detecting its trace - that is the subject of our article on silent aim. And because the question always comes back: yes, the final decision has to be made somewhere other than the player's machine, which is the whole client versus server argument.
If you want to see what a menu loading file looks like - the unknown caller, the recovered token, the timestamp - the demo panel is open without registration, our RedM anticheat shows where this family sits among the others, and the general principles are laid out in how a RedM anticheat works.