0

The following example of NASM assembly is meant to be called with a command-line argument representing a target filename to write in:

$ ./myprogram myfile.txt

On Linux systems, at the beginning of the program, the stack is filled with A. the count of arguments including the program name (here, 2) and B. the memory address at which each argument starts.

section .text
    global _start

_start:
    pop ebx             ; argc (argument count) (not used)
    pop ebx             ; memory offset for the program name (not used)
    pop ebx             ; memory offset for the filename

    mov eax, 8          ; syscall to create a file (filename is read from ebx)
    mov ecx, 00644Q     ; read/write permissions in octal (rw_rw_rw_)
    int 80h             ; Call the kernel

Given that filename.txt is created dynamically from the input of the user, how does the file creator know the size of the filename? Assuming the offset of the first character is 500 (meaning ebx = 500), then the memory would look as follows (representing the Chars instead of their hex values):

498   499   500   501   502   503   504   505   506   507   508   509   510   511
 ?     ?     m     y     f     i     l     e     .     t     x     t     ?     ?

I don't see anywhere in the code that indicates that the file name stops at 509. If the value in ebx is 500, then how does the file creator know that it has to stop reading the filename at 509?

Could it be that when command-line arguments are automatically pushed into the stack, each of them is terminated by a null character that the file creator is expecting?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Jivan
  • 21,522
  • 15
  • 80
  • 131
  • 3
    Paths as args to Unix system calls are 0-terminated C strings, implicit-length. Same as the elements of the argv array. – Peter Cordes Apr 01 '21 at 22:58
  • 1
    Yes, command line arguments (like all strings you deal with in the UNIX programming interface) are NUL terminated. – fuz Apr 02 '21 at 08:20

0 Answers0