Tracing library calls

The ltrace utility performs a similar function to strace, except that it is used to trace library calls instead of system calls. The results of running ltrace against xingyi_bindshell are shown in Figure 10.23. We can see that the C library is being loaded, 257 bytes of memory are allocated and then filled with zeros, popen is called to get the Python version, the version returned is 2.7.6, strstr is called and returns zero, fork is used to create a new process, and the program exits.

FIGURE 10.23

Running ltrace against xingyi_bindshell.

The results of running ltrace against xingyi_rootshell with the correct password supplied are shown in Figure 10.24. We can see that the C library is loaded, 18 bytes of memory are allocated and then set to zero, up to 16 characters of a string are stored in a string buffer (probably the password passed in, but we need to trace the program with gdb to verify this), a string is compared to “sw0rdm4n” and found to be identical, a file descriptor is duplicated, and a bash shell is created using the C system function.

FIGURE 10.24

Running ltraces against xingyi_rootshell with the correct password supplied.

The results of running ltrace against xingyi_reverse_shell 127.0.0.1 are shown in Figure 10.25. We can see the C library is loaded, the string length of “127.0.0.1” is checked repeatedly, fork is called creating process 3116, and two warnings are printed before the program exits when Control-C is pressed. A new process listening on port 7777 has been created.

FIGURE 10.25

At this point we have enough information about these binaries to say that they are malicious. We know that they create listening sockets, shells, and have other common malware traits. If we want to learn more, it is time to use a debugger.