How to find the stack size 64bit windows?

Index > Windows > How to find the stack size 64bit windows?

Author

Thread

eeikel

Joined: 17 Jun 2013
Posts: 7
Location: NL

eeikel 14 Apr 2016, 09:49

Hello,
i tried to get the stacksize and compare a register to see if an object is located on the stack or heap.
something like this:

In c:

Code:

#include "stdlib.h"
#include "stdio.h"
#include "string.h"

    void * isHeap(const void*);
                 int number = 12;
                 int * ptr = malloc(sizeof(int));
int main(){
                 *ptr = 34;

                 printf("%s",isHeap(&number));
                 printf("%s",isHeap(ptr));
                 if(ptr){free(ptr);puts("object freed.\n");};
return 0;
}

in asm OBJ file :

Code:


 format MS64 COFF ; object.o file
     public isHeap
     ;extrn 'printf' as _printf
          msg_on_stack db 'stack', 13, 10
          msg_on_heap  db 'heap' , 13, 10
                                        isHeap:

                                                ; stack grows down from a high address asigned by os, heap grows up from low address asigned by os
                                                mov rax, rsp     ; copy stackpointer value to rax
                                                add rax, 0x08    ; call causes stackpointer to be decremented add 8bytes to get previous original value

                                                cmp rax, rcx     ; compare in coming value in rxc with stackpointer value saved in rax
                                                jc .isStack      ; jc = above or equal CarryFlag = 1, jnc is opposite below or equal CarryFlag = 0
                                                mov rax,  msg_on_heap
                                               ; call _printf
                                               ; mov rax, 1 ; return one if true
                                                ret

                                              .isStack:
                                                       mov rax, msg_on_stack
                                                       ; call _printf
                                                       ; mov rax, 0 ; return 0 if false
                                                       ret

This seems to be working but i doubt if the code is good...
[/code]

14 Apr 2016, 09:49

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 14 Apr 2016, 10:00

Things on the stack will be at addresses numerically higher than or equal to RSP. But the relative positions of the heap and stack are not defined. One or the other may be higher in the address space so you will have to detect that at runtime.

14 Apr 2016, 10:00

eeikel

Joined: 17 Jun 2013
Posts: 7
Location: NL

eeikel 15 Apr 2016, 08:31

Goodmorning, I didn't want to walk the stack just a quick try to see if i could check wheater an address is located on the stack or heap.
The reason is iám doing some research to build a memory allocator for a program i'am working on and wanted to see if it is possible to check the memory address locations are valid and how it works in asm and windows.

My allocator design is to HeapAlloc or VirtualAlloc pagesized memory and allocate cache sized memory blocks through the program where needed. When fragmatation kicks in copy contents to a new pagesized block and return the old block to the operating system.

http://www.gamasutra.com/blogs/MichaelKissner/2011104/258271/Writing_a_Game_from_Scratch_Part_2_Memory.php
http://gameangst.com/?p=585
http://g.oswego.edu/dl/html/malloc.html
https://software.intel.com/en-us/articles/introduction-to-x64-assembly
http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/
http://www.codemachine.com/article_x64deepdive.html

15 Apr 2016, 08:31

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 15 Apr 2016, 08:34

You don't have to walk the stack, merely check if an address falls within the range [RSP,top-of-stack).

15 Apr 2016, 08:34

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 15 Apr 2016, 11:08

revolution

Quote:

range [RSP,top-of-stack)

rsp is the top of stack.

_________________
Faith is a superposition of knowledge and fallacy

15 Apr 2016, 11:08

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 15 Apr 2016, 11:50

l_inc wrote:

revolution

Quote:
range [RSP,top-of-stack)

rsp is the top of stack.

I always think in terms of numerical addresses. So for me top == highest address.

15 Apr 2016, 11:50

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 15 Apr 2016, 12:12

revolution
Well, this is wrong. And this kind of arbitrary manipulation with terms leads to misunderstandings and misconceptions. Top of stack is by definition modified by the stack operations.

And even in terms of plain numbers I'm not aware of any culture in the world, writing bottom-to-top. So if you are to type consecutive numbers, then you start at the top (of a sheet or a screen) and continue to increase them towards the bottom.

_________________
Faith is a superposition of knowledge and fallacy

15 Apr 2016, 12:12

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 15 Apr 2016, 14:50

l_inc wrote:

revolution
Well, this is wrong.

Well it is different. But as to wrong or right I am not so sure anyone can be so absolute.

However I do apologise to the OP if I caused some confusion. Your stack will be between RSP and increasing address values up to some value where the stack began its life when the thread started.

15 Apr 2016, 14:50

bitRAKE

Joined: 21 Jul 2003
Posts: 4020
Location: vpcmpistri

bitRAKE 15 Apr 2016, 15:08

A lazy way would be to get the stack address at program start (RSP) - stack will only grow downward (in terms of numerical address) from there. Stack reserve is set in the PE file format (ie constant). Round initial address to page size (BS = bottom of stack), and all stack addresses will be between BS - reserve, and BS.

15 Apr 2016, 15:08

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 15 Apr 2016, 15:12

bitRAKE wrote:

... get the stack address at program start (RSP) ...

Perhaps think about threads rather than the program. Each thread gets its own stack when started and so has a different RSP value. And the "main" program is really just another thread.

15 Apr 2016, 15:12

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 15 Apr 2016, 15:35

l_inc wrote:

So if you are to type consecutive numbers, then you start at the top (of a sheet or a screen) and continue to increase them towards the bottom.

Actually in a way that reinforces what I think about the stack. It starts at the top and the most recent item is on the bottom, just like a sheet of paper, or this text input box in this reply window. The bitmap format uses the smallest offset to to show the bottom pixels so there isn't any particular standard numbering order when humans define things. Razz

15 Apr 2016, 15:35

bitRAKE

Joined: 21 Jul 2003
Posts: 4020
Location: vpcmpistri

bitRAKE 15 Apr 2016, 16:41

revolution wrote:

bitRAKE wrote:
... get the stack address at program start (RSP) ...
Perhaps think about threads rather than the program. Each thread gets its own stack when started and so has a different RSP value. And the "main" program is really just another thread.

That's why I call this "lazy" - even main program could be given a new stack. Start of thread could also do this lazy method - it's only a couple instructions. So, each thread would know it's own stack.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

15 Apr 2016, 16:41

bitRAKE

Joined: 21 Jul 2003
Posts: 4020
Location: vpcmpistri

bitRAKE 15 Apr 2016, 23:32

Code:

FORMAT PE64 GUI 5.0 AT $10000
;       Reserve,        Commit
STACK   $10000,         $10000 ; defaults

SECTION '' READABLE WRITEABLE EXECUTABLE

ENTRY $
  push rsp
  pop rax
  ; stack end address
  add rax,4096 ; assume default page size
  and rax,0-4096 ; assume default page size
  ; stack start
  lea rcx,[rax-$10000]
  retn

The above code appears to work (per thread). Why is $3000 extra needed in memory map? $1000 for guard pages on both ends, but why $1000 more? Maybe thread info block is there?

Edits: The $3000 is at the start - still don't know why.

Even with these values Windows lets the stack grow downward to size $3C000. So, it doesn't really work. Could write an exception handler and update stack size dynamically. Or check the address dynamically against the memory map {preferred, make no assumption as to what Windows is really doing}. No lazy method.

If you play around with different reserve sizes, we can see strange things from Windows. For example, the reserve size isn't always available! (I reserved $100000, a MB; and only got $FF000 usable.)

15 Apr 2016, 23:32

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 16 Apr 2016, 21:29

revolution

Quote:

But as to wrong or right I am not so sure anyone can be so absolute.

It seems you are trying to drive the answer into a philosophical plane, and I don't feel it's appropriate. Can you say it's wrong that the Earth is flat? Have you seen it to be ball-like? On images only? Even if in real life, how can you be sure that was not just your fantasy or a dream? Or maybe your memories have been manipulated? Maybe they are being manipulated right now? There's a subjectively imposed boundary between what one calls knowledge and what belief (see my post signature). So either you throw away an important part of the language to always show you're in doubt about everything and this way always look unconfident, or you accept that starting from some 99 something percent of being sure you can say "I know", "This is wrong", etc.

So yes, it is clearly wrong that the top of stack is at larger addresses than its bottom. Because there is a single conventional definition for the term "top of stack" (covering containers beyond the context of a program stack). And the probability/importance of you silently creating your personal definition is negligible for this statement sounding absolute.

Quote:

Actually in a way that reinforces what I think about the stack. It starts at the top and the most recent item is on the bottom, just like a sheet of paper

This way of misrepresentation of an argument is called demagogism . You cannot take just any object to serve as a model for a stack. And I didn't take a sheet of paper or a screen to model it. I took it as an argument that it's not uncommon to associate smaller numbers or numerical addresses with higher spatial positions, which renders your anyway wrong argument even more invalid. And in the specific context of numerical addresses (debuggers, disassemblers, hex editors, etc.) smaller addresses are nearly always shown above larger addresses. It does not mean you cannot represent a stack so that it grows downwards (although I find these representations misleading), but you are still wrong calling the (this way appearing) upper limit of the stack top of stack.

_________________
Faith is a superposition of knowledge and fallacy

16 Apr 2016, 21:29

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum