I'm currently reading Gray Hat Hacking The Ethical Hacker's Handbook, Fourth Edition and I have a question with an exercise in the book. The lab "Lab 10 - 1 Overflow of meet.c" is a lab in which we perform a buffer overflow in the program. The program is as follow:

#include <stdio.h>   // needed for screen printing
#include <string.h>

greeting(char *temp1,char *temp2){ // greeting function to say hello
   char name[400];    // string variable to hold the name
   strcpy(name, temp2);    // copy the function argument to name
   printf("Hello %s %s\n", temp1, name); // print out the greeting
main(int argc, char * argv[]){      // note the format for arguments
   greeting(argv[1], argv[2]);      // call function pass title & name
   printf("Bye %s %s\n", argv[1], argv[2]);   // say "bye"
} // exit program

The book informs you to compile the code with:

gcc -ggdb -mpreferred-stack-boundary=2 -fno-stack-protector -z execstack -o meet meet.c

I'm not too sure what each argument pass to the compiler mean I read from the man page that mpreferred-stack-boundary attempts to aligned the stack boundary in this case 2 ^ 2 = 4 bytes. I've seen the no stack protector flag used before so I know that it allows smashing of the stack and the -z execstack I want to believe is to make data executable form the stack (removing the NX bit).

And prior to all this we already disabled ASLR using the command:

echo "0" > /proc/sys/kernel/randomize_va_space

The book also mention to disable the following:

echo "0" > /proc/sys/kernel/exec-shield
echo "0" > /proc/sys/kernel/exec-shield-randomize

I didn't find these files in the specified directory so I didn't run the command I was curious if this was causing my issue so I googled it and found this forum post:


But the forum post stated that the arguments we past to the compiler already takes care of disabling the "exec-shield" feature and the "exec-shield-randomize" feature.

So the issue I am having is when I follow the book instructions I receive different results from the book.

The book said the stack frame would resemble this:

                         Variable                            Parameters
|           |    ESP   |    Name   |   EBP   |   EIP   |   Temp1   |   Temp2  |
Low Mem:               <--------- Stack Grow                         High Mem:
0x11111111                                                        0xfffffff0

They then loaded the program in gnu debugger with the following command:

gdb -q meet

They then placed a breakpoint on line 7:

strcpy(name, temp2);

An passed the overflow argument value using perl:

(gdb) run Mr perl -e 'print "A" x 600'

For that the got the following output:

Breakpoint 1, greeting (temp1=0x41414141 <Address 0x41414141 out of bounds>,
    temp2=0x41414141 <Address 0x41414141 out of bounds>) at meet.c:7
          printf("Hello %s %s\n",temp1, name); //print out the greeting

So they successfully written over the EIP register, temp1 and temp2 pointers as the book said but when I tried it I got this:

my gdb output

I tried 600, 1,000, 10,000, and as you can see in the screenshot 100,000 A's. So can someone tell me if I am doing something wrong am I forgeting to disable a security feature or something like that?

OS info:

Ubunut 14.04 Linux ubuntu 3.19.0-49-generic #55~14.04.1-Ubuntu SMP Fri Jan 22 11:23:34 UTC 2016 i686 i686 i686 GNU/Linux


This is the book results: Gray Hat BOF breakpoint result

The book state that now the pointers temp1 and temp2 are overwritten and now points to null for me this didn't happen. Why?

  • What do your registers look like when the crash happens?
    – Dirk
    Commented Feb 24, 2016 at 13:24
  • Have you noticed, that despite of your x 100000 in the command line, gdb says 'A' <repeats 200 times>?
    – ott--
    Commented Feb 24, 2016 at 15:40
  • @ott-- yea I noticed hence the reason I believe it was due to some security feature I forgot to disabled. I'm at work right now I will take a look at everyone's response in depth when I reach home. Commented Feb 24, 2016 at 16:09
  • @PolymathMonkey do you want me to crash the program with any number of A's because 600 A's also crashes the program my concern is why i don't get the results the book gets. The book has the temp1 & temp2 variable addresss being all A's (0x41) im just wondering why this is not happening for me. Commented Feb 25, 2016 at 0:44

2 Answers 2


Your screenshot shows that gdb has hit the breakpoint, Temp1 and temp2 aren't overwritten yet because you are hitting a breakpoint on strcpy which halts execution before strcpy overwrites the stack. As per your book image you can see that their line 7 is printf which happens after strcpy corrupts the stack. Try using the c gdb command to continue. Eip control occurs in the epilogue, when the function returns.

  • Yea I understand what you're saying I blieve. You're saying that EIP controls occur after the function call has finish, in which it clears the stack form the value placed on it from its function call and return (EIP) to the next line from which it made the call from right? I really want to know why temp 1 & temp2 is not overwritten because its messing up my understanding of how the stack works (with security features disabled). I will provide an excerpt with the book results. Commented Feb 25, 2016 at 0:55
  • 1
    Temp1 and temp2 aren't overwritten yet because you are hitting a breakpoint on strcpy which halts execution before strcpy overwrites the stack. As per your book image you can see that their line 7 is printf which happens after strcpy corrupts the stack.
    – wireghoul
    Commented Feb 25, 2016 at 1:14
  • (FACEPALM) yup that is exactly what i was looking for. One extra line i made in my code I thought the source i had was identical to what was in the book. It went out of sync when i added an extra line before the main declaration. none the less thank you soooooooo much. Can you modify your answer so I check this off as the solution. Commented Feb 25, 2016 at 1:21

One side note not directly related to the problem :

I'm not sure if the book you're using is the best to start your pentesting\exploit development with. I would recommend OSCP's hands-on or Georgia weidman's book "Penetration testing A Hands-On Introduction to Hacking"
Or you can try SEED project's labs.

Now i'm not sure i can tell what is going wrong without trying the lab (Which i'll try do and get back to you). However, I can tell you that increasing the buffer's size is not always the answer. In fact, it sometimes corrupts your exploit because your extra long buffer might overwrite the caller's function data causing the app to call the exception handler which -if happened -will move the address of the exception handler function to the EIP, and will force you to do things in a different way to overwrite the EIP because now the address of the exception handler is in the EIP, not your buffer .

  • Thanks for the tips on the hands-on and books will take a look into them. I understand what you are saying. I understand the exploit is to overwrite EIP value and if i increase the buffer that would cause the address of the exception handler to be placed in the EIP instead; thanks for that explanation. I eventual want to overwrite the EIP to get the exploit working but I'm wondering why doesn't temp1 & temp2 address don't get overwritten I don't believe the stack frame is that large right? hence the reason I am increasing the size just to see if I can overwrite the address of temp1 and temp2. Commented Feb 24, 2016 at 5:29
  • I've added some info about my OS basically the output of uname -r command. Commented Feb 24, 2016 at 5:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .