Cheat Engine

[Polynomial]

Had a thought (albeit whilst drunk) about the stack pointer. Would it be possible to allocate new memory, copy the contents of the stack to that new location, then change esp to the new memory address? Or is ESP read only?

[Flyte]

Why would you want to?

[Dark Byte]

yes, you can do that, but why?

[Polynomial]

It'd be something that I might do when obfuscating. Just an idea anyway.

[Slugsnack]

You probably shouldn't though, the stack is not just the same as a regular block of memory. For example, at the end of it are some guard pages so if the stack 'overflows' for the first few times, it can be extended.

[Polynomial]

Shouldn't a ReadProcessMemory or NtQueryVirtualMemory call find all the memory on the stack so I can copy to it, stack guards and all? I would expect the OS to be able to find the stack guards easily, since they are offset from ESP.

[Slugsnack]

well yes, you could do that. something else you might like to know though, is that each thread uses its own stack. and if you wanted to relocate a stack, it'd probably be best to suspend that thread, do your work, then continue it

if you were looking for the guard pages, it's probably better to start looking for ebp as well. the offset from esp would be variable. still completely missing the reason as to why you'd want to do this though :/

[Polynomial]

It's pretty much a chaff-style protection. If you came across some code that you know utilizes anti-debugger mechanisms, and you see that it's shifted the stack to a new area of memory, you'd automatically assume that it's some kind of protection method and go analyse it. Eventually you'd realise that it doesn't actually do anything, but it'd nag in the back of your head whenever another mechanism tripped during debugging. I find psychology can be a useful protection mechanism.

[Slugsnack]

btw i think the easiest way of relocating the stack would be to do so from another thread. bearing in mind making any function calls from an existing thread would alter its stack, you'd probably want it to be static during the copying process

[Polynomial]

I'd probably store ESP in a variable somewhere, freeze the thread, use a second thread to ReadProcessMemory the stack and generate the new one, store the new stack pointer in that variable, unfreeze the first thread and then have it write that value to ESP.

Here's a step-by-step to illustrate what I mean:
T1 writes ESP to Var
T1 starts T2
T2 freezes T1
T2 copies stack to NewStack
T2 writes address of NewStack into Var
T2 unfreezes T1
T1 writes Var to ESP

[Slugsnack]

the writing of variable is not necessary. i believe you'd be able to do the whole thing with Get/SetThreadContext()/SuspendThread(), etc.

[Polynomial]

Wasn't aware you could read the stack pointer with GetThreadContext. I'll take a look at the docs and give it a go.

[Slugsnack]

yes, registers count as part of thread's context. think of everything that must be preserved when the processor does a context switch. on my machine, the CONTEXT structure is defined to have the following members :
- ContextFlags
- Dr0
- Dr1
- Dr2
- Dr3
- Dr6
- Dr7
- Eax
- Ebp
- Ebx
- Ecx
- Edi
- Edx
- EFlags
- Eip
- Esi
- Esp
- ExtendedRegisters
- FloatSave
- SegCs
- SegDs
- SegEs
- SegFs
- SegGs
- SegSs

here's a cool example of get/setthreadcontext(). it should explain to you the concepts behind what you're trying to do. in masm32 though :
http://win32assembly.online.fr/tut29.html

[Polynomial]

So it doesn't store SSE registers like xmm1? Seems odd. Or is that covered in ExtendedRegisters?

[Slugsnack]

the ContextFlags member of CONTEXT would tell you which of the other members of the CONTEXT are valid. bear in mind the mmx registers overlay the fpu registers. you should download the latest sdk and look inside your WinNT.h