3

I was trying to understand buffer overflow attacks using the following C program

#include"stdio.h"  
#include"string.h"   
void iwontprint()  
{  
    printf("i wont be printed!");  
}  

void callme()  
{  
    char buffer[8];  
    gets(buffer);  
    puts(buffer);  
}  

int main(int argc,int** argv)  
{  
    callme();  
    return 0;  
}

Loading up the program in GDB before calling the gets(buffer) gives the following value of ESP :

0xbffff4d4: 0xb7ff0590 0x080484db 0xb7fc1ff4 0xbffff4e8  
0xbffff4e4: 0x080484b6 0xbffff568 0xb7e79e46 0x00000001

And after entering the input 123456789abc\x7c\x84\x04\x08 I am getting totally different values in ESP :

0xbffff4d4: 0xbffff4d8 0x34333231 0x38373635 0x63626139  
0xbffff4e4: 0x6337785c 0x3438785c 0x3430785c 0x3830785c

I've already set randomize_va_space = 0

$cat /proc/sys/kernel/randomize_va_space   
0

Can anybody provide any pointers as to what am I missing here ?

closed as off topic by Mellowcandle, 0xC0000022L, mrduclaw, Ange, perror Apr 10 '13 at 13:53

Questions on Reverse Engineering Stack Exchange are expected to relate to reverse engineering within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Although very interesting I find it off topic, voting to close – Mellowcandle Apr 9 '13 at 16:09
9

Your Stack is totally fine. Look more careful at the values:

0x34333231 0x38373635 0x63626139 0x6337785c 0x3438785c 0x3430785c 0x3830785c

which interpreted as an ascii string becomes this. literally:

123456789abc\x7c\x84\x04\x08

As you can see, it's exactly what you entered. And I mean by that, that for example \x7c is the String "\x7c" and not "|". Use this technique to send the values properly:

echo -e "123456789abc\x7c\x84\x04\x08" | ./yourbinary

  • Thanks for your response. however I am not able to understand why 0x63626139 is there instead of 0x0804847c (which i entered as input in little endian). – Novice User Apr 9 '13 at 10:07
  • AFAIK , 0xbffff4d8 & 0x34333231 are for char buffer[8] and 0x38373635 should be for value of EBP (old). Then the next value should be the one i entered (beyond 12 bytes) ? – Novice User Apr 9 '13 at 10:09
  • No. You didn't enter 0x0804847c. You entered 0x3830785c, which is: 0x5c==\ , 0x78==x, 0x30==0, 0x38==8 that is \x08 as a string. not the byte value 0x08. – samuirai Apr 9 '13 at 10:17
  • actually , echo won't interpret \x escapes either unless you specify -e switch – 0xea Apr 9 '13 at 10:26
  • Only on Linux. The BSD Version doesn't know this option (unix.com/man-page/FreeBSD/1/echo) – samuirai Apr 9 '13 at 10:28
4

Samurai's answer is correct , but put more clearly , your mistake is that you enter the literal string

123456789abc\x7c\x84\x04\x08

where as what you probably want is something like:

perl -e 'print "123456789abc\x7c\x84\x04\x08"' | ./yourbinary

In the first case the \x7c\x84\x04\x08 is just that, a 16 characters length string, where in the second case, the \x escape sequence is actually interpreted and \x7c\x84\x04\x08 is printed as just 4 bytes.

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