On batch analysis

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.