Cheat Engine

[++METHOS]

Based on this post..

[++METHOS]

Giving this some more thought, something that may not be very practical at all, but could possibly eliminate any need for ever having to update any AOB signatures again, would involve an AOB scan that was dynamic.

It's a bit difficult for me to articulate because it's late here at the moment, but it would require a memory block of data to be stored as reference, inside of the script, that CE would automatically generate during script creation. Perhaps 100 bytes above the point of injection and 100 bytes below the point of injection (or, the entire sub-routine). CE could generate a basic AOB signature, but also have a large data block to refer to if the injection fails.

If the injection fails, CE could remove bytes on the end of the signature, or set them as wildcard values, one-by-one, until results are found. Then, it could compare the data blocks for those results, with the data block inside of the script, and choose the one with the highest percentage of similarity. If it could intelligently determine where the injection point needed to be, based on the original memory block, it could then read the bytes from the new memory block, and replace the old memory block and the old AOB signature by writing in the new data to the script.

Obvious downsides would be implementation, the possible inability to save the new signatures for trainers, the time to successfully perform all of the tasks...dramatically increasing wait times for script activation, the possibly large memory or disk usage, intelligent injection requirements etc..

[++METHOS]

Now that I've had some sleep, I realize that the need for intelligent injection requirements is moot, given that CE determines the injection location during the scan. So the hardest part may be writing a routine that can perform comparative analysis against multiple data blocks while determining which one is most similar to the base block.

Perhaps forcing CE to build more search results by shortening the original signature, byte-by-byte, until a minimum percentage of similarity is achieved between data blocks (e.g. 70%) would be necessary. This would eliminate the possibility of an incorrect injection when the key injection point has many changes within that small range of bytes, but not so much in the data block, as a whole. Forcing CE to rely on the data block, as a whole, would help to achieve the correct injection point. If CE was limited to a 3 byte signature to search from, for example, the results may be large, requiring a great deal of time. However, given the amount of time that the pointer scanner can take, it seems like it would be worth it, not having to fix signatures for people all of the time.

Perhaps including it as an option would be good for anyone that just wants to fix things manually. For example, if the injection fails, a window prompt asking if you would like CE to try to fix it would be good. An additional measure to avoid potential issues would be to have CE create a new script inside the table, so that reverting back to the old script could be possible, if needed.

If such a feature could be implemented inside of a trainer, all of the trainers that we publish could potentially be self-updating. A backup/copy of the trainer could be automatically created anytime a new signature is re-written in to the code in the event that the new signature is wrong.

[++METHOS]

Regarding comparative analysis of data blocks, there is a decent 'compare' plugin written for notepad++ that can determine where data has changed and/or is missing, but can also see if data has shifted up/down, which would be integral for this kind of application.