Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 1 down vote favorite

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.

share|improve this question

1 Answer

up vote 2 down vote accepted

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.

share|improve this answer
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 Mar 27 at 22:20
And with loads somewhere else i mean completely off cause otherwise it would work :) – Rob Mar 27 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 Mar 27 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 Mar 28 at 14:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.