One of the issues when analyzing malicious Linux executables occurs when the executable has been statically linked and the debugging symbols stripped. Since the debugging symbols are stripped, IDA Pro is unable to identify the names of the library functions and we are left to determine the names on our own, or load and/or create the appropriate IDA signatures to identify the functions. To do this, we need to know which libraries were used during compilation, and possibly the OS (Linux distribution name and version) it was compiled on as well.

The embedded strings of a file can often give you clues to this information. Once you determine the library that was used, the IDA Pro FLAIR tools can be used to create signatures of the library for use in IDA. The process to create signatures using FLAIR is pretty simple:

1. Create a pattern file (PAT) using the FLAIR pattern creation tools (pcf, pelf, etc).
2. Run sigmake to create the SIG file.
3. Copy the resulting SIG file to your IDA Pro sig/ directory.

The signature can then be loaded in IDA Pro, and IDA should recognize the functions from the library.

However, this process hinges on knowing the exact library and version that was used. If strings analysis doesn't give you that information, it would need to be found through another method.

In my research, I found a program named rsymtab that can be used to find library functions in a statically linked executable. Unfortunately, I found that rsymtab wasn't 100% reliable and would miss some functions that I knew were present. No tool is perfect, but I wanted to see if I could find a better way. This led me back to IDA Pro and FLAIR.

The FLAIR pattern generation tools create a PAT file which contains a signature for each function within a library. We can use this pattern to detect functions in files and to determine which libraries an executable was statically compiled against. To do this, I decided to use Yara, a tool specifically designed to detect text or binary patterns in files.

To facilitate a conversion from the PAT file to Yara signatures, I wrote the pat2yara.py [sign] Python script. The script reads in a PAT file generated by the FLAIR tools, extracts each pattern, and turns them into Yara signatures. To make function identification easier, it also has the ability to add the OS and library name to the Yara rule.

$ python pat2yara.py -h

usage: pat2yara.py [-h] [-o OS] [-s] [-l LIBNAME] [-p] PAT_file

Convert Flair PAT file to Yara sigs.

positional arguments:
  PAT_file              PAT file to convert to Yara sigs.

optional arguments:
  -h, --help            show this help message and exit
  -o OS, --os OS        OS the library came from.
  -s, --prepend-os      Prepend OS to Yara rule name.
  -l LIBNAME, --libname LIBNAME
                        Library the PAT file is from.
  -p, --prepend-lib     Prepend LIBNAME to Yara rule name.

NOTE: In order to use this, you must have a licensed copy of IDA Pro with the FLAIR tools. To my knowledge, the FLAIR tools can only be downloaded if you have a current support contract.

The script is run as follows to create Yara signatures for glibc-2.3.5 from a PAT file.

$ python pat2yara.py -o "Fedora Core 4" -l "glibc-2.3.5-10" -s -p libc.pat > libc.yar

$ head libc.yar

rule FedoraCore4_glibc23510__vhangup
{
    meta:
        os = "Fedora Core 4"
        library = "glibc-2.3.5-10"

    strings:
        $pattern = { 89 DA 8B 5C 24 04 B8 6F 00 00 00 CD 80 89 D3 3D 01 F0 FF FF 0F 83 ?? ?? ?? ?? C3 }

    condition:
        $pattern
}

Utilizing Yara allows us to quickly determine which libraries and versions were used in a statically compiled program. Some work still needs to be performed beforehand by downloading the libraries and creating the IDA and Yara signatures. However, the Yara signatures can be used in our static analysis of the executable (*cough* MASTIFF *cough*) to quickly determine what libraries and OS were used during the compilation process.

For example, I created two Yara signature files for the libc and libcrypt libraries that originated from the Fedora Core 4 glibc-2.3.5-10 RPM.

$ ls -l libc.yar libcrypt.yar 
-rw-r--r-- 1 tyler tyler   1429 Nov 11 13:42 libcrypt.yar
-rw-r--r-- 1 tyler tyler 291597 Nov 11 13:42 libc.yar

$ grep rule libcrypt.yar | wc -l
5

$ grep rule libc.yar | wc -l
1149

When the Yara signatures are run against a malicious executable, we can see that libc was used during compilation, but libcrypt was not.

$ yara libc.yar badexe  | wc -l
395

$ yara libcrypt.yar badexe  | wc -l
0

This is just an example - a number of Yara signatures could have been run against the executable to cover a wider set of libraries. We can see that using Yara, and the pat2yara.py [sign] script to generate the Yara rules, we can quickly determine which libraries are in use and better focus analysis.

If you have any questions or comments on the script, let me know!

Download: pat2yara.py [sign]
SHA256: fb3481c30affe2849fc3c26876f962223de41f0d065de7833443cf2042e87cfa