The command in step 1 falls under the information-gathering phase of the methodology. Let's assume that we perform each step of our methodology and during our initial analysis, when running readelf with the -d argument, we notice a non-standard shared library called libhider.so is required for the binary to execute. In the event we discover such a library, it's a good idea to apply as much iteration as possible to analyze that library to determine its purpose in the original binary. So, pausing on our analysis, we focus our attention on the libhider.so shared library. Obviously, the library is in our Chapter-04 project folder, but, for the sake of working through the remainder of this recipe, let's imagine it's in some other directory, such as /tmp. In step 2, we run the updatedb and locate commands as sudo to update the mlocate database and search that database for libhider.so, respectively. Next, we change directories via the Terminal session to the location of the libhider.so library, gather some initial information on the library using the file, strings, and readelf commands, and then disassemble the executable portions of the library using objdump, making sure to format the output in Intel format.

Since this is a shared library, our iteration of the methodology should be sufficient to get an understanding of how the library works, the functions in the library, and so on. When we review the output of the disassembly using objdump, we can clearly see the hideMe and unhideMe function names. Admittedly, this is a very drastic example of implementing iteration. If only all binary analysis were this easy, right?