A .map file describes the overall layout of a binary, including information about the sections that make up the binary and the location of symbols within each section. When generating a .map file, you are asked for the name of the file you wish to create and the types of symbols you would like to store in the .map file. Figure 14-5 shows the MAP file options dialog, in which you select the information you wish to include in the .map file.

Figure 14-5. MAP file-generation options

Address information in a .map file is represented using logical addresses. A logical address describes a symbol’s location using a segment number and a segment offset. The first few lines of a simple .map file are shown in the following listing. In this listing we show three segments and the first two of many symbols. The logical address of _fprintf indicates that it resides at byte offset 69h within the first (.text) segment.

Start         Length     Name                   Class
 0001:00000000 000008644H .text                  CODE
 0002:00000000 000001DD6H .rdata                 DATA
 0003:00000000 000002B84H .data                  DATA

  Address         Publics by Value

 0001:00000000       _main
 0001:00000069       _fprintf

MAP files generated by IDA are compatible with Borland’s Turbo Debugger. The principle purpose of .map files is to assist in restoring symbol names when debugging binaries that may have been stripped.

IDA can generate a .asm file from the current database. The general idea is to create a file that could be run through an assembler to re-create the underlying binary file. IDA attempts to dump enough information, including such things as structure layouts, to make successful assembly possible. Whether you will be able to successfully assemble the generated .asm file depends on a number of factors, not the least of which is whether your particular assembler understands the syntax IDA uses.

The target assembly language syntax is determined by the Target assembler setting found on the Analysis tab under the Options ▸ General menu. By default IDA generates an assembly file representing the entire database. However, you may limit the scope of the listing by clicking and dragging or using shift-up arrow or shift-down arrow to scroll and select the region you wish to dump. In console versions of IDA, you would utilize the Anchor (alt-L) command to set an anchor point at the start of a selection region and then use the arrow keys to extend the size of the region.

An INC (include) file contains definitions of data structures and enumerated datatypes. This is essentially a dump of the contents of the Structures windows in a form suitable for consumption by an assembler.

An LST file is nothing more than a text file dump of the contents of the IDA disassembly window. You can narrow the scope of the generating listing by selecting a range of addresses to dump, as described previously for ASM files.

While this is the most promising menu option, it unfortunately is also the most crippled. In a nutshell, it doesn’t work for most file types, and you can expect to receive an error message stating, “This type of output file is not supported.”

While this would be an ideal capability for a patcher, in general it is very difficult to regenerate executable files from an IDA database. The information that you are presented with in an IDA database is comprised primarily of the contents of the sections that make up the original input file. In many cases, however, IDA does not process every section of an input file, and certain information is lost when the file is loaded into the database, making generation of an executable from the database impossible. The simplest example of such loss is the fact that IDA does not load the resource (.rsrc) section of PE files by default, which makes restoration of the resource section from the database impossible.

In other cases, IDA processes information from the original binary but does not make it easily accessible in its original form. Examples include symbol tables, import tables, and export tables, which would require a fair amount of effort to properly reconstruct in order to generate a functional executable file.

One effort to provide an EXE-generation capability for IDA is the pe_scripts^[93] of Atli Mar Gudmundsson. These are a set of IDA scripts for working with PE files. One of the scripts is titled pe_write.idc, and its goal is to dump a working PE image out of an existing database. If you intend to patch a PE file, the proper sequence of events for using the scripts is as follows:

Scripting with IDC is the subject of Chapter 15.

An IDA DIF file is a plaintext file that lists all bytes that have been modified within an IDA database. This is the most useful file format if your goal is to patch an original binary based on changes made to an IDA database. The format of the file is quite simple, as shown in the example .dif file here:

This difference file is created by The Interactive Disassembler

dif_example.exe
000002F8: 83 FF
000002F9: EC 75
000002FA: 04 EC
000002FB: FF 68

The file includes a one-line header comment followed by the name of the original binary file and then a list of bytes within the file that have changed. Each change line specifies the file offset (not virtual address) of the changed byte, the original value of the byte, and the current value of the byte within the database. In this example, the database for dif_example.exe has been modified at four locations corresponding to byte offsets 0x2F8–0x2FB within the original file. It is a trivial task to write a program to parse IDA .dif files and apply the changes to the original binary file to generate a patched version of the binary. One such utility is available at the companion website for this book.^[94]

IDA takes advantage of the markup capabilities available with HTML in order to generate colorized disassembly listings. An IDA-generated HTML file is essentially an LST file with HTML tags added to produce a listing that is colored similarly to the actual IDA disassembly window. Unfortunately, the generated HTML files do not contain any hyperlinks that would make navigating the file any easier than if one used a standard text listing. For example, one useful feature would be the addition of hyperlinks to all name references, which would make following name references as simple as following a link.