IDA DATA DISPLAYS : Différence entre versions

De Wiki expérimental
(Page créée avec « At this point you should have some confidence loading hinaries into IDA and letting DA work its magic while you sip your favorite heverage. Once IDA's initial analysis pha... »)
 
 
(12 révisions intermédiaires par le même utilisateur non affichées)
Ligne 7 : Ligne 7 :
  
 
If something unexpected happens to your database as a resuit of an inadvertent keypress, you are on your own to restore your dïsplays to their previous states.
 
If something unexpected happens to your database as a resuit of an inadvertent keypress, you are on your own to restore your dïsplays to their previous states.
 +
 +
Almost ail actions have an associated menu item, hotkey, and toolbar hutton. Remember, the IDA toolbar is highly configurable, as is the mapping of hotkeys to menu actions.
 +
IDA offers gond, context-sensitive menu actions in response to right mouse clicks.
 +
Whïle these menus do not offer an exhaustive list of permissible actions at a given location, they do serve as good reminders for the most commun actions you will be performing.
 +
With these facts in mmd, lets begin ont coverage of the principal IDA data displays.
 +
 +
The Principal IDA Displays
 +
 +
In its default configuration, IDA creates seven (as of version 6.1) display windows during the initial loading-and-analysis phase for a new binary. Each of these display windows is accessible via a set of titie tabs displayed immedïately beneath the navigation band (shown previously in Figure 4-9). The three immediately visible windows are the IDA-Vïew window, the Functions window, and the Output window. Whether or not they are open by default, ail of the windows discussed in this chapter can be opened via the Vïew > Open Subviews menu. Keep this fact in mmd, as it is fairly easy to ïnadvertently close the display windows.
 +
 +
The ESC key is one of the more useful hotkeys in ail of IDA. When the disassembly window is active, the ESC key functions in a manner similar to a web browser's back button and is therefore very useful in navigating the disassembly display (navigation is covered in detaïl in Chapter 6). Unfortunately, when any other window is active, the ESC key serves to close the window. Occasionally, this is exactly what you want. At other times, you will immedïately wïsh you had that closed window back.
 +
 +
The Disassembly Window
 +
 +
Also known as the IDA-Vïew window, the disassembly window will be your prïmary tool for manipulating and analyzing binaries. Accordïngly, it is important that you become intimately familiar with the manner in which information is presented in the disassembly window.
 +
 +
Two display formats are available for the disassembly window: the default graph-based view and a text-orïented listing view. Most IDA users tend to prefer one view over the other, and the view that better suits your needs is often determïned by how you prefer to visualize a programs flow. If you prefer to use the text listing view as your default disassembly view, you can change the default by using the Options > General dïalog to turn off Use graph view by default on the Graph tab. Whenever the disassembly view is active, you can easily switch between graph and listing views at any time by using the spacebar.
 +
 +
IDA Grapli View
 +
 +
Figure 5-1 shows a very simple function displayed in graph vïew. Graph views are somewhat reminiscent of program flowcharts in that a fonction is broken up into basic blocks1 so you can visualize the functions control flow front one block to another.
 +
 +
Onscreen, you'll notice IDA uses différent colored arrows to distinguish varions types of flows2 between the blocks of a fonction. Basic blocks that terminate with a conditional jump generate two possible fiows depending on the condition being tested: the Ves edge arrow (yes, the branch is taken) is green by default, and the No edge arrow (no, the branch is not taken) is red by de[ault. Basic blocks that terminale with only one potential successor block utilize a Normal edge (blue by de[ault) to point to the next block to be executed.
 +
 +
Double-clicking this import would jump the disassembly window to address 0040Elo8. The contents of this memory location in hex view would be ?? ?? ?? ??. IDA isa static analysis toril, and it bas no way to know what address will be entered into this memory location when the program is executed. The Imports window also offers functionality available in command-une tools such as objdump (-T), readeif (-s), and dumpbin (/IMPORTS).
 +
 +
An important point to remember about the Imports window is that it displays only the symbols that a binary wants handled automatically by the dynamic loader. Symbols that a binary chooses to load on lits own using a mechanism such as diopen/disym or LoadLibrary/GetProcAddress will not be listed in the Imports window.
 +
 +
The Structures Window
 +
 +
The Structures window is used to display the layout of any complex data structures, such as C structs or unions, that IDA determines are in use within a binary. During the analysis phase, IDA consults its extensive library of fonction
 +
-
 +
type signatures in an attempt to match fonction parameter types to memory used within the program. The Structures window shown in Figure 5-6 indicates that IDA believes the program uses the sockaddr' data structure.
 +
 +
In graph mode, IDA dïsplays one fonction at a time. For users with a wheel mouse, graph zooming is possible using the CTRL-wheel combination. Keyboard zoom control requires CTRL-+ to zoom in or CTRL-- to zoom out (using the + and — keys on the numeric keypad). Large or complex fonctions may cause the graph view to become extremely cluttered, making the graph dïfflcult to navigate. In such cases, the Graph Overview window (sec Figure 5-2) is available to provide soute situational awareness. The overview window aiways displays the complete block structure of the graph along with a dashed [rame that indicates the region of the graph currently being vïewed in the disassembly window. The dashed [rame can be dragged across the overview window to rapïdly reposition the graph view to any desïred location on the graph.
 +
 +
Rearranging blocks
 +
 +
Individual blocks within the graph can be dragged to new positions by clicking the titie bar for the desired block and dragging it to a new position. Beware that IDA performs only minimal rerouting of any edges assocïated with a moved block. You can manually reroute edges by dragging vertices to new locations. New vertices can be introduced into an edge by double-clicking the desïred location within an edge whïle holding the SHIFT key. If ai any point you find yourself wishing to revert to the default layout for your graph, you can do so by right-clicking the graph and choosing Layout Graph.
 +
 +
Grouping and collapsing blocks
 +
 +
Blocks can be grouped, either individually or together with other blocks, and collapsed to reduce the clutter in the display. Collapsing blocks is a particularly useful technique for keeping track of blocks that you have already analyzed. You can collapse any block by right-clicking the block's title bar and selecting Group Nodes.
 +
 +
Creating additional disassembly windows
 +
 +
If you ever find yourself wanting to view graphs of two fonctions simultaneously, ail you need to do is open another disassembly window using Views > Open Subviews > Disassembly. The first disassembly window
 +
opened is titled IDA l7kw-A. Subsequent disassembly windows are titled IDA 17kw-B, IDA VJew-C, and so on. Each disassembly is independent of
 +
the other, and it is perfectly acceptable to view a graph in one window while viewing a text listing in another or to view three different graphs in three different windows.
 +
Keep in mmd that your control over the view extends beyond just these examples. Additional IDA graphing capabilities are covered in Chapter 9, whïle more information on the manipulation of IDAs graph view is avaïlable in the IDA help file.
 +
 +
IDA Text View
 +
 +
The text-orïented disassembly window is the traditional display used for viewing and manipulating IDA-generated disassemblies. The text display presents the entire disassembly listing of a program (as opposed to a single fonction ai a time in graph mode) and provides the only means for viewing the data regions of a binary. Ail of the information avaïlable in the graph dis-play is avaïlable in the text display in one form or another.
 +
 +
Figure 5-4 shows the text view listing of the saute fonction shown in Figures 5-1 and 5-3. The disassembly is presented in linear fashion, with virtual addresses dïsplayed by default. Virtual addresses are typïcally dïsplayed in a [SECTION NAME]:[VIRTUAL ADDRESS] format suchas .text:004011C1.
 +
 +
The left portion of the display, seen at O, is called the arrows window and is used to depict nonlinear flow within a function. Solïd arrows represent unconditionaljumps, while dashed arrows represent conditionaljurnps. When ajump (conditional or unconditional) transfers control to an radier address in the program, a heavy weighted une (solid or dashed) is used. Such reverse flow in a program often indicates the presence of a loop. In Figure 5-4, a loop arrow fiows from address 004011fF to 00401105.
 +
 +
The declarations at O (also present in graph view) represent IDAs best estimate concerning the layout of the functions stack frame.3 IDA compotes the structure of a functions stack frame by performing detailed analysis of the behavior of the stack pointer and any stack frame pointer used within a function. Stack displays are discussed further in Chapter 6.
 +
The comments (a semicolon introduces a comment) at O are civssreferences. In ibis case we see code cross-references (as opposed to data crossreferences), which indicate that another program instruction transfers control to the location containing the cross-reference comment. Cross-references are the subject of Chapter 9.
 +
 +
For the remainder of the book we will primarily utilize the text display for examples. Well use the graph display only in cases where it may provide significantly more clarity. In Chapter 7 we will cover the specifics of manipulating the text display in order to clean up and annotate a disassembly.
 +
3. A stack Trame (or activation rewixi) isa hlock of mernory, al local ed in a programs runhirite stack, that contains holh the pararnelers passed into a fonction and the local variables declared within the fonction. Stark haines are allocaled upon eniry hue a fonction and released as the fonction exils. Stark frames are discussed in more detail in Chapler 6.
 +
 +
The Functions Window
 +
The Fonctions window is used to list every fonction that IDA bas recognized in the database. A Fonctions window entry rnight look like the following:
 +
 +
rualloc .text 00BDC260 00000180 R B
 +
 +
This particular une indicates that the malloc fonction can be found in the .text section of the binary at virtual address ooBDC260, is 384 bytes (hex 180) long, returns to the caller (R), and uses the EBP register (B) to reference its local variables. Flags used to describe a fonction (such as R and B above) are described in IDAs built-in help file (or by right-clicking a fonction and choosing Properties. The flags are shown as editable checkboxes in the resulting Properties dïalog).
 +
As with other dïsplay windows, double-clicking an entry in the Fonctions window causes the dïsassembly window to jump to the location of the selected fonction.
 +
 +
The Output Window
 +
 +
The Output window ai the bottom of the IDA workspace rounds out the default set of windows that are visible when a new file is opened. The Ouput window serves as IDAs output console and is the place to look for information on tasks IDA is performing. When a binary is first opened, for example, messages are generated to indicate both what phase of analysis IDA is in ai any given time and what actions IDA is carryïng out to create the new database. As von work with a database, the Output window is used to output the status of varions operations that von perform. The contents of the Output window can be copied to the system clipboard or cleared entirely by rïght-clïckïng anywhere in the window and selecting the appropriate operation. The Output window will often be the primary means by whïch von display output [rom any scripts and plug-ins that you develop for IDA.
 +
 +
Secondary IDA Displays
 +
 +
In addition to the dïsassembly, Fonctions, and Output windows, IDA opens a number of other tabbed windows on your IDA desktop. These tabs are present just under the navigation band (see O in Figure 4-9). These windows are used to provide alternate or specialized views into the database. The utility of these displays depends on both the characteristïcs of the binary von are analyzing and your skill with IDA. Several of these windows are sufficïently specïalized to require more detaïled coverage in later chapters.
 +
 +
The Hex View Window
 +
 +
Hex View is something of a misnomer in this case, as the IDA Hex View window can be configured to display a variety of formats and doubles as a hex editor. By default, the Hex View window provides a standard hex dump of the program content with 16 bytes per une and ASCII equivalents displayed alongside. As with the disassembly window, several hex views can be opened simultaneously. The first Hex window is titled Hex l7kw-A, the second Hex View B, the next Hex View C, and so on. By default, the first Hex window is synchronized with the first disassembly window. When a disassembly view is synchronized with a hex view, scrolling in one window causes the other window to scroil to the same location (same virtual address). In addition, when an item is selected in disassembly view, the corresponding bytes are highlighted in hex view. In Figure 5-5, the disassembly view cursor is positioned at address 0040108C, a cail instruction, causing the five bytes that make up the instruction to be highlighted in the Hex window.
 +
 +
In soute cases you may [md that the Hex window shows nothing but question marks. This is IDAs way of telling you that it bas no idea what values might occupy a given virtual address range. Such is the case when a program contains a bss4 section, which typically occupies no space within a file but is expanded by the loader to accommodate the programs static storage requirements.
 +
 +
The Exports Window
 +
 +
The Exports window lists the entry points into a file. These include the programs execution entry point, as specified in its brader section, along with any fonctions and variables that the file exports for use by other files. Exported fonctions are commonly found in shared libraries such as Windows DLL files. Exported entries are lïsted by nourrir, virtual address, and, if applicable, by ordinal number.5 For executable files, the Exports window always contains ai least one entry: the programs execution entry point. IDA naines ibis entry point start. A typical Exports window entry follows:
 +
 +
LoadLibraryA 7C801D77 578
 +
 +
As with many of the other IDA windows, double-clicking an entry in the Exports window willjump the disassembly window to the address assocïated with that entry. The Exports window offers functïonality avaïlable in commandline torils such as objdump (-î), readeif (-s), and dumpbin (/ExP0RTs).
 +
 +
The Imports Window
 +
 +
The Imports window is a counterpart to the Exports window. It lists ail functions that are ïmported by the binary being analyzed. The Imports window is relevant only when a binary makes use of shared libraries. Statïcally lïnked binaries have no external dependencies and therefore no imports. Each entry in the Imports window lists the name of an ïmported item (fonction or data) and the name of the library that contains that item. Since the code for an imported fonction resides in a shared library, the addresses listed with each entry refer to the virtual address of the associated import table entry.' An example of an Import window entry is shown here:
 +
 +
0040E108 GetNloduleHandleA KERNEL32
 +
 +
The Enums Window
 +
 +
The Enums window is somewhat similar to the Structures window. When IDA detects the use of  standard enumerated datatype (C enum), that datatype will be listed in the Enums window. You can make your disassemblies far more readable by using enums in place of integer constants. Like the Structures window, the Enums window offers facilities for deflning your own enumerated types that you can use with your disassembled binaries.
 +
 +
Tertiary IDA Displays
 +
 +
The last windows that we will dïscuss are those that IDA dors not open by default. Each of these windows is available via View > Open Subvïews, but they tend to provide information to whïch you may not require immediate access and are thus initially kept out of the way.
 +
 +
The Strings Window
 +
 +
The Strings window is the buïlt-in IDA equivalent of the strings utïlity and then soute. In IDA versions 5.1 and radier, the Strings window was open as part of the default desktop; however, with version 5.2, the Strings window is no longer open by default, though it remains available via View > Open Subvïews > Strings.
 +
 +
The purpose of the Strings window is to display a lïst of strings extracted from a binary along with the address at which each string resides. Like doubleclicking names in the Names window, double-clicking any string listed in the Strings window causes the dïsassembly window to jump to the address of the selected string. When used with cross-references (Chapter 9), the Strings window provides the means to rapidly spot an interesting string and to track back to any location in the program that references that string. For example, you might see the string SOFTWARE Microsoftl Windows I Current Version IRwi listed and wonder why an application is referencing this particular key within the Windows registry. As you will see in the following chapter, navigating to the program location that references this string takes only four clicks. Understanding the operation of the Strings window is essential to using it effectïvely. IDA dors not permanently store the strings it extracts from a binary. Therefore, every time the Strings window is opened, the entire database must be scanned or rescanned for string content. String scanning is performed in accordance with the settïngs of the Strings window, and you can access these settïngs by right-clicking within the Strings window and selecting Setup. As shown in Figure 5-7, the Setup Strings window is used to specify the types of strings that IDA should scan for. The default string type that IDA scans for is a C-style, null-terminated, 7-bit, ASCII string of at least flve characters in length.
 +
 +
If you expect to encounter anything other than C-style strings, you should reconfigure the Setup Strings window to choose the appropriate string type to search for. For example, Windows programs often make use of Unicode strings, while Borland Delphi binaries use Pascal-style strings with a 2-byte length. Every time you close the Setup Strings window by clicking OK, IDA will rescan the database for strings in accordance with the new settings. Two setup options deserve special mention:
 +
 +
Display only defined strings
 +
 +
This option restrïcts the Strings window to displaying only named string data items that have been
 +
automatically created by IDA or manually created by the user. Wïth this option selected, ail other options are disabled, and IDA will not automatically scan for addïtional string content.
 +
 +
Ignore instructions/data definitions
 +
 +
This option causes IDA to scan for strings across instruction and existing data definitions. Using this option allows IDA to (1) see strings that may be embedded in the code portion of a binary and have been mistakenly converted into instructions or (2) to sec strings within data that may be formatted as something other than a string (such as an array of bytes or integers). This option will also lead to the generation of manyjunk strings, which are sequences that happen to consïst of five or more ASCII characters whether or not they are legible. The effect of using this option is similar to using the strings command with the -a switch.
 +
 +
Figure 5-8 demonstrates that IDA durs not necessarily show ail strings within a binary if the strings setup is not confïgured properly. In this case, Ignore instructions/data definitions bas not been selected.
 +
 +
The result is that the string at location rdata : 0040C19C ("Please guess a nom-ber between 1 and %d.") remains undetected. The moral here is to make sure that you are looking for ail of the types of strings you expert to encounter in ail of the places you might [md them.
 +
 +
The Naines Window
 +
 +
The Names window, shown in Figure 5-9, provides a summary listing of ail of the global names within a binary. A naine is nothing more than a symbolic description given to a program virtuai address. IDA initïally derives the iist of names from symbol-table and signature analysis during the initial loading of a flic. Names can be sorted aiphabetïcafly or in virtuai address order (either ascending or descending). The Names window is useful for rapidiy navigating to known locations within a program listing. Double-clicking any Names window entry will ïmmedïately jump the disassembly view to dïsplay the selected name.
 +
 +
Dïsplayed narnes are both color and letter coded. The coding scherne is summarized below:
 +
*F A regular function. These are functions that IDA dors not recognize as library fonctions.
 +
*L A library function. IDA recognizes library fonctions through the use of signature-matching algorïthms. If a signature dors not exist for a given library function, the function will be labeled as a regular function instead.
 +
*I An irnported name, most commonly a function name irnported from a shared library. The difference between this and a library function is that no code is present for an imported name, while the body of a library function will be present in the disassernbly.
 +
*C Named code. These are named program instruction locations that IDA dors not consider to be part of any function. This is possible when IDA finds a name in a programs symbol table but neyer secs a cail to the corresponding program location.
 +
*D Data. Narned data locations typïcally represent global variables.
 +
 +
A String data. This is a referenced data location containing a sequence of characters that conform to one of IDAs known string data types, such as a null-terminated ASCII C string.
 +
 +
As you browse through disassemblies, you will notice that there are many named locations for whïch no name is listed in the Narnes wïndow. In the process of disassembling a program, IDA generates narnes for ail locations that are referenced directly eïther as code (a branch or calI target) or as data (read, written, or address taken). If a location is named in the programs symbol table, IDA adopts the name [rom the symbol table. If no symbol table entry is available for a given program location, IDA generates a default name for use in the disassembly. When IDA chooses to name a location, the virtual address of the location is combined wïth a prefix that indicates what type of location is being named. Incorporating the virtual address into a generated name ensures that ail generated narnes will be unique, as no two locations can share the same virtual address. Autogenerated riantes of this type are not displayed in the Names window. Some of the more commun prefixes used for autogenerated names include these:
 +
 +
*sub_xxxxxx A subroutine at address xxxxxx
 +
*loc_xxxxxx An instruction location at address xxxxxx
 +
*byte_xxxxxx 8-bit data at location xxxxxx
 +
*word_xxxxxx 16-bit data at location xxxxxx
 +
*dword_xxxxxx 32-bit data at location xxxxxx
 +
*unk_xxxxxx Data of unknown size at location xxxxxx
 +
 +
Throughout the course of the book we will show additional algorithms that IDA applies in choosing narres for program data locations.
 +
 +
The Segments Window
 +
 +
The Segments window displays a summary listing of the segments present in the binary fie. Note that what IDA terras segments are most often called sections when discussing the structure of binary files. Do not confuse the use of the terra segments in this manner with the memory segments assocïated with CPUs that implement a segmented memory architecture. Information presented in the window includes the segment name, start and end addresses, and permission flags. The start and end addresses represent the virtual address range to whïch the program sections will be mapped at runtime. The following listing is an example of Segments window content from a Windows binary:
 +
 +
Name Start End R W X D L AUgn Base Type Class .40 es ss ds fs gs
 +
UPXO 00401000 00407000 R W X L para 0001 public CODE 32 0000 0000 0001 FFFFFFFF FFFFFFFF
 +
UPX1 00407000 00408000 R W X L para 0002 public CODE 32 0000 0000 0001 FFFFFFFF FFFFFFFF
 +
UPX2 00408000 0040803C R W L para 0003 public DATA 32 0000 0000 0001 FFFFFFFF FFFFFFFF
 +
.idata 0040803C 00408050 R W L para 0003 public XTRN 32 0000 0000 0001 FFFFFFFF FFFFFFFF
 +
UPX2 00408050 00409000 R W L para 0003 public DATA 32 0000 0000 0001 FFFFFFFF FFFFFFFF
 +
 +
In this case, we mïght quickly suspect that something is funny with this particular binary since it uses nonstandard segment names and bas two executable segments that are wrïtable, thus indicating the possïbïlïty of self -modïfying code (more on this in Chapter 21). The fact that IDA knows the size of a segment does not indicate that IDA knows the contents of the segment. For a variety of reasons, segments often occupy less space on disk than they do in memory. In such cases, IDA displays values for the portions of the segment that IDA bas determined it could fili from the disk file. For the remainder of the segment, IDA displays question marks.
 +
 +
Double-clicking any entry in the windowjumps the disassembly view to the start of the selected segment. Right-clicking an entry provides a context menu from which von can add new segments, delete existing segments, or edit the properties of existing segments. These features are particularly useful when reverse engineering files with nonstandard formats, as the binarys segment structure may not have been detected by the IDA loader.
 +
 +
Command-line counterparts to the Segments window include objdump (-h), readel-f (-s), and dumpbin (/HEADERS).
 +
 +
The Signatures Window
 +
 +
IDA makes use of an extensive library of signatures for ïdentïfying known blocks of code. Signatures are used to identify common compiler-generated startup sequences in an attempt to determine the compiler that may have been used to build a given binary. Signatures are also used to categorize functions as known library fonctions ïnserted by a compiler or as fonctions added to the binary as a resuit of static lïnking. When IDA identifies library
 +
fonctions for you, you can focus more of your effort on the code that IDA did not recognize (which is probably far more interesting to you than reverse engineering the inner workings of print-f).
 +
The Signatures window is used to list the signatures that IDA bas already matched against the open binary flic. An example from a Windows PE file is shown here:
 +
 +
File State #-func Library narne
 +
vc32rt-f AppUed 501 Microsoft VisuaiC 2-8/net runtime
 +
 +
This example indicates that IDA bas applïed the vc32rtf signatures (from dDADIR>/sis) against the binary and, in doing so, bas been able to recognize 501 fonctions as library fonctions. Thats 501 fonctions that you wili not need to reverse engineer!
 +
 +
In at ieast two cases, you wiil want to know how to apply additïonal signatures against your binaries. In the flrst case, IDA may [ail to recognize the compiler that was used to build a binary, with a resulting inability to select appropriate signatures to apply. In this case, you may wish to force IDA to apply one or more signatures that your prehmïnary analysis bas ied you to beheve IDA should try. The second situation invoives creating your own signatures for libraries that may not have existing signatures ïncluded with IDA. An example might be the creation of signatures for the static version of the OpenSSL libraries that ship with FreeBSD 8.0. DataRescue makes a toolkit avaiiable for generating custom signatures that can be used by IDAs signature-matching engine. We'il cover the generation of custom signatures in Chapter 12. Regardless of why you want to apply new signatures, eïther pressing the INSERT key or right-clïckïng the Signatures window wili offer you the Apply new signature option, at which time you can choose from a hst of ail signatures known to your installation of IDA.
 +
 +
The Type Libraries Window
 +
 +
Similar in concept to the Signatures window is the Type Libraries window. Type libraries represent IDAs accumulated knowiedge of predefined datatypes and function prototypes gieaned from header files ïncluded with most popular compilers. By processing header files, IDA understands the datatypes that are expected by common library fonctions and can annotate your disassemblies accordingly. Simïiarly, from these header files IDA understands both the size and layout of complex data structures. AlI of this type information is collected into TIL files (cIDADIR>/tit and apphed any time a binary is anaiyzed. As with signatures, IDA must first be able to deduce the libraries that a program uses belote it can select an appropriate set of TIL files to load. You can request that IDA ioad addïtional type libraries by pressing the INSERT key or by right-clicking within the Type Libraries window and choosing Load type library. Type libraries are covered in more detaïi in Chapter 13.
 +
 +
The Function Calis Window
 +
 +
In any program, a fonction can both call and be called by other fonctions. In fact, it is a fairiy simple task to construct a graph that displays the relationships between callers and caiiees. Such a graph is called a function callgraph or /'wiction rail tree (we will demonstrate how to have IDA generate such graphs in Chapter 9). On occasion, we may not be interested in seeing the entire cail graph of a program; ïnstead, we may be interested only in knowing the immediate neighbors of a given fonction. For our purposes, we will cali Y a neïghbor of X if Y directiy rails X or X dïrectiy cails Y.
 +
 +
The Function Calis window provides the answer to ibis neighbor question. When you open the Function Cails window, IDA determines the neïghbors of the fonction in which the cursor is positïoned and generates a dispiay such as that shown in Figure 5-10.
 +
 +
In this example, we sec that the function named sub 40182c is called frontsix different locations in main and main in turn makes 15 other fonction
 +
cails. Double-clicking any line within the Function CalIs window immediately jumps the disassembly window to the selected caliing or called function (or caller and calice). IDA cross-references (xrefs) are the mechanïsms that underhe the generation of the Function CalIs windows. Xrefs will be covered in more detaïl in Chapter 9.
 +
 +
The Problems Window
 +
 +
The Probiems window is IDAs way of informing you of any difflcuitïes that it bas encountered in disassembiing a binary and how it bas chosen to deal wïth those difficuities. In some instances, you may be able to manipulate the disassembiy to heip IDA overcome a probiem, and in other instances you may not. You can expert to encounter problems in even the sïmpiest of
 +
binaries. In many cases, simply choosing to ignore the problems is not a bad strategy. In order to correct many of the problems, you need to have a better understanding of the binary than IDA bas, which for trust of us is probably not goïng to happent.

Version actuelle en date du 15 août 2019 à 02:21

At this point you should have some confidence loading hinaries into IDA and letting DA work its magic while you sip your favorite heverage. Once IDA's initial analysis phase is complete, it is time for you to take control. One of the best ways for you to familiarize yourself with IDA's displays is sirnply to browse around the varions tabbed subwindows that IDA populates with data about your binary. The effïciency and effectiveness of your reverse engineering sessions will improve as your cornfort level with IDA increases.

Before we dive into the major IDA subdisplays, it is useful to cover a few basic rules concerning IDA's user interface:

There is no undo in IDA.

If something unexpected happens to your database as a resuit of an inadvertent keypress, you are on your own to restore your dïsplays to their previous states.

Almost ail actions have an associated menu item, hotkey, and toolbar hutton. Remember, the IDA toolbar is highly configurable, as is the mapping of hotkeys to menu actions. IDA offers gond, context-sensitive menu actions in response to right mouse clicks. Whïle these menus do not offer an exhaustive list of permissible actions at a given location, they do serve as good reminders for the most commun actions you will be performing. With these facts in mmd, lets begin ont coverage of the principal IDA data displays.

The Principal IDA Displays

In its default configuration, IDA creates seven (as of version 6.1) display windows during the initial loading-and-analysis phase for a new binary. Each of these display windows is accessible via a set of titie tabs displayed immedïately beneath the navigation band (shown previously in Figure 4-9). The three immediately visible windows are the IDA-Vïew window, the Functions window, and the Output window. Whether or not they are open by default, ail of the windows discussed in this chapter can be opened via the Vïew > Open Subviews menu. Keep this fact in mmd, as it is fairly easy to ïnadvertently close the display windows.

The ESC key is one of the more useful hotkeys in ail of IDA. When the disassembly window is active, the ESC key functions in a manner similar to a web browser's back button and is therefore very useful in navigating the disassembly display (navigation is covered in detaïl in Chapter 6). Unfortunately, when any other window is active, the ESC key serves to close the window. Occasionally, this is exactly what you want. At other times, you will immedïately wïsh you had that closed window back.

The Disassembly Window

Also known as the IDA-Vïew window, the disassembly window will be your prïmary tool for manipulating and analyzing binaries. Accordïngly, it is important that you become intimately familiar with the manner in which information is presented in the disassembly window.

Two display formats are available for the disassembly window: the default graph-based view and a text-orïented listing view. Most IDA users tend to prefer one view over the other, and the view that better suits your needs is often determïned by how you prefer to visualize a programs flow. If you prefer to use the text listing view as your default disassembly view, you can change the default by using the Options > General dïalog to turn off Use graph view by default on the Graph tab. Whenever the disassembly view is active, you can easily switch between graph and listing views at any time by using the spacebar.

IDA Grapli View

Figure 5-1 shows a very simple function displayed in graph vïew. Graph views are somewhat reminiscent of program flowcharts in that a fonction is broken up into basic blocks1 so you can visualize the functions control flow front one block to another.

Onscreen, you'll notice IDA uses différent colored arrows to distinguish varions types of flows2 between the blocks of a fonction. Basic blocks that terminate with a conditional jump generate two possible fiows depending on the condition being tested: the Ves edge arrow (yes, the branch is taken) is green by default, and the No edge arrow (no, the branch is not taken) is red by de[ault. Basic blocks that terminale with only one potential successor block utilize a Normal edge (blue by de[ault) to point to the next block to be executed.

Double-clicking this import would jump the disassembly window to address 0040Elo8. The contents of this memory location in hex view would be ?? ?? ?? ??. IDA isa static analysis toril, and it bas no way to know what address will be entered into this memory location when the program is executed. The Imports window also offers functionality available in command-une tools such as objdump (-T), readeif (-s), and dumpbin (/IMPORTS).

An important point to remember about the Imports window is that it displays only the symbols that a binary wants handled automatically by the dynamic loader. Symbols that a binary chooses to load on lits own using a mechanism such as diopen/disym or LoadLibrary/GetProcAddress will not be listed in the Imports window.

The Structures Window

The Structures window is used to display the layout of any complex data structures, such as C structs or unions, that IDA determines are in use within a binary. During the analysis phase, IDA consults its extensive library of fonction - type signatures in an attempt to match fonction parameter types to memory used within the program. The Structures window shown in Figure 5-6 indicates that IDA believes the program uses the sockaddr' data structure.

In graph mode, IDA dïsplays one fonction at a time. For users with a wheel mouse, graph zooming is possible using the CTRL-wheel combination. Keyboard zoom control requires CTRL-+ to zoom in or CTRL-- to zoom out (using the + and — keys on the numeric keypad). Large or complex fonctions may cause the graph view to become extremely cluttered, making the graph dïfflcult to navigate. In such cases, the Graph Overview window (sec Figure 5-2) is available to provide soute situational awareness. The overview window aiways displays the complete block structure of the graph along with a dashed [rame that indicates the region of the graph currently being vïewed in the disassembly window. The dashed [rame can be dragged across the overview window to rapïdly reposition the graph view to any desïred location on the graph.

Rearranging blocks

Individual blocks within the graph can be dragged to new positions by clicking the titie bar for the desired block and dragging it to a new position. Beware that IDA performs only minimal rerouting of any edges assocïated with a moved block. You can manually reroute edges by dragging vertices to new locations. New vertices can be introduced into an edge by double-clicking the desïred location within an edge whïle holding the SHIFT key. If ai any point you find yourself wishing to revert to the default layout for your graph, you can do so by right-clicking the graph and choosing Layout Graph.

Grouping and collapsing blocks

Blocks can be grouped, either individually or together with other blocks, and collapsed to reduce the clutter in the display. Collapsing blocks is a particularly useful technique for keeping track of blocks that you have already analyzed. You can collapse any block by right-clicking the block's title bar and selecting Group Nodes.

Creating additional disassembly windows

If you ever find yourself wanting to view graphs of two fonctions simultaneously, ail you need to do is open another disassembly window using Views > Open Subviews > Disassembly. The first disassembly window opened is titled IDA l7kw-A. Subsequent disassembly windows are titled IDA 17kw-B, IDA VJew-C, and so on. Each disassembly is independent of the other, and it is perfectly acceptable to view a graph in one window while viewing a text listing in another or to view three different graphs in three different windows. Keep in mmd that your control over the view extends beyond just these examples. Additional IDA graphing capabilities are covered in Chapter 9, whïle more information on the manipulation of IDAs graph view is avaïlable in the IDA help file.

IDA Text View

The text-orïented disassembly window is the traditional display used for viewing and manipulating IDA-generated disassemblies. The text display presents the entire disassembly listing of a program (as opposed to a single fonction ai a time in graph mode) and provides the only means for viewing the data regions of a binary. Ail of the information avaïlable in the graph dis-play is avaïlable in the text display in one form or another.

Figure 5-4 shows the text view listing of the saute fonction shown in Figures 5-1 and 5-3. The disassembly is presented in linear fashion, with virtual addresses dïsplayed by default. Virtual addresses are typïcally dïsplayed in a [SECTION NAME]:[VIRTUAL ADDRESS] format suchas .text:004011C1.

The left portion of the display, seen at O, is called the arrows window and is used to depict nonlinear flow within a function. Solïd arrows represent unconditionaljumps, while dashed arrows represent conditionaljurnps. When ajump (conditional or unconditional) transfers control to an radier address in the program, a heavy weighted une (solid or dashed) is used. Such reverse flow in a program often indicates the presence of a loop. In Figure 5-4, a loop arrow fiows from address 004011fF to 00401105.

The declarations at O (also present in graph view) represent IDAs best estimate concerning the layout of the functions stack frame.3 IDA compotes the structure of a functions stack frame by performing detailed analysis of the behavior of the stack pointer and any stack frame pointer used within a function. Stack displays are discussed further in Chapter 6. The comments (a semicolon introduces a comment) at O are civssreferences. In ibis case we see code cross-references (as opposed to data crossreferences), which indicate that another program instruction transfers control to the location containing the cross-reference comment. Cross-references are the subject of Chapter 9.

For the remainder of the book we will primarily utilize the text display for examples. Well use the graph display only in cases where it may provide significantly more clarity. In Chapter 7 we will cover the specifics of manipulating the text display in order to clean up and annotate a disassembly. 3. A stack Trame (or activation rewixi) isa hlock of mernory, al local ed in a programs runhirite stack, that contains holh the pararnelers passed into a fonction and the local variables declared within the fonction. Stark haines are allocaled upon eniry hue a fonction and released as the fonction exils. Stark frames are discussed in more detail in Chapler 6.

The Functions Window The Fonctions window is used to list every fonction that IDA bas recognized in the database. A Fonctions window entry rnight look like the following:

rualloc	.text	00BDC260 00000180 R	B

This particular une indicates that the malloc fonction can be found in the .text section of the binary at virtual address ooBDC260, is 384 bytes (hex 180) long, returns to the caller (R), and uses the EBP register (B) to reference its local variables. Flags used to describe a fonction (such as R and B above) are described in IDAs built-in help file (or by right-clicking a fonction and choosing Properties. The flags are shown as editable checkboxes in the resulting Properties dïalog). As with other dïsplay windows, double-clicking an entry in the Fonctions window causes the dïsassembly window to jump to the location of the selected fonction.

The Output Window

The Output window ai the bottom of the IDA workspace rounds out the default set of windows that are visible when a new file is opened. The Ouput window serves as IDAs output console and is the place to look for information on tasks IDA is performing. When a binary is first opened, for example, messages are generated to indicate both what phase of analysis IDA is in ai any given time and what actions IDA is carryïng out to create the new database. As von work with a database, the Output window is used to output the status of varions operations that von perform. The contents of the Output window can be copied to the system clipboard or cleared entirely by rïght-clïckïng anywhere in the window and selecting the appropriate operation. The Output window will often be the primary means by whïch von display output [rom any scripts and plug-ins that you develop for IDA.

Secondary IDA Displays

In addition to the dïsassembly, Fonctions, and Output windows, IDA opens a number of other tabbed windows on your IDA desktop. These tabs are present just under the navigation band (see O in Figure 4-9). These windows are used to provide alternate or specialized views into the database. The utility of these displays depends on both the characteristïcs of the binary von are analyzing and your skill with IDA. Several of these windows are sufficïently specïalized to require more detaïled coverage in later chapters.

The Hex View Window

Hex View is something of a misnomer in this case, as the IDA Hex View window can be configured to display a variety of formats and doubles as a hex editor. By default, the Hex View window provides a standard hex dump of the program content with 16 bytes per une and ASCII equivalents displayed alongside. As with the disassembly window, several hex views can be opened simultaneously. The first Hex window is titled Hex l7kw-A, the second Hex View B, the next Hex View C, and so on. By default, the first Hex window is synchronized with the first disassembly window. When a disassembly view is synchronized with a hex view, scrolling in one window causes the other window to scroil to the same location (same virtual address). In addition, when an item is selected in disassembly view, the corresponding bytes are highlighted in hex view. In Figure 5-5, the disassembly view cursor is positioned at address 0040108C, a cail instruction, causing the five bytes that make up the instruction to be highlighted in the Hex window.

In soute cases you may [md that the Hex window shows nothing but question marks. This is IDAs way of telling you that it bas no idea what values might occupy a given virtual address range. Such is the case when a program contains a bss4 section, which typically occupies no space within a file but is expanded by the loader to accommodate the programs static storage requirements.

The Exports Window

The Exports window lists the entry points into a file. These include the programs execution entry point, as specified in its brader section, along with any fonctions and variables that the file exports for use by other files. Exported fonctions are commonly found in shared libraries such as Windows DLL files. Exported entries are lïsted by nourrir, virtual address, and, if applicable, by ordinal number.5 For executable files, the Exports window always contains ai least one entry: the programs execution entry point. IDA naines ibis entry point start. A typical Exports window entry follows:

LoadLibraryA	7C801D77 578

As with many of the other IDA windows, double-clicking an entry in the Exports window willjump the disassembly window to the address assocïated with that entry. The Exports window offers functïonality avaïlable in commandline torils such as objdump (-î), readeif (-s), and dumpbin (/ExP0RTs).

The Imports Window

The Imports window is a counterpart to the Exports window. It lists ail functions that are ïmported by the binary being analyzed. The Imports window is relevant only when a binary makes use of shared libraries. Statïcally lïnked binaries have no external dependencies and therefore no imports. Each entry in the Imports window lists the name of an ïmported item (fonction or data) and the name of the library that contains that item. Since the code for an imported fonction resides in a shared library, the addresses listed with each entry refer to the virtual address of the associated import table entry.' An example of an Import window entry is shown here:

0040E108 GetNloduleHandleA	KERNEL32

The Enums Window

The Enums window is somewhat similar to the Structures window. When IDA detects the use of standard enumerated datatype (C enum), that datatype will be listed in the Enums window. You can make your disassemblies far more readable by using enums in place of integer constants. Like the Structures window, the Enums window offers facilities for deflning your own enumerated types that you can use with your disassembled binaries.

Tertiary IDA Displays

The last windows that we will dïscuss are those that IDA dors not open by default. Each of these windows is available via View > Open Subvïews, but they tend to provide information to whïch you may not require immediate access and are thus initially kept out of the way.

The Strings Window

The Strings window is the buïlt-in IDA equivalent of the strings utïlity and then soute. In IDA versions 5.1 and radier, the Strings window was open as part of the default desktop; however, with version 5.2, the Strings window is no longer open by default, though it remains available via View > Open Subvïews > Strings.

The purpose of the Strings window is to display a lïst of strings extracted from a binary along with the address at which each string resides. Like doubleclicking names in the Names window, double-clicking any string listed in the Strings window causes the dïsassembly window to jump to the address of the selected string. When used with cross-references (Chapter 9), the Strings window provides the means to rapidly spot an interesting string and to track back to any location in the program that references that string. For example, you might see the string SOFTWARE Microsoftl Windows I Current Version IRwi listed and wonder why an application is referencing this particular key within the Windows registry. As you will see in the following chapter, navigating to the program location that references this string takes only four clicks. Understanding the operation of the Strings window is essential to using it effectïvely. IDA dors not permanently store the strings it extracts from a binary. Therefore, every time the Strings window is opened, the entire database must be scanned or rescanned for string content. String scanning is performed in accordance with the settïngs of the Strings window, and you can access these settïngs by right-clicking within the Strings window and selecting Setup. As shown in Figure 5-7, the Setup Strings window is used to specify the types of strings that IDA should scan for. The default string type that IDA scans for is a C-style, null-terminated, 7-bit, ASCII string of at least flve characters in length.

If you expect to encounter anything other than C-style strings, you should reconfigure the Setup Strings window to choose the appropriate string type to search for. For example, Windows programs often make use of Unicode strings, while Borland Delphi binaries use Pascal-style strings with a 2-byte length. Every time you close the Setup Strings window by clicking OK, IDA will rescan the database for strings in accordance with the new settings. Two setup options deserve special mention:

Display only defined strings

This option restrïcts the Strings window to displaying only named string data items that have been automatically created by IDA or manually created by the user. Wïth this option selected, ail other options are disabled, and IDA will not automatically scan for addïtional string content.

Ignore instructions/data definitions

This option causes IDA to scan for strings across instruction and existing data definitions. Using this option allows IDA to (1) see strings that may be embedded in the code portion of a binary and have been mistakenly converted into instructions or (2) to sec strings within data that may be formatted as something other than a string (such as an array of bytes or integers). This option will also lead to the generation of manyjunk strings, which are sequences that happen to consïst of five or more ASCII characters whether or not they are legible. The effect of using this option is similar to using the strings command with the -a switch.

Figure 5-8 demonstrates that IDA durs not necessarily show ail strings within a binary if the strings setup is not confïgured properly. In this case, Ignore instructions/data definitions bas not been selected.

The result is that the string at location rdata : 0040C19C ("Please guess a nom-ber between 1 and %d.") remains undetected. The moral here is to make sure that you are looking for ail of the types of strings you expert to encounter in ail of the places you might [md them.

The Naines Window

The Names window, shown in Figure 5-9, provides a summary listing of ail of the global names within a binary. A naine is nothing more than a symbolic description given to a program virtuai address. IDA initïally derives the iist of names from symbol-table and signature analysis during the initial loading of a flic. Names can be sorted aiphabetïcafly or in virtuai address order (either ascending or descending). The Names window is useful for rapidiy navigating to known locations within a program listing. Double-clicking any Names window entry will ïmmedïately jump the disassembly view to dïsplay the selected name.

Dïsplayed narnes are both color and letter coded. The coding scherne is summarized below:

  • F A regular function. These are functions that IDA dors not recognize as library fonctions.
  • L A library function. IDA recognizes library fonctions through the use of signature-matching algorïthms. If a signature dors not exist for a given library function, the function will be labeled as a regular function instead.
  • I An irnported name, most commonly a function name irnported from a shared library. The difference between this and a library function is that no code is present for an imported name, while the body of a library function will be present in the disassernbly.
  • C Named code. These are named program instruction locations that IDA dors not consider to be part of any function. This is possible when IDA finds a name in a programs symbol table but neyer secs a cail to the corresponding program location.
  • D Data. Narned data locations typïcally represent global variables.

A String data. This is a referenced data location containing a sequence of characters that conform to one of IDAs known string data types, such as a null-terminated ASCII C string.

As you browse through disassemblies, you will notice that there are many named locations for whïch no name is listed in the Narnes wïndow. In the process of disassembling a program, IDA generates narnes for ail locations that are referenced directly eïther as code (a branch or calI target) or as data (read, written, or address taken). If a location is named in the programs symbol table, IDA adopts the name [rom the symbol table. If no symbol table entry is available for a given program location, IDA generates a default name for use in the disassembly. When IDA chooses to name a location, the virtual address of the location is combined wïth a prefix that indicates what type of location is being named. Incorporating the virtual address into a generated name ensures that ail generated narnes will be unique, as no two locations can share the same virtual address. Autogenerated riantes of this type are not displayed in the Names window. Some of the more commun prefixes used for autogenerated names include these:

  • sub_xxxxxx A subroutine at address xxxxxx
  • loc_xxxxxx An instruction location at address xxxxxx
  • byte_xxxxxx 8-bit data at location xxxxxx
  • word_xxxxxx 16-bit data at location xxxxxx
  • dword_xxxxxx 32-bit data at location xxxxxx
  • unk_xxxxxx Data of unknown size at location xxxxxx

Throughout the course of the book we will show additional algorithms that IDA applies in choosing narres for program data locations.

The Segments Window

The Segments window displays a summary listing of the segments present in the binary fie. Note that what IDA terras segments are most often called sections when discussing the structure of binary files. Do not confuse the use of the terra segments in this manner with the memory segments assocïated with CPUs that implement a segmented memory architecture. Information presented in the window includes the segment name, start and end addresses, and permission flags. The start and end addresses represent the virtual address range to whïch the program sections will be mapped at runtime. The following listing is an example of Segments window content from a Windows binary:

Name Start End R W X D L AUgn Base Type Class .40 es ss ds fs gs UPXO 00401000 00407000 R W X L para 0001 public CODE 32 0000 0000 0001 FFFFFFFF FFFFFFFF UPX1 00407000 00408000 R W X L para 0002 public CODE 32 0000 0000 0001 FFFFFFFF FFFFFFFF UPX2 00408000 0040803C R W L para 0003 public DATA 32 0000 0000 0001 FFFFFFFF FFFFFFFF .idata 0040803C 00408050 R W L para 0003 public XTRN 32 0000 0000 0001 FFFFFFFF FFFFFFFF UPX2 00408050 00409000 R W L para 0003 public DATA 32 0000 0000 0001 FFFFFFFF FFFFFFFF

In this case, we mïght quickly suspect that something is funny with this particular binary since it uses nonstandard segment names and bas two executable segments that are wrïtable, thus indicating the possïbïlïty of self -modïfying code (more on this in Chapter 21). The fact that IDA knows the size of a segment does not indicate that IDA knows the contents of the segment. For a variety of reasons, segments often occupy less space on disk than they do in memory. In such cases, IDA displays values for the portions of the segment that IDA bas determined it could fili from the disk file. For the remainder of the segment, IDA displays question marks.

Double-clicking any entry in the windowjumps the disassembly view to the start of the selected segment. Right-clicking an entry provides a context menu from which von can add new segments, delete existing segments, or edit the properties of existing segments. These features are particularly useful when reverse engineering files with nonstandard formats, as the binarys segment structure may not have been detected by the IDA loader.

Command-line counterparts to the Segments window include objdump (-h), readel-f (-s), and dumpbin (/HEADERS).

The Signatures Window

IDA makes use of an extensive library of signatures for ïdentïfying known blocks of code. Signatures are used to identify common compiler-generated startup sequences in an attempt to determine the compiler that may have been used to build a given binary. Signatures are also used to categorize functions as known library fonctions ïnserted by a compiler or as fonctions added to the binary as a resuit of static lïnking. When IDA identifies library fonctions for you, you can focus more of your effort on the code that IDA did not recognize (which is probably far more interesting to you than reverse engineering the inner workings of print-f). The Signatures window is used to list the signatures that IDA bas already matched against the open binary flic. An example from a Windows PE file is shown here:

File	State	#-func Library narne
vc32rt-f AppUed	501	Microsoft VisuaiC 2-8/net runtime

This example indicates that IDA bas applïed the vc32rtf signatures (from dDADIR>/sis) against the binary and, in doing so, bas been able to recognize 501 fonctions as library fonctions. Thats 501 fonctions that you wili not need to reverse engineer!

In at ieast two cases, you wiil want to know how to apply additïonal signatures against your binaries. In the flrst case, IDA may [ail to recognize the compiler that was used to build a binary, with a resulting inability to select appropriate signatures to apply. In this case, you may wish to force IDA to apply one or more signatures that your prehmïnary analysis bas ied you to beheve IDA should try. The second situation invoives creating your own signatures for libraries that may not have existing signatures ïncluded with IDA. An example might be the creation of signatures for the static version of the OpenSSL libraries that ship with FreeBSD 8.0. DataRescue makes a toolkit avaiiable for generating custom signatures that can be used by IDAs signature-matching engine. We'il cover the generation of custom signatures in Chapter 12. Regardless of why you want to apply new signatures, eïther pressing the INSERT key or right-clïckïng the Signatures window wili offer you the Apply new signature option, at which time you can choose from a hst of ail signatures known to your installation of IDA.

The Type Libraries Window

Similar in concept to the Signatures window is the Type Libraries window. Type libraries represent IDAs accumulated knowiedge of predefined datatypes and function prototypes gieaned from header files ïncluded with most popular compilers. By processing header files, IDA understands the datatypes that are expected by common library fonctions and can annotate your disassemblies accordingly. Simïiarly, from these header files IDA understands both the size and layout of complex data structures. AlI of this type information is collected into TIL files (cIDADIR>/tit and apphed any time a binary is anaiyzed. As with signatures, IDA must first be able to deduce the libraries that a program uses belote it can select an appropriate set of TIL files to load. You can request that IDA ioad addïtional type libraries by pressing the INSERT key or by right-clicking within the Type Libraries window and choosing Load type library. Type libraries are covered in more detaïi in Chapter 13.

The Function Calis Window

In any program, a fonction can both call and be called by other fonctions. In fact, it is a fairiy simple task to construct a graph that displays the relationships between callers and caiiees. Such a graph is called a function callgraph or /'wiction rail tree (we will demonstrate how to have IDA generate such graphs in Chapter 9). On occasion, we may not be interested in seeing the entire cail graph of a program; ïnstead, we may be interested only in knowing the immediate neighbors of a given fonction. For our purposes, we will cali Y a neïghbor of X if Y directiy rails X or X dïrectiy cails Y.

The Function Calis window provides the answer to ibis neighbor question. When you open the Function Cails window, IDA determines the neïghbors of the fonction in which the cursor is positïoned and generates a dispiay such as that shown in Figure 5-10.

In this example, we sec that the function named sub 40182c is called frontsix different locations in main and main in turn makes 15 other fonction cails. Double-clicking any line within the Function CalIs window immediately jumps the disassembly window to the selected caliing or called function (or caller and calice). IDA cross-references (xrefs) are the mechanïsms that underhe the generation of the Function CalIs windows. Xrefs will be covered in more detaïl in Chapter 9.

The Problems Window

The Probiems window is IDAs way of informing you of any difflcuitïes that it bas encountered in disassembiing a binary and how it bas chosen to deal wïth those difficuities. In some instances, you may be able to manipulate the disassembiy to heip IDA overcome a probiem, and in other instances you may not. You can expert to encounter problems in even the sïmpiest of binaries. In many cases, simply choosing to ignore the problems is not a bad strategy. In order to correct many of the problems, you need to have a better understanding of the binary than IDA bas, which for trust of us is probably not goïng to happent.