Cheat Engine

[jgoemat]

I've added a menu option to the Templates menu in autoassembler to replace the code injection one because every time I create a script I do the same chores. I'd like for it to be added to the base code, I think it will help people write better scripts, at least make them easier for me to read and find the places if the code changes. Here's what it does:

1) Automatically put ENABLE and DISABLE sections - saves me from having to click two menu options
2) Puts a standard generic comment at the top that can be edited with places for Game, Version, Date, Author and a comment on what the script does
3) Use define for address above ENABLE after the comment - if the address changes then it only needs to be changed in one place, and it's easy to see when you open the script
4) Use define for the AOB being replaced at the top - that way it can be used in multiple places, see #5 and #6
5) Use assert(address,bytes) immediately after ENABLE - I think this is recommended practice (if not using AOBSCAN) and will keep CE from crashing updated games
6) Use "db bytes" to replace original code, with instructions in comments, together with the assert it will keep people from making a mistake and only changing the values in once place if the game changes
7) Simplify labels, not using 'exit' or 'originalcode', changing 'returnhere' to 'return'. Also adding 'code' for where to jump to instead of 'newmem' so variables can be added first so they will be aligned to 4-byte addresses
8) Indent assembly instructions 2 spaces to make labels stand out.
9) Put large section of surrounding code (about 128 bytes before/after, starting at the first 'int 3' or 'push ebp' before the injected address and ending if a 'ret' is seen) in a comment at the bottom, this will help find the injection point if it changes and for people to see the context of the code around the injection point.

What do you think? I would like more people to include information like this in their scripts and tables and this would make it easy. I'll send the updated formautoinjectunit.pas to anyone that wants it. Next I'm going to work on a template that automatically does an AOBSCAN on the code being replaced and parses the results until only one match is found and uses that instead of hard-coded addresses, but parsing the surrounding ASM and using wildcards for addresses that may change will be complicated...

Sample script created solely from the menu command:

[mgr.inz.Player]

Great idea. I think I should be able to create Lua plugin for that.

[Dark Byte]

should be possible yes
I recommend using registerFormAddNotification() and check whenever a TfrmAutoInject form is created

[jgoemat]

I just thought of a way to make a pretty accurate automatic aobscan for the code. For the template I already can disassemble the surrounding lines for the comment at the bottom. I would use that and do an aobscan for the actual code being replaced. If it only finds one result, that's great, if not I can just read the memory for X bytes around each result to get the surrounding bytes. Then I can compare it with disassembled bytes around the code being replaced. To ignore statics I have a few options, what do you think would be best?

1) Ignore all hex groupings of 4 bytes by replacing with "* * * *" (would mistakenly catch things like mov eax,[ecx+00000024], but offsets can change sometimes)

2) Ignore hex groupings of 4 bytes or more if the disassembled instruction contains the module name (would only affect things like 'fld qword ptr [Monaco.exe+250160]' but would catch any static in the module as well as long jumps and calls which might be affected by code changes and would leave short jumps, but it would fail for statics in other modules) This could fall back to another method transparently if there was no module because the code was compiled at runtime.

3) Ignore all hex groupings of 4 where value is at least a threshhold (will work for small offsets which most likely won't change and should catch most problems

I'm thinking I'd create arrays of bytes and flags (or hex AOB strings) for about 50 bytes disassembled before and after the injection point, then loop for 0-50 bytes in front of the replaced code and stop when I found there was only one match in my aobscan results. That would be the maximum length I can get to going ahead of the code. Then i would go backwards from 1 to max-1 bytes and for each one compare up to max bytes in the results. If I found a lower number of bytes than max (possibly with weighting to prefer an address starting with our code) then set max to that and start to the index. That should find the shortest AOB that will give unique results...

I thought about replacing the original code with **s too, that way AOBscan would work even after injection...

[Dark Byte]

3 would work with a max absolute value of 0x10000 since from that point on it can be an address