General principles

OllyDbg Plugin API

General principles

Welcome. OllyDbg v1.10 is the final version. I decided to stop its development. This does not mean that OllyDbg is dead - currently I'm preparing v2.0 - but new version will be incompatible with v1.xx, at least what concerns plugins. Sorry, but this is the only possible solution.

This documents describes OllyDbg Plugin API v1.10. There are no significant changes in interfaces or in structures, so plugins compiled for OllyDbg 1.06 or 1.08 will usually work with OllyDbg 1.10. The only changes that may be not 100% backward-compatible are limited to:

-Structures t_reg and t_bpoint are extended;

-New option "Always on top" requires special support from plugin windows;

-Function Browsefilename supports Save File dialog;

Plugin is a DLL that resides in OllyDbg directory and adds functionality to OllyDbg. You are free to write and distribute your own plugins, provided that they are free, too. (See License Agreement for details). On your request, I am ready to place such plugins for download on my home page. Commercial plugins are also allowed, but in this case you need special license.

To co-operate, different plugins require unique names, .udd tags, nametypes and so on. If you need some of these resources, please contact me. This service is absolutely free for you!

During startup, OllyDbg loads all available DLLs one by one and looks for entry points named _ODBG_Plugindata and _ODBG_Plugininit. If these entries are present and plugin reports compatible interface version, OllyDbg registers plugin and adds entry or submenu to Plugins popup in the main OllyDbg menu.

Plugins can add menu items to Disassembler, Dump, Stack, Registers, Memory, Modules, Threads, Breakpoints, Watches, References, Windows and Run trace windows. They can intercept both global shortcuts and shortcuts from one of the listed windows. They also can create own MDI windows. Plugins can write plugin-specific data to .udd files with module-dependent information and ollydbg.ini and access different data structures that describe debugged application. There are several (in general, optional) callback functions that allow easy but close interaction with OllyDbg. Additionally, plugins may call more than 170 plugin API functions.

Plugin interface is not object-oriented. Perharps this will come as surprise to you, but all my experience tells me that OOP is not as good as main software vendors try to sell. It is really good if you write small application performing standard functions. For a big weird project (and OllyDbg is a big weird project) OOP gives no real improvements in development time, errors in components are very hard to locate and even harder to correct. And - contrary to what vendors tell us - OO programs are usually slow. Stop crying, this is only my opinion, albeit proved by all my experience in the last 15 years or so. Anyway, try to swallow that you will get no ready-to-use objects here and are doomed to free memory by yourself when plugin terminates.

Plugin API is not re-entrant and does not implement critical sections. If your plugin creates new thread, don't call API functions from this thread, otherwise you risk to corrupt internal data structures and crash both program and OllyDbg!

Some exported API functions are not described here. Their direct use may bring OllyDbg in unstable state. I have added them for better compatibility with future versions of plugin interface.

See also: Compilation