I stashed some shellcode in an environment variable and am in the process of trying to overflow a program.
./notesearch $(python -c 'print "\x01\x01\x01\x01\x01\x01\x01\x01" * 15 + "\x9e\xe7\xff\xff\xff\x7f"')
The kick is that the overflow works perfect when run in GDB, as it throws me back a shell. However, outside of GDB things aren't running so smoothly. I turned off ASLR which was giving me problems originally until I finally resolved that problem and am now using the C function getenv() to get the exact variable which I am overflowing the program with. I am sure that I am filling the saved frame perfect because when I remove the last 6 bytes from the code that I am overflowing the program with it doesn't seg fault,
./notesearch $(python -c 'print "\x01\x01\x95\xe6\xff\xff\xff\x7f" * 15') #no seg fault
however when I add a single byte to the string afterwards it does, meaning I must be hitting the saved frame pointer with that last byte, as further confirmed with GDB.
./notesearch $(python -c 'print "\x01\x01\x95\xe6\xff\xff\xff\x7f" * 15 + "\x9e"') # does seg fault
Anyways, I also compiled with gcc notesearch.c -o notesearch -ggdb -fno-stack-protector -z execstack
, and as I said before it is working in GDB anyways, so I'm assuming it's more kernel protection? Any ideas?
It has been my experience that doing exploit development while observing something with gdb, memory offsets can change unexpectedly between the debugged environment and the "Real World."
As a suggestion, if you want to just sort of brute force it, try adjusting your offsets by between 1 and 8 bytes in either direction. Even better, try this:
ulimit -c nolimit
)Armed with this, get the exact offsets from tools/pattern_offset.rb!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With