{"id":969,"date":"2022-08-30T15:10:12","date_gmt":"2022-08-30T15:10:12","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2013\/11\/09\/what-is-on-the-stack-before-my-program-starts-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:10:12","modified_gmt":"2022-08-30T15:10:12","slug":"what-is-on-the-stack-before-my-program-starts-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/what-is-on-the-stack-before-my-program-starts-collection-of-common-programming-errors\/","title":{"rendered":"What is on the stack before my program starts?-Collection of common programming errors"},"content":{"rendered":"

Before the execution of main()<\/code> a bunch of other operations need to be done by the OS to properly setup the environment before control of the execution is handled to your application. So, most of what’s on the stack at this point is garbage left from previous operations.<\/p>\n

Right before main()<\/code> is executed, you can expect to find argc<\/code> and argv<\/code> on the stack as well.<\/p>\n

EDIT:<\/strong><\/p>\n

A comment from a user kinda challenged me to go through the process of debugging an assembly application in gdb<\/strong> and examining the stack to backup a statement I made on the original answer.<\/p>\n

So please consider the following assembly code written in nasm<\/em>:<\/p>\n

section .data\n\n  mymsg db \"hello, world\", 0xa  ; string with a carriage-return\n  mylen equ $-mymsg             ; string length in bytes\n\nsection .text\nglobal mystart                ; make the main function externally visible\n\nmystart:\n    ; prepare the arguments for syscall write()\n    push dword mylen          ; msg length                           \n    push dword mymsg          ; msg to write\n    push dword 1              ; file descriptor number\n\n    ; call write()\n    mov eax, 0x4              ; 0x4 identifies syscall write()\n    sub esp, 4                ; OS X (and BSD) syscalls needs \"extra space\" on stack\n    int 0x80                  ; trigger the call\n\n    ; clean up the stack\n    add esp, 16               ; 3 args * 4 bytes\/arg + 4 bytes extra space = 16 bytes\n\n    ; prepare argument for syscall exit()\n    push dword 0              ; exit status returned to the operating system\n\n    ; call exit()\n    mov eax, 0x1              ; 0x1 identifies syscall exit()\n    sub esp, 4                ; OS X (and BSD) system calls needs \"extra space\" on stack\n    int 0x80                  ; trigger the call\n<\/code><\/pre>\n
I compiled this on Mac OS X with:<\/p>\n
nasm -f macho -o hello.o hello.nasm\nld -o hello -e mystart hello.o \n<\/code><\/pre>\n
As you can probably tell by the source code, the start of the application is defined by mystart<\/code>, and it doesn’t take any parameters.<\/p>\n
Now, let’s make this investigation a little more exciting by opening this program in gdb<\/strong>:<\/p>\n
gdb .\/hello\n<\/code><\/pre>\n
After gdb<\/strong> has loaded, it’s important for educational purposes to set a cmd line parameter for this application even though it wasn’t written to accept any.<\/p>\n
set args deadbeef\n<\/code><\/pre>\n
The application is still not running at this point. We need to set a breakpoint<\/em> to the beginning of the main<\/em> function so can inspect the stack to see what’s going on before our application starts executing it’s own code:<\/p>\n
break mystart\n<\/code><\/pre>\n
Execute the command run<\/code> on gdb to start the application and break the execution. Now we can inspect the stack with:<\/p>\n
x\/20xw $esp\n<\/code><\/pre>\n
outputs:<\/p>\n
(gdb) x\/20xw $esp\n0xbffff8cc: 0x00002000  0x00000000  0x00000002  0xbffff96c\n0xbffff8dc: 0xbffff98b  0x00000000  0xbffff994  0xbffff9b0\n0xbffff8ec: 0xbffff9c1  0xbffff9d1  0xbffffa0b  0xbffffa40\n0xbffff8fc: 0xbffffa5b  0xbffffa86  0xbffffa97  0xbffffaad\n0xbffff90c: 0xbffffad8  0xbffffafa  0xbffffb06  0xbffffb28\n<\/code><\/pre>\n
Yes Sir, this command prints the contents of the stack. It tells gdb<\/strong> to show 20 words in hexadecimal format starting at the address stored by the $esp<\/code> register.<\/p>\n
Let’s see, $esp<\/code> actually points to 0xbffff8cc<\/code>, ok but examining what’s stored by this memory address reveals another<\/em> address: 0x00002000<\/code>. To what does it points to???<\/p>\n
(gdb) x\/20sw 0x00002000\n0x2000 :  \"hello, world\\n\"\n<\/code><\/pre>\n
Not a shocker, right?! So let’s take a look at what some of the other addresses of the table are pointing to:<\/p>\n
(gdb) x\/1sw 0xbffff96c\n0xbffff96c:  \"\/Developer\/workspace\/asm\/hello\"\n<\/code><\/pre>\n
Wow. That’s actually the original application’s name and path<\/strong> stored right there on the stack! Awesome, let’s continue to the next interesting address of the table:<\/p>\n
(gdb) x\/1sw 0xbffff98b\n0xbffff98b:  \"deadbeef\"\n<\/code><\/pre>\n
Jackpot! The cmd line argument we passed upon executing our application also got stored in the stack. So as I’ve stated before, among the garbage stored in the stack before your application executes, you can also find cmd line parameters that were used to execute the application even when the main()<\/code> function of the application is void<\/code> and doesn’t take any parameters.<\/p>\n
Originally posted 2013-11-09 23:08:39. <\/small><\/p>","protected":false},"excerpt":{"rendered":"
Before the execution of main() a bunch of other operations need to be done by the OS to properly setup the environment before control of the execution is handled to your application. So, most of what’s on the stack at this point is garbage left from previous operations. Right before main() is executed, you can […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-969","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/969","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=969"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/969\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}