IDA FLIRT Signatures for Linux Binaries

When you're reverse engineering a new piece of malware in IDA (the Disassembler and Debugger developed by Hex Rays), you hope that IDA can identify the library functions in the sample, and you can focus on functionality unique to the malware itself. 

Often that's not the case and IDA presents a list of functions named by default with “sub_” followed by the function’s address (Figure 1 – left). It’s much more helpful when IDA has the correct library function signatures and provides a list containing more descriptive names. (Figure 1 – right).

A good set of signatures can save you hours or days of work especially when the functions get as complicated as the graph overview in Figure 2. This details the highlighted function in the column on the right in Figure 1, “RsaPublicEncryptEx_constprop_4”.

With so many operating system distributions, it's difficult for the creators of IDA to provide function signatures that cover all possible combinations of open source code libraries, compilers, and linkers.  When signatures you need are not included with IDA, you can create your own using IDA's FLAIR (Fast Library Acquisition for Identification and Recognition) toolset.  Each step in the signature creation process seems straightforward but has its challenges:

1. Determine the operating system (OS) and compiler used to create the sample
2. Determine libraries used in the sample
3. Obtain static libraries compiled with the same OS and compiler as the sample
4. Use IDA to create signatures for the libraries and apply signatures to the database

Using a remote access trojan (RAT) known as Dacls, identified in Figure 3, the rest of this document will walk through each signature creation step and describe some ways to overcome the challenges involved.

Step 1: Determine the OS and compiler used to create the sample

The "file" command in Figure 4 displays basic build information from the sample that provides clues about which OS and compiler may have been used to create the sample.

The file command shows that the dacls_sample is a 64-bit ELF (executable and link format), statically linked and stripped for GNU/Linux 3.2.0. The version number 3.2.0 corresponds to the ABI (Application Binary Interface) version used to compile the sample.

The ABI version is embedded in the ELF header and is also accessible using the "readelf" command (Figure 5) with the "--notes" switch.

If the sample is compiled with GCC, a helpful comment is added to the ELF “notes” section containing the GCC compiler version as well as the Linux distribution and version information associated with that version of GCC. The DACLS sample fortunately contains this information (Figure 6).

Step 2: Determine libraries used in the sample

Looking through the strings in the sample, there are several that correspond to the .c filenames found in the GLIBC library. Beyond the source code file names, a couple strings stick out in the disassembly and IDA’s “strings” subview tab indicating possible use of wolfSSL or wolfcrypt.

• SSLeay wolfSSL compatibility
• wolfcrypt cleanup failed

An online search leads to wolfSSL's website and the description of their open source library:

"The wolfSSL embedded SSL library is a lightweight, portable, C-language-based SSL/TLS library targeted at IoT, embedded, and RTOS environments primarily because of its size, speed, and feature set."

Figure 7 shows the strings located near the “SSLeay wolfSSL compatibility” string in the binary. The proximity of these strings indicates they're potentially related. The string at the bottom, “3.15.7” is a valid version number for a previous release of wolfSSL available in the time frame of December 26, 2018. It seems reasonable that a wolfSSL version from December 2018 was used in this malware sample submitted to Virus Total in October 2019. This date also narrows the timeframe during which this malware was written.

Step 3: Obtain identified libraries to signature

Based on the investigation of the sample, it appears signatures need to be created for the GLIBC library from an Ubuntu 18.04 64-bit system and the wolfSSL library version 3.15.7.

GLIBC Library from Ubuntu 18.04

One way to obtain the Ubuntu 18.04 GLIBC library is to create a virtual machine and grab the library from the default installation location: /usr/lib/x86_64-linux-gnu/

A listing (Figure 8) of the /usr/lib/x86_64-linux-gnu/ directory shows all the static library files present.

A zip file of these static library files can be created and copied to the system where the IDA signature tools are located.

wolfSSL Library

A zip file containing the source code for wolfSSL version 3.15.7 can be downloaded from wolfSSL’s releases repository.

Using the same Ubuntu 18.04 virtual machine that contained the GLIBC library described above, the wolfSSL static library can be obtained from the downloaded zip file with the following steps:

Install gcc, automake, autoconf, and libtool

• Unzip the WolfSSL file containing the version 3.15.7 source code
• In the top level source code directory run the following commands:

./autogen.sh

./configure --enable-static

make

The static library is not generated by default so use of the "--enable-static" switch during configuration is necessary. After running the make command, the wolfSSL static library can be found within the unzipped wolfSSL directory at: ./src/.libs/libwolfssl.a

Step 4: Use IDA to create and apply signatures

For IDA Pro Version 7.2, the signature tools will be in a folder called flair72.zip.  The tools needed to make signatures for Linux binaries are pelf, pelf.rtb, and sigmake. These three tools can be found in the extracted flair72 directory at: .\bin\linux

To create signatures for the GLIBC static libraries follow these steps in a directory containing the FLAIR tools and the .a files obtained from the Ubuntu 18.04 virtual machine:

A. Create the pattern file

./pelf *.a glibc_ubuntu_18.04.pat

If an error similar to "Unknown relocation type 26 (offset in section=0x2f)" occurs, rerun the pelf command using the "-r" switch as follows:

./pelf -r26:0:0 libc.a libc_ubuntu_18.04.pat

B. Create the signature file

./sigmake -n"Ubuntu 18.04 glibc" glibc_ubuntu_18.04.pat glibc_ubuntu_18.04.sig

If IDA runs into functions that are too similar, the following message may appear:

glibc_ubuntu_18.04.sig: modules/leaves: 1346/1598, COLLISIONS: 13

See the documentation to learn how to resolve collisions.

The documentation explains more about the options for resolving collisions. To move quickly past the collisions (basically ignoring them and letting IDA do what IDA does), open the glibc_ubuntu_18.04.exc file and delete the lines at the top beginning with a semicolon. Then rerun the sigmake command. When the sigmake command runs successfully there will be no output messages and a .sig file will be created in the working directory.

C. Add the signature file to IDA

Move the glibc_ubuntu_18.04.sig file into IDA's signature directory: <IDA Install Location>/sig

D. Apply the signature to the Linux binary

In IDA's menu bar, click File -> Load file -> FLIRT signature file...

In the "List of available library modules" window, scroll down to the newly added signature, click on it, and click OK. The library signatures will be applied. To view how many functions were identified, click View -> Open Subviews -> Signatures.  The Signatures subview window will list the signature set applied to the binary and how many functions were identified using each signature.

The method described above can also be applied to the libwolfssl.a file to create signatures for wolfSSL. Applying these signatures takes us back to Figure 1. You move from the generic function names in the left column to the descriptive function names in the right column, significantly speeding up the analysis of the malware sample in IDA.

Variations in libc.a signature accuracy by Linux distribution
If the dacls_sample had not been compiled with GCC and was missing the helpful .comment string, "Ubuntu 7.3.0-27ubuntu1~18.04", the only information available to identify the Linux distribution would have been the output of the file command:

The file command output reveals that the GNU/Linux version is 3.2.0 and that it is a 64-bit OS.

One way to proceed without having identified the specific OS would be to create signatures for libc.a for some of the most common Linux distributions and see which signatures successfully identified the most functions. Each operating system has slightly different installation procedures and locations where the static version of the GLIBC library can be found. Appendix A describes steps to obtain the libc.a library from Fedora, CentOS, and Ubuntu.

The table in Figure 3 contains a list of various Linux distributions with their corresponding release dates, GLIBC, ABI, and GCC versions. The release dates are from Wikipedia or the Linux distribution's main website. The GLIBC, ABI, and GCC versions were obtained through the use of the code in Appendix B on each Linux distribution and version.

The code in Appendix B was compiled (gcc -o glibc_version glibc_version.c) using the default version of GCC present on each system. Executing the glibc_version program outputs the GLIBC version to the terminal, the "readelf --notes glibc_version" command output contains the ABI version and the "readelf -p .comment glibc_version" command output contains the GCC version.

For each of the Linux distributions in Figure 9, signatures were generated for the libc.a library and applied to the Dacls RAT sample described in Figure 1. While some of the Fedora distributions from late 2017 and early 2018 identified a couple hundred functions, the Ubuntu 18.04 signatures were far more accurate with close to 1000 functions identified. 

For more tech solutions, read the latest from our cyber technical experts. 

This article is for informational purposes only, its content may be based on employees’ independent research, and does not represent the position or opinion of Booz Allen. Furthermore, Booz Allen disclaims all warranties in the article's content, does not recommend/endorse any third-party products referenced therein, and any reliance and use of the article is at the reader’s sole discretion and risk.