为什么我的C程序在二进制文件中没有jmp esp指令？

Question

Why can you find jmp esp only in big applications?

In this little program you cant find jmp esp . But why? This is the source code:

#include <stdio.h>

int main(int argc, char **argv)
{
    char buffer[64];

    printf("Type in something: ");
    gets(buffer);
    return 0;
}

Answer 1

AT&T jmp *%esp / Intel jmp esp has machine code ff e4 . You should be looking for that byte sequence at any offset.
(I assembled a .s with that instruction and used objdump -d to get the machine code.)

There is a lot of discussion in comments from people who thought you were talking about
jmp *(%esp) as a ret without pop. For future readers, see Why JMP ESP instead of directly jumping into the stack on security.SE for more about this ret2reg technique to defeat stack ASLR when trying to return to your executable payload. (But not defeating non-executable stacks, so this is rarely useful on its own in modern systems.) It's a special case of a ROP gadget.

---

Compilers are never going to use that instruction intentionally, so you'll only ever find it as part of the bytes for another instruction, or in a non-code section. Or not at all if no data happens to include it.

Also, your search method could miss it if it did occur.

objdump | grep 'jmp.*esp' objdump | grep 'jmp.*esp' is not good here. That will miss ff e4 as part of mov eax, 0x1234e4ff for example. And disassembly of data sections similarly will only "check" bytes where objdump decides that an instruction starts. (It doesn't do overlapping disassembly starting from every possible byte address; it gets to the end of one instruction and assumes the next instruction starts there.)

---

But even so, I compiled your code with gcc8.2 with optimization disabled ( gcc -m32 foo.c ) and searched for e4 bytes in the output of hexdump -C . None of them were preceded by an ff byte. (I tried again with gcc -m32 -no-pie -fno-pie foo.c , still no ff e4)

There's no reason to expect that to appear in a tiny executable .

You could introduce one with a global const unsigned char jmp_esp[] = { 0xff, 0xe4 };

But note that modern toolchains (like late 2018 / 2019) put even the .rodata section in a non-executable segment. So you'd need to compile with -zexecstack for byte sequences in non-code sections to be useful as gadgets.

But you probably need -z execstack or something else to make the stack itself executable, for your payload itself to be in an executable page, not just a jmp esp in a const array.

---

If you disabled library ASLR, then you could use an ff e4 at a known address somewhere in libc. But with normal randomization of library mapping addresses, it's probably just as easy to try to guess the stack address of your buffer directly, +- some bytes you fill with a NOP slide. (Unless you can get the program you're attacking to leak a library address, defeating ASLR).