De Wiki expérimental

It's about time we got down to actually using IDA. The remainder of this book is ledicated to varions features of IDA and how you can leverage them to best suit your reverse engineering needs. In this chapter we hegin by covering the options you are presented with when you launch IDA, and then we describe just what is happening when you open a binary file for analysis. Finaily, well present a quick overview of the user interface to lay the groundwork for the remaining chapters.

For the sake of standardization, examples in both this chapter and the remainder of the book will be presented with the Windows Qt GUI interface unless an example requires a specific, different version of IDA (such as an example of Linux debugging).

Launching IDA

Any time you launch IDA, you will be greeted briefly by a splash screen that displays a summary of your license information. Once the splash screen clears, IDA displays another dialog offering three ways to proceed toits desktop environment, as shown in Figure 4-1.

If you prefer not to sec the welcome message, feel free to uncheck the Dïsplay ai startup checkbox at the bottom of the dialog. If you check the box, future sessions will begin as if you had clicked the Go button, and you will be taken directly to an empty IDA workspace. If ai some point you find yourself ionging for the Welcome dialog (after ail, it convenientiy aliows you to return to recentiy used files), you will need to edit IDAs regïstry key to set the Displaywelcome value back to 1. Alternatively, selecting Windows > Reset hïdden messages will restore ail previously hidden messages. NOTE When installedon Windows, IDA creates the followingregistrykey: HKEY_CURRENT_USER\ Software\Hex-Rays\IDA.' Many options that canhe configured within IDA itself(as opposed to editing one o/'the configuration 111es) are stored within this registry key. Howevei; on otherplatforrns, IDA stores such values in a hinary data file ($HOME/ .idapro/idareg) that is not easily edited.

Each of the three options shown in Figure 4-1 offers a slïghtly different method to proceed to the IDA desktop. These three iaunch options are revïewed here:


Choosing New opens a standard File Open dialog to select the fie to be analyzed. Foilowing file selection, one or more additional dialogs are dispiayed that aliow you to choose specific file-analysis options before the file is loaded, anaiyzed, and displayed.


The Go button terminales the ioad process and causes IDA to open with an empty workspace. At this point, if you want to open a file, you may drag and drop a binary flic onto your IDA desktop, or you may use one of the options [rom the File menu to open a file. The File > Open command results in a File Open dialog, as described previousiy. By default, IDA utïiizes a known extensions filter to lirait the view of the File dialog. Make sure that you modify or clear the filter (such as choosing Ail Files) so that the File dialog correctiy displays the file you are interested in opening.2 When you open a file this way, IDA attempts to automaticaiiy identify the selected files type; however, you should pay carefui attention to the Loading dialog to see which loaders have been selected to process the file.


You shouid utilize the Previous button when you wish to open one of the files in the iïst of recent files that is directly beiow the Previous button. The hst of recently used files is populated with values [rom the History subkey of IDAs Windows registry key (or ida reg on non-Windows piatforms). The maximum length of the history lïst is initially set to 10, but this lirait may be raised as high as 100 by editing the appropriate entry in idagui.c/'gor idatuLcfg (sec Chapter 11). Utiiïzing the history list is the most convenient option for resuming work on recently used database files.

filA File Loading

When choosing to open a new file using the File > Open command, you wilil be presented with the loading dialog shown in Figure 4-2. IDA generates a iïst of potentiai file types and dïsplays that hst ait the top of the dialog. This hst represents the IDA loaders that are best suïted for dealing with the selected file. The iïst is created by executing each of the file loaders in IDAs loaders directory in order to find any loaders that recognize the new file. Note that in Figure 4-2, both the Windows PE loader (pe.ldw) and the MS-DOS EXE loader (dos.ldw) ciaim to recognize the selected file. Readers familiar with the PE file format wiii not be surprised by this, as the PE file format is an extended form of the MS-DOS EXE file format. The iast entry in the iist, Binary File, wilil aiways be present since it is IDAs default for loading files that if dors not recognize, and this provides the lowest-level method for loading any file. When offered the choïce of severai loaders, if is not a bad initial strategy to sïmply accept the default selection unless you possess specific information that contradïcts IDAs determination.

At times, Binary File will be the only entry that appears in the loader list. In such cases, the implied message is that none of the loaders recognize the chosen file. If you opt to continue the loading process, make sure that you select the processor type in accordance with your understanding of the file contents.

The Processor Type drop-down menu allows you to specify which processor module (from IDAs pmcdirectory) should be used during the disassembly process. In most cases, IDA will choose the proper processor based on information that it reads [rom the executable files headers. When IDA cant properly determine the processor type associated with the flic being opened, you will need to manually select a processor type before continuing with the file-loading operation.

The Loading Segment and Loading Offset fields are active only when the Binary File input format is chosen in conjonction with an x86 family processor. Sirice the binary loader is unable to extract any memory layout information, the segment and offset values entered here are combined to form the base address for the loaded file content. Should you forget to specify a base address during the initial loading process, the base address of the IDA image can be modïfied at any time using the Edit > Segments > Rebase Program command.

The Kernel Options buttons provide access to configure the specific disassembly analysis options that IDA will utilize to enhance the recursive-descent process. In the overwhelming majorïty of cases, the default options provide the best possible disassembly. The IDA help files provide additional information on available kernel options.

The Processor Options button provides access to configuration options that apply to the selected processor module. However, processor options are not necessarily available for every processor module. Limited help is available for processor options as these options are very highly dependent on the selected processor module and the programming proflciency of the modules author. The remaining Options checkboxes are used to gain flner control over the file-loading process. Each of the options is descrïbed further in IDAs help file. The options are not applicable to ail input file types, and in most cases, you can rely on the default selections. Specïflc cases when you may need to modify these options will be covered in Chapter 21.

Using the Binary File Loader

When you opt to utilize the binary loader, you need to be prepared to do more than your usual share of the processing work. With no file header information to guide the analysis process, it is up to you to step in and perform tasks that more capable loaders often do automatïcally. Examples of situations that may caIl for the use of the binary loader include the analysis of ROM images and exploit payloads that may have been extracted front network packet captures or log flics. When the x86 processor module is paired with the binary loader, the dia-log shown in Figure 4-3 will be displayed. Wïth no recognizable file headers available to assist IDA, it is up to the user to specify whether code should be treated as 16-bit or 32-bit mode code. Other processors for which IDA can distinguïsh between 16- and 32-bit modes include ARM and MIPS.

Binary files contain no information concerning their memory layout (ai least no information that IDA knows how to recognize). When an x86 processor type bas been selected, base address information must be specifled in the loader dïalogs Loading Segment and Loading Offset fields, as mentioned earlier. For ail other processor types, IDA displays the memory layout dialog shown in Figure 4-4. As a convenience, you may create a RAM section, a ROM section, or both and designate the address range of each. The Input File options are used to specïfy which portion of the input file (the default is the entire file) should be loaded and to which address the file content should be mapped.

IDA Database Files

When you are happy wïth your loading options and click OK to close the dialog, the real work of loading the file begins. At this point, IDAs goal is to ioad the selected executabie file into memory and to analyze the relevant portions. This results in the creation of an IDA database whose components are stored in four files, each with a base name matching the selected executable and whose extensions are .ida kil, nain, and .fil. The .idû flic contains the content of a B-tree-style database, while the id] flic contains flags that describe each program byte. The .narn file contains index information related to named program locations as displayed in IDAs Names window (discussed further in Chapter 5). Finafly, the .tilfile is used to store information concerning local type definitions specific to a given database. The formats of each of these files are proprïetary to IDA, and they are not easily edïted outside of the IDA environment.

For convenience, these four flues are archived, and optionally compressed, into a single 1DB file whenever you close your current project. When people refer to an IDA database, they are typicaily referring to the 1DB file. An uncompressed database file is usually 10 times the size of the original input binary file. When the database is closed properly, you should never see files with 1d0, kil, .nain, or tu extensions in your workïng directories. Their presence often indicates that a database was not closed properiy (for example, when IDA crashes) and that the database may be corrupt.


Once a loader begins ta analyze a file, it may encourent circumstances that recuire additional user input in arder ta complote the laading process. One exemple of this occurs with PE files that have been created with PDE3 debugging information. If IDA determines that a Program Database (PDB) file may exist, you will be asked whether you want IDA ta locale and to pracess the carresponding PDB file as shawn in this message:

IDA Pro has deterrnined that the input file was linked with debug inFormation. Do you want ta look for the corresponiding PDB File ai the local synibol store and the Microsoft Symbol Server? A second exemple of a loader-generated international message accurs with obfuscated programs such as malware. Obfuscation techniques often play fast and loose with file format specifications, which con cause prablems for laaders expecting well-structured files. Knowing this, the PE loader perfores sonne validation on import tables, and if the import tables do not seem to be farmatted according ta convention, IDA will display the following message:

The imports segment seems tu be destroyed. This MAY mean that the file was packed or otherwise niodified in coter ta niake il more difficult to analyze. IF you want ta sec te irnports segment in the original fora, Pieuse reload il with the niake imports section checkbox cleared. Exemples of this errar and how ta deal with il will be covered in Chuinter 21.

It is important to understand that once a database bas been created for a given executable, IDA no longer requires access to that executable uniess you intend to use IDAs ïntegrated debugger to debug the executable ïtseif. From a security standpoint, this is a nice feature. For instance, when you are anaiyzing a nialware sampie, you can pass the associated database among analysts without passing along the malicious executable itself. There are no known cases in which an IDA database bas been used as an attack vector for malicious software.

At its heart, IDA is nothing more than a database application. New databases are created and populated automatïcally from executable files. The varions displays that IDA offers are simply views into the database that reveal information in a format useful to the software reverse engineer. Any modifications that users make to the database are reflected in the views and saved with the database, but these changes have no effect on the original executable file. The power of IDA lies in the tools it contains to analyze and manipulate the data within the database.

IDA Database Creation

Once you have chosen a file to analyze and specïfied your options, IDA mitiates the creation of a database. For this process, IDA turcs control over to the selected loader module, whose job it is to load the file from disk, parse any file-header information that it may recognize, create varïous program sections containing either code or data as specïfïed in the files headers, and, finally, identïfy specific entry points into the code belote returning control to IDA. In this regard, IDA loader modules behave much as operating system loaders behave. The IDA loader will determine a virtual memory layout based on information contaïned in the program file headers and configure the database accordingly.

Once the loader bas finished, the disassembly engine within IDA takes over and begins passing one address at a time to the selected processor module. The processor modules job is to determine the type of instruction located at that address, the length of the instruction at that address, and the location (s) at which execution can continue from that address (e.g., is the current instruction sequential or branching?). When IDA is comfortable that it bas found ail of the instructions in the file, it makes a second pass through the list of instruction addresses and asks the processor module to generate the assembly language version of each instruction for display.

Following this disassembly, IDA automatically conducts additional analysis of the binary file to extract additional information likely to be useful to the analyst. Users can expect to find some or ail of the following information incorporated into the database once IDA completes its initial analysis:

Compiler identification

It is often useful to know what compiler was used to build a piece of software. Identïfyïng the compiler that was used can help us understand function-calling conventions used in a binary as well as determine what libraries the binary may be linked with. When a file is loaded, IDA attempts to ïdentify the compiler that was used to create the input file. If the compiler can be identified, the input file is scanned for sequences of boïlerplate code known to be used by that compiler. Such functions are color coded in an effort to reduce the amount of code that needs to be analyzed.

Function argument and local variable identification

Within each identified fonction (addresses that are targets of cali instructions), IDA performs a detailed analysis of the behavior of the stack pointer register in order to both recognize accesses to variables located within the stack and understand the layout of the functions stack [rame.4 Narres are automatically generated for such variables based on their use as eïther local variables within the fonction or as arguments passed into the fonction as part of the fonction calI process.

Datatype information

Utilizing knowledge of commun library functions and their required parameters, IDA adds comments to the database to indicate the locations at which parameters are passed into these functions. These comments save the analyst a tremendous amount of time by providing information that would otherwïse need to be retrieved from varïous application programming interface (API) references.

Closing IDA Databases

Any lime you close a database, whether you are closing IDA altogether or simply swïtching to a different database, you are presented with the Save Database dialog, as shown in Figure 4-6.

If this is the initial save of newly created database, the new database filename is derived from the input filename by replacing the input extension wïth the .1db extension (e.g., exarnple.exeyields a database named exarnple.Jdb). When the input file bas no extension, .1db is appended to form the narre of the database (e.g., httpdyields httpd.idb) . The avaïlable save options and their assocïated implications are summarized in the following list: Dont pack database

This option simply flushes changes to the four database component files and closes the desktop without creating an 1DB file. This option is not recornrnended when closing your databases.

Pack database (Store)

Selecting the Store option resuits in the four database component files being archived into a single 1DB file. Any previous 1DB will be overwritten without confirmation. No compression is used with the Store option. Once the 1DB flIc bas been created, the four database component files are deleted.

Pack database (Deflate)

The Deflate option is identical to the Store option, with the exception that the database component files are compressed within the 1DB archive.

Collect garbage

Requesting garbage collection causes IDA to delete any unused memory pages front the database prior to closing it. Select this option in conjunction with Deflate in order to create the smallest possible 1DB file. This option is not generally required unless disk space is at a premium.

DONT SAVE the database

You inay wonder why anyone would choose not to save his work. It turns out that this option is the only way to discard changes that you have made to a database since the last time it was saved. When this option is selected, IDA sïmply deletes the four database component files and leaves any existing 1DB file untouched. Using this option is as close as you will get to an undo or revert capability while using IDA.

Reopening a Database

Granted, reopening an existing database doesn't involve rocket science,5 so you may be wondering why this topic is covered at ail. Under ordinary circumstances, returning to work on an existing database is as simple as selecting the database using one of IDAs file-opening methods. Database files open much faster the second (and subsequent) time around because there is no analysis to perform. As an added bonus, IDA restores your IDA desktop to the same state it was in at the time it was closed. Now for the bad news. Believe or not, IDA crashes on occasion. Whether because of a bug in IDA ïtself or because of a bug in some bleeding-edge plug-in you have installed, crashes leave open databases in a potentially corrupt state. Once you restart IDA and attempt to reopen the affected data-base, you are likely to see one of the dialogs shown in Figures 4-7 and 4-8.

When IDA crashes, there is no opportunity for IDA to close the active database, and the intermediate database files do not get deleted. If this was not the first time that you were working with a particular database, you may have a situation in which both an 1DB file and potentïally corrupt intermediate files are present at the same time. The 1DB file represents the last-known good state of the database, whïle the intermediate files contain any changes that may have been made since the last save operation. In this case, you will be offered the choice to revert to the saved version or resume use of the open, potentially corrupt version, as shown in Figure 4-7. Choosing Continue with Unpacked Base by no means guarantees that you will recover your work. The unpacked database is probably in an inconsistent state, whïch will prompt IDA to offer the dialog shown in Figure 4-8. In this case, IDA ïtself recommends that you consider restoring [rom the packed data, su consider yourself warned if you opt to go with a repaired database.

When an active database bas neyer been saved, thus leaving only intermediate files present at the time of the crash, IDA offers the repair option in Figure 4-8 as surin as you try to open the original executable file again.

Introduction to the IDA Desktop

Given the amount of time you are likely to spend staring at your IDA desktop, you will want to spend some time familiarizing yourself with ils varions components. Figure 4-9 shows an overvïew of a default IDA desktop. The behavior of the desktop during file analysis is discussed in the following section.

Areas of ïnterest in this introductory view include the following:

1. The toolbar ana O contains torils corresponding to the most commonly used IDA operations. Toolbars are added to and removed [rom the desktop using the Vïew > Toolbars command. Using drag-and-drop, you can reposition each of the toolbars to suit your needs. Figure 4-9 shows IDAs basic mode toolbar with a single row of triol buttons. An advanced mode toolbar is available using View > Toolbars > Advanced mode. The Advanced mode toolbars contain three full rows of triol buttons.

2. The horizontal color band is IDAs overview navigator O, also called the na vigation band. The navigation band presents a linear view of the address space of the loaded file. By default, the entire address range of the hinary is represented. You can zoom in and out of the address range by rightclicking anywhere within the navigation band and selecting one of the available zoom options. Different colors represent different types of flic content, such as data or code. A small current position indicator (yellow hy default) points at the navigation band address that corresponds to the current address range being displayed in the disassembly window. Hovering the mouse cursor river any portion of the navigation band yields a toril tip that describes that location in the binary. Clicking the navigation band jumps the disassernbly vïew tu the selected location within the hinary. The colors used in the navigation band can be customized using the Options Colors command. Dragging the navigation band away [rom the IDA desktop yields a detached Overview Navigator, as shown in Figure 4-10. Also shown in Figure 4-10 is the current position indicator (the haiflength, downward-facing arrow tu the left of location O) and a colorkey identïfying the file content hy functional groups.

3. Coming back to Figure 4-9, tabs O are provided for each of the currently open data displays. Data displays contain information extracted from the binary and represent the various views into the database. The majority ofyour analysis work is likely to take place through interaction with the available data displays. Figure 4-9 shows three of the available data displays: IDA-View, Fonctions, and Graph Overview. Additional data displays are available via the View > Open Subviews menu, and this menu is also used to restore any displays that have been closed, whether on purpose or inadvertently.

4. The disassernhly view O is the primary data display. Two display styles are available for the disassembly view: graph view (default) and listing view. In graph view, IDA displays a flowchart-style graph of a single function at any given time. When this is combined with the graph overview, you can gain an understanding of the flow of the function using a visual break-down of the fonctions structure. When the IDA-View window is active, the spacebar toggies between graph view-style and listing-style displays. If you wïsh to make listing view your default, you must uncheck Use graph view by default on the Graph tab via the Options > General menu, as shown in Figure 4-11.

6. The Output window Q is where you can expect to flnd any informational messages generated by IDA. Here von will find status messages concerning the progress of the file-analysis phase, along with any error messages resulting from user-requested operations. The Output window roughly equates to a console output device.

7. The Functions window O rounds out the default IDA display windows and will be discussed further in Chapter 5.

Desktop Behavior During Initial Analysis

A tremendous amount of activity takes place within the IDA desktop during the initial autoanalysis of newly opened file. You can gain an understanding of this analysis by observing various desktop displays during the analysis process. Desktop activity von may observe includes the following:

  • Progress messages printed to the Output window
  • Initial location and disassembly output generated for the disassembly window
  • Initial population of the Fonctions window, followed by periodic updates as the analysis progresses
  • Transformation of the navigation band as new areas of the binary are recognized as code and data, blocks of code are further recognized as functions, and, finally, fonctions are recognized specifically as lïbrary code using IDAs pattern-matching techniques
  • The current position indicator traversing the navigation band to show the regions currently being analyzed

The following output is representative of messages generated by IDA during the initial analysis of a newly opened binary file. Notice that the messages form a narrative of the analysis process and offer insight into the sequence of operations performed by IDA during that analysis.

Two particularly helpful progress messages are Vou may start to explore the input file right now O and The initial autoanalysis has been finished

O. The fïrst message informs you that IDA has made enough progress with its analysis that you can begin navigating through the varions data displays. Navigating dors not ïmply changing, however, and you should wait to rnake any changes to the database outil the analysis phase has been cornpleted. If you atternpt to change the database prior to completion of the analysis phase, the analysis engine may corne along later and modify your changes further, or you may even prevent the analysis engine frorn doing itsjob correctly. The second of these messages, whïch is fairly self-explanatory, indicates that you can expect no more automatic changes to take place in the desktop data displays. At this point it is sale to make any changes you like to the database.

IDA Desktop Tips and Tricks

IDA offers a tremendous amount of information, and its desktop can become cluttered. Here are some tips for rnaking the best use of your desktop:

  • The more screen real estate you dedicate to IDA, the happier you will be. Use this fact to justify the purchase of a king-size monitor (or two)!
  • Dont forget the Vïew > Open Subvïews command as a means of restoring data displays that you have inadvertently closed.
  • The Windows > Reset Desktop command offers a useful way to quickly restore your desktop to its original layout.
  • Utilize the Windows > Save Desktop command to save a current layout of desktop configurations that you find partïcularly useful. The Windows Load Desktop command is used to quickly revert to a saved layout.
  • The only window for which the dïsplay font can be changed is the Disassernbly window (either graph or listing view). Fonts are set using the Options > Font command.