So when exploiting a Buffer Overflow vulnerability, the attacker needs to not only generate the payload (Let's say to create a binding shell), but also set up the corrupted buffer with the said payload to be sent to the victim's machine. (ie. a tcp echo server that utilizes a vulnerable BoF function call that is running on Windows XP OS). And as part of setting up the buffer, there needs to be certain parameters taken from the victim's machine; such as

  • the EIP offset at the moment of the crash
  • the memory location of the corrupted EIP (pointing at the payload to be executed).

My Question is:

In a professional pen testing environment how would the pen tester access the above two parameters without having access to the victim's machine? Meaning without having to install a disassembler and debugger inside the victim PC and actually analyze the program in the debugger.

Is there another way to simulate this attack without having access to the victim's machine?

  • 1
    Are you basically asking how a buffer overflow can be done remotely?
    – forest
    Apr 5, 2018 at 3:55
  • Yes that is exactly what I meant in the question =]
    – 0x5929
    Apr 5, 2018 at 3:57
  • A copy of the software on their own machine they can use to fuzz and debug crashes
    – McMatty
    Apr 5, 2018 at 4:53
  • Obtained by some social engineering?
    – 0x5929
    Apr 5, 2018 at 5:52

1 Answer 1


Most of the times you'll have to emulate the target's system and develop your exploit locally. About how to learn about the target's system, that has to do with the enumeration process. Of course depending on the binary you're trying to exploit, it may be possible to achieve an information leakage, and in that way you'll be able to make your exploit work even remotely even if your system is a bit different from the target's system (of course if your target uses e.g. linux you'll have to use linux also, but not the exact version).

For example, in case of a format string vulnerability you may be able to leak libc remotely. But there are other cases also, for example if the binary uses a string writing function, like puts (or printf etc...), it may be possible to use that function to leak libc base address from a GOT entry in runtime so you can construct a multi-stage exploit that bypasses even aslr. Now about how you can compute libc base address from a leak, there many ways (you can either use libc database or a web wrapper of libc-database here etc...).

  • I see, so can one calculate the EIP offset and the corrupted EIP memory location (of JMP ESP instruction for example) from the said information leak (libc base address) ?
    – 0x5929
    Apr 5, 2018 at 14:36
  • yes almost, EIP offset depends on the binary and doesn't have to do anything with libc, but JMP ESP and other gadgets will probably (if they are part of the binary) depend on libc base address, so the important thing here is that even if aslr is enabled your exploit will still be working!
    – game0ver
    Apr 5, 2018 at 15:57
  • @gameOver, thank you for the explanation. So technically without a copy of the binary we are trying to exploit, it would be very difficult to obtain the EIP offset or even the JMP ESP instruction memory when the libc base address is leaked?
    – 0x5929
    Apr 5, 2018 at 16:08
  • and best way to administer this attack is to actually have a copy of the vulnerable binary?
    – 0x5929
    Apr 5, 2018 at 16:10
  • 1
    yes of course, without the binary you will probably not be able to determine EIP offset to craft your exploit, but in case you have the binary then your exploit will be more "system-independent".
    – game0ver
    Apr 5, 2018 at 20:05

You must log in to answer this question.

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