IDA v5.1 introduces the notion of dynamic colors. Plugins can install a callback which dynamically calculates colors and provides them to the user interface. In the previous versions of IDA plugins were forced to change the item color in the database thus overwriting any user-defined colors. The new IDA makes it possible to calculate colors on the fly.

Another news is that the navigation band colors are dynamic too. Just install a colorizer for the navigation band using the ui_set_nav_colorizer event and IDA will ask your plugin to supply item colors.

Plugins can also provide their own hints (on the mouse hovering) instead of the default hints displayed by IDA. There are even several different hint callbacks: they differ in complexity. You can start with simple get_ea_hint for single line hints, then switch to ui_get_item_hint for multiline hints and finally you can use the ui_get_custom_viewer_hint event for hints in any customazible window.

The last event belongs to the group of custom_viewer events. This group can be used to create and display a window like the disassembly window (colored lines with virtualized access to the data). Some other windows in IDA use custom_viewers: structures and enumerations are two notable examples. Now you can create your own custom windows. The set up is quite complex and will require another post.

Meanwhile enjoy a new plugin which uses the dynamic coloring feature. The plugin is named Olden because it "ages" the listing by modifying the background color of the instruction under the cursor. This way you leave a "trail" after you. I find this plugin especially useful to debug huge applications. It is extremely easy to get lost in the debugged code but with this plugin, you will at least be able to exclaim: "I've been here before!" :)

The plugin works with IDA v5.1. As usual, it comes with full source code:

http://www.hexblog.com/ida_pro/files/olden.zip Have fun! :)

Posted by Ilfak Guilfanov at 07:02 PM | Permalink | Comments (5)

Ever tried to run many instances of IDA simultaneously? I mean, not only one or two, but much more, tens of them at the same time? Not everyone needs it but sometimes a whole directory must be analyzed. Imagine you have created a plugin which finds something interesting in binaries...

Owners of multi-core multi-processors systems would want to use the full potential of their processors for such volumnious analyses. Since IDA is not multithreaded yet and won't be in the near future, the only way to parallelize the analysis is to disassemble several files at once.

Before v5.1, if you tried to launch many copies of IDA from a batch file or a script, you would eventually get strange error messages. For example, IDA could complain about the registry access failures. The new version can handle as many copies as you want, up to the system limit. Click here to download a movie of 25 copies of IDA launched simultaneously.

A frequent question related to the batch analysis: which version of IDA is the best to run in the batch mode?

IDA comes with the text and graphical user interface versions. While all of them support the -B, -A, and -S switches, there are subtle differences regarding the resource allocation. When you have half a dozen of IDAs running on the system, you want to reduce it.

At first sight, the text version should require less resources than the gui version. This is true, the VCL library creates several hundred widgets while the text version needs only a text window.

However, it is possible to run idag.exe so that it won't create even a single window. The -B switch does exactly this. This way the gui version turns out to be better.

If you need to analyze many files with your own plugin, then you can not use the -B switch. Use a combination of -A and -S in this case:

idag -A -Smyscript.idc input_file

The contents of myscript.idc could look like this:

static main()
{
  RunPlugin("myplugin", 0); // run myplugin with argument 0
}

The script specified in the -S switch is executed immediately when the database is opened. At this point the user interface has not initialized itself yet. If your plugin closes IDA at the end, the interface will never be initialized, saving you both memory and processor time.

Another solution would be to use the PLUGIN_FIX flag in the plugin description but this method would require you to install a hook and wait for the database to be opened.

Posted by Ilfak Guilfanov at 09:52 PM | Permalink | Comments (6)