It is important that we begin with an understanding of how the debugger treats your database when you initiate (and terminate) a debugging session. A debugger needs a process image to work with. Debuggers obtain process images either by attaching to existing processes or by creating new processes from executable files. An IDA database does not contain a valid process image, nor in most cases can a valid process image be reconstructed from a database (if one could, then File ▸ Produce File ▸ Create EXE File might be simple to implement). When you launch a debugger session from IDA, the disassembler side informs the debugger side of the name of the original input file, which the debugger uses to create and attach to a new process. Information provided to the debugger includes disassembly formatting, symbol names, data formatting, and any comments that you have entered into the database. An important point to understand is that any patches (changes in byte content) you have applied to your database will not be reflected in the process being debugged. In other words, it is not possible to patch changes into the database and expect to observe the effect of those changes when you launch the debugger.
The opposite holds true as well. When you have finished debugging a process and you return to disassembly mode, by default the only changes that will be reflected in the database are cosmetic in nature (such as renamed variables or functions). Any memory changes, such as self-modified code, are not pulled back into the database for you to analyze. If you wish to migrate any content, such as newly de-obfuscated code, from the debugger back to your disassembly database, IDA will allow you to do so via the Debugger ▸ Take Memory Snapshot command. The resulting confirmation dialog is shown in Figure 25-1.
The default option is to copy loader segments from the running process to the database. Loader segments are those segments that were loaded into the database by the IDA loader module used to create the current database. In the case of an obfuscated program, one or more of these segments probably contain data that has been obfuscated and are therefore nearly impossible to analyze in the disassembler. These are precisely the segments that you will want to copy back from the running process image in order to take advantage of the de-obfuscation work performed by the process running under debugger control.
Selecting All segments causes all segments created by the debugger to be copied back to the database. These segments include the contents of all shared libraries loaded in support of the process as well as additional process-related segments, such as the stack and heap contents.
When the debugger is used to attach to an existing process with no associated database, none of the debugger segments will be flagged as loader segments because the file was not loaded by one of IDA’s loaders. In such cases, you may elect to capture all available segments into a new database. Alternatively, you may elect to edit segment attributes and designate one or more segments as loader segments. Segment attributes may be edited by first opening the Segments window (View ▸ Open Subviews ▸ Segments). Any segment marked as a loader segment will contain an L in the L column of the Program Segmentation window. Right-clicking a segment of interest and selecting Edit Segment opens the segment attributes dialog shown in Figure 25-2.
Selecting the Loader segment checkbox marks the segment as a loader segment and allows it to be copied into the database along with all other loader segments.
The segment attributes dialog is also useful when you have created a process from an open database and wish to add additional loader segments before taking a memory snapshot. For example, if an obfuscated process extracts the original code into a block of memory allocated in the heap (or a memory-mapped block), you will want to mark that memory block as a loader segment before you snapshot memory; otherwise, the de-obfuscated code will not be copied back into your database.