CODEWITHSUNDEEP
assemblyx86intel
Shibumi
Shibumi

Reputation: 715

execv with user input

I am writing a little programm in x86er assembly intel syntax. It should ask the user for input like "ls" and execute this command through "/bin/sh -c ". But it didn't work.. The problem is the adress of "ls". I can't insert the adress of the input in the argument array. Here some output of gdb:

gdb$ x/s 0x8049115
0x8049115:  "\034\221\004\bDDDls\n"

as you can see.. I am copying the string not the adress of the string. How can I fix the problem? :)

Here is my code:

section .bss
buffer: resb 128

section .data
msg: db "Your Input here: "
len: equ $-msg
exec: db "/bin/sh#-c#AAAABBBBCCCCDDDD"

section .text
global _start

_start:

  mov eax, 4
  mov ebx, 1
  mov ecx, msg
  mov edx, len
  int 0x80

  mov eax, 3
  mov ebx, 0
  mov ecx, buffer
  int 0x80

  xor eax, eax
  mov byte [exec + 7], al
  mov byte [exec + 10], al
  mov long [exec + 12], exec
  lea ebx, [exec + 8]
  mov long [exec + 16], ebx
  lea ebx, [buffer]
  mov long [exec + 20], ebx
  mov long [exec + 24], eax
  mov byte al, 0x0b
  mov ebx, exec
  lea ecx, [exec + 12]
  lea edx, [exec + 24]
  int 0x80

Upvotes: 0

Views: 366

Answers (1)

Jester
Jester

Reputation: 58762

A few problems there:

  1. You only reserve 27 bytes at exec but you need 28 so you overwrite the start of buffer. What you are seeing in gdb is part your exec block followed by the buffer. Notice you have 3 D placeholders left, but you will write 4 more bytes. This is the main issue.
  2. You pass the message length into the read syscall. Not a terrible problem but limits input to 17 bytes while you have space for 128.
  3. The read system call returns the line feed, but doesn't null terminate the string. Depending on memory layout, you might get lucky with a following zero byte and the line feed is ignored by the shell. For safety you should replace the \n with a 0 yourself.

Upvotes: 1

Related Questions