We have a program that is vulnerable to a one byte frame pointer overwrite. The stack is marked executable, the Linux machine has aslr disabled, stack cookies are disabled, and it's a little endian standard x86.

We may run:


for(int i=0; i <=256; i++)
  buf[i] = argv[1][i];

However, I want to put my shellcode into buf and then jump to it. If I would use a normal stack overflow, I could get exploit reliability by going to a loaded library which has the jmp $esp instruction somewhere encoded, and then put my shellcode where the function arguments are and so forth. But this is not possible here.

So what do you do if it's a remote process (you can't hardcode the address values) and need exploit reliability? The only thing that came to mind is stack alignment where we could be able to predict the low bits (2 or 3 bits maybe?).

I just need to know the low byte of the frame pointer so I can overwrite it with a little smaller value control eip to point to jmp esp and at the instruction at esp would be like a short jump -0x80 or something such as that.

I have decreased the frame pointer => ret gets executed => control eip => point eip to jmp esp instruction => next instruction is the short jump -0xsomevalue execution => payload gets executed.

I thought about other heuristics like writing the pointer to jmp esp over and over into the buffer so that it's more likely to get control of eip, but that way my method of jmp -0xsomevalue wouldn't work anymore.

  • I'm not sure I understand your problem here. Obviously you want to use the technique of frame-pointer overwrite. And, then you need to guess where you are in memory, so you use a small ROP technique to guess... But, then, where is the problem ?
    – perror
    Commented Apr 7, 2013 at 10:44
  • You could pad the buffer with \x90 (nops) until you reach your shellcode? [NNNNNNNNNSSSSSSSSS] (N is nops S is shellcode), you then "gues" in the whole NOP interval. Nops are a single byte. Otherwise I dont really know what you mean.
    – Anonymous
    Commented Sep 10, 2013 at 9:06
  • @SanderDemeester I think the OP knows the NOP sled trick... it's pretty common knowledge and he seems to know a thing or two. Commented Oct 22, 2013 at 14:54
  • 1
    @Rob I would suggest storing your shellcode in an environment variable in the shell Commented Oct 22, 2013 at 14:55
  • 1
    To answer this question we would need much more than you have provided. For example, is this in a function? Is this in the main function? What else is happening around it? How is it later used? With what you have provided it is clearly bad but it is entirely possible that it is not exploitable. Commented Feb 24, 2014 at 19:00

2 Answers 2


I had an extremely similar homework problem that I had in a security class. The reliability of your exploit depends on how large the buffer is. If you are overflowing a particularly large buffer, then your exploit will have a larger chance of working.

Here is how your exploit sandwich should be structured:

[NOPS][Shellcode (usually about ~60 bytes)][FP overwrite]

As you know, you will only be able to overwrite the last couple of bits of the Frame Pointer. This will cause the EIP to point into your sled if you are lucky enough. If you have a buffer of size 265 like in your example, here is how a good sandwhich would look:

[NOPS * 150][Shellcode][FP overwrite] << FP Overwrite MUST be at index 256

Now as I said, the reliability of your exploit is going to rely on the size of the sled you can produce. If you buffer is 1024 bytes, then your exploit will be very efficient.

If you come up with a good value for your Frame Pointer overwrite, then you are going to have a lot more success with your exploit. Also creating the largest possible sled is going to be key here as well. For this exploit, it is probably safe to use:

NOPS = (size of exploited buffer + 1) - length of shellcode - 1


NOPS = (size of exploited buffer) - length of shellcode

This will give you the largest change possible of landing in your NOP sled. Now just play with the FP overwrite value and find a value that is pretty consistent.

helpful info on off-by-one errors:

How a nop sled works:

Here is the article I had to read for my class, it was really helpful:


Creating reliable exploits requires time and patience and lots of debugging.

I think what you are looking for is a NOP Sled or NOP Slide. When you execute the short jump you need to land it in the middle of the NOP Slide, so the execution then slides through the NOPs to your shellcode.

Check out this site for a detailed breakdown of exploit writing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .