Reverse engineering

IDA Pro Configuration Options

Configuration Files

We know that some of the Ida's settings are saved in the .idb archive database files, but are not actually persisted across global Ida settings. Configuration files are stored in the cfg/ directory and we're presenting the files below:

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

[plain]

# ls cfg/

6805.cfg 78k0s.cfg avr.cfg clsid.cfg dsp561xx.cfg f2mc16l.cfg hcs12.cfg i960.cfg kr1878.cfg mips.xml pdb.cfg ppc.cfg sparc.xml templates.xml tms320c55.cfg

6808.cfg ad218x.cfg bochsrc.cfg cr16.cfg dsp563xx.cfg f2mc16lx.cfg hcs12x.cfg i960.xml m32r.cfg mn102l00.cfg pe.cfg ppc.xml st10.cfg tlcs900.cfg xbe.cfg

6811.cfg alpha.cfg c166.cfg dbg_bochs.cfg dsp566xx.cfg fr.cfg hexrays.cfg ida.cfg m740.cfg n64.cfg pe.xml ppcdcr.cfg st20.cfg tms32054.xml z180.cfg

6812.cfg alpha.xml c166v1.cfg dbg_gdb.cfg dsp56k.cfg gdb_arch.cfg hppa.xml idagui.cfg m7700.cfg noret.cfg pic12.cfg psx.cfg st7.cfg tms32055.xml

6816.cfg arm.xml c166v2.cfg dbg_wince.cfg exceptions.cfg h8.cfg hpux.cfg idatui.cfg m7900.cfg oakdsp.cfg pic14.cfg python.cfg st9.cfg tms320c3.cfg

78k0.cfg atrap.cfg c39.cfg dbg_windbg.cfg f2mc.xml h8500.xml i51.cfg kernel.xml mc68.xml pc.xml pic16.cfg sh3.cfg super10.cfg tms320c54.cfg

[/plain]

We can see that there are a lot of configuration files stored in the cfg/ directory. Most of the configuration files are named after their processor name like sparc, ppc; those configuration files are important only when analyzing the executable for that particular processor. But the most important configuration files are those that govern the use of Ida and they are the following:

• ida.cfg
• idagui.cfg
• idatui.cfg

We don't really have to explain what each of the configuration files store, since their names speak for themselves. Obviously ida.cfg stores most common configuration options, while idagui.cfg applies to the graphical user interface and idatui.cfg applies to the command line version of Ida.

The Ida Configuration Files

The ida.cfg contains quite a log of configuration options. Below we're counting the number of lines of the ida.cfg configuration file, which is basically just a text file:

[plain]

# cat cfg/ida.cfg | wc -l

1288

[/plain]

The ida.cfg file is read when Ida is starting and it applies various configuration options. It assigns default processor types to file extensions. This is also the file that holds default configuration options accessible via Options – General, as can be seen on the picture below:

Let's take a look at the picture below that presents the options from the ida.cfg configuration file. We can see that the COMMENTS_INDENTION is specified as 40 characters, but the Options above says only 24 characters. Also, the instruction indention is 0 on the picture above, but 16 on the picture below. Why is that? Honestly, I have no idea. If any of you reading this know, please provide the answer and I'll update the article accordingly.

The idagui.cfg configuration file contains configuration options for Ida's keyboard shortcuts and some other configuration options that we won't discuss here. Let's take a look at an example of the defined shortcuts in the idagui.cfg configuration file; we can see that on the picture below:

There are a couple of shortcuts defined, but let's take a look at only the shortcut that opens the structures window. The shortcut is Shift-F9, and corresponds to the OpenStructures action. If we actually press Shift-F9 when in Ida, the structures window immediately pops-up, as we can see in the picture below:

Editing the shortcut options in the idagui.cfg can be useful for various reasons; if we're used to shortcuts from other disassembly tools, we might change the shortcuts in Ida to not confuse them among various tools. But usually, we don't want to do that, it's better to learn different shortcuts for different tools and use the default. So why are we mentioning this at all? It's because we can also define our own shortcuts that don't already exist – and it is there where the real advantage lies. If we find ourselves using some function quite often and it doesn't already have a shortcut defined, why not define our own shortcut and save ourselves a little time? The entries on the picture above that have zero as a shortcut means that the corresponding entry doesn't have a shortcut defined.

Using FLIRT (Fast Library Identification and Recognition Technology) Signatures

When analyzing the executable, how often do we stumble upon some compiled-in library that was intentionally put there or was a result of a static compilation of the binary? It's not that rare, which is why it's important to recognize such code so we don't try to analyze it ourselves, because it would be a waste of time. We can learn the same information by reverse engineering that statically compiled-in code or we can read the documentation, which is probably available somewhere on the Internet, possibly the MSDN Library for Windows or man pages for Linux, etc... Yhy would we want to do this? The reason is that the statically compiled-in code is part of the library and doesn't need to be reverse engineered, since it's not part of the program code that we're after; as a reverse engineers we're interested in the program code and not in the library code that's compiled-in. It could be fun reverse engineering the library itself, but it's a waste of time and not needed since the documentation already exists.

When we start analyzing an executable with Ida, Ida must check whether it recognizes some of the signatures in the binary to be part of the common libraries. Ida uses the signature files contained in the sig/ directory to match those signatures. Each signature file comprises of custom Ida signature headers that must contain the signature itself plus the metadata about the signature; how else is Ida supposed to know where the signature was taken from? Let's take a look at an example, the gcc32rtf.sig signature file with the xxd tool. On the picture below, we've presented the first part of the signature file where it's clear that the signature is created by the "GCC (mingw/cygwin) v3.4 runtimex".

Let's stat analyzing Putty.exe, which is a SSH and telnet client used very often in Windows environments. After Ida is done analyzing the binary, we can view the signatures it finds in the binary by clicking on the View – Open Subviews – Signatures. On the picture below, we can see the recognized signatures in the Putty SSH client program:

We can see that the signature is probably part of the Microsoft VisualC 2-10/net runtime library. If we would like to see a list of all available signatures Ida tries to match the analyzed binary against ,we can click on the File – Load File – FLIRT Signature File. The picture presenting all the FLIRT signatures is shown below:

We can see that there are 143 signatures currently loaded into Ida. On the picture below, we can see that the vc32rtf is also part of the FLIRT signature list as it should be.

When the binary is loaded into Ida to be analyzed, Ida first tries to identify the compiler used to compile the program in question. This is done with the use of specific signature files. If Ida can uniquely identify the compiler used to compile the binary, it will apply the signature files specific for that compiler to the binary. Ida mostly uses the signatures for proprietary compilers because there is a finite number of them being used. But why does it not use the open source gcc compiler signatures? The reason is that there are just too many variations available. This is because every distribution of Linux operating system uses its own version of standard libraries. Let's take Gentoo distribution of Linux system for example; with Gentoo we have to compile everything by ourselves, even the standard libraries and all of the compiler programs depend upon the compiler flags that we're using and can be modified with ease. But some of the compiler flags can cause the compiler to produce different binary executables upon compilation. Let's take a look at the dynamically compiled libraries in the /bin/bash executable program:

[plain]

# ldd /bin/bash

linux-vdso.so.1 (0x00007fffee3ff000)

libreadline.so.6 => /lib64/libreadline.so.6 (0x00007fd79c949000)

libncurses.so.5 => /lib64/libncurses.so.5 (0x00007fd79c6f4000)

libdl.so.2 => /lib64/libdl.so.2 (0x00007fd79c4f0000)

libc.so.6 => /lib64/libc.so.6 (0x00007fd79c145000)

/lib64/ld-linux-x86-64.so.2 (0x00007fd79cb91000)

[/plain]

We can see that there are six libraries that /bin/bash program needs to work successfully and each of them can be unique for our own system. The problem is even bigger with distributions like LFS (Linux From Scratch) where you have even more control over the compilation process. However, the problem is just as big with binary versions of Linux operating systems like Ubuntu, Mint, etc… because we would still need to collect every statically build shared library from every new version of each Linux distribution. But the compiler options are not the only thing that can result in different libraries; other reasons are also because the library source code was recently updated and contains new code, some patched code and some code can even be deleted. Another reason for different shared libraries is the use of different versions of compilers used for compilation. We've seen that Ida can't contain all possible signatures, because there are just too many of them, which is why it contains only a few open-source shared library signatures, and most of the proprietary shared library signatures.

If for any reason we would like to apply our own FLIRT signature file to the loaded binary, we need to create the FLIRT signature file, place it in the sig/ directory and load it in the pop-up dialog that we can get by selecting the File – Load File – FLIRT Signature File, which we previously used to list all the available signature files. On the presented list of signature files, we must select our custom FLIRT signature file and double-click it to apply it to the executable (well actually, we're applying it to the database, since the Ida converts the binary executable into its own representation and uses that for further actions, so once that is done the executable is not needed anymore). What actually happens when applying a custom signature file to the Ida database is that every signature in the signature file is compared to every function in the database and if the signature matches, we know that we have found a library function and we must mark is accordingly.

Conclusion

We've seen how easy it is to change various configuration options in Ida configuration files. If you want to make changes to those files, you should use the idauser.cfg configuration file. If it doesn't exist, create it. The configuration options specified in idauser.cfg override the same configuration options from ida.cfg and you don't have to edit a large text file and then keep it in since you just have one file you can redistribute to all installation of Ida and be gone with it.

With FLAIR tools, we can create our own FLAIR signature file and add the library signatures to Ida, which can be particularly useful on Linux operating systems (others as well). By doing that, we can mark most of the code as library functions, so we don't have to reverse engineer quite so much code, which proves faster and more efficient; nobody really want to be reverse engineering library functions if the documentation is available in the main pages, right?

References

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

[1] Chris Eagle, The IDA Pro Book: The unofficial guide to the world's most popular disassembler.