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:

# 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

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.

Ethical Hacking Training – Resources (InfoSec)

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:

# cat cfg/ida.cfg | wc -l

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:

# ldd /bin/bash (0x00007fffee3ff000) => /lib64/ (0x00007fd79c949000) => /lib64/ (0x00007fd79c6f4000) => /lib64/ (0x00007fd79c4f0000) => /lib64/ (0x00007fd79c145000)
        /lib64/ (0x00007fd79cb91000)

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.


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?


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