EH-Net

Could someone please explain exactly what is going on in the following code... actually.. just that pointer line.. not exactly sure whats going on.

Also, I'm going through the shell coders handbook and have a question..

So we are overflowing the following program:

I compiled it with the mpreferred-stack-boundary=2 option.

Ran it in the same operating system and CPU type as the examples.. this applies to other examples from other sources as well.. so why is it that the amount of memory the cpu allocates on the stack always different.

In the book when this program is run through gdb and return_input is disassembled.. it shows sub $0x20, %esp a.k.a 32.. but on my computer it shows 0x24 or 36...

shouldn't the buffer be the same?

also, this was the same case when I was following along with the BoF series at securitytube.net ... the funny thing though.. was that the code he provided worked for me.. even though gdb showed that we had different memory sizes allocated...

 ???

As I understand, you are setting the 4 byte buffer location to a specific address in memory (0x08048415).  You are typecasting the address of the 4 byte buffer as a long pointer and dereferencing it, so that you can set its value.  At least, that's the way I understand it.

Which page of the Shellcoders Handbook are you on? 

You are probably running into some stack randomization and protection with the newer gcc versions.  Try compiling with the -fno-stack-protector option set. 

He's on page 21 stack overflows...

Let's plop it open on a newer system (sure life is unfair!)

# gdb function
GNU gdb 6.8-debian
Copyright (C) 2008 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 "i486-linux-gnu"...
(gdb) disas main
Dump of assembler code for function main:
0x0804835c <main+0>:    push   %ebp
0x0804835d <main+1>:    mov    %esp,%ebp
0x0804835f <main+3>:    sub    $0x8,%esp
0x08048362 <main+6>:    movl   $0x2,0x4(%esp)
0x0804836a <main+14>:   movl   $0x1,(%esp)
0x08048371 <main+21>:   call   0x8048354 <function>
0x08048376 <main+26>:   movl   $0x8048498,(%esp)
0x0804837d <main+33>:   call   0x8048290 <printf@plt>
0x08048382 <main+38>:   leave
0x08048383 <main+39>:   ret
End of assembler dump.
(gdb)


Notice the differences in compiling on two different machines?

For function return_input we have:

# gdb function
GNU gdb 6.8-debian
Copyright (C) 2008 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 "i486-linux-gnu"...
(gdb) disas main
Dump of assembler code for function main:
0x08048412 <main+0>:    push   %ebp
0x08048413 <main+1>:    mov    %esp,%ebp
0x08048415 <main+3>:    call   0x80483f4 <return_input>
0x0804841a <main+8>:    mov    $0x0,%eax
0x0804841f <main+13>:   pop    %ebp
0x08048420 <main+14>:   ret
End of assembler dump.


Not to omit the errors:

strategos ~ # gcc -mpreferred-stack-boundary=2 -fno-stack-protector  -ggdb void.c -o function
/tmp/ccDrZEEj.o: In function `return_input':
/root/void.c:7: warning: the `gets' function is dangerous and should not be used.

Anyhow, see the difference in return address (0x80483f4). What is your return address when you compiled the original?

...

Notice the address?

stuffing ... 0x80483f4;

What is your output from function when you disassembled it?

To be fair, I went back to the root of it all.... RHEL9



Magic number: 0x8048328

What likely confused you is your next disassemble call:

In the book you will see disas main again when it should be disas function:


(gdb) disas function


What part is not working for you?

Thank you for the responses :D. I'll get back to you with more details on my memory prob.

Alright.. here it is.

Overflowing following program:

2. Disas main to get memory location where return_input is called.


As you can see, it is called at 0x0804841 I'm confused why you used the actual location of <return_input>

3. I then check to see how much space is reserved for return_input by disas return_input


As you can see.. it reserves 0x24 which in binary is 36. i don't understand why it reserves 36 but in the example in the book it only reserves 0x20 aka 32 .. its the same program.. with the same variable sizes..??

so then the example program used to overwrite the memory locations with the pointer to the <return_input> call is:


Since I have 4 bytes extra.. i changed both values to:


Makes sense.. right?

BTW.. why is stuffing 4 bytes larger.. is there something appended to the end like in strings?

Anyways.. in the end when I feed the program into the overflow program.. it doesn't work.

Below.. i execute the command (./address_to_char;cat) | ./overflow and then it waits for input, i type in "input" and it exits. Completely different then what the book shows.. so it isn't working.. or is it? is the ./address_to_char the first input the program expects .. and my input "input" the second input because it goes back to return_addr?


The book shows something like this:


(page 22)

Lastly.. the command (./address_to_char;cat) | ./overflow .. what exactly is going on there..i thought to input the output of a program to another you would use the ">" command.

If anyone could help me out it would be awesome.. because I can't continue until I understand these basics :D.

Thanks!


Edit: I also used the following options:

-fno-stack-protector

echo 0 > /proc/sys/kernel/randomize_va_space - disable virtual address randomization

gcc -mpreferred-stack-boundary=2 -ggdb

I don't have the book so I can't help you much.

I compiled your program with and without -mpreferred-stack-boundary=2 option. When th option is set my disassembly for main and return_input is.

As you can see, for me the stack shifted 40 decimal bytes.

Compiling without -mpreferred-stack-boundary=2
Stack moved 56 bytes down.

I then set one breakpoint before gets is called and one after, for both of the above cases.

For the first case ( -mpreferred-s.....)
For the first case, as you can see the first 10 decimal bytes weren't filled at all. Where 0xbffff0c8 is the stack pointer just before gets() was called. So the 40 bytes shift minus 10 bytes not filled space = 30 bytes buffer.
0x08048483 is the return address.
My solution for you ends here. I'm still a beginner ]

Now for the strange part and hopefully, if someone answers it, it might help you too (you still reading it? ;))
For the second case (without -mpreferr.....)

Clearly, the first 18 decimal bytes weren't filled. So 56 bytes shift in ESP minus 18 bytes unfilled space=38 bytes buffer. But this time I get a segmentation fault even when overflow overwrites the 'old' base pointer. I don't know why. This could be because of -mpreferred-stack-boundary not set.
0xbffff000 is the overwritten value of 'old' base pointer. bffff0 is the original value from the old base pointer and the last 00 is the null byte from the string (AA...).