Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


Tips for update-friendly scripts

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine
View previous topic :: View next topic  
Author Message
mrjunior
Newbie cheater
Reputation: 1

Joined: 07 Jul 2018
Posts: 12

PostPosted: Mon Oct 30, 2023 9:51 am    Post subject: Tips for update-friendly scripts Reply with quote

What are general rules of thumb while making an update friendly script? In this context updates can be frequent but it's usually bug fixes and slight additions/changes. I'm mainly concerned about possible future updates just changing the instruction from something like mov [eax+04],edx to mov [edx+04],eax, which would break the script, does this even happen or am I worrying for nothing? Would like to get a general list of things to keep in mind when working on such scripts besides the answer to the question Smile
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 470

Joined: 09 May 2003
Posts: 25788
Location: The netherlands

PostPosted: Mon Oct 30, 2023 10:03 am    Post subject: Reply with quote

It happens if a compileroption or whole compiler is changed.

But that doesn't happen too often. And when it does you'll have to make a new script as there's other things that may have broken (structure offsets could even have been changed)

but generally it doesn't happen and an aobscan script is often good enough

_________________
Do not ask me about online cheats. I don't know any and wont help finding them.

Like my help? Join me on Patreon so i can keep helping
Back to top
View user's profile Send private message MSN Messenger
++METHOS
I post too much
Reputation: 92

Joined: 29 Oct 2010
Posts: 4197

PostPosted: Mon Oct 30, 2023 10:11 am    Post subject: Reply with quote

1. Use AOB signatures in your scripts for locating your injection points (there are built-in templates and custom templates that can do this for you).
2. Use wildcard entries for all potentially-dynamic bytes in your AOB signature (there are tools/plugins and even custom templates that can automatically create large signatures with wildcard entries already included; some work better than others).
3. Use a template that provides a large block of original code (commented-out), or, make a habit of including an extended AOB signature (again, commented-out), so that you have something to work with in case your original signature fails to locate the new injection location.
4. Learn how to manually scan for AOB signatures in the event that your injection fails.
5. If you share your table(s), get into the habit of including instructions, either inside of your script(s), or, within your table extras, so that users can fix their own tables.
Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 152

Joined: 06 Jul 2014
Posts: 4700

PostPosted: Mon Oct 30, 2023 10:50 am    Post subject: Reply with quote

Use aobscan template.

If aobscan is too slow and the code is in a module, use the full injection template. It asserts the code at the injection point is what you expected it to be.

Both the aobscan and full injection templates have a comment at the end that shows the code around the injection point. Keep that comment there. It's very useful for updating a script if it breaks.

You can try to get fancy with wildcards and offsets, but that's easy to screw up and is likely to be a waste of time anyway.

_________________
I don't know where I'm going, but I'll figure it out when I get there.
Back to top
View user's profile Send private message
mrjunior
Newbie cheater
Reputation: 1

Joined: 07 Jul 2018
Posts: 12

PostPosted: Mon Oct 30, 2023 11:06 am    Post subject: Reply with quote

ParkourPenguin wrote:
You can try to get fancy with wildcards and offsets, but that's easy to screw up and is likely to be a waste of time anyway.

I've thought of that, but then, again, if I wildcard the register/offset bytes I'll end up not knowing which register/offset to access when writing own assembly. Would be cool if you could scan for specific order of operations and reference destination and source of those operations in your scripts, making the script break only if the whole flow was changed, but that doesn't seem possible (?).

Dark Byte wrote:
It happens if a compileroption or whole compiler is changed.

Looks good to me then, I tampered with a game for a while and I think I saw a register change once at the spot I often had to look at, but that was a while ago and I'm not sure anymore. So you're saying that even if the code in that section was modified (additions or removals included), that would keep the same byte code for the same operation?
Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 152

Joined: 06 Jul 2014
Posts: 4700

PostPosted: Mon Oct 30, 2023 11:44 am    Post subject: Reply with quote

mrjunior wrote:
I've thought of that, but then, again, if I wildcard the register/offset bytes I'll end up not knowing which register/offset to access when writing own assembly. Would be cool if you could scan for specific order of operations and reference destination and source of those operations in your scripts, making the script break only if the whole flow was changed, but that doesn't seem possible (?).
Yeah, I've seen several people replace offsets with wildcards but use the offsets anyway in the injection. Instead of the aobscan failing, this will just do "something else" at runtime. Easy to screw up.

You can use {$lua} to do the aobscan and disassemble the result to get offsets and registers (return string 'define(symbol,value)' to get this information in the AA script). The biggest problem is that the number of bytes an instruction is comprised of might change on small changes like which register is used (e.g. REX prefix). Usual aobscan patterns can't be used for several instructions (in general), and you end up needing to do weird things with groupscans or something else. Doing everything you can to make it as general as possible can be really expensive and might slow down scans tremendously... not to mention the time it takes for you to do all that.

I've thought about this several times and it's never been worth it. aobscan is good enough.

_________________
I don't know where I'm going, but I'll figure it out when I get there.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites