Cheat Engine

[jgoemat]

This is frmautoinjectunit.pas renamed so I could upload it.

New procedure: TfrmAutoInject.menuFullInjectionClick
* uses defines for address and hex bytes being replaced
* asserts that the right bytes are there before overwriting them

New procedure TfrmAutoInject.menuAOBInjectionClick
* prompts for symbol name to use
* uses aobscan to find bytes to replace
* does an initial scan of the code being replaced, if there is only 1 match use the hex bytes we got
* if multiple matches, read the memory 20 bytes before and after each match and compare, masking any 4-byte operands over 0000FFFF, expanding until we get a single match
* prefers an extra 5 bytes behind the code in order by avoid using an offset for clarity, but will look behind replaced code and use offset
* if code being replaced is in a module, will use the new aobscanmodule and narrows the search to that module

Both:
* includes 10 lines before and after in comments at the bottom
* includes comment at top with exe name, date, and user automatically populated

Sample AOB script (you can see the aobscan needed three extra bytes to find a unique match), I entered 'ENERGY' for the symbol name:

[Dark Byte]

Thanks, i'll see about adding this

I think the AOB injection masking isn't working properly.

(Also, I think it might have been a lot easier if you just used the disassembler class and used the LastDisassembleData and used the seperators to pinpoint the wildcard regions

[jgoemat]

[Dark Byte]

yeah, I already tested it and it seems to work ok. I can't get it to generate wildcard aob's but that's probably because of the simple code locations I picked (or it doesn't do that a all, didn't check into it)

and yes, I already figured that adding negative value support could be done by adding the and <> 'FFFF'

I've implemented it in the svn already with some modifications.

About separators, it's an array containing indexes into the byte array (whose index starts at 0)
In the example, it's an array of 1 length, with the only element with value 1
That means that the bytes can be split up into 2 chunks:
232 and 140,201,200,255

sometimes there is a seperator index pointing to the last byte+1 so watch that (of course, since the usual usage it to copy till seperatorindex-1 that doesn't cause an issue)

[mgr.inz.Player]

@jgoemat, congrats. Can't +rep you (have to wait)

Looks like I don't have to make "lua script plugin" (autorun Lua script).

[Dark Byte]

If you wish to you still can so people don't have to wait for 6.4

[Geri]

It's a good thing to have an efficient template, I also have some templates just on my desktop for copy-pasting.

But there is one thing I like in the default template, and it's exactly it's simplicity. If you come up with a final template, consider that most beginners have no idea what is registersymbol, labels and stuff like that. I even had to make a description for aobscan, because so many people could not use it. So if you make a template which is efficient but it has symbols and labels all over the place, it will confuse them like hell.
And if they have to rename some symbols, it will confuse them even more.

At least this is what I see as one of the most common problems with beginner CE users. They have no idea that labels or symbols are global or only local in the script, they have trouble to understand how is aobscan working, it's a point in their learning where most of them needs assistance. (We know that they won't read the help file.)

EDIT: Ah forget the rest, I see you have done everything you could to make this working for noobs, good job.

EDIT 2: And of course my whole post is irrelevant if this template will be for aobscan only, where using symbols is just unavoidable.

[Dark Byte]

since it's slightly related just letting you know I just added a new aa command:
Reassemble(address)

e.g it can be used like this (for the cases you really can not find a proper injection spot)

[mgr.inz.Player]

Nice. Previously I used:

- labels, if offsets are changing (after game update)

[Dark Byte]

yes, it's mainly useful if the instruction you are interested in isn't affected by relocation but the instruction before and after it are.
e.g:

[mgr.inz.Player]

"89 4C 86 xx 5E C2" - only one address. So, no problems with "another getXXX"
Anyway, yeah it's bad example.... (good for readmem, not good for reassemble)




Just to be sure, we can use it like this:

reassemble(something+1A) - we can add offset (or subtract). I tested it, it works. Is it correct?

reassemble(registeredsymbol) - so, it should work in another AA script too? (main AA script with aobscan's and registersymbol's, and empty [disable], and other 'child' AA script where we do the rest: reassemble, alloc, etc )

reassemble(defineZ) - defined. tested, works.

reassemble(label) - gives "label could not be found".

[Dark Byte]

Offsets (+xxx) work yes.

Labels don't work right now and not sure i want to add support for that. (Labels tend to be in self written locations)

[Geri]

[Dark Byte]

yes, it reassembles it based on the new position.

basically, it just replaces the "reassemble()" line with the line it disassembled as assembler text, so when the assembler goes over it, it assembles it based on the current position. (So a long jump)

[Geri]

Very nice feature. This will greatly increase the effectiveness of aobscan. I have used

je aobscanname+14

to solve the problem with short jumps and aobscan, but that is working only as long as the jump distance is the same. Which often changes unfortunately. But with this instruction, that problem will be also solved.