Hex Rays
Hex Rays Blog —  State of the art code analysis

Debugger and process memory

Just a small note about the debugger plugins and events. Many users who try to develop a plugin for the debugger notice that IDA behaves slightly differently in the notification callbacks than anywhere else.

For example, IDA might claim that EIP points to an address without a segment, or none of exported names of a loaded DLL are available.

This happens because of the database synchronization. When you query IDA about a segment or a name, the information from the database is returned. The database is not (and can not be) always in sync with the process memory. The debugged process might allocate or free memory chunks thousands of times per second. The synchronization operation is very expensive: it requires enumerating all memory regions and collecting information about their types, permissions, etc. That’s why IDA tries to perform it as rarely as possible.

We tried to save the end user from this problem: the database gets synchronized as soon as the process is suspended. This is the expected behavior, so far so good.

Alas, we can not provide plugin writers with the same virtual reality: there are two distinct entities, the process memory and the program segmentation. The latter is stored in the database and it can go out of sync with the former. As a plugin writer, you have the following choices:

  • Bypass the database and talk directly to the debugger module using the dbg->read_memory() and dbg->write_memory() functions.
    Advantages: no synchronization issues
    Disadvantages: only memory read/write functions are available, names, functions, and other high level abstractions are not; also, direct calls are not cached.

  • Explicitly synchronize the database with the process memory.
    Advantages: all high level abstractions are available, repetitive “read memory” requests will be cached by the kernel (especially useful for remote debugging); breakpoints in the process memory are hidden
    Disadvantages: slow

  • Do not synchronize.
    Advantages: fast
    Disadvantages: occasionally a call to an IDA function might fail (e.g. getseg() might return NULL for a valid address); nevertheless, this approach can be used if you know in advance that the memory config won’t change or the changes are irrelevant to your analysis

Feel free to use the best method depending on your needs. When you need to force a synchronization, use this:
invalidate_dbgmem_config(); isEnabled(any_address);
Or maybe a better approach exists?.. 😉
Go to top of page