Cheat Engine

bugzor · How do I cheat? Reputation: 0 Joined: 20 Oct 2018 Posts: 5

I've managed to create a pseudo 1-hit kill script that basically spams aobscans to find the enemies hp, and changes them to 1.

The problem is that i haven't found a way to automatically cleanup the aobscan results, as in, the scan files in the temp folder, and the problem with that is that the aobscan function seems to go through every scan file in the temp folder. The result is that the script gets slower the longer it runs.

So my question is; is there a proper way to delete the aobscan results?

Also, the reason that i didn't created a proper 1-hit kill script is partially because i'm a n00b, and partially because the "Find out what..." stuff doesn't work on the target.

Dark Byte · Posted: Thu Oct 25, 2018 6:01 am Post subject:

is this the lua aobscan? If so just call .destroy() on the returned stringlist object

bugzor · How do I cheat? Reputation: 0 Joined: 20 Oct 2018 Posts: 5

This is indeed lua.

i tried fiddling with .destroy(), and while it does indeed destroy the object, it doesnt actually do anything to the scan files in the temp folder.

On a related note, i found that when using the gui to scan, the new scan button properly cleans up the scan files.

Dark Byte · Posted: Fri Oct 26, 2018 1:35 pm Post subject:

could be a bug in lua aobscan (though i can't quickly see what the issue is)

do the temp files also not get deleted if you don't look at the folder ?

you can also try the memscan class to do an aob scan

bugzor · How do I cheat? Reputation: 0 Joined: 20 Oct 2018 Posts: 5

Yup, the issue is present whether or not the folder is open.

I also noticed that the files stay even when the scan doesn't find anything, which is strange as aobscan returns nil in that case.

I've changed the script to use memscan instead now, which properly cleans up after itself.

ParkourPenguin · Posted: Fri Oct 26, 2018 3:10 pm Post subject:

I can't replicate it.

It shouldn't have anything to do with destroying the stringlist- the memscan object is cleaned up before control is passed back to Lua.

Some other process might have an open handle to the file when CE tries to delete it.

bugzor · How do I cheat? Reputation: 0 Joined: 20 Oct 2018 Posts: 5

I just replicated it by opening cheat engine, targeting a random program and running this line in the cheat table:

ParkourPenguin · Posted: Fri Oct 26, 2018 4:11 pm Post subject:

You're using AOBScan incorrectly. Seems like CE as it is doesn't deal with this very well.

Please refer to celua.txt and defines.lua for documentation. You're probably looking for something like this:

bugzor · How do I cheat? Reputation: 0 Joined: 20 Oct 2018 Posts: 5

I just pasted your code into a new cheat table and the issue is still present.

I also looked into celua.txt and saw that the third argument should be an integer, so i changed it... which didn't make a difference.

What's weirder is that i managed to make it work at some point by changing the array to 20 20 20 20 20 20 20 20, however changing any of those bytes to 30 made the issue pop up again. Unfortunately i can't seem to replicate this anymore.

One thing i did test while i could replicate it was whether the searches were returning any results, and both of them were, so that doesn't seem to be the problem.

Dark Byte · Posted: Sat Oct 27, 2018 1:53 am Post subject:

it's very likely that you may have an anti virus or other protection that still has the temp files open at the time they get deleted.

So do the memscan method but after the scan is done start a timer for a few seconds which will then destroy the memscan object and hope the AV has released the file by then

ParkourPenguin · Posted: Sat Oct 27, 2018 11:57 am Post subject:

I think I found it. There's a race condition between the SaveFirstScanThread and the main thread. If the memscan is destroyed before the SaveFirstScanThread releases the file handle, the files won't get deleted (sharing violation).

Dark Byte · Posted: Sat Oct 27, 2018 12:21 pm Post subject:

I'm not sure. The Memscan destructor terminates and destroys the saveFirstScanThread before it goes and deletes the results (free also calls terminate and waits for it (TThread.Destroy calls SysDestroy which calls terminate and waitfor))
And saveFirstScan always releases the files on thread exit (finally section)

but I do see it not cleaning results on my win10 test system as well. Could be it's a cached filesystem copy and windows being 'smart' again. (Just like their shutdown which is actually just sleep)

edit: I commented out the threadcode of TSaveFirstScanThread and still non-deleted files but removing the creation of TSaveFirstScanThread does stop it

ParkourPenguin · Posted: Sat Oct 27, 2018 12:49 pm Post subject:

I say that based on what I'm seeing from Process Monitor.

scanController creates saveFirstScanThread
scanController exits
saveFirstScanThread gets a handle to ADDRESSES.TMP
main thread starts iterating over files in the temp directory (i.e. ADDRESSES.TMP and MEMORY.TMP)
saveFirstScanThread gets a handle to MEMORY.TMP
saveFirstScanThread reads from ADDRESSES.TMP
main thread tries to destroy ADDRESSES.TMP, results in sharing violation
main thread gives up

I can't see why this would happen either.

Dark Byte · Posted: Sat Oct 27, 2018 12:57 pm Post subject:

Does this also happen on a non-ssd harddisk ?

ParkourPenguin · Posted: Sat Oct 27, 2018 1:01 pm Post subject:

For me, yes. I'm on an old computer that doesn't have an ssd. (running win7; CE 6.8.1)

Edit: If saveFirstScanThread is never created, everything is destroyed as intended (tested 1000+ times).