having fun with strace
i don’t have any strength to do assembly today (and for the rest of the week) because i’m so happy that stephanie talked to me! my mind is somehow still stuck at that particular time frame and i’ve only been thinking about her ever since this afternoon. i don’t know if that will change anytime soon. she’s such a goddess!
today, i’ll just be doing some strace-ing. still a fun activity imho. i’m curious as to how exactly things work in the background. for my first strace activity, i’ll use my most recent work. i hope to gain more understanding about system calls in linux and of of course, how to use basic strace to diagnose programs.
first, i tried running the program with no arguments:
amerei@heaven ~/workdir $ strace ./steph_swdir
execve("./steph_swdir", ["./steph_swdir"], [/* 54 vars */]) = 0
readlink("/proc/self/cwd", "/home/amerei/git/null/public/asm", 131072) = 32
symlink("/home/amerei/git/null/public/asm", "/home/amerei/workdir") =
-1 EEXIST (File exists)
unlink("/home/amerei/workdir") = 0
symlink("/home/amerei/git/null/public/asm", "/home/amerei/workdir") = 0
_exit(0)
interesting! what do we have here?
> execve(”./steph_swdir”, [”./steph_swdir”], [/* 54 vars */]) = 0
line 1 tells us that strace ran our command with one argument. but we didn’t declare any arguments to our program? what’s up with [”./steph_swdir”] being included as an argument? we now realize that even if there are no arguments, argv[0] (or the program name) still get’s passed behind our backs. whenever we run a program in linux, the stack’s first entry would be 1+number of actual arguments, followed by our program name.
> readlink(”/proc/self/cwd”, “/home/amerei/git/null/public/asm”, 131072) = 32
our program called sys_readlink with three arguments. this tells us that /proc/self/cwd has the value /home/amerei/git/null/public/asm, and that it is 32 bytes long! why? let’s read sys_readlink’s man page shall we?
RETURN VALUE
The call returns the count of characters placed in the buffer if it
succeeds, or a -1 if an error occurs, placing the error code in errno.
> symlink(”/home/amerei/git/null/public/asm”, “/home/amerei/workdir”) = -1 EEXIST (File exists)
our program tried making a symlink using the buffer taken from sys_readlink above, which happens to be our pwd. unfortunately, the symlink already exists! so the system call returned -1 and set errno to EEXIST what does man 2 symlink have to say?
If newpath exists it will not be overwritten.
> unlink(”/home/amerei/workdir”) = 0
it seems that sys_symlink is picky on some conditions. i will refuse to create a symlink if a symlink with the same name already exists! now, the program tries to delete the bugger to satisfy sys_symlink’s condition that a newpath must not exist. the deletion was successful because it returned zero.
> symlink(”/home/amerei/git/null/public/asm”, “/home/amerei/workdir”) = 0
sys_symlink is called again and this time, it’s successful! sys_unlink was a good call!
> _exit(0) = ?
exit gracefully. but what’s with the question mark? again, we refer to the manual. (man 2 exit)
RETURN VALUE
These functions do not return.
now we have it. our assemblified bash script ran under scrutinity. and we were able to actually trace our program as it made a series of calls during it’s wake. hopefully, i ‘d be able to trace more elaborate binaries next time, like /bin/cat or, hmm… some simple c programs.
i sooooo love you steph!
