Cheat Engine

[paul44]

No idea whether this is a bug, intentional or simply standard "mem_behaviour" (for lack of better word)
Note that is an FYI, as i now know how the solve this. Could not find any related post, and i'm actually curious why this happens...?


Anyways: it took me awhile to pinpoint the issue here actually. A gamer had this particular issue with my ACS table, and eventually i was able to figure out what caused it (well, still in testing status, but seems pretty right)

info images: [ https://imgur.com/a/XGv5TU4 ]

The main script uses both a lua script (among others kills the antidebug thread) and an asm script (collecting game pointers).
While i never had this issue myself - win 7 nor win 10 - this particular user kept on receiving 'offset too big' errors... several CEF posts linked/helped me to identify the issue, being assigning the mem_addresses to my resp. vars/symbols.

However, since i always use 'glocalalloc(symbol,x,$process), i assumed their mem_locations would "sit" in proximity of the game_exe. Short story: dis/enabling 'async' seems to make the difference ?! Also note that when using 'alloc()' - btw here without using $process - their mem_locations are always fine (async or not).

ps1: there are 2 'Collecting...' scripts here so I could figure out which one generated the error; normally they are combined in just 1 script
ps2: you can ignore some of the symbols as they have not yet been populated by their resp. scripts...
ps3: still an issue despite applying following technique: [ https://forum.cheatengine.org/viewtopic.php?p=5722856 ]
...
push rax
mov rax,_pointer1
mov [rax],rbx
pop rax

ps4: prtscreens come from gamer (i can not test/verify this myself as never had/have this issue)

[Dark Byte]

just depends on luck

some games just waste a lot of virtual memory by reserving GB's of memory (mono and .net do this often)

often you're lucky and there's a gap but sometimes there's just no 64kb gap available anymore

in that case alloc with prefered base will fail

Best solution is to use scripts that understand the 2GB issue. use 14 byte jmps (jmp far) and try to not overwrite riprelative instructions (which includes relatice jmps) or else recode those yourself
e.g
je acdef01234 would be recoded as

[paul44]

^"luck" seems to be the proper wording

anyways: had to do some re/search to figure out what you meant with 'jmp 14' ?! But basically did 2 things: 1) separate lua (in async) from asm code (normal) 2) applied the 'jmp 14' approach to my main script... et voilà (working as expected again)

And btw: the main culprit is win 11. For testing purposes, he was able to install the game on a win10 installation, on which everything runs fine. iow the exact same game/table on win 7~10 will run fine, but gives some serious issues on Win11... that sounds promising

I've got this guts feeling that my FRF colleagues and i will be confronted with some challenges upon Win11 release day.
Note: i'm planning to write a small instruction set on how to migrate a 'jmp 5' script to 'jmp 14'. when released, I'll link that info here as well...

and as always, thx for the instructions

[Dark Byte]

when generating scripts using the templates, you can hold down ctrl and the resulting script will use 14 byte jmps, just watch the instructions you're overwriting)

[paul44]

Wrote up a little guide for myself, so i did not have too much trouble "converting" my existing scripts: [ https://www.dropbox.com/s/q1glqbyw1oxj7hr/ACS_FarJump.pdf?dl=0 ]

For completeness sake, I have opened a topic @FRF: [ https://fearlessrevolution.com/viewtopic.php?f=11&t=19793 ]
since a) i frequent this forum far more then #CEF b) i expect (possibly) more discussions there related to this particular issue...

The wording might/will be off here and there, but i'm sure you'll get the idea.