index

Your DMA Cheat Isn't Undetectable - Reverse Engineering Popular FiveM DMA Cheats

· 3min

It’s a common misconception that DMA cheats are undetectable simply because they don’t run on your primary machine. I had some free time and decided to reverse engineer a few of the more popular FiveM DMA cheats to see what was actually happening under the hood, and today I will explain why this isn’t the case.

1. The Reality Behind “Undetectable” DMA

This investigation came from reversing two different FiveM DMA cheats that implemented silent aim through a trampoline hook on a bullet processing routine (internally tied to sBulletInstance).

At a high level, the cheat’s design wasn’t subtle:

  • It intercepted execution at a key instruction (movss xmm3, [r9]).
  • Redirected flow into a custom codecave via a jmp.
  • Modified projectile end positions.
  • & then restored origional execution only when the feature was toggled off.

On paper, this sounds “clean”. In practise, it’s anything but.

2. How The Hook Actually Worked

The core trick was a classic trampoline:

  • The game executes a floating point move into xmm3.
  • The instruction is patched with a jmp to a codecave.
  • The codecave simply moves the aimbot’s target vec3 into the r9 register and then jumps back.

They key detail: this hook is conditional. It’s only actives while the silent aim key is held. So far, this is pretty standard “hiding in plain sight” cheat engineering.

_dt-35_dt-35

3. The Mistake

Here is where things get interesting. Even though the jmp is restored when silent aim is disabled, the codecave itself is never properly cleaned up. Which means that the shellcode remains in RWX memory. Only the entry hook is toggled, not the payload.

This creates a huge detection opportunity: instead of chasing ephemeral behavior, you can scan for persistent shellcode signatures. In other words, they tried to hide execution flow, but instead left the engine running.

4. Memory Forensics Beats “Stealth” Design

Because the codecave remains intact, you can detect usage indirectly:

  • Scan process memory regions for known shellcode patterns.
  • Identify the previously mentioned logic.
  • Correlate execution artifacts with hook activation windows

Even without catching the trampoline live, the footprint remains. This flips the problem on it’s head: you don’t need to observe the cheat in action - you just need to find where it has been.

5. Verifying Behavior

Both providers shipped with unpacked libraries, so to understand what was happening internally, I instrumented memory access patterns by replacing the provided vmm.dll with a modified build that logs read and write operations. Then, by injecting a lightweight DLL with a console output window, it became possible to debug the following:

  • Writes into the codecave region.
  • Restoration of original instructions after the keybind was released.

The logging made it obvious: the system wasn’t abstract, it was literally just a patch > execute > unpatch, with state left behind.

_dt-35

6. Why This Matters for Detection

The important takeaway isn’t the hook itself, it’s the architectural flaw of: temporary execution control does not guarantee temporary memory impact.

Even if the trampoline is removed, the game state is restored and the feature is disabled; the cheat still leaves allocated executable memory, persistent shellcode and reconstructible behavior patterns. Unfortuently for you, that’s enough for detection systems that focus on memory integrity over runtime observation.

7. What About Recoil & Spread Modifiers?

Other features in the same two cheats followed an even simpler model. Instead of constantly writing a value to memory (e.g. 0.0f vertical), they simply patched the prologue with nop’s. These are even easier to detect because they rely on: static byte patches, easily hashable instruction regions & known-good memory comparisons.

In other words, the sophistication doesn’t scale with the marketing claims.

8. Closing Thoughts

DMA cheats often rely on one narrative: “we’re outside the system, so we’re invisible.”

However these two cases show something different:

  • You don’t need kernel visibility to detect them.
  • You don’t need live interception.
  • You just need to observe what they forgot to clean up

And more often than not, that’s where the real evidence lives.

_dt-34