I'm currently trying to exploit a simple program called basic_vuln.c

#include <stdio.h>;
int main(int argc, char** argv) {
  char buf[64];  
  strcpy(buf, argv[1]);  

I'm using xubuntu 12.10 with 3.5.0-17 Linux Kernel, ASLR turned off and compiled with the current version of tiny c compiler.

Now to the actual problem, I'm injecting a basic shellcode which spawns /bin/sh. The problem is that when I execute it within gdb, everything works fine and I get a shell. But if I start the program within bash I get a segfault.

I tried to get a core dump to see where the problem lies, but I guess because of the corrupt memory I don't get any (if I don't give the program any arguments, it segfaults and I get a core dump).

Any ideas? If you require more details on the system like gdb version or similar, I'll post it as fast as I can after request.

1 Answer 1


This will almost always happen. When you load a program into gdb, things get shifted around a bit - not much, but enough to make an address overwrite wrong.

You have a couple of options, you can use tools (such as metasploit's pattern_create.rb) to determine the actual address of your buffer in memory when the program is run outside the debugger. This is achieved simply by passing a non-repeating pattern to your program, and seeing at which address the segfault occurs (core dump), that way you can determine how far into your buffer lies the section that is written into the return address. ignore my rambling, this is completely unrelated, go with the nop sled

Or you can just extend your NOP sled a little and start guessing addresses. It usually doesn't take more than a dozen or so attempts on a small program.

  • Thanks for the answer, the problem is i already use a nopsled and tried different addresses, and they all work within gdb, and they all don't work without gdb. I'll try to look at /proc/pid/maps , maybe it loads somewhere else when used with gdb.
    – Rob
    Commented Mar 27, 2013 at 22:20
  • And with loads somewhere else i mean completely off cause otherwise it would work :)
    – Rob
    Commented Mar 27, 2013 at 22:35
  • Ok, the difference was like 0x50 or something, somehow weird but it now works. Thanks a lot. Also it is (works with debugger xor without debugger).
    – Rob
    Commented Mar 27, 2013 at 22:40
  • Glad you got there in the end, this is something I would like to read into a little more, as I have always been able to get around it quickly, I have never bothered looking into it. Perhaps one of the gurus such as @ThomasPornin could shed some light on debugger stack-addresses.
    – lynks
    Commented Mar 28, 2013 at 14:56
  • Found a good explanation while looking for the answer to a similar problem on stackoverflow
    – EricM
    Commented Mar 18, 2014 at 18:21

You must log in to answer this question.

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