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 -s
n
command does a similar thing: finds all null-terminated strings that are at least
n
characters long.
-