CROSS-REFERENCES AND GRAPHING : Différence entre versions

De Wiki expérimental
(Page créée avec « Some of the more common questions asked vhile reverse engineering a hinary are along the unes of "Where is this function called from?" and "What fonctions access this data... »)
(Aucune différence)

Version du 16 août 2019 à 01:39

Some of the more common questions asked vhile reverse engineering a hinary are along the unes of "Where is this function called from?" and "What fonctions access this data?" These and other similar questions seek to catalog the references to and from various resources in a program. Two examples serve to show the usefulness of such questions.

Consider the case in which you have located a function contaïning a stackallocated buffer that can be overflowed, possïbly leading to exploitation of the program. Since the function may be buried deep within a complex application, your next step mïght be to determine exactly how the function can be reached. The function is useless to you unless you can get it to execute. This leads to the question What functions caIl this vulnerable function?" as well as addïtional questions regarding the nature of the data that those fonctions may pass to the vulnerable function. This une of reasoning must continue as you work your way back up potential cail chains to [md one that you can influence to properly exploit the overflow that you have discovered.

In another case, consider a binary that contains a large number of ASCII strings, at least one of which you [md suspicious, such as "Executing Denial of Service attack!" Does the presence of this string indicate that the binary actuaiiy performs a Denial of Service attack? No, it simpiy indicates that the binary happens to contain that particular ASCII sequence. You might infer that the message is displayed somehowjust prior to launching an attack; however, you need to find the related code in order to verify your suspicions. Here the answer to the question "Where is this string referenced?" would help you to quickly track down the program location (s) that make use of the string. Front there, perhaps it can assist you in locating any actual Denial of Service attack code.

IDA helps to answer these types of questions through its extensive crossreferencing features. IDA provides a number of mechanisms for displaying and accessing cross-reference data, including graph-generatïon capabilities that provide a highly visual representation of the relatïonships between code and data. In this chapter we dïscuss the types of cross-reference information that IDA makes available, the tools for accessing cross-reference data, and how to interpret that data.


We begin our discussion by noting that cross-references within IDA are often referred to simply as xrefs. Within this test, we will use xrefonly where it is used to refer to the content of an IDA menu item or diaiog. In ail other cases we will stick to the term cross-reference. There are two basic categories of cross-references in IDA: code cross-references and data cross-references. Within each category, we will detail severai different types of cross-references. Assocïated with each cross-reference is the notion of a direction. AIl cross-references are made front one address to another address. The [rom and to addresses may be either code or data addresses. If you are familiar with graph theory, you may choose to think of addresses as nodes in a directed graph and cross-references as the edges in that graph. Figure 9-1 provides a quick refresher on graph terminology. In this simple graph, three nodes O are connected by two directed edges O.

Note that nodes may also be referred to as vertices. Directed edges are drawn using arrows to indicate the allowed direction of travel across the edge. In Figure 9-1, it is possible to travel front the upper node to either of the lower nodes, but it is not possible to travel [rom eïther of the lower codes to the upper ourle.

Code cross-references are a very important concept, as they facilitate IDAs generation of controlflowgraphs and fwiction rail graphs, each of which we discuss later in the chapter. Belote we dive into the detaïls of cross-references, it is useful to understand how IDA dïsplays cross-reference information in a disassembly listing. Figure 9-2 shows the brader line for a disassembled fonction (sub_401000) containing a cross-reference as a regular comment (right side of the figure).

int main() {
int p = &reT_it	//results in an 'offset style data reference
= read_it	//results in a "read' style data reference
write_it =	//results in a 'write' style data reference
callflowO;	//results in a "cali' style code reference
if (read_it == 3) { //results in "jump style code reference
write_it = 2;	//results in a "write" style data reference
else {	//results in an "jump" style code reference
write_it = 1;	//results in a "write" style data reference
callflowO;	//results in an "cail" style code reference

The program contains operations that will exercise ail of IDAs crossreferencing features, as noted in the comment text.

An ordinaryflowis the sirnplest flow type, and it represents sequential flow from one instruction to another. This is the default execution flow for A nonbranching instructions such as ADD. There are no special dïsplay mdicators for ordinary fiows other than the order in whïch instructions are hsted in the disassernbly. If instruction A has an ordinary flow to instruction B, then instruction B wili imrnedïateiy foilow instruction A in the disassernbiy listing. In the following listing, every instruction other than O and O has an associated ordinary flow to lis immediate successor: