Plugins
Plugins are, of course, new in version 3.84 and offer a massive improvement in extensibility over IDC scripts. To write plugins you must get the IDA SDK, which you need to request specifically. You must also have the appropriate compiler. For the Win32 version of IDA, you need Borland C++ 5.02 (5.01 may work -- I'd be interested to here from anyone who's tried any version of C++ Builder). For DOS and OS/2, you need the Watcom compiler. Almost everything on this page will page be aimed at the Win32 version of IDA, so I'll only discuss Borland issues (sorry). You must have a Borland compiler because, among other reasons, IDA.WLL uses the Borland fastcall calling convention which no other compiler (as far as I know) supports.
Tips for writing plugins
Setting up the Build Environment
The Plugins
A new version of search for immediate
IDB to SIG - Create signature files directly out of an IDA database
Setting up the Build Environment
Ok, I'll try to make this easy, but what you really need to do is familiarize yourself with the format and syntax of Borland makefiles.
First of all, you need to set a couple of environment variables:
- IDA
This needs to be set to the root SDK directory. For example, c:\ida\sdk.
- BC501
This needs to point to your Borland root directory. It doesn't matter if you actually have version 5.02, the IDA makefiles still look for this environment variable.
Here are the main files which need to be editied:
- /w32bor.cgf
You need to edit the library and include paths at the very beginning of the file to point to your bc5/include dir, your IDA include dir, and the corresponding library include directories. It is probably not a good idea to edit anything else in this file.
- /plugins/plugins.mak
This is the plugin specific makefile. It only needs to be edited you plan to put the source for your plugins anywhere other than in /plugins. If you do that (as I do) then you need to edit the following lines:
$(BINARY): ..\plugin.def $(OBJS) $(IDALIB)
should be made relative to the dir specified in the IDA env variable:
$(BINARY): $(IDA)plugins\plugin.def $(OBJS) $(IDALIB)
option stub=..\stub.
should be changed in a similar manner:
option stub=$(IDA)plugins\stub.
..\plugin.def
again, same deal:
$(IDA)plugins\plugin.def
That should be all that needs to be changed in this file.
Using the Standard Template Library in Plugins
Borland C++ comes with the Rogue Wave implementation of the Standard Template Library. At first I thought it wouldn't really be possible to use STL in plugins because I was sure there would some sort of incompatibility between what STL needs and what Ilfak has in his include/makefile madness. However, it works, but there's a trick to it. First, you have to include the STL headers after any IDA headers. Second, you should use the new include style (no .h extension) to make sure that all the standard library stuff stays in the std namespace. This, of course, means that references to standard lib types must be qualified with std::. Third, you need to #define __NOT_ONLY_PRO_FUNCS__ before including the IDA headers to keep IDA from shutting off access to some C standard lib functions needed by STL. Finally, you should include <vector> before any other STL headers. This isn't strictly speaking necessary, but there are some headers that <vector> includes that are necessary so that <map>, etc. don't screw up on a redefinition of ios, istream, and ostream. I haven't tried to sort out the exact cause of this yet. It appears to be a Rogue Wave problem. Anyway, icluding <vector> first does the trick. To see all of this in action, check out my IDB to SIG plugin.
If you have it, Multi-Edit is a great editor to use as an IDE for writing IDA plugins. Besides being wonderfully configurable, it allows you to build a project directly from the editor and to jump to compiler errors quickly and easily. <I'll finish the configuration info soon ...>
A new version of search for immediate
I have always found IDA's built-in search-for-immediate frustrating. Suppose you are looking all references to a certain Windows resource ID which is number 0x20. What you're really interested in are cases where 0x20 is either moved into a register or pushed on to the stack. You're not interested in instructions like mov edx, [eax+20h]. What this plugin does is find only those instructions where the value is looking for is referenced as a true immediate. It implements both search (plugin arg = 0) and search again (plugin arg = 1).
I'm calling this v0.5 beta even it seems fairly stable (and is not that complicated) I'd like to add some extensions that will make it much more useable. I hope a new version will be ready soon.
IDB to SIG - Create signature files directly out of an IDA database
This is a rewrite of something I originally did in IDC (check the IDC page). It creates a pattern (.PAT) file for a function or set of functions in an IDA database. The file can then be fed through SIGMAKE.EXE (found in the FLAIR package) to create a useable IDA signature file. This has several uses. One of the most significant is that it can be used to transfer function names from a database of an older version of a file to a database for a newer version. I have in fact used it to successfully transfer function names from a disassembly of IDA.WLL version 3.75 to IDA.WLL version 3.84. Naturally, it will only find those functions which have not changed (or at least have not changed much - the actual sig algorithm is a thing of great mystery to me). It can also be used to create a sig file for a particular set of code for which have no lib or obj files.
The plugin has three basic modes of operation. It can generate a pattern for all user defined functions in the database (plugin arg = 0), for all entry point functions (useful for dlls - plugin arg = 1), and for the current function (the one the cursor is sitting in - plugin arg = 2).
There be some bugs still in it, although it's worked wuite a few times for me. Please let me know if you find any. I also have some ideas for improvements, which I hope to implement soon. If you have any ideas, please send me an email.