Cheat Engine

[coffeeAchiever]

If you read CE tutorials, you'll read that black addresses are dynamic and green are static, but what does that really mean?

I know more about Linux than Windows, but if I had to take a guess at what static and dynamic means if CE were a Linux application, I would say that CE reads the following segments of a process's virtual address space:

1. data segment: pre-initialized statics/globals
2. BSS segment: kernel-initialized statics/globals
3. stack: automatic variables
4. heap: dynamically allocated variables

I also see offsets into other process's address spaces, so CE probably follows dynamically linked references to other processes. Libraries, for instance. I never learned the details of how shared code is stored in memory, but I assume it has its own address space which somehow gets "tacked on" to the virtual space of other processes. Somehow.

I know this isn't quite correct for Win32, but I'm sure there must be parallels. If I had to take a guess, I'd say:

1. black addresses are heap addresses and green addresses are everything else.

or

2. black addresses are heap and stack variables, and green variables are everything else.

I looked up virtual memory layouts on Windows. It looks more complicated, but the ideas are the same. Anyway, I'm sure that's completely out of scope for these forums (unless anyone here gets off on stuff like this -- I would love to learn more.)

My main questions:

1. If I asked a computer science professor what the difference is between black and green addresses in CE, what would he tell me?
2. There's a ton of tutorials about CE in the context of cheating at games. Some of them are quite good, but is there a more theoretically minded CE tutorial that anyone has written?

Thanks!

[Krampus]

1. Black addresses are dynamic. They change every time the game is reset, sometimes even while playing the game. Green addresses are static. Usually they point to dynamic addresses. In coding, a green address would be a pointer to dynamically allocated memory.

In C++ (A lot of games are written in C++), I could declare a pointer to memory on the heap like this:

int * pPointer = new int;

This is an integer pointer, and it points to a piece of allocated memory. That allocated memory could kind of be seen as a black address. The pointer can be seen as a green address.

At the end, or during the runtime, we free the allocate memory:

delete pPointer;
pPointer = NULL;

When this happens, the address of the dynamic memory changes. If we found the pointer, we wouldn't have to deal with that issue.

I probably WAY over explained that, as well as made a few errors in the process, but it should get the idea over nicely .

2. Not that I know of.

[zm0d]

[coffeeAchiever]

Thanks -- I had to look up what PE (it's the Win32 version of the ELF or COFF format), but makes perfect sense.

Black variables are both stack and heap, and that makes perfect sense. Heap is a no-brainer. Stack makes sense because any program that has control flow will not allocate stack items in the same order and therefore not have the same address. The only thing you can be 100% sure of are the addresses that are pre-allocated at compile time, which are globals and statics, both initialized explicitly by the programmer or implicitly by the compiler. Thanks for explaining that.

As a followup question, one difference between MS Win and Linux is that the Linux stack/heap is pretty high in the address space. On Win32, it's extremely low. Below everything except except for some system reserved stuff.

But then I see scans like this where black addresses are much higher than green addresses, like the scan I'm attaching.

What precisely is happening here? Shouldn't the black addresses be generally lower than green addresses?

[Dark Byte]

stack is actually a "semi" static address. the symbol threadstack0 will point to a certain constant position in the main thread's stack. At initialization there is a high chance the first local variables and passed parameters are always in the same order and can contain interesting references.
e. g: CGame *g=new CGame(); g->run();
the local varable g would recide in the stack and contain the pointer to the game object (which is quite handy to have)

It's not shown in the addresslist, but some features can use it (pointerscan for one)

the location of stack and heap is actually randomized since windows vista(every run they get allocated at a new position)
and when the current heap region is used up windows will just allocate a new block at another location
also, besides heap there are other memory management options.
e.g: it's common to use an api like virtualalloc to allocate a block of memory and manage it yourself (similar to using mmap in linux)

[Krampus]

[zm0d]

[coffeeAchiever]

[Dark Byte]

yes, that's basically it. The assembler code generated actually references those addresses directly (e. g: mov eax, [804a024]) so they have to be there else things go wrong
(in windows and possibly linux there is also a relocation table that can change that code when loaded, but it is all relative to eachother. always the same distance. And look up "position independant code" )

and change

[giomismo]