3

Whenever I attach a process in OllyDbg v1.10 on my Windows 7 64-bit machine, I notice that the first saved EBP on the stack doesn't point to the very base of the stack. Instead it points 16 bytes before it.

To illustrate what I mean, see the following screenshot: screen-shot of OllyDbg stack window

The EBP (highlighted in gray), which is right above the RETURN to ntdll.76FC9F45, is pointing to 1B05FFEC. Note that this address ends with EC, not FC.

Question 1: Why isn't the EBP pointing to 1B05FFFC?

Question 2: What do the first 16 bytes on the stack represent?

Question 3: Is the number of bytes (16), which are between StackBase and the address to where the first EBP points to, fixed for Windows OSs?

| improve this question | |
3

Question 1: Why isn't the EBP pointing to 1B05FFFC?

Because 1B05FFFC is not the base address of the stack frame.

The only reason that OllyDbg shows 1B05FFFC as the last address in the stack-view is that it's the address of the last DWORD in the stack's memory page.

Question 2: What do the first 16 bytes on the stack represent?

It depends on the debugger.

For example, from my limited testing...

When attaching WinDbg to a 32-bit EXE on Windows 7 x64, [ESP] is the return address back into ntdll!DbgUiRemoteBreakin from the call to ntdll!DbgBreakPoint.

When attaching OllyDbg v2.01 to a 32-bit EXE on Windows 7 x64 or Windows 7 x86, the debugger suspends the debuggee in the middle of an executing debuggee thread, so the value of ESP is whatever ESP was in the debuggee's thread at the moment OllyDbg attached to it.

| improve this answer | |
  • Hmm, that's strange... because the following code snippet should return the base of the stack, right? NtQueryInformationThread(remoteThread,(THREADINFOCLASS) 0, &tbi, sizeof(THREAD_BASIC_INFORMATION), &bytes_read); if (bytes_read != sizeof(THREAD_BASIC_INFORMATION)) return 1; NT_TIB *teb = (NT_TIB*) tbi.TebBaseAddress; stackBase = (DWORD) teb->StackBase; The teb->stackBase actually ends in FF, not EF. – Benny Feb 17 '14 at 18:59
  • In your answer to Question2 you mentioned that the 16 bytes depend on the debugger. However, I've used the code snipped from my previous comment to get the stack base address. Then I read DWORD after DWORD using memcpy, from base to top, and those 16 bytes at the beginning are still there. – Benny Feb 17 '14 at 20:02
  • 1
    The Thread Information Block's StackBase and StackLimit refer to the memory reserved for the thread's initial stack space (see doxygen.reactos.org/de/dbc/…). EBP (typically) points to the base of the current function's stack frame; it does not point to the base of the memory reserved for the thread's initial stack space. – Jason Geffner Feb 18 '14 at 0:28
  • Thanks for this insight Jason Geffner. Could you also please answer the following question for the sake of completeness? Question 3: Is the number of bytes (16) which are between StackBase and the address to where the first EBP points to, fixed for Windows OSs? I will edit my question above to include Question 3. – Benny Feb 18 '14 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.