Re: Tools to analyze "captured" binaries?

[rob () KARRDE COM (Rob Lee)]

You have some good questions on Tool Analysis.  I hope to provide you with
an overview of where to go and what to use to do the analysis that you would
like.

If you have a test network I would move the binaries to that network.

The FIRST SECTIONS COVERS the commands FILE, GREP, AND STRINGS for GENERAL
FILE ANALYSIS.

The first one is the command "file".
        When one first compiles a computer program you will find that either the
binary is dynamically linked, statically linked, with debug output, or
stripped.
        + Dynamically Linked
                -- Requires the availability of libraries loaded by the operating system.
        + Statically Linked
                -- All functions are included in the binary.  But with a price that the
results in much larger executable file.  This is typically seen in
commercial apps like Netscape, Staroffice, etc.
        + Debug Output
                --  Includes Debugging Symbols (e.g. variable names, functions, internal
symbols, source line numbers, source file information)
        + Stripped
                --  Discards symbols from object files and makes executable much smaller

It is interesting to note that most "script kiddies" will compile programs
straight from the "makefile" without adjusting the properties inside that
file.  For instance, the default for tfn (TRIBE FLOOD NETWORK) and some
other programs compiles the program with debugging symbols.  If a hacker is
smart and he is good he will statically link his executable and then strip
it.  This would make the binary VERY hard to take apart.  But luckily for us
security types and forensic experts, most hackers do not go to this detail.
But THE GOOD ONES WILL!!!

The second one is the command "strings -a"  which will display printable
characters sequences that are at least 4 characters long and the -a command
shows all strings in the binary file.
        + You can tell a BUNCH from just this alone.  Compare it against strings of
other binaries so you get used to knowing what to look for.

The third one is "grep".  Hopefully I dont need to go into too much detail
here.

THE SECOND SECIONT COVERS the NON-RUNNING PROGRAM FILE ANALYSIS

The unix debuggers "gdb, ltrace, strace, xxgdb, memprof"
        "gdb, xxgdb, memprof"
        +  Allows the actions taken in a program to be monitored
        +  displays function and variable names

         "strace"
        + System Call Tracer
        + Wiretap on the interactions between a program and the operating system
        + displays information on file access, network access, memory access, and
tons of other calls
        + Drawback is that the program is actually run (USE A STANDALONE MACHINE!)

         "ltrace"
        + log every library routine call

         "nm"
        + display compiler and runtime linker symbol table

         "ldd"
        + identify dynamic libraries used

THE THIRD SECTION DEALS WITH RUNNING PROGRAMS

Finally once you have gotten this far execute the program on a stand-alone
machine OR if you have a program in MEMORY that no longer resides on the box
itself you need to do the following.  DO NOT CONNECT TO THE PORT THE PROGRAM
IS RUNNING ON (BAD THINGS COULD HAPPEN!).

If you are on a live box.  SUSPEND the process until you have figured out
what it is.  KILL -STOP <pid>

        the /proc directory  -- pseudo-filesystem which is used as an interface to
kernel data structures
                + contains links to executable code (EVEN IF DELETED---> CAN RETIREVE
BINARY OF A DELETED PROCESS )
                + File Descriptors (EVEN IF UNLINKED--> CAN RETIRVE CONTENTS OF AN
UNLINKED FILE)
                + there is a Numerical Subdirectory for each Running Process

                + To Attain a Process
                        1.  Identify the Process ID of the Target Process Using
                                ++ ps -auxeww for command, environment, and more
                                ++ reviewing contents of /proc
                                ++ using network monitor logs
                                ++ using the program lsof
                        2.  Change directories to the /proc/<pid>
                        3.  Copy the exe Link to your chosen destination
                        4.  Once you have the binary.  Do the initial file analysis, the
debugging, etc...

For Solaris:
        object/a.out (program file)
        ms      (process memory)
        map     (memory map)

For Linux
        exe (program file)
        mem     (process memory)
        maps    (memory map)

For FreeBSD
        file (program file)
        mem     (process memory)
        map     (memory map)

The program "top"

        ++  useful process information

THE program "lsof"

++ This program will list all the open files and sockets on a system.  You
will be able to tell if something is listening for connections.
        ++ You can see the inode of the files and configuration files that were
used.  This is useful if you want to look at the inodes that had deleted
files in their place.  You should be able to pull out the data.
        ++ You can see the libraries that are used with the program.  Really easy
to see sniffers here. (PCAP?)

                ++ run lsof -p <pid>

The program "gcore" (note gcore is not available on LINUX but other
alternatives exist)

++ This program will produce a core file dump from the running process.
VERY useful if you would run strings on it.

Binary analysis is long, time consuming, and sometimes a non-result process.
If you need help on a file.  I would be happy to look at some files for you
in my free time.  You only get good at this with practice.  I would have a
floppy disk or cdrom with good binaries on it to do some of this analysis.
There might be trojans of ps, lsof, top,

If you have any question please contact me at rob () karrde com.

Rob Lee
____________________________________________________
Rob T. Lee, 1LT, USAF

Email:           rob () karrde com
____________________________________________________

-----Original Message-----
From: Incidents Mailing List [mailto:INCIDENTS () SECURITYFOCUS COM]On
Behalf Of Anton Chuvakin
Sent: Wednesday, April 19, 2000 4:19 PM
To: INCIDENTS () SECURITYFOCUS COM
Subject: Tools to analyze "captured" binaries?
Importance: High

Hi there!

I just got a bunch of trojaned binaries (usual rootkit, I guess,
fingerd/ftp/login together with a sniffer) from my friend's box (hacked
via ADMROCKS, of course). What tools (apart from strings, ldd, file) I can
use to analyze those?

Thanks,

--
         Anton A. Chuvakin
> > Where is a will there is a way. <<
     http://www.chuvakin.org
          licq: 29034084