Quantcast
Channel: Waste in memory allocation for local variables - Stack Overflow
Viewing all articles
Browse latest Browse all 3

Waste in memory allocation for local variables

$
0
0

This my program:

void test_function(int a, int b, int c, int d){    int flag;    char buffer[10];   flag = 31337;   buffer[0] = 'A';}int main() {    test_function(1, 2, 3, 4);}

I compile this program with the debug option:

gcc -g my_program.c

I use gdb and I disassemble the test_function with intel syntax:

(gdb) disassemble test_functionDump of assembler code for function test_function:0x08048344 <test_function+0>:   push   ebp0x08048345 <test_function+1>:   mov    ebp,esp0x08048347 <test_function+3>:   sub    esp,0x280x0804834a <test_function+6>:   mov    DWORD PTR [ebp-12],0x7a690x08048351 <test_function+13>:  mov    BYTE PTR [ebp-40],0x410x08048355 <test_function+17>:  leave  0x08048356 <test_function+18>:  ret    End of assembler dump.

And I disassemble the main:

(gdb) disassemble mainDump of assembler code for function main:0x08048357 <main+0>:    push   ebp0x08048358 <main+1>:    mov    ebp,esp0x0804835a <main+3>:    sub    esp,0x180x0804835d <main+6>:    and    esp,0xfffffff00x08048360 <main+9>:    mov    eax,0x00x08048365 <main+14>:   sub    esp,eax0x08048367 <main+16>:   mov    DWORD PTR [esp+12],0x40x0804836f <main+24>:   mov    DWORD PTR [esp+8],0x30x08048377 <main+32>:   mov    DWORD PTR [esp+4],0x20x0804837f <main+40>:   mov    DWORD PTR [esp],0x10x08048386 <main+47>:   call   0x8048344 <test_function>0x0804838b <main+52>:   leave  0x0804838c <main+53>:   ret    End of assembler dump.

I place a breakpoint at this adresse: 0x08048355 (leave instruction for the test_function) and I run the program.

I watch the stack like this:

(gdb) x/16w $esp0xbffff7d0:     0x00000041      0x08049548      0xbffff7e8      0x080482490xbffff7e0:     0xb7f9f729      0xb7fd6ff4      0xbffff818      0x00007a690xbffff7f0:     0xb7fd6ff4      0xbffff8ac      0xbffff818      0x0804838b0xbffff800:     0x00000001      0x00000002      0x00000003      0x00000004

0x0804838b is the return adress, 0xbffff818 is the saved frame pointer (main ebp) and flag variable is stocked 12 bytes further. Why 12?

I don't understand this instruction:

0x0804834a <test_function+6>:   mov    DWORD PTR [ebp-12],0x7a69

Why we don't stock the content's variable 0x00007a69 in ebp-4 instead of 0xbffff8ac?

Same question for buffer. Why 40?

We don't waste the memory? 0xb7fd6ff4 0xbffff8ac and 0xb7f9f729 0xb7fd6ff4 0xbffff818 0x08049548 0xbffff7e8 0x08048249 are not used?

This the output for the command gcc -Q -v -g my_program.c:

Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/specsConfigured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug i486-linux-gnuThread model: posixgcc version 3.3.6 (Ubuntu 1:3.3.6-15ubuntu1) /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/cc1 -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=6 notesearch.c -dumpbase notesearch.c -auxbase notesearch -g -version -o /tmp/ccGT0kTf.sGNU C version 3.3.6 (Ubuntu 1:3.3.6-15ubuntu1) (i486-linux-gnu)        compiled by GNU C version 3.3.6 (Ubuntu 1:3.3.6-15ubuntu1).GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129473options passed:  -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=6 -auxbase -goptions enabled:  -fpeephole -ffunction-cse -fkeep-static-consts -fpcc-struct-return -fgcse-lm -fgcse-sm -fsched-interblock -fsched-spec -fbranch-count-reg -fcommon -fgnu-linker -fargument-alias -fzero-initialized-in-bss -fident -fmath-errno -ftrapping-math -m80387 -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387 -maccumulate-outgoing-args -mcpu=pentiumpro -march=i486ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"ignoring nonexistent directory "/usr/i486-linux-gnu/include"ignoring nonexistent directory "/usr/include/i486-linux-gnu"#include "..." search starts here:#include <...> search starts here: /usr/local/include /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/include /usr/includeEnd of search list. gnu_dev_major gnu_dev_minor gnu_dev_makedev stat lstat fstat mknod fatal ec_malloc dump main print_notes find_user_note search_noteExecution times (seconds) preprocessing         :   0.00 ( 0%) usr   0.01 (25%) sys   0.00 ( 0%) wall lexical analysis      :   0.00 ( 0%) usr   0.01 (25%) sys   0.00 ( 0%) wall parser                :   0.02 (100%) usr   0.01 (25%) sys   0.00 ( 0%) wall TOTAL                 :   0.02             0.04             0.00 as -V -Qy -o /tmp/ccugTYeu.o /tmp/ccGT0kTf.sGNU assembler version 2.17.50 (i486-linux-gnu) using BFD version 2.17.50 20070103 Ubuntu /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crt1.o /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crti.o /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/crtbegin.o -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6 -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. /tmp/ccugTYeu.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/crtend.o /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crtn.o

NOTE: I read the book "The art of exploitation" and I use the VM provides with the book.


Viewing all articles
Browse latest Browse all 3

Latest Images

Trending Articles





Latest Images