Cheat Engine

[mgr.inz.Player]

I want to create another lua script for me and autorun script for others, both using D3D. Something similar to:

"-- Direct 3D Hook Function --" section,
the one between --TRAINERGENERATORSTART-- and --TRAINERGENERATORSTOP--

But, this script will be for already existing generic trainers (CT, CETRAINER) with Lua script.

I think I just hook those:

- memoryrecordhotkey_onPostHotkey
- memoryrecordhotkey_onHotkey
That way I can collect all memrec objects (memrecHotkey.Owner).

Another function will hook onPostHotkey and onHotkey functions.
That way I will know which cheat is now enabled or disabled

I will add simple notify animation about enabled cheat. (hmm, "graphical beep").
User will place that script in autorun and all D3D game will have that "graphical beep"
(of course I will check if d3d9.dll is loaded, or newer dll)






But there is one little problem. Some people:
- trainer creators, are using AA aobscan - post, second part ("I prefer signatures that do not cover the injection point")

- and then, other people launch CE, enable cheat, close CE. Then after a while they: launch CE, disable cheat, close CE


I know that calling createD3DHook few times (from different CE instances) is not an option. CE or game can crash. Maybe something like D3DWasHooked() and reopenD3DHook() could be handy.

reopenD3DHook() will search for previously created hook, destroy objects (sprites and textures) and then it will return d3dhook object

[Dark Byte]

createD3DHook actually does what you describe. When it hooks it opens the shared memory, and zero's it out. The problem is that memory also contains memory pointers and handles in the target process so yeah, crash. And because cheat engine doesn't know the exact offset where it allocated that memory it can't be safely de-allocated and the events for frame locking are also owner specific. (shared handle between the owner CE version and the game)


But there is a way to detect if it's loaded:
allocateSharedMemory('CED3D_'+getOpenedProcessID())

If the first byte of this result is 0 (empty path to cheat engine) it's not loaded

So if it's loaded you can tell the user to restart the game

[mgr.inz.Player]

[Dark Byte]

i'll look into it but it's not as straightforward

modulename+offset isn't a reliable solution as some programs might populate that memory block after all and actively use it so best spot is just store it in the shared memory object

The first problem is a small chicken and egg problem (can be solved)
To control access to the command list an Event is used. To obtain a handle to that event a process that owns it needs to call DuplicateHandle with that handle and a pointer to the memory new process. (so also needs to open CE itself, which is most of the time impossible if the game isn't running as admin)




---
Also, the d3d hook is not at all designed to deal with cheat engine closing. There is a part where it sends key presses and mouse clicks in the game's window to ce's lua and waits for a response on how to deal with it

And the most important thing: WHY close cheat engine/the trainer during the game? It won't take up much memory(the working set shrinks as blocks will get paged out), and depending on your script it won't take up much cpu
(It's not because of detection, because the module named "ced3d9hook.dll" is blatantly present inside the game's module list)

[mgr.inz.Player]

[mgr.inz.Player]

Or two AA scripts example:
Hook1:

[Dark Byte]

That is another example of why closing the first cheat engine is a bad idea
It will be unable to disable the cheat once ce has been closed since the address to the original unmodified bytes will be gone

[mgr.inz.Player]

Personally I use something like this for cheats with aobscan: