27.19 Finding Words Inside Binary Files

If you try to read binaries (52.9) on your screen with, say, cat -v (25.7), you'll see a lot of non-printable characters. Buried in there somewhere though are words and strings of characters that might make some sense. For example, if the code is copyrighted, you can usually find that information in the binary. The pathnames of special files that the program reads will probably show up. If you're trying to figure out which program printed an error message, use strings on the binaries and look for the error. Some versions of strings do a better job of getting just the useful information; others may write a lot of junk, too. But what the heck - pipe the output to a pager (25.3, 25.4) or grep (27.2), redirect it to a file - ignore the stuff you don't want.

Here's a (shortened) example on SunOS:

% strings /bin/write
@(#)write.c 1.10 88/05/10 SMI
Usage: write user [ttyname]
write: Can't find your tty
Message from %s@%s on %s at %d:%02d ...
Write failed (%s logged out?)
         (((((                  
DDDDDDDDDD

The first line comes from SCCS (20.12)- you can see the version number, the date the code was last modified or released, and so on. The %s, %d, and %02d are special places that the printf(3) function will replace with values like the username, hostname, hour, and minute.

By default, strings doesn't search all of a binary file: it only reads the initialized and loaded sections. The - (dash) option tells strings to search all of the file. Another useful option is -n, where n is the minimum-length string to print. Setting a higher limit will cut the "noise," but you might also lose what you're looking for.

The od -sn command does a similar thing: finds all null-terminated strings that are at least n characters long.