Table of contents:
IDAPython script/processor module writers should have a look at least at the following sections:
IDA 7.0 consists of
x86_64 binaries (as opposed to all previous versions,
which consisted of
i386 binaries). This has the very unfortunate
side-effect that all existing binary plugins will stop working.
Thus, since ABI compatibility is gone and therefore those binary plugins would require recompiling, we decided that now would be a perfect time to perform a much-needed API cleanup:
Binary plugin authors will not only have to recompile: first, a small porting effort will be needed in order to adapt to the new, cleaned-up API.
The situation, however, is very different for IDAPython script/plugin
authors: the exact architecture of the platform where IDA runs (i.e.,
i386) is (mostly, at least) irrelevent to them.
Consequently, we decided we would provide a compatibility layer, that maps the 'old' 6.95 APIs, to the new 7.0 ones, in order to ease the adoption of IDA 7.0 in as many cases as possible.
Backward-compatibility is provided by python.cfg's
When that directive is set to
YES, additional code will be loaded
into IDAPython, providing mappings for the older function names, classes,
With that directive turned on, existing scripts should just work. If that isn't the case, please contact us on [email protected] and we'll try our best and fix IDAPython so that it covers your use-case.
This is not, however, a viable & long-term solution:
AUTOIMPORT_COMPAT_IDA695 directive is turned on by default, which
means that existing scripts should work.
When some time has passed, a later release of IDA will ship with
AUTOIMPORT_COMPAT_IDA695 set to
NO by default.
Of course, users can still turn it back on, but that will at
least hint the user that something might require attention.
After some time (it's difficult to provide a time frame, here. We'll have to see how things go), we'll simply remove the backward-compatibility code. It will then be impossible for scripts that were not ported to function.
If your script(s) is(are) meant to work with IDA 7.0 onwards, it might be a good idea to port them as soon as possible.
The modifications should be (in almost all cases) trivial, since many API changes consist of function, types & constants renaming.
Please have a look at the 6.95 → 7.0 API guide for information about that renaming.
A very good test to test whether your scripts have been
properly ported, is to set
NO,restart IDA, and try your scripts again.
The best course of action here is to simply set to
NO from the beginning, and
write your script/plugin directly with the new API.
We did what was reasonably feasible, to provide an IDAPython API that's as backward-compatible as possible with the IDA 6.95 API
However, we considered it unreasonable for some parts of the API to be ported. Most notably:
module/script/proctemplate.py(or any other
*.pyfile in that directory) for examples how to use the new API.
Most (all?) of the renamed functions, constants, etc... should be
covered, in all modules:
If something doesn't work/isn't there anymore, it's likely an omission from our side. In that case, please let us know about any missing bits & pieces, that you believe should be there and that we might have forgotten!