Cheat Engine

[ParkourPenguin]

Instructions can access other areas of memory by directly specifying an address:

[++METHOS]

Thank you for writing this up. I have personally never experienced this issue, but I am aware of others that have.

Assuming that I am understanding this correctly, wouldn't having a custom injection type allow circumvention of this problem? For example, an injection type that made use of multiple lines of injection in lieu of a single line?

I think, even if such a measure would not offer a viable solution for this specific problem, that being able to 'bulk' inject would be useful anyway, as I have experienced situations where multiple injection points had to be manually consolidated into one script due to the fact that they were so close to each other and would have otherwise caused the target to crash.

Thanks.

[ParkourPenguin]

Most of the time, RIP-relative addressing isn't a problem. Most people already have the address they're accessing near the code injection itself- e.g. multiple `alloc` calls or labels.
This becomes a problem when accessing memory defined outside the script using it. e.g. two `alloc` calls in two different scripts might not be anywhere near each other.

I think what you're describing doesn't fix the problem. Regardless of what your code injections do or how they're organized, you still need to jump from the game's code into memory you allocated. You always have to be aware of 5-byte vs 14-byte jumps.

You could make a template that always uses a 14-byte jump and ignore the `jmp` problem completely, but overwriting more code comes with more problems.
JIT-compiled instructions with hard coded addresses would be harder to avoid. e.g. original code `mov rdx,[1071483CE0]`, address changes on restart. You could use reassemble / readmem, but that's annoying and most people don't know how to use those correctly. Weirder cases would require {$lua} to extract the address from the instruction manually, as restrictions around RIP-relative addressing might become a problem due to accessing that address from a different location in memory.
Any branches (jmp / jcc) to an instruction after the first in the injection point will crash the game. e.g. in the last script, any `jmp Tutorial-x86_64.exe+2B4C2` instruction that happened to be executed would jump to garbage code when the script is active. Very difficult to debug: breakpoints won't trigger, the game would appear to crash randomly. Using "Memory Viewer -> Tools -> Dissect code" would help, but that's only if you already know this could be a problem in the first place.

[++METHOS]

Thanks. I guess I do not fully understand the problem. For example, why does such a limitation exist in the first place?

If, for example, the code that you allocate needed to be placed somewhere far away from your injection point, is the 2GB/4GB limitation a matter of avoiding execution delays or something else?

Thanks.

[ParkourPenguin]

It's impossible to directly access an address more than 2 GiB away from the instruction accessing it.

For example, if you tried to assemble the instruction `mov [0x300000000],eax` at the address 0x200000000, it will fail to assemble. 0x300000000 - 0x200000000 = 0x100000000 = 4 GiB. It's simply an instruction that can't exist at that address.

There's a lot of extraneous information in the first post. I'll try to edit it down later.

[++METHOS]

Thanks. I will check back later, then.

I guess I still do not understand why it is impossible. This makes me curious about what would happen if you call something outside of the main module and place your code there, and whether or not such limitations would still be present. I assume that this would not be necessary or ideal.

It is not so important, I guess. I am mostly just curious.

Thanks.

[ParkourPenguin]

Edited it. Removed most of the technical jargon, spaced out some of the wall-of-text paragraphs, added more code examples, and removed much of the extraneous information. It should read easier.

[++METHOS]

Thanks. That clarifies a lot.