[Project 1] Calling confused and returning clean

[Ashwin]

Hi,

Has anyone cracked problem 5? If so, any hints that could be helpful?

Although I could call confused() from victim_func(), and return to
main() and print "Done", the control is going back to victim_func()
after that. I couldn't reason this. Anyone wants to discuss about
this?

Thanks and Regards,
Ashwin

[ranal]

AFAIK the main is called again. that is why the victim_func() is
executed. in yesterday's demo the starting addr. of main was at a[8]
(i do not know whether you noticed it) i think if we can overwrite it
with some garbage, the main might not get called. but when the
professor introduced args that addr. disappeared. (even after printing
till 25 he could not get that addr. on the stack)


ranal

[Partha Dasgupta]

The appearance of the address of main (and sometimes addresses of other functions) on the stack was baffling me.

But it is due to calls to printf. When you print something, the argument is passed via the stack. If that stack location is not clobbered, the argument stays on the stack and then may be picked up as a return address due to the buffer overflow and subsequent returns without corresponding calls.

--
You received this message because you are subscribed to the Google Groups "asu-cse-466-Fall-2007" group.
To post to this group, send email to asu-cse-46...@googlegroups.com.
To unsubscribe from this group, send email to asu-cse-466-fall...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/asu-cse-466-fall-2007?hl=en.

--
Partha Dasgupta,
School of Computing Informatics, Arizona State University
EMail: par...@asu.edu
http://cactus.eas.asu.edu/partha

[Ashwin]

Yes. That's what I thought too. But I loaded the binary on gdb, and
set a breakpoint where I'm returning to main() and checked the
contents of esp and eip. Nothing unusual. The next instruction
executed was not the beginning of main. I continued execution, and it
returns clean out of main, and then to start and then to init. Here's
what I found.

<code>

0x08048599 <main+76>: call 0x8048455 <victim_func>
0x0804859e <main+81>: movl $0x80487b7,(%esp)
0x080485a5 <main+88>: call 0x8048368 <printf@plt>
0x080485aa <main+93>: mov $0x0,%eax
0x080485af <main+98>: add $0x14,%esp
0x080485b2 <main+101>: pop %ecx
0x080485b3 <main+102>: pop %ebp
0x080485b4 <main+103>: lea -0x4(%ecx),%esp
0x080485b7 <main+106>: ret
End of assembler dump.
(gdb) b *0x804859e
Breakpoint 1 at 0x804859e
(gdb) run
Starting program: /home/shastry/a.out
Address of system: 8048338
Address of victim_func: 8048455
Return of main(): 0xb7e7a450
Enter n: 9
~~~~~~~~~~~~~ values and address of n locations ~~~~~~~~~~
a[0] = 80487a1, address = bfc8b618
a[1] = bfc8b634, address = bfc8b61c
a[2] = bfc8b634, address = bfc8b620
a[3] = b7faeff4, address = bfc8b624
a[4] = bfc8b648, address = bfc8b628
a[5] = 804859e, address = bfc8b62c
a[6] = 80487a1, address = bfc8b630
a[7] = b7e7a450, address = bfc8b634
a[8] = bfc8b658, address = bfc8b638
Enter 9 HEX Values
1
2
3
4
5
8048414
804859e
0
0
Done reading junk numbers
**Who called me? Why am I here?? *** 0

Breakpoint 1, 0x0804859e in main ()
Current language: auto; currently asm
(gdb) ni
0x080485a5 in main ()
(gdb) i r esp eip
esp 0xbfc8b634 0xbfc8b634
eip 0x80485a5 0x80485a5 <main+88>
(gdb) ni

0x080485aa in main ()
(gdb) ni
0x080485af in main ()
(gdb) ni
0x080485b2 in main ()
(gdb)

</code>

But, this is happening only during debugging. Not when I execute it
normally.

[Partha Dasgupta]

> But, this is happening only during debugging.
> Not when I execute it normally.

Debugging changes everything, as functions of the debugger are called using the processes stack in surreptitious ways. Also leaves garbage on the stack in "unused" areas.

Looks like the leftover garbage causes quite an issue.

--p