How it works
Internal vs External Cheats: Risk, Feature Set and Performance Compared
The same feature list can be built two ways: inside the game process or outside it. That single architectural choice decides what is possible, what it costs in performance and what an anti-cheat has to work with.
Internal versus external describes where the cheat’s code lives relative to the game process. It is not a price tier — it is an engineering fork, and feature set, performance cost and the shape of the risk all follow from it.
Internal
The code is loaded into the game’s address space, by DLL injection or by manually mapping an image into memory. Once inside, it operates as a peer of the game: it reads and writes game structures directly, hooks calls, and can render through the game’s own graphics pipeline.
What you gain:
- the widest possible feature set, including anything that requires touching game logic;
- drawing inside the game’s frame rather than on top of the window;
- minimal latency — data is read where the game itself uses it;
- near-zero performance overhead.
What you pay:
- a foreign module sits inside the process whose integrity the anti-cheat watches most closely;
- a bug crashes the game, not a separate application;
- every game update breaks more, because the dependency on internals runs deeper.
External
The code runs as a separate process and reads the game’s memory from outside. The classic implementation uses system memory-reading APIs; the more advanced one uses its own kernel driver (kernel-external). Rendering happens in a separate overlay window on top of the game, or on a second screen.
What you gain:
- no foreign module inside the game process;
- a cheat crash does not take the game down;
- game updates usually require address fixes rather than a redesign.
What you pay:
- a narrower feature set — without calling game functions, many things are approximated or unavailable;
- the overlay is its own attack surface: it is visible to capture software and bound by windowing rules;
- continuous memory reading costs CPU time;
- reaching into another process from outside is itself an observable event.
Side by side
| Criterion | Internal | External |
|---|---|---|
| Where the code runs | inside the game process | separate process or driver |
| Feature set | broader | narrower, mostly reading |
| Latency | minimal | one read cycle behind |
| FPS impact | negligible | noticeable on weak systems |
| On crash | takes the game with it | game keeps running |
| What the anti-cheat sees | foreign module, hooks | process access, driver, overlay |
| Sensitivity to patches | high | moderate |
The third option: DMA
A separate card plus a second PC is the external model taken to its logical conclusion: reads are performed by a PCIe device and nothing at all runs on the gaming machine. Cost, components and real limits are covered in the DMA guide.
Matching type to game
- Fast competitive shooters — Counter-Strike 2, Apex Legends — reward precision and low latency, which historically favoured internal builds. In CS2, however, a league client such as FACEIT AC often sits on top of the game’s own anti-cheat and changes the calculation entirely.
- Extraction and survival titles — Escape from Tarkov, Rust — are mostly about information: loot, players, rotations. An external build or a second-screen radar covers that well.
- Titles with strict system requirements (Secure Boot, TPM, driver blocklists) often decide for you: the question stops being preference and becomes what will launch at all.
The practical takeaway
Implementation type is an input parameter, not a quality rating. A badly written external cheat is more dangerous than a well written internal one, and the reverse is equally true. Judge a purchase on the build’s detection history, its turnaround after patches and the state of its support — and use the internal/external distinction to predict what the thing can do and what it will cost you in frames. For what the features themselves mean, see ESP, aimbot and the rest; for pre-purchase due diligence, the selection checklist.