Cheat Engine

[justa_dude]

Hi folks,

I'm much more comfortable writing in C/C++ than ASM (lol, no shock there I suppose). The script engine is therefore very very attractive to me. What exactly is it? How does it work? Is it basically a full-fledged C compiler? My only exposure to it so far is in working through the CE tutorial, and I'd really like to read up on it. I suppose I can learn some things by examining the assembly that it produces, but it sure would be nice to have some more formal documentation. Any pointers?

Thanks in advance,
adude

[Dark Byte]

you can check out here:
http://home.mweb.co.za/sd/sdonovan/underc.html
also I hear https://code.google.com/p/underc-fltk/ is trying to continue work on it (but looks stalled as well)

I'm not so sure if future versions of CE will still come with this specific C-library though (1: porting to 64-bit is going to be tricky, 2: currently it has a small memory leak for each executed script, making it unsuitable for injection in routines that are executed millions of times)

[justa_dude]

Wow! underc is AMAZING! I'm afraid that diving into the CE source isn't on my immediate agenda, but I'm quite curious about how underc is "glued" in.

A cursory glance at the code it generates makes me think that maybe CE just wraps the C++ code into a string and passes it to a monolithic parser that's been injected into the debugged process. Is this correct? Does CE do any manipulation of the string prior to passing it on to underc - i.e. matching variables with the CE symbol tables?

Is there any facility within CE for working with the C++ script it feeds to underc once the code has been "injected" (aside from direct modification in memory, of course)? It would be nice to be able to tinker incrementally with the underc scripts like I do with the autoassembler via attaching scripts to the table. Should I just build my strings in the autoassembler and pass them directly to the underc dll? Is there a convenient way to do so?

Is the scoping of everything in a CE-hosted underc script local to the script itself? Is it possible to declare a function in one script that calls a function in another? Is it possible to declare static variables that persist from one execution to the next, or must one use a priori pointers?

What is the nature of the memory leak?

HAHA - sorry, yet again, for the deluge of questions. Many of them probably have obvious answers, so I apologize for thinking out loud. The idea of being able to drop a C switch block or start dropping pairs into a C++ STL map in the middle of an assembly block on the fly just blows my mind! Going from coding in C with inline assembly to coding in assembly with inline C++ is just an amazing notion!

Thanks,
adude

[Dark Byte]

it's just a wrapper so it becomes thread safe.
(basically a class that has beginscript, execute, endscript, where beginscript and endscript ae just a critical section enter/leave)

It also adds in some pre-defines, so those values are always there, like the addresses of some of ce's plugin api's

declaring a function in one script and being called by the other: the scriptengine supports it, but not supported by the implementation of CE (This is because an even bigger memory leak ,in 10's of KB's at a time, so ce clears as much as possible before a new script is executed)

As for the nature of the memory leak: Not sure where in the library it is, but I see that even just executing an empty script " just some spaces and a ;" eats up some memory

As for an easier and more powerful alternate to underc:
Just write your C++ code in a real c++ compiler, compile it as a dll with ungarbled names, inject that dll into the game and do:

[justa_dude]

Thank you for the kind explanation and great example code. Much appreciated, sir.

[justa_dude]

Is there any way to give a full file path to the injectdll auto-assembler function? If not, where does it look - normal DLL search path?

Thanks,
adude

[Dark Byte]

Yes, it can take a full pathname
But if you don't provide one ce will first check if the dll is in CE's folder
if not found, it checks if the dll is in the current work dir of ce
and if that fails, the normal dll search path

[justa_dude]

Thank you, sir, for responding. I'm afraid that I can't seem to figure out how to give it a full path. What, for example, is the syntax for injecting "C:\Develop\Projects\testdll\testdll.dll?"

Thanks in advance,
adude

ps: the error I get is "error in line X,(injectdll('all_permutations_of_pathname_I_can_think_of.dll')):this instruction can't be compiled

[Dark Byte]

loadlibrary(C:\Develop\Projects\testdll\testdll.dll)
should work fine

I tested it in ce 5.6 loading ce 6's dll (different folder)

[justa_dude]

loadlibrary works a treat! Thanks, DB - you really are THE MAN!

Sincerely,
adude

[justa_dude]

I built underc today, and I can see why you're planning on dropping support. It's loaded w/ tons of gnarly preprocessor stuff in order to support compilers that were in use a decade ago. Fixing up the ifdefs and namespace issues (.h stdlib files don't seem to be supported anymore) it built OK, but it was a pain.

Are the memory leaks perhaps related to using createremotethread to execute the scripts and then not closing the handles that createremotethread returns?

Cheers,
adude

[Dark Byte]

the memory leak also happens on the local execution in ce so without createremotethread (e.g when using it to render the dissect data view you'll see the memory leak in action)