I just started learning about bof exploits. to some extent I was able to grasp the concepts. however, there is something that I could not understand till now even after searching the web for it !

When Exploiting stack based BOF, the EBP and the EIP values on the stack should be over written with supplied buffer code. however, I tried fuzz "ABILITY FTP SERVER". I was able to find the exact bytes that overwrites the EIP.

the fuzzer sent 966*"\x41" + 4*"\x42" + "\x43"*1030

the EIP was overwritten with BBBB as expected. it was preceded with 966A and 1030C were after the bbbb.

after the crash, I examined the debugger and found some issues confusing:

1-the EBP address is lower than the ESP although it should be higher than it. as per my knowledge ESP should be at the lowest address !

2-Since ESP was over written with part of the supplied buffer which is "CCCCCCCCCCCCCCCCCCCCC", the EBP as well should be over written, however, it was not.

3-is not it expected that the supplied buffer starts from the ESP and going downside towards the EIP at the bottom of the stack? w hich means that the ESP should points to AAAAAAA instead of CCCCCCCCC ?

1-the EBP address is lower than the ESP although it should be higher than it. as per my knowledge ESP should be at the lowest address !

You need to look at the target source code (or step through the executable). Where in the code execution are you? Since EIP is 0x42424242, it looks like your function has just returned. So, three things have just happened:

1) the current frame pointer (EBP) which had not been modified by you was copied into ESP

2) the saved frame pointer which was modified by you was restored into EBP

3) A return ("ret") instruction transferred control to the saved EIP value which was stored at the current ESP location

So, according to this screenshot, EBP was 0x012bb6b8. The saved EBP was 0x003abb40 and the saved EIP was 0x42424242 which was stored at 0x012bb6b4 (ESP - 4).

That doesn't make sense. We know you overwrote the saved EIP value with 0x42424242 and we know that EIP should have been adjacent to EBP on the stack. So, the saved EBP value should be made up of 0x41s and/or 0x42s. It's possible that this code was compiled to not use EBP as the frame pointer or that at this particular point in the code the compiler performed some optimization which prevented EBP from being restored. I'm not sure.

Look at the disassembly and step through the code.

2-Since ESP was over written with part of the supplied buffer which is "CCCCCCCCCCCCCCCCCCCCC", the EBP as well should be over written, however, it was not.

Don't confuse overwriting ESP or EBP with overwriting the contents at the location pointed to by EBP and ESP. EBP and ESP are pointers stored in registers. Since the value in EBP changes for each new function call (which necessitates a new stack frame), the old EBP is stored on the stack itself. If you overwrite the old EBP value on the stack, then it will be loaded into the EBP register when the function returns. Until the function returns, your overflow will not affect EBP. To overwrite ESP, you need to control EBP first so you need a second function return to copy your modified EBP into ESP.

3-is not it expected that the supplied buffer starts from the ESP and going downside towards the EIP at the bottom of the stack? w hich means that the ESP should points to AAAAAAA instead of CCCCCCCCC ?

A string copy is going to target a variable/buffer on the stack. It won't necessarily start at ESP. The copy should move down the stack (toward a higher address). The saved EIP should be further down the stack (at a higher address).

In your screenshot, EIP is 0x42424242 which means that the function has already executed "ret". This also means that the EBP value was copied into ESP. EBP pointed to a lower location on the stack (a higher memory address) so it makes sense that it would point to "BBBB" or "CCCC".

2-is not it expected that the supplied buffer starts from the ESP and going downside towards the EIP at the bottom of the stack? w hich means that the ESP should points to AAAAAAA instead of CCCCCCCCC ?

"Aren't the function parameters you've supplied (ptr to param1 in your example) getting popped also?I mean, if you overwrite saved EIP with some acceptable address, and after DoStuff returns, EIP gets popped off the stack, but these passed input parameters must be popped too?If I am correct,then ESP will point to "+ some bytes" after "EIP + input vars", and not directly after "EIP" and this is the reason you add four symbols before the shellcode (my $preshellcode = “XXXX”;) ?Thank you!"

and

"I figure out my first question when i read this article http://en.wikipedia.org/wiki/X…..entions. In my c code i use to debug, if i defines the DoStuff function as "void _cdecl DoStuff(char* param1)" or "void DoStuff(char* param1)", then there is no need to adjust the shellcode with 4 more bytes.If i defines the DoStuff function as "void _stdcall DoStuff(char* param1)",then we have to adjust the shellcode with 4 more bytes. The difference is made by whom is responsible for cleaning the arguments from the stack,the caller or the callee.Is it right?"

the key point is that function arguments gets popped out of the stack too, that's why ESP is pointing to higher address values. also this may differ from function to another based on the first post which indicates that this depends on who is responsible for cleaning the arguments from the stack !