View previous topic :: View next topic |
Author |
Message |
mrjunior Newbie cheater
Reputation: 1
Joined: 07 Jul 2018 Posts: 12
|
Posted: Mon Oct 30, 2023 9:51 am Post subject: Tips for update-friendly scripts |
|
|
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
|
|
Back to top |
|
 |
Dark Byte Site Admin
Reputation: 470
Joined: 09 May 2003 Posts: 25788 Location: The netherlands
|
Posted: Mon Oct 30, 2023 10:03 am Post subject: |
|
|
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 |
|
 |
++METHOS I post too much
Reputation: 92
Joined: 29 Oct 2010 Posts: 4197
|
Posted: Mon Oct 30, 2023 10:11 am Post subject: |
|
|
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 |
|
 |
ParkourPenguin I post too much
Reputation: 152
Joined: 06 Jul 2014 Posts: 4700
|
Posted: Mon Oct 30, 2023 10:50 am Post subject: |
|
|
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 |
|
 |
mrjunior Newbie cheater
Reputation: 1
Joined: 07 Jul 2018 Posts: 12
|
Posted: Mon Oct 30, 2023 11:06 am Post subject: |
|
|
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 |
|
 |
ParkourPenguin I post too much
Reputation: 152
Joined: 06 Jul 2014 Posts: 4700
|
Posted: Mon Oct 30, 2023 11:44 am Post subject: |
|
|
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 |
|
 |
|