Cheat Engine

[justa_dude]

Hi folks,

Does the auto-assembler's createthread function spawn a new thread whenever it is called, or does it just happen when the script is first assembled? That is, if I need to trigger an event to happen at some later time, can I spawn a thread with createthread to handle it? I can't tell from the documentation, and all the examples I've seen just use it to execute code from a different context.

Thanks in advance,
adude

[XaLeX]

To me it looks like some sort of preprocessor directive.

I did some testing and if it's placed in a non executed block, it still spawns the thread.
that is, if you do something like

[Dark Byte]

createthrea spawns the thread each time the script is executed.

If you want to make it happen at specific times, you have to do a code injection at a often used location, and there check for the event. And on that event call CreateThread

[justa_dude]

That was a good way to check, Xalex! Thanks for the taking a look, mate.

Thank you, too, for the suggestion DB. I had to read your response five times before I understood what you meant - but now that I see what you mean, it makes perfect sense. And I would want to still create a thread in such a situation instead of dispatching my own events because of the performance hit incurred by patching in a bunch of junk in a tightly nested loop.

Man, you guys are sharp!

I think that maybe it would be an easier workaround in this case to just let the thread run ad infinitum with booleans to "start" or "stop."

I did come across something that gave me some trouble in solving the problem on my own. I usually do my debugging over a terminal server connection, and createthread seems to do something funny in this case. I don't really understand what's going on. The thread's code gets injected properly, but it never gets executed. Also, if it's assigned to the address list, the check-mark never appears when you enable the script and the disable section never gets executed. It's the first time I've had problems with the TSS setup, and I'm not quite sure how to workaround it. Any ideas?

Thanks a million,
adude

[Dark Byte]

sounds like a security problem
CreateRemoteThread requires administrator rights, and special privilege added to that

Check that the account you use has the rights to setup SeDebugProcess privilege and to fully open processes, including ones that it doesn't own

[justa_dude]

The account I use is an administrative account local to the machine being debugged. My understanding is that such users are granted SeDebug by default. Would I be able to attach the debugger otherwise? Is there anything I should check, aside from Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment in the policy editor?

Thanks DB,
adude

[Dark Byte]

hmm, no idea

as for debugging when that right would be disabled you'd only be able to debug apps you started yourself, or if you'd use the kernel debugger

[Dark Byte]

What you could try is run the application using "run As..." and then run it with the same credentials as the account you use for terminal services.
Most likely there won't be a problem then

[justa_dude]

I usually run cheat engine w/ the same credentials as the host machine. I tried it the other way around (running the debugee w/ the debuger's credentials and CE w/ debugger's credentials) and ended up w/ the same result. Running CE and the debugee on the same machine is the only way I've gotten it to work so far.

For what it's worth, this is the script I'm using for testing purposes:

[justa_dude]

Not sure if this is interesting to anyone else, but I just noticed on the documentation page for the CreateRemoteThread function that, "Terminal Services isolates each terminal session by design. Therefore, CreateRemoteThread fails if the target process is in a different session than the calling process."

So much for that, I guess.

Cheers,
adude