We start the recipe with a command to display the help menu for nm in step 1 and the man page for nm in step 2. Most of the tools have a sufficient help menu; however, because of the nature of the output, I believe the man page is more useful as it explains the meaning behind some of the information that's displayed in the output. For example, the letter A next to a symbol means the symbol is absolute and additional linking won't change the symbol, whereas the letters B or b denote symbols in the BSS section. We already know from Chapter 2, 32-Bit Assembly on Linux and the ELF Specification, that the BSS section contains uninitialized data. If you plan to use nm, it's a good idea to study the man page for nm, and specifically, the various symbol types denoted by uppercase and lowercase letters. There's no sense in repeating what the man page already lays out for us.

In step 3, we run the nm tool using the default output against four different files. First, we run nm against our compiled binary, then against our stripped binary, next against our binary compiled with debugging information, and finally,  against an unlinked assembled object file. Did you notice that the output when running nm against the stripped binary is lacking? Well, it should be because I've stripped the binary of its symbol table. All is not lost, however, as in step 4, we could issue the -D argument to nm against our stripped binary, which would reveal the dynamic symbols instead of the normal symbols from the symbol table. As you may recall readelf will output all symbols in a binary when we issue the -s argument. If we choose to use nm to discover our binary has been stripped of its symbol table, we'll have to run the tool twice, using different arguments each time. However, if we use readelf, the -s argument handles that for us. This is something to keep in mind if efficiency is more important than flexibility in output formatting.

We issue the -f argument along with two non-default options in step 5, which tells nm to display the output using the posix format in the first command, and the sysv format in the second. Personally, I find the sysv format more useful, but that's because I like a ton of information in my face and don't mind manually sorting through it. If you prefer the default bsd output format, that's completely up to you, but I encourage you to figure out your output format preference for your own workflow and go with it. Moving on to step 6, we see some of the more beneficial functionality of nm by issuing the command with the -A argument against two binaries—our standard binary and one compiled with debugging symbols present. This -A argument essentially places the filename next to each symbol so that if we ever have to examine several files at once, we can discern the symbols of each file easily.

In step 7, we issue the -S argument to nm, which displays the size of the symbol in hexadecimal in the event we need to know that information. We also issue the -A argument to put the filename next to each symbol in the output. The nm tool, as I mentioned previously, offers various arguments that allow us to format the output according to our needs. Step 8 demonstrates this nicely with the -n argument, which tells nm to sort the output numerically by the symbols' address, instead of alphabetically by the symbol name. If we're concerned with the location of the symbol in the binary, the -n argument is extremely useful to us.

Finally, in step 9, we issue the -l and -a arguments to nm against a binary compiled with debugging symbols present. These arguments tell nm to list any line numbers (-l) for any symbols using debugging information if it's present in the binary, and display debugger-only symbols (-a). In the event we're bug hunting in binaries that have been developed in-house within our own organizations as opposed to identifying potentially malicious binaries, it's sometimes useful to examine a binary compiled with debugging information present. This debugging information will provide additional useful knowledge about the binary and how it operates. Conversely, once our analysis is complete, we need to make sure the developers remove that debugging information before releasing the binary to production.