Cheat Engine

predprey · Last edited by predprey on Sun Oct 11, 2015 7:02 pm; edited 1 time in total

When enabling a script such as the one below which uses a label, auto assembler adds 4 nop opcode after the jmp command. This was using x64 CE on a x64 application. An example script is like the one below:

Zanzer · Posted: Sun Oct 11, 2015 6:50 pm Post subject:

It is added because the instructions you overwrite with your injection take up that many bytes.
If it didn't NOP those, the JMP back to RETURN would be in the middle of one of those overwritten instructions.
Your computer would then run as if that was the beginning of some instruction, likely crashing.

predprey · Posted: Sun Oct 11, 2015 7:02 pm Post subject:

sorry, forgot to change the "jmp code" under INJECT: to "jmp newmem". so I think what you meant was the original code XX XX XX XX XX would become XX XX 90 90 90. I was referring to the injected code under newmem, where instead of

Zanzer · Posted: Sun Oct 11, 2015 7:12 pm Post subject:

That is what I was referring to as well.
Look at the code at your injection site when you activate the script.
It overwrites multiple instructions.
The number of bytes you write must match the number of bytes the previous instructions used.

predprey · Posted: Sun Oct 11, 2015 7:46 pm Post subject:

ok here's a more "complete" script to make things clearer

Zanzer · Posted: Sun Oct 11, 2015 7:55 pm Post subject:

Oh, the extra NOPs inside the code cave.
I believe that has to do with timing.
CE is reserving enough space for the maximum size of a JMP.
It isn't until the later code gets assembled that CE knows the true size.
So when it goes back and assembles the proper JMP, it NOPs all the extra bytes.

predprey · Posted: Sun Oct 11, 2015 8:59 pm Post subject:

doesn't compilers encounter this same problem of not knowing the number of bytes the instruction is going to take up? can't auto assembler just employ the same solution that is used to overcome this?

Rydian · Posted: Mon Oct 12, 2015 1:55 am Post subject:

You're injecting on an instruction that only takes up 2 bytes.
"fftype0hd.exe"+30E3E: 03 FD

An arbitrary jump takes up 5 bytes. So it needs to overwrite more than 2 bytes in order to put the jump there.
So it needs to overwrite the next instruction as well so that it has enough space to put the jump in.
"fftype0hd.exe"+30E3E: 03 FD
"fftype0hd.exe"+30E40: 3B 3D 12 84 62 00

So it's overwriting two instructions, which total to 8 bytes "removed". But it only needs 5 of those bytes.
So it overwrites the last three bytes with nops, because those bytes DO exist, and they have to be something.
Leaving "half" of the instruction (the bytes asis) would just be garbage assembly that would crash the program.

'Cause CE's not about to go re-adjust the entire damn program's memory.

A compiler has access to WAY more information than a debugger. TONS of data is LOST on compilation.
CE can't use data it doesn't have to know which jumps need to lead where at which time.

EDIT: And it's not just jumps. Some data might be read in as an address to start a read of data or something like that.
There's way too many unknowns, and arbitrarily moving data around causing problems everywhere is... well, it's known.
It's so heavily known that it's actually the reason that the nop instruction exists in like, every architecture ever.

Dark Byte · Posted: Mon Oct 12, 2015 1:58 am Post subject:

that's the way ce's assembler works
forward jumps are unknown locations so it reserves the max amount of memory needed for the jmp (in 64 it thats 12 bytes)

you can override that behaviour by using jmp short xxxxxxxx

predprey · Posted: Mon Oct 12, 2015 10:41 am Post subject:

ok that explains it, thanks