Gold 9999, infinite health — the most direct cheat
Memory tampering is the most primitive and direct form of game cheat. Where SpeedHack warps the game's "time," a memory hack directly overwrites the values the game holds in memory at runtime — gold 100 to 9999, health 50 to infinite, a score to an arbitrary number. The tools are easy to get, too: Cheat Engine on PC and GameGuardian on Android are effectively the standard.
The biggest problem is that this tampering barely shows. Because values change quietly inside the client with no external network traffic or abnormal packets, segments with weak server cross-checking — shops, inventory, single-player scores, idle currency — are easily exposed.
This article looks at the exact procedure of memory tampering, why common defenses have limits, and what strategy actually stops it.
How a memory hack finds and changes values — the mechanics
Major memory editors work in a similar flow regardless of language or engine — four steps: "value scan → narrow → pointer lock → tamper."
Value scan (thousands of candidates) ──> Narrow (change value, rescan, intersect) ──> Pointer scan (survives restart) ──> Freeze/Edit (lock & tamper)
1) Value Scan The attacker enters a value shown on screen (e.g., gold 100) and scans all addresses in the process's allocated memory that store '100'. The first scan returns thousands or more.
2) Refine The attacker changes the value in game (e.g., spends gold down to 90) and rescans for '90', taking the intersection with the previous result. Repeating this narrows the candidates to one or two, pinpointing the address holding the actual gold data.
3) Pointer Scan Restarting the process changes the address every time due to ASLR and dynamic heap allocation. To overcome this, the attacker runs a pointer scan to trace a "stable pointer path that points to the value." The resulting pointer map (cheat table) finds the address again after restarts — and is easily shared between users.
4) Freeze/Edit The attacker changes the found address's value to any number, or activates "Freeze" to keep overwriting it with a fixed value so the game logic can't reduce it.
The key insight: it makes little difference whether Unity is built with Mono or IL2CPP. Value scanning looks for data sitting in memory as plaintext, so a variable declared as plaintext like int hp = 100; is likely exposed as '100' regardless of build backend.
Common defenses and their limits
1) Storing plain variables as-is — highly vulnerable
Using int gold or float hp without any handling makes them an immediate target at the 'value scan' step. It's the most common — and weakest — state.
2) Hiding values (simple obfuscation) — likely bypassed Adding a constant or XOR-ing before storing blocks naive value scans the first time. But attackers bypass it with an Unknown Initial Value Scan, narrowing by the trend of "did the value increase or decrease" rather than the exact number. Only the form of the displayed vs stored value differs; the tracking itself isn't stopped.
3) C#-based secure value types — risk of reverse-engineering exposure Encrypting the stored value and verifying integrity with a checksum is the right direction — tampering breaks the checksum, so it's detectable. But if the encrypt/decrypt and verification logic sits in C# (managed code), an attacker can use IL2CPP reverse engineering to understand the routine and extract the key, or NOP-out the verification logic. It's the structural limit that appears when the verification system lives in the same code layer as the attacker.
4) Server authority — strongest, but unrealistic to apply everywhere A design where the server owns important values and the client only displays them is ideal for security. But validating offline/single-player segments, or combat values and idle currency that update dozens of times per second, all on the server is constrained by latency and cost. Without a client-side first line, the server bears the burden of filtering all abnormal input after the fact.
Defending with Native-layer secure value types
The core matches SpeedHack defense — separate the sensitive data and its verification logic into a layer the attacker can't easily reach. Combine three elements.
(1) Data encryption and integrity Keep protected values (currency, health, score) in memory not as plaintext but encrypted, accompanied by a checksum proving integrity. A simple scan can't find the original value, and any forced overwrite is clearly detected as tampering via checksum mismatch.
(2) Move verification/decryption logic outside managed code (Native) Place the secure value's core processing in the Native C++ layer rather than C#. Resistance against attempts to bypass the defense by reverse-engineering C# scripts rises sharply. To manipulate a value, an attacker must first analyze the natively compiled protection logic and verification path — so the difficulty spikes.
(3) Detect abnormal memory-access behavior Identify cases where a value that should change stays abnormally fixed due to a pointer Freeze, or where traces of a known tampering tool are detected. Detection responses (log, terminate client, notify server) are set per operational policy.
OZero Security provides this principle as Zero-GC secure value types (Secure Types). It handles protected values in an encrypted, integrity-verified form while being optimized to incur no runtime GC allocation, so it applies even to frequently updated loops like combat and inventory with minimal overhead. Because the core verification logic lives in the Native C++ layer, it provides defense against managed-code tampering. Furthermore, applying the Plus Add-on's per-app Native Variant makes the protection logic's form different per build, preventing a cheat pattern or tool cracked in one game from applying directly to another.
Summary
- A memory hack works in the standardized process of value scan → narrow → pointer lock → tamper, and plaintext data is easily exposed regardless of build (Mono/IL2CPP).
- Simple obfuscation or in-C# protection logic can be bypassed by trend scanning and reverse engineering.
- Effective defense requires an organic combination of an encrypted/integrity data structure + verification logic separated into Native + abnormal-behavior detection.
- For the most important data, applying both server cross-validation and client security in a double layer is recommended.
Protecting even a single number requires defending against many attack vectors — memory scanning, pointer tracing, code reverse engineering. Building this yourself and keeping up with evolving cheat patterns is a heavy burden, so adopting a proven solution is the efficient choice.