idapython/src

IDAPython project for Hex-Ray's IDA Pro

IDAPython

Python plugin for Interactive Disassembler

IDAPython is an IDA plugin which makes it possible to write scripts for IDA in the Python programming language. IDAPython provides full access to both the IDA API and any installed Python module.

Check the scripts in the examples directory to get an quick glimpse.

Availability

Latest stable versions of IDAPython are available from https://github.com/idapython/src

Resources

The full function cross-reference is readable online at https://www.hex-rays.com/products/ida/support/idapython_docs/

Mailing list for the project is hosted by Google Groups at https://groups.google.com/g/idapython

Installation from binaries

1. Install latest Python 3.x version from https://www.python.org/
2. Copy the whole "python" directory to %IDADIR%
3. Copy "idapython.cfg" to %IDADIR%\cfg

Usage

• Run script: File / Script file (Alt+F7)
• Execute Python statement(s) (Shift+F2)
• Run previously executed script again: View / Recent Scripts (Alt+F9)

Batch mode execution:

Start IDA with the following command line options:

 -A -OIDAPython:yourscript.py file_to_work_on

or

-Syourscript.py

or

-S"yourscript.py arg1 arg2 arg3"

(Please see https://hex-rays.com/blog/running-scripts-from-the-command-line-with-idascript/)

If you want fully unattended execution mode, make sure your script exits with a qexit() call.

By default scripts run after the database is opened. Extended option format is:

  -OIDAPython:[N;]script.py

Where N can be: 0: run script after opening database (default) 1: run script when UI is ready 2: run script immediately on plugin load (shortly after IDA starts and before processor modules and loaders)

User init file

You can place your custom settings to a file called idapythonrc.py that should be placed to

${HOME}/.idapro/

or

%AppData%\Hex-Rays\IDA Pro

The user init file is read and executed at the end of the init process.

Please note that IDAPython can be configured with idapython.cfg file.

Invoking Python from IDC

The IDAPython plugin exposes a new IDC function exec_python(string python_code) that allows execution of Python code from IDC.

Invoking IDC from Python

It is possible to use the idc.eval_idc() to evaluate IDC expressions from Python.

Switching the default language between Python and IDC

By default, IDA will use IDC to evaluate expressions in dialog boxes and in eval_expr().
It is possible to change the default language to Python.

In order to do that, use the following (IDC/Python) code:

load_and_run_plugin("idapython", 3)

To go back to IDC, use the following code:

load_and_run_plugin("idapython", 4)

src's Issues

Hardcoded value without any reference, use ida_dbg.DSTATE_SUSP instead

https://github.com/idapython/src/blob/caeafef297371eae1c929845385dbe5d859abade/examples/debugging/show_debug_names.py#LL19C22-L19C22

The code is much clearer in what is actually happening:
if ida_dbg.get_process_state() != ida_dbg.DSTATE_SUSP:

May I also ask why you are not using ida_dbg.dbg_can_query() instead of checking both for loaded and suspended ?

No module named IMP

No module named IMP error on Pycharm 3.12 since it was removed.

error in idaapi.as_int32

There seems to be an error here.

Python>idaapi.as_int32(0) == 0
False
Python>idaapi.as_int32(0) == idaapi.as_signed(0, 32)
False
Python>idaapi.as_signed(0, 32) == 0
True
Python>idaapi.as_int32(0)
-0x100000000

Linux build error: process 'make' returned non-zero exit status 2

In the final step of the build process, I got this error (formerly line 58 of build.py- where subprocess.check_call is called)

make: *** [../../allmake.mak:806: obj/x64_linux_gcc_32_opt/idapython.o] Error 1
Traceback (most recent call last):
File "/home/dry/IDA/idasdk75/plugins/idapython/build.py", line 60, in run
subprocess.check_call(proc_argv, env=full_env)
File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['make']' returned non-zero exit status 2.

Any idea what error 2 stands for and how to resolve this? I followed all steps pretty much exactly.

Can you not change the value of a multiline StringInput?

Edit: Got confused because StringLabel and StringInput are separate, but Form.MultiLineTextControl supports InputControl, so it works now!

I have no issue with the normal StringInput, but when I use Form.FT_MULTI_LINE_TEXT, I am unable to set the value at any time.

First I tried to set the initial value of the input

'iPrompt': Form.StringInput(value="test", tp=Form.FT_MULTI_LINE_TEXT),

Which results in an empty box

Then I tried this, which does nothing

self.iPrompt.value = "test"

and

self.iPrompt.text= "test"

and in a form change action also does nothing:

self.SetControlValue(self.iPrompt, "test")
self.RefreshField(self.iPrompt)

I was unable to find a single example in the IDA docs or Github search or Google search. Is it just not supported? I am using IDA Pro 7.7 by the way.

How do I get it jmp parameters

call get_arg_addrs can be used

jmp How to get it

Press the Tab key

I'd like to get 13 arg

IDApython for IDA8.3

My IDA8.3 cannot find the python plugin. Can you tell me how to do it?

Exposing the 'debug' variable from kernwin.hpp

Hex-Rays, since you control the SDK, in kernwin.hpp, it would be nice if you simply move this:

#ifndef SWIG
//---------------------------------------------------------------------------
//      D E B U G G I N G   F U N C T I O N S
//---------------------------------------------------------------------------

/// Controls debug messages - combination of \ref IDA_DEBUG_
idaman uint32 ida_export_data debug;

/// \defgroup IDA_DEBUG_ IDA debug bits
/// used by ::debug
//@{
#define IDA_DEBUG_DREFS         0x00000001      ///< drefs
#define IDA_DEBUG_OFFSET        0x00000002      ///< offsets
...

Just after the debug and its subsequent IDA_DEBUG_XXXX flags.

There’s no reason to exclude ‘debug’, since you had no reason to exclude both ‘errorexit’ and ’batch’ from kernwin.hpp.

‘debug’ and its defines are equally handy for IDAPython and C++.

Can you please update kernwin.hpp for next release, so we get debug in IDAPython?

ida_idp.set_processor_type causes internal error 1391

Calling ida_idp.set_processor_type("metapc", SETPROC_LOADER) after startup with no IDB open, it won't set the default type but cause an internal error 1391.

The error occurs on IDA Pro 8.3.

FindInstructions.py IDA6.9

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "../idapython/Scripts/FindInstructions.py", line 134, in find
    c.choose()
  File "..\IDA 6.9\python\idaapi.py", line 49405, in choose
    self.icon)
TypeError: in method 'choose_choose', argument 1 of type 'void *'
Script Default snippet error: Traceback (most recent call last):
  File "<string>", line 45, in <module>
  File "..\IDA 6.9\python\idaapi.py", line 49405, in choose
    self.icon)
TypeError: in method 'choose_choose', argument 1 of type 'void *'

Python3 str does not have .decode(), this will cause the idaapi.has_mbcs to always be False

https://github.com/idapython/src/blob/d34bb4b45a4b862d9af992e30220e9c344834ce3/pywraps/py_idaapi.py#LL407C10-L407C10

There are some .decode() that will fail on Python 3.

doExtra does not exists

I am using idapython 1.7.2. When I execute ExtLinA, the command line reports AttributeError: 'module' object has no attribute 'doExtra'.

Python 3.12 has removed "imp"

src/tools/dumpdoc.py

Line 17 in 6142005

import imp

fails since

The imp module has been removed. (Contributed by Barry Warsaw in gh-98040.)

Source: https://docs.python.org/3.12/whatsnew/3.12.html

The same also for

src/tools/inspect.py

Line 635 in 6142005

import imp

how can i get all exported functions?

we can see functions in IDA pro like this:

__int64 __fastcall mallopt(int a1, unsigned int a2)
{
...
}

Is there any way we can use a python script to get all functions from an ELF and dump them in a log file in that format?

examples/analysis/dump_func_info.py does dumps something but i don't need.

self.header refers to the method and not the property

src/python/idautils.py

Line 747 in df6fcff

return "peutils_t(imagebase=%s, header=%s)" % (hex(self.imagebase), hex(self.header))

Gives the error:
File \IDA\python\3\idautils.py:747, in peutils_t.str(self)
746 def str(self):
--> 747 return "peutils_t(imagebase=%s, header=%s)" % (hex(self.imagebase), hex(self.header))

TypeError: 'method' object cannot be interpreted as an integer

There is a properry with the same name, I suggest renaming either the property or of the method.

how to change and set color for edge in python class GraphViewer ?

how to change and set color for edge in python class GraphViewer ?

SetNodeInfo(self, node_index, node_info, flags) ?

p = ida_graph.node_info_t()
p.frame_color = self.random_hex_color()
p.bg_color = p.frame_color^0xffffff
self.SetNodeInfo(nid, p, ida_graph.NIF_FRAME_COLOR)

but edge is not node

get_tev_reg_mem not in idaapi.py

Calling idc.GetTevRegMem() leads to this error:

File "/opt/ida-6.9/python/idc.py", line 8332, in GetTevRegMem
return idaapi.get_tev_reg_mem(tev, idx)
AttributeError: 'module' object has no attribute 'get_tev_reg_mem'

I took a look in to the idaapi.py and indeed, the corresponding function is not there.
Is this a hexrays issue?

ida_dbg.set_manual_regions()

I am looking for a documentation on ida_dbg.set_manual_regions(), it seems it's exposed since 7.3 but not documented so far. Is there any hint on how to use it right and how it differs from simply creating segments?

Reference: https://hex-rays.com/products/ida/support/idapython_docs/ida_dbg.html#ida_dbg.set_manual_regions

Python demangling does not ignore postfix _nn

demangle_name always return None and get_ea_name, get_long_name, and get_name always return the unmangled name because of the postfix (.12345 or _1234) but names demangle fine in hex rays pseudocode since there is the "ignore postfix _nn" option in the settings.

print(idc.demangle_name("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128", idc.get_inf_attr(idc.INF_SHORT_DN)))
None
print(idc.demangle_name("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128", idc.get_inf_attr(idc.INF_LONG_DN)))
None
print(idc.demangle_name("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128", idc.INF_LONG_DN))
None
print(idc.demangle_name("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128", idc.INF_SHORT_DN))
None
print(idc.demangle_name("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128", idaapi.cvar.inf.long_demnames))
None
print(idaapi.demangle_name("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128", idaapi.cvar.inf.long_demnames))
None
print(idaapi.demangle_name("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128", idaapi.cvar.inf.short_demnames))
None
idaapi.get_ea_name(ea, ida_name.GN_SHORT|ida_name.GN_DEMANGLED)
_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128
idaapi.get_ea_name(ea, ida_name.GN_LONG|ida_name.GN_DEMANGLED)
_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128

idc.get_name(ea, ida_name.GN_VISIBLE|idaapi.GN_DEMANGLED)
_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE_331187_100128

idc.get_long_name(ea, ida_name.GN_VISIBLE|idaapi.GN_DEMANGLED)
_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE_331187_100128

Hex Rays Pseudocode:
jag::graphics::FOGDISTANCE_DEFAULT

It requires manually removing the suffix with a custom function if you want it to actually demangle:

import re

def remove_mangled_postfix(symbol_name):
    # Remove suffixes with periods
    if "." in symbol_name:
        return symbol_name.split('.')[0]
    
    # Remove suffixes with underscores
    return re.sub(r'_[\d+_]+$', '', symbol_name)

print(idaapi.demangle_name(remove_mangled_postfix("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE.331187.100128"), idaapi.cvar.inf.long_demnames))
jag::graphics::FOGDISTANCE_DEFAULT

print(idaapi.demangle_name(remove_mangled_postfix("_ZN3jag8graphicsL19FOGDISTANCE_DEFAULTE_331187_100128"), idaapi.cvar.inf.long_demnames))
jag::graphics::FOGDISTANCE_DEFAULT

But I feel that this shouldnt be necessary. All of the mangled symbols are going to have these suffixes since different signatures can generate the same mangled name. And this is only going to work on G++/GCC/itanium symbols. What if it were a different type of mangling? The remove_mangled_postfix would need special cases for all other mangling standards.

Surely other IDA plugins are not jumping through this extra hoop? Am I doing something wrong?

py_get_numbered_type: badly-formed utf-8 being stored within a type can result in a UnicodeDecodeError on Py3.

So, I encountered a strange issue with the local types api. I'm not doing anything too special other than using the tinfo_t class which seems to require serialization/deserialization with some parts of it. The tinfo_t.serialize method facilitates this by returning a tuple containing the components that can then be used with tinfo_t.deserialize and specifically the ida_typeinf.get_numbered_type functions.

If I'm recalling correctly, during the Py2<->Py3 transition, the tinfo_t.serialize method seemed to have changed which required you to specially handle parts of the tuple that is returned. Specifically, the "cmt" fields were being returned as strings (str) whereas all of the APIs that use them expect them to be bytes. I've been working around this via a simple type-check and then encoding it when a str is received.

However, one of the types residing in an old database that I have seems to have gotten a non-utf8-encoded string assigned as one of these fields. This causes an issue with the ida_typeinf.get_numbered_type function in IDAPython as it immediately raises an instance of the UnicodeDecodeError exception due to being unable to properly decode its fields.

I'm not sure of the original cause (and it's likely user-error), but it's an easy thing to fix within a database. Still, I noticed that the ida_typeinf.get_numbered_type has become completely worthless as a result of this. It's significance is increased as ida_typeinf.get_numbered_type is the only way to get a local type via its ordinal number. So, if somebody shoots themselves in the foot (on purpose or by accident) and stashes a non-utf8 string as one of the type's fields, the type will have to be completely removed and re-created in order to access via this IDAPython API.

Anyways, the ida_typeinf.get_numbered_type function is bound to the following code. This function, py_get_numbered_type, does an implicit string conversion to UTF-8 as a result of the line at 603 where "ssi" is used as the format. According to the docs at https://docs.python.org/3/c-api/arg.html#strings-and-buffers, bytes should be using "y" as its format. Unfortunately, there's also a Py2-compatibility issue here since the "y" format does not exist in Py2's flavor of Py_BuildValue which is worth consideration.

src/pywraps/py_typeinf.hpp

Lines 600 to 611 in e1c108a

	static PyObject *py_get_numbered_type(const til_t *til, uint32 ordinal)
	{
	const type_t *type;
	const p_list *fields;
	const char *cmt;
	const p_list *fieldcmts;
	sclass_t sclass;
	if ( get_numbered_type(til, ordinal, &type, &fields, &cmt, &fieldcmts, &sclass) )
	return Py_BuildValue("(" PY_BV_TYPE PY_BV_FIELDS "ssi)", type, fields, cmt, fieldcmts, sclass);
	else
	Py_RETURN_NONE;
	}

For the sake of completion, here's what the components of that local type actually look like. That "\xdd" byte at the beginning of the fourth element of the following tuple is causing the UTF-8 decoding issue.

(b'\r1\x07\x07\x07\x07\x07\x07', b'\nv_flags_0\rv_subIndex_4\x15v_previousSubIndex_8\x12v_currentlyUsed_c\x0ev_subIndex_10\x0fv_subOffset_14', None, b"\xdd\x01[value&00000100] means that it uses gv_wmmTableSpace_1b3d0\n[value&00000010] makes the top 8 bits of this value a multiplier\n[value&FF000000] seems to be the chunk size of the arena?\n[value&00000001] means that it's inuse\x01\x01\x011[note] this index seems to be the external index", 0x0)

I get that you guys have a support@, but since this is actually related to the swig bindings and is not really critical (since you can just delete and re-create the type entirely). Figured I'd post it here.