Stack is totally messed up by trying to produce a buffer overflow

after hours of debugging without any effort, I hope to find some help here on StackOverflow.

I'm currently on a PTP training and due to the fact that I'm only using Linux, i also want to practice the very firsts Labs on my local machine.

What i have to do is to exploit a very simple Program via buffer overflow. Just the Sources are given:

goodpwd.cpp:

#include <iostream>
#include <cstring>

int bf_overflow(char *str){
       char buffer[10];         //our buffer
       strcpy(buffer,str);      //the vulnerable command
       return 0;
}

int good_password(){            // a function which is never executed
       printf("Valid password supplied\n");
       printf("This is good_password function \n");
       return 0;
}

int main(int argc, char *argv[])
{
       int password=0; // controls whether password is valid or not
       printf("You are in goodpwd.exe now\n");
       bf_overflow(argv[1]); //call the function and pass user input
       if ( password == 1) {
             good_password(); //this should never happen
 }
         else {
       printf("Invalid Password!!!\n");
 }
       printf("Quitting sample1.exe\n");
       return 0;
}

I compiled it to get an executable by using

gcc -fno-stack-protector -z execstack -o goodpwd goodpwd.cpp -ggdb -m32 -lstdc++ -no-pie -O0

(I also already tried it without -no-pie and -O0 but I thought maybe the optimization could be the problem..)

I used gdb to debug the executable:

gdb goodpwd -tui -q

After setting a breakpoint to line 6 (the one with the vulnerable strcpy) I executed the following command:

(gdb) run AAAAAAAAAAAAAABCDE

after pressing n to go to the next line, I had a look into the stack:

(gdb) x/20x $esp

this gave me the following result:

0xffffd6f0:     0xffffd748      0x4141a8b0      0x41414141      0x41414141
0xffffd700:     0x41414141      0x45444342      0xffffd700      0x0804923b
0xffffd710:     0xffffd99c      0xf7fe4bd0      0xffffd800      0x08049209
0xffffd720:     0x00000002      0xffffd7f4      0xffffd800      0x00000000
0xffffd730:     0x0804c000      0x00000002      0x08049080      0xffffd760

I cannot explain myself why:

• there are two A's at 0xffffd6f4
• there are no A's at 0xffffd6f6
• I got 16 A's starting at 0xffffd6f8
• I got EDCB at 0xffffd704 (because of little endian, thank you @1201ProgramAlarm)
• $bsp is 0xffffd708 and $eip is 0x80491a7 but after doing two more steps (leaving the function) $eip is set to 0x804923e because after all I've learned, I'm pretty sure it should be 0x08049209
• after those two steps I get those error: main (argc=<error reading variable: Cannot access memory at address 0x4141a8b0>, argv=<error reading variable: Cannot access memory at address 0x4141a8b4>) at goodpwd.cpp:21

I'd really appreciate if there's someone who's able to help me. Struggling in module 3 of 43 is not the best feeling I've ever got :D

Edit: ASLR should be deactivated:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Maybe it was a bit too late yesterday. But today I found out, that @1202ProgramAlarm made a very good point.

Because of using a little-endian system, 0xffffd704 was right. My confusions about 0xffffd6f4 and 0xffffd6f6 have been irrelevant because they not influenced the result.

The value of the old $EIP was still in 0xffffd70e but I never touched it. I just had to enhance the string in the argument and afterwards I've been able to exploit the vulnerability. It was a lot of fun. Thanks for the advises.