8

I wrote a program in C that is exploitable to BOF.

TL;DR - My payload (NOP-sled + shellcode + return address) overrides EIP but I can't set EIP to point to the address of my payload, although I can set EIP to be anywhere else outside the Stack adress-range. Stack seems to be executable and the proections I familiar with are off.

I sent a payload using ragg2 De bruijin pattern, and found the offset that overrides EIP. I then created a payload with NOP-sled, then shellcode, and at the offset that overrides EIP I wrote the address of the middle of my NOP-sled.

So the payload looked something like this: NOP-sled + Shellcode + Address somewhere at the middle of my NOP-Sled (Little Endian).

Something strange happened and I wasn't able to exploit the program: after the segfault, EIP wasn't at the address I used at the end of my payload, EIP was like 600 addresses after. But when I changed the address at the end of my payload to something else, like "AABB" (0x42424141), or 0xd4d4fdff (instead of 0xd4d4ffff that is an address at the middle of my shellcode, little-endian) it worked just fine and EIP was at the address I supplied.

nx protection is off, ASLR is disabled, Selinux disabled, the memory page seems to be executable and the ELF compiled using "-fno-stack-protector -z execstack" on GCC.

Tried it also on gdb and also outside of any debugger.

what can be the problem? Why it refuses to jump to the address on the stack?

Info about the binary:

havecode true
pic      false
canary   false
nx       false
crypto   false
va       true
intrp    /lib/ld-linux.so.2
bintype  elf
class    ELF32
lang     c
arch     x86
bits     32
machine  Intel 80386
os       linux
minopsz  1
maxopsz  16
pcalign  0
subsys   linux
endian   little
stripped false
static   false
linenum  true
lsyms    true
relocs   true
rpath    NONE
binsz    6162

Info about the stack:

sys 132K 0xfffdd000 - 0xffffe000 s -rwx [stack] [stack] ; map._stack_._rwx

EDIT: You can find more details, including commands and the shellcode itself here: http://pastebin.com/HYbByNSE

Improve this question
5
  • Can you post your shellcode and the full command line arguments/env/exploit you're using to execute this?
    – movsx
    Commented Jan 14, 2017 at 14:43
  • Here you go, tell me if you need anymore data: pastebin.com/HYbByNSE
    – api pota
    Commented Jan 14, 2017 at 15:54
  • Is it possible that 0xd4d4ffff isn't actually in the NOP sled? Did you get that address in gdb by any chance?
    – movsx
    Commented Jan 14, 2017 at 16:20
  • I got it in radare2. The payload isn't working in r2 debug mode even though it supposed to work. I know that the addresses are changed inside a debugger like r2 or gdb so I also tried the payload with different addresses +-20 bytes. The thing is that EIP isn't taking any address from the range of the stack, any other address works fine. So 0xd4d4ffff is on the NOP-Sled when I try to exploit the program in radare2 but of course it might not be on the stack outside r2, that;s why I tried another addresses.
    – api pota
    Commented Jan 14, 2017 at 16:28
  • 1
    Without looking at it too much, I got it working just by reducing the NOP's to 24. Similar environment (32 bit, NX and ASLR disabled)
    – movsx
    Commented Jan 16, 2017 at 2:04

1 Answer 1

Reset to default
2

Based on the payload that you posted, It seems that you want EIP to jump to 0xffffd4d4. Set a breakpoint at that address (0xffffd4d4) before running the program. This way you will know if program execution ever reached 0xffffd4d4.

Maybe there is a problem in the Shellcode and your program might be segfaulting halfway through the shellcode. I had a lot of similar problems when I had started out.

PS. In your question you mentioned 0xd4d4ffff. Please check. Because if you want to jump to 0xd4d4ffff you need to replace EIP with \xff\xff\xd4\xd4 and not \xd4\xd4\xff\xff.

Improve this answer

You must log in to answer this question.

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