Cheat Engine Code Injection Tutorial for Beginners

Basic memory editing can take you surprisingly far in Cheat Engine. You can find health, change money, freeze stamina, and generally convince a game that arithmetic is optional. But sooner or later, changing the value itself is not enough.

Maybe the game keeps restoring it. Maybe you want to change how damage works rather than simply freezing health. Maybe you want more control than replacing one instruction with NOPs. That is where code injection comes in.

Code injection lets you redirect a game’s existing instruction into a small block of custom assembly code, run your own logic, and then return to the original flow.

If you have not used Find Out What Writes to This Address yet, learn that first. Code injection makes much more sense once you already know which instruction you want to modify.

What Is Code Injection in Cheat Engine?

Suppose you find this instruction responsible for reducing health:

sub [rbx+30],eax

The simplest modification would be to replace it with NOPs so it stops running. That may work, but it gives you very little control. If the same instruction also affects enemies, you may accidentally make everyone immortal.

Code injection takes a different approach. Instead of simply deleting the instruction, you replace it with a jump to a new block of memory containing your own code. Your custom code runs there and then jumps back to the game.

Conceptually:

Original game code
 ↓
Jump to injected code
 ↓
Run custom instructions
 ↓
Return to the game

That detour is the injection.

Start With the Instruction You Want to Modify

Health is a good beginner example. Find the health address normally, then use Find Out What Writes to This Address and take damage. Imagine you find:

sub [rbx+30],eax

Open that instruction in Cheat Engine’s Memory Viewer, then open the Auto Assembler and use the Code Injection template.

Cheat Engine can generate most of the boilerplate automatically, which is much safer than manually guessing instruction sizes and jump locations.

What a Basic Injection Script Looks Like

A simplified script may look like this:

[ENABLE]
alloc(newmem,1024)
label(return)
newmem:
 sub [rbx+30],eax
 jmp return
Game.exe+123456:
 jmp newmem
 nop
return:
[DISABLE]
Game.exe+123456:
 sub [rbx+30],eax
dealloc(newmem)

The exact output will vary depending on the game and instruction, but the structure is what matters.

Do not copy Game.exe+123456 literally. It is only an example address.

[ENABLE] and [DISABLE]

Cheat Engine table scripts usually contain:

[ENABLE]

and:

[DISABLE]

The code under [ENABLE] runs when you activate the script. The code under [DISABLE] restores the original behaviour when you turn it off. A good injection script should always be reversible.

If enabling the cheat is easy but disabling it requires restarting the game, the script is not finished yet.

In case you need it: How to Automatically Enable Cheat Engine Scripts After Attaching to a Game

What Does alloc() Do?

This line:

alloc(newmem,1024)

asks Cheat Engine to reserve a new block of memory inside the target process. That is where your custom assembly code will live.

The name newmem is simply a label, while 1024 is the amount of memory being reserved. For a small injection, that is usually more than enough. The important part is that your custom code gets its own safe space instead of overwriting unrelated game instructions.

What Does newmem: Mean?

This:

newmem:

marks the beginning of your injected code.

For example:

newmem:
 sub [rbx+30],eax
 jmp return

currently performs the original instruction and then returns to the game.

That may seem pointless, but it is actually useful for testing. Before changing anything, enable the untouched injection and make sure the game still behaves normally. If it does, you know the detour itself works.

Then you can start modifying the logic.

Why Keep the Original Instruction?

When the injection is installed, the original instruction is replaced by a jump:

jmp newmem

That means the original code no longer runs at its old location. If the game still needs that instruction, you must execute it inside your injected code.

In this example:

sub [rbx+30],eax

still performs the health subtraction. Removing it entirely would prevent damage, but only if that is actually what you want.

This is why code injection is more flexible than simply NOPing an instruction. You can decide when the original code should run and when it should not.

What Do jmp newmem and jmp return Do?

This:

jmp newmem

redirects execution from the original game code into your allocated memory.

Then:

jmp return

sends execution back to the first instruction after the overwritten bytes.

So the flow becomes:

Game code → newmem → custom logic → return → game continues

That is the entire structure of a basic injection.

Why Is There Sometimes a nop?

You may see:

Game.exe+123456:
 jmp newmem
 nop

The jump may use fewer bytes than the original instruction or instructions being replaced. The extra nop fills the remaining space so that no partial instruction is left behind. You generally do not need to calculate this manually if you use Cheat Engine’s injection template.

That is one of the reasons the template exists.

Making the Injection Do Something

Once the basic injection works, you can modify the logic inside newmem.

Suppose the original code is:

sub [rbx+30],eax

If you simply want to prevent that subtraction, you could use:

newmem:
 jmp return

Now the game enters your injected code and skips the damage instruction. If the instruction only affects the player, this may create a simple god mode. The problem is that games often reuse the same instruction for players, enemies, companions, and NPCs.

So a better injection may eventually need logic like:

If this object is the player:
 skip damage
Otherwise:
 run the original subtraction

Assembly does not literally use that syntax, of course. You would build the condition using instructions such as cmp and conditional jumps. But that is the real power of code injection: you can add logic instead of merely deleting code.

Why the Disable Section Matters

When the script is turned off, the original instructions should be restored:

[DISABLE]
Game.exe+123456:
 sub [rbx+30],eax
dealloc(newmem)

The original code returns, then the memory allocated for your custom block is released. More robust scripts may restore the exact original bytes using db, especially when several instructions were overwritten. The important rule is simple: Always restore what you replaced. That makes testing much safer.

Code Injection vs. AOB Scanning

Code injection and AOB scanning are related, but they solve different problems.

Code injection answers:

What custom code should run here?

AOB scanning answers:

How do I reliably find this location again?

A fixed address such as:

Game.exe+123456

may work today but break after an update. An AOB signature searches for a recognizable sequence of bytes and can make the injection point easier to relocate.

So the usual progression is:

1. Find the instruction.
2. Build the injection.
3. Test that the logic works.
4. Use an AOB signature to make the injection more reusable.

If you already use an AOB injection script, code injection is still happening underneath. The AOB scan simply helps Cheat Engine find the correct location.

Common Beginner Mistakes

The first common mistake is removing the original instruction without understanding whether the game still needs it. If you only want to modify behaviour under certain conditions, keep the original code available inside the appropriate branch.

Another common mistake is overwriting only part of an instruction. CPU instructions have different lengths, so let Cheat Engine’s template handle the jump region whenever possible.

You should also check whether the instruction affects more than your target. A perfectly working damage injection is still wrong if it makes every enemy immortal too.

Finally, always test the disable section. Enable the script, verify the effect, disable it, and confirm that normal behaviour returns. A cheat that works only in the ON direction is less of a toggle and more of a hostage situation.

Where registersymbol() Fits In

More advanced scripts may contain:

registersymbol(something)

This exposes a label or allocated address elsewhere in Cheat Engine. For example, you could create an editable damage multiplier and register it so it can appear in the address list. That is useful, but it is not required for a first code injection.

For now, focus on the core pattern: allocate memory, redirect execution, run your logic, return safely, and restore everything when disabled.

A Practical Workflow

A beginner-friendly workflow is:

1. Find the gameplay value.
2. Use Find Out What Writes to This Address.
3. Identify the relevant instruction.
4. Open it in Memory Viewer.
5. Generate the Code Injection template.
6. Enable the untouched template first.
7. Confirm the game still behaves normally.
8. Modify the code inside newmem.
9. Test the effect.
10. Disable the script and verify that normal behaviour returns.

Once the script works reliably, you can consider converting the injection point to an AOB signature. This step-by-step approach makes debugging much easier because you know which change introduced the problem.

Final Thoughts

Code injection is where Cheat Engine starts feeling fundamentally different from a basic memory editor. Instead of repeatedly forcing health to 999, you can intercept the instruction responsible for changing health and alter how it behaves.

The core structure is straightforward. Cheat Engine allocates memory for your custom code, redirects execution into it, runs your instructions, and then returns to the game. When the script is disabled, the original code is restored.

Once that pattern makes sense, commands such as alloc, newmem, jmp, return, [ENABLE], and [DISABLE] stop looking like random assembly incantations. They are simply the plumbing that makes the detour work. And once the detour works, you can decide what should happen along the way.