9
A bit of history: (aka an aging guy blabbering about)
In the old days, we didn't have python in IDA and when an individual wanted to develop an IDA plugin he had to implement it in C and use the SDK available from hex-ray's download center using credentials received when you purchase an IDA license. We did have, however, IDC. IDC is IDA's old, proprietary ...
7
Another solution:
ea = ScreenEA() # Or whatever you want
buf = idc.GetManyBytes(ea, ItemSize(ea))
6
I just created a wikia for IDA Pro.
Do add your contributions there! :)
I'll also be adding some info every now and then.
It is a community wiki, so please do no evil! =P
6
Here it is.
Run it with idal -c -A -S./script.py ./test.bin
# I didn't check this code, please use carefully !
# IDAPython documentation is at https://www.hex-rays.com/products/ida/support/idapython_docs/
import idautils
import idc
for ea in idautils.Segments():
segend = idc.GetSegmentAttr(ea, idc.SEGATTR_END)
start = ea
while start < ...
6
TL;DR: There's no simple API to achieve this, code is at the end of the answer or here.
As far as I know, there is no easy way to get the references to stack structure. It seems like calling idautils.XrefsTo(sid) where sid is the frame id (retrieved using idc.GetFrame) should work, however I couldn't get it to yield any result in my attempts.
Instead, ...
6
There is one function that does this: build_stkvar_xrefs, defined in C++ but exposed via the Python SWIG bindings. IDA builds stack xrefs dynamically when you ask for it. In order to use the function, it requires a little bit of setup.
You'll need to use a few functions to get what you need:
get_func(ea): retrieves the func_t structure for the function at ...
5
From IDA 6.4 news:
+ SDK: added extra_cmt_changed IDB event for the anterior/posterior comment changes;
also renamed the SDK functions related to these comments
5
Yes. The newer versions of IDA has official bindings for the Hex-Rays decompiler.
Originally, the Python bindings were written by EiNSTeiN around the Hex-Rays Decompiler SDK API. Later it has been merged into IDAPython.
You can find the documentation under "ida_hexrays" in the IDAPython docs.
Examples can be found in IDAPython repository. Check the scripts ...
4
When I needed to do a similar task I ended up hooking the IDB save event and then scanned the IDB for modifications using the IDA API before each user save. it took about a few seconds to scan the entire function list, aggregating most information for both functions and data elements.
To me, that sounds like a more practical approach than trying to reverse ...
4
Elaborating on existing answers, if you prefer to use IDAPython:
decode_insn(here())
print hex(cmd.Op1.addr)
4
I don't know it either so I put together this small script in order to do some empirical analysis.
import idaapi
import idc
import idautils
for f in Functions():
fc = idaapi.FlowChart(idaapi.get_func(f))
for bb in fc:
if bb.type == 3:
print "%x type: %d" % (bb.startEA, bb.type)
print "Done"
I throw it to several x86 and ...
4
While the API may be cumbersome, most of the information you are looking for is "readily" available from IDA during static analysis. Some of it is somewhat generic, while other pieces require different handling per processor type.
To check if an operand performs read or write access to memory, you can use the following:
import idaapi
import idautils
import ...
3
There is an IDApython function that provides what you're after.
It's called idaapi.get_file_type_name() and it will return the same string displayed in the "Load a new file" dialog:
Additionally, there's another function called get_loader_name, which is only accessible through IDA's C SDK and isn't exposed by IDAPython because it wasn't thought to be ...
3
The update methods of actions are usually called when the relevant GUI components (usually various IDA views) are refreshed. To make things speedier, IDA avoids refreshing views until such a refresh is required.
When scripting IDA, we often make changes without touching the GUI, so IDA has no way of telling when a change is done and it should refresh. To ...
3
AFAIK you cannot debug a 64 bit application locally with IDA Pro.
You need to use remote debugging.
See this page: https://www.hex-rays.com/products/ida/debugger/#details
and this: https://www.hex-rays.com/products/ida/debugger/cross-win-linux/win32towin64.shtml
3
I found the reason why the plugin didn't work: the PLUGIN symbol wasn't exported from the dll (.plw).
In headers prior to version 5.1 the symbol isn't declared __declspec(dllexport), meaning it has to be exported via a .DEF file or a workaround has to be used so that the symbol definition can be made __declspec(dllexport) despite the wrong declaration in ...
3
You would need to create a Loader plugin for them. See the ldr directory in the IDA Pro SDK.
Once the Loader is built, you would copy it to the loaders subdirectory under IDA Pro's directory.
Here's a nice blog entry on writing IDA Pro file loaders in higher level languages: http://www.hexblog.com/?p=110
3
Before you dump the process's memory to disk, use a tool like Scylla to reconstruct the Import Table.
3
Have you tried manually loading the Hex-Rays plugin before loading your plugin?
For example:
#include <idc.idc>
static main() {
Wait();
Message("Hello world from IDC!\n");
RunPlugin("hexrays",0);
RunPlugin("REcompile vs Hexrays",0);
//Exit(0);
}
3
Short answer is that both idaapi and idc modules should be avoided if possible.
The idaapi module is there for backwards compatibility and should be avoided if possible. It will be dropped in a future version of IDA (probably with little to no warning ahead of time). You should strongly prefer the ida_ prefixed modules.
In older versions of IDA, a single ...
3
the disassembly You posted for sub 401000 is incomplete
this is a limited explanation
it checks the provided buffer (0x40A000 in the first call for the first null terminator )
and possibly decrypts it and memcpy() the decrypted string to szUserName
(the part is missing in your post (everything that happens after 0x401025 the jz path)
look at ...
2
While in debugger, select the import table and run idc\renimp.idc.
Top comment from the file:
/*
Rename imports.
This script renames entries of a dynamically built import table.
For example, from a table like this:
dd offset ntdll_NtPowerInformation
dd offset ntdll_NtInitiatePowerAction
dd offset ntdll_NtSetThreadExecutionState
...
2
char szBuffer[MAXSTR];
ua_outop2( get_screen_ea( ), szBuffer, MAXSTR, 1 );
ea_t qword = cmd.Operands[1].addr;
2
Currently I'm working around that by having PLUGIN_KEEP set upon load
but patching PLUGIN_UNL into PLUGIN.flags
This is not a "workaround" but actually a documented way to have IDA unload your plugin.
#define PLUGIN_UNL 0x0008 ///< Unload the plugin immediately after calling 'run'.
///< This flag may be set ...
2
This is a bit of a tricky question, because technically MakeCode is not what causing the rest of the code to be analyzed as code. A hint for that can be the fact that MakeCode actually returns the length of the current instruction. It is only later that additional following bytes are being converted to code (if possible).
Thing is, that for IDA to do what ...
2
The treeloc_t constructor does not accept an EA, and you need to specify the comment preciser:
ea = idaapi.get_screen_ea()
cfunc = idaapi.decompile(ea)
tl = idaapi.treeloc_t()
tl.ea = ea
tl.itp = idaapi.ITP_SEMI
cfunc.set_user_cmt(tl, "Test comment")
cfunc.save_user_cmts()
You can find more info about the precisers in hexrays.hpp. Not all precisers work ...
2
No, you can't extract an IDA graph to the xml file.
If you still want to use an external graph viewer, IDA supports two graph specification languages Graph Description Language and the D.O.T.
2
NirIzr's answer has a major drawback: All those locations following the decoded instructions are still added to the analyzer queue, they're just not being processed. That means if you ever enable analysis again, IDA will go back and process them all, completely obliterating whatever your script did.
A better solution is to go into "Kernel options 1" and ...
2
After looking around a bit more, I noticed that if I handle the following two processor module (HT_IDP) events, I can pretty much catch the moment I wanted:
processor_t::event_t::ev_newfile when a new database is being created (like from a PE file)
processor_t::event_t::ev_oldfile when an existing database has been loaded (from a .idb file)
2
Solution is very simple:
get pointer to pseudoview
vdui_t * vuu= open_pseudocode(func->startEA, 0);
Get Pointer to variables
lvars_t& lvars = *pFunction->get_lvars();
Simply rename variable
vuu->rename_lvar(&lvars.at(i), "permanamed", true);
last bool flag in rename_lvar func, operate if renaming is permanent or not .
p.s.
Its kind'a bad ...
Only top voted, non community-wiki answers of a minimum length are eligible
