Cheat Engine

fun1 · Newbie cheater Reputation: 0 Joined: 04 May 2025 Posts: 16

I have 2 scripts, which run at same time, and must inject in 2 different game functions (fyi, one for the player health by self damages, eg. fall from high, and the other for the damages inflicted by weapons)... they do exactly the same, amof find the logical solution was really very simple... but instead, it took few hours to make them functional in CE... the problems you will understand by the story...

first version scripts, I simply used the same template found in another approved working scripts from the forum:

Dark Byte · Posted: Wed May 07, 2025 1:06 am Post subject:

the script you found as example is likely bad as you should never use globalalloc unless you have a really really good reason to use it (e.g when it's impossible to free, which is not the case in your situation)

fun1 · Newbie cheater Reputation: 0 Joined: 04 May 2025 Posts: 16

Thanks for the point out... yes I understood that globalalloc is not common practice... but I had to shift to that out of frustration during the early attempts to fix the crash, since with simple alloc was keep crashing... Confused

Besides the globalalloc (which I confirm it works anyway), my questions were about... ok, I see my questions were maybe not very clear... I will try to summarize them again:

1) what type of variables,labels,symbols(...) in AA scripts are local/global visibility and/or shared? and how to discern the boundary between local and global?
2) what symbols must be declared? btw, I noticed in the saved file .ct, that CE seem to auto-define by itself (all alone) the allocs, and maybe also the aob, is that possible?
3) when in case of nested lables, what labels must use in the jumps (in my case, newmem* or saveinject*)?
4) why nested labels (or, some of them) don't READMEM, while still allowed?
5) in my very specific case, my 2 scripts are very redundant, would it be possible to do the same with only 1 script (containing both aobscans INJECT1&2)?
Thanks

ParkourPenguin · Posted: Wed May 07, 2025 12:38 pm Post subject:

I don't know what "template" you got that from or who "approved" it as working, but it's wrong. Even an AI wouldn't produce that level of crap.

Use the AOBScan template provided by CE.

1) Symbols defined by `globalloc` and passed to `registersymbol` are global. `globalalloc` will only allocate memory once, and that memory will never be deallocated.
2) You should declare all of them. Labels can be implicitly declared on their first use, but that can be dangerous if there's already a symbol with the same name (e.g. `memcpy` or some other API).
If you saved when a script was enabled, the values of the registered symbols might also be saved.
3) Labels aren't nested. `jmp` is an instruction that jumps to an address (the jmp after saveinject is useless).
4) `readmem` is a pseudoinstruction that copies memory. Don't use it unless you know you have a good reason to do so.
5) Yes, you can combine two scripts into one. Don't try to do that unless you know what all the code in the AA script does.

fun1 · Newbie cheater Reputation: 0 Joined: 04 May 2025 Posts: 16

Hi, thanks again for your answer, I have been digging in a lot of scripts, if you insist I can try to find back from where came that template, so you will be able to address your complaint about the level of human proficiency in CE directly to the author Wink

If you dont mind, I still would have a few curiosities to ask:

1) you wrote "Symbols defined by `globalloc` and passed to `registersymbol` are global.". Clear. What about symbols defined in simple ALLOC, global or local? What about symbols defined in AOBSCAN/AOBSCANMODULE, global or local? What about the other symbols defined by LABEL only, global or local? Whar about "children" scripts, do they follow the usual inheritance rule, such as variables/symbols declared in the parents are global/shared with the children, but not viceversa? or how? finally, do the "global" term in CE, means shared with *all* the scripts, or only with the children?

2) you wrote "You should declare all of them". That means it is common practice to REGISTERSYMBOL all of them, correct? why, if some of them are already automatically registered? Then, I understand that "the values of the registered symbols" are infact saved in the .ct file only "when a script" is in ENABLE state, correct? why such distinctive behavior?

3) you wrote "Labels aren't nested". When in the script I write one label and after another label, eg. "newmem: saveinject:", I call this nested. If you have another term for it, please suggest. In my logic, those 2 labels nest, alias are pointing at the same memory address, and are indeed accepted by CE. Unfortunately, only the first was found by readmem, the second not. Just to be sure, is this behavior expected result? Also you wrote, "the jmp after saveinject is useless", care to elaborate on that? Was it useless the declaration of a nested label saveinject? Or you didn't like the jump to a readmem? Or what? And why?

4) readmem came from that template, and I logically found it very useful (actually, mandatory), to backup the original instruction (from which,the need of "saveinject") before the injected jump overwrite... otherwise the original instruction is lost forever, and can't DISABLE the script anymore... moreover, if it's an instruction containing a dynamic address (as I see,it happens), I can't imagine no other way to get it back... where am I wrong?

5) Interesting. Would you suggest, just for the sake of educational, how you could combine my 2 scripts in one (the only difference is the bytes sequence *blabla-1&2 of aobscan)?

6) bonus question! Idea

in general, why (or,how possible) sometimes games have the code all sitting in its module memory area (for which, is enough AOBSCANMODULE)? But others, have the code (talking about the code,not the data) allocated (dynamically?) somewhere else (for which, the need for the much longer AOBSCAN)? is it only a matter of totally different compilers, which are so drastically different in coding strategy? or what?
Thanks

ParkourPenguin · Posted: Wed May 07, 2025 8:21 pm Post subject:

1) Symbols defined by `alloc`, `label`, and `aobscan` are all local to the script. You can make them global by using `registersymbol`.
Parent / child memory records are only a way to organize the cheat table. Any two unique scripts are separate from each other. There is no form of inheritance.

2) No.

fun1 · Newbie cheater Reputation: 0 Joined: 04 May 2025 Posts: 16

Hi, thanks for the answers, that cleared some of the fog(-of-war) Wink

1) Finally: `registersymbol` turns the symbols into global/shared. Imho, this detail is of primordial importance, because global/shared visibility is *not* always desiderable (suggest: update wiki @Auto_Assembler:registerSymbol with this info)
About `globalalloc`, it's still not clear to me, why it's so much discouraged. Instead I find it, would say very "optimized", the idea to preserve a memory area for the exact same instructions, and do not allocate/deallocate it every time script ENABLE/DISABLE, because it saves a lot of cpu cycles. Care to elaborate a bit more on that?

3) Following your suggestions, I tried again, the following script fails to DISABLE (but with error different from that previous readmem0):

ParkourPenguin · Posted: Thu May 08, 2025 6:13 pm Post subject:

1) For small things, globalalloc is fine. e.g. store an address the game is using so you can use it elsewhere in the cheat table.
Unless you enable and disable a script hundreds of times per second, you'd never notice the difference between a script that reuses memory and a script that allocates / deallocates memory. You have already noticed that using globalalloc liberally makes it very easy to screw things up- i.e. reusing `newmem`.

2) Need `registersymbol(saveinject1)` / `unregistersymbol(saveinject1)`

Enabling the script and disabling the script are two separate invocations of the auto assembler. When the script is enabled, some extra information called "disable info" is created to help disable the script. Some symbols are saved in the disable info- notably allocs. Not much else is. Standard labels are not saved- you have to use `registersymbol` so the AA script in the [DISABLE] section knows what it was. See my script in the previous example.

The stuff about the disassembler has to do with alignment of instructions in the disassembler. It has nothing to do with globalalloc vs alloc. The only thing that changes is CE will display any registered symbols in place of the address in the disassembler by default.

4) If CE can't find a unique AOB for you, you probably won't be able to find one either. (wildcards don't help with unique AOBs)
`readmem` reads some number of bytes from an address and writes them at the address where `readmem` is placed.
`reassemble` disassembles the instruction at the specified address and re-assembles it where `reassemble` is placed.
The reason you should use `reassemble` instead of `readmem` when executing code is because some instructions change what they do depending on the address they're located at. Copying the bytes of an instruction from one location to another (i.e. `readmem`) can change what that instruction does.