Forum Thread: Overwriting the EIP. (Help)

You might have to bounce it off another program. Have you read Ciuffy's Attack on the Stack series? That might help a lot.

Thanks Cracker Hacker !

You are not being very clear. Like when you say "afterwards you overwrite the EIP.... But nothing happens. Why is this????" Do you mean that you don't see your string overwrite the contents of EIP? Then you say "I addressed it with the malicious code I wish to execute, but nothing." What space in memory is your shellcode landing? Going only by what you provided us I think you are a bit confused at what you are trying to do, or I am by your explanation.

Hey Dill,

Sorry. By "But nothing happens", I meant, that I did not see it overwrite the contents of the EIP.

Do you see it overwrite any registers?

Nope. Not at all.

Then what exactly are you trying to do?

I'm just testing my skills. But, when I run my malicious code, it doesn't work.

I'm sure it doesn't. Let's start over. What exactly are you trying to do? For example, do you have a program you believe is vulnerable to a buffer overflow and you would like to exploit that? Or are you trying to use an exploit you found and it's not working? Just saying that your string doesn't overwrite EIP and then your malicious code (shellcode right?) doesn't work gets us nowhere, and only leaves so many more questions.

I found a program that I think is vulnerable to a buffer overflow and I'd like to exploit that.

OK, that I may be able to work with. Give me a few minutes to write something up to try and help you.

The first thing we need to do is verify that we can overflow the buffer and overwrite a register. Use your string and keep increasing it's size until you see it in one (if so this may mean we can control the application and ultimately point it to your shellcode).

Here we can see that several registers have been overwritten and importantly EIP has been overwritten.

If we can overwrite EIP (an instruction pointer) we may be able to control where the next instruction comes from. In the debugger we can clearly see that we have overwritten EIP. So the next thing we need to do is find out how much memory we have to overwrite before hitting EIP. We can do this by using a unique string so we can easily narrow it down. Metasploit can do this for us with:

/usr/share/metasploit-framework/tools/pattern_create.rb <size_goes_here>
Then we can look in our debugger and see the contents of the registers.

Now we can see the contents of EIP after we overwrote the memory. From our unique string EIP now contains 0lB9 in this case. We can then use metasploit again to determine the exact length. /usr/share/metasploit-framework/tools/pattern_offset.rb <contents_of_EIP>

Ah, the Mini-Stream MP3 Converter, eh?

Easy RM to MP3 Converter, it's a great example from the corelan team. To give credit were credit is due. It simply worked well in this case.

Oh, the new one. I worked with Mini-stream and published an exploit for it. Very similar, the buffer overflow dependencies are.

This tells us the exact length we need to overflow the buffer and overwrite EIP. Now we need to figure out how to tell EIP to jump to our shellcode. If we look at the debugger we can see (in this example) that ESP has been overwritten also. So we should be able to overflow the buffer rewrite EIP and tell it to point to ESP that we have overwritten with our shell code right?

You could always bounce it off another program (usually a required process) at the jmp point.

Exactly what you would look at next. You would want to find something that would use the jmp to ESP. This will allow us to tell EIP to jmp to our shellcode that will be located in ESP.

I don't get this part: are you trying to jump to ESP to avoid address randomization, so that you just have to calculate where in .text or else this instruction is?

Basically, when the function is exiting:
leave moves ESP to EBP, so somewhere past the overflow, an address which is being overwritten by the overflow.

ret acquires the overwrittem return address (addressing a "jmp esp" instruction), so that the process jumps into the injected string for sure, and the flow of the program can be controlled and it's easier to inject code, since you only need to do some calculations to align RET and shellcode

Is this what are you trying to do, or am I misreading?

Sorry for not being clear Ciuffy, it was getting late and I may have rushed things. In this simple example that's pretty much the outline of what we are trying to do. We want to jump to esp since that points to our shellcode, a clean and simple way to do this would be to find a jmp esp instruction located in the application it's self. This would ensure that we would always be able to return to our shellcode after the crash and do it cleanly. Since we know that if the application is loaded the instructions will be there as long as the location of the jmp esp isn't randomized also (this does not include randomization that's what made it a very simple example to use).

No problem, it was more like a mental breakdown for myself. Well, jumping to registers is actually used as a way to avoid ASLR, if you can then calculate your way trough it.

What architecture are you using?
Is the debugger running no address randomization?
Is the stack executable?

Maybe you are doing everything correctly but ignoring the defensive layer.

Clapping @ Ciuffys Rise <!-- Like the spin?-->