Recent Posts

Pages: [1] 2
IDA Pro / Re: IDA Class Informer
« Last post by Administrator on June 01, 2017, 11:27:52 PM »
Mentioned in Chris Eagle's popular IDA Pro book:

qwerty9384 made a tutorial game hacking tutorial using Class Informer:

In this thread, someone has made a IDA 6.8 version and more (use at your own risk):
IDA Pro / StringMiner
« Last post by Administrator on May 10, 2016, 11:01:39 PM »
Work in progress..
IDA Pro / Signature Matching Plugins
« Last post by Administrator on May 09, 2015, 11:18:41 PM »
IDA Signsrch
IDA Pro plug-in conversion of Luigi Auriemma's signsrch signature matching


Example search output:

Update May 2015:
1) Added a 64bit version.
2) Updated to IDA SDK 6.8 version.

> Sourceforge IDA Signsrch <
IDA Pro / IDA ExtraPass PlugIn
« Last post by Administrator on May 09, 2015, 02:35:36 PM »
DA ExtraPass plugin
An IDA Pro Win32 target clean up plug-in by Sirmabus.
Version 3.4

It does essentially four cleaning/fixing steps:
1. Convert stray code section values to "unknown".
2. Fix missing "align" blocks.
3. Fix missing code bytes.
4. Locate and fix missing/undefined functions.

It's intended for, and only tested on typical MSVC and Intel complied Windows 32bit binary executables
but it might still be helpful on Delphi/Borland and other complied targets.


Update [May 2017]:
Added 64bit version. Improved find/fix alignment pass.

Update [May 2015]:
Updated to IDA SDK 6.7

>> Sourceforge: ExtraPass plugin
IDA Pro / Informational comment plug-ins
« Last post by Administrator on May 08, 2015, 11:20:22 PM »
I've updated my what I call "informational comment plug-ins".
They are three plugins meant to be applied together in sequence.
I usually run these after I run my "Extra Pass" (cleaner fixer) and "Class Informer" (if the target has C++ Run Time Type Info).

>> Sourceforge: Function String Associate
>> Sourceforge: Mark Reference Counts
>> Sourceforge: WhatAPIs

It's easier to express what they do in "before and after" images.

Here (the "before") you have a fairly common IDA Pro 32bit function example:

Pretty cool that IDA was able to derive the function arguments, but other then that
it probably won't look that significant to you.

Then looking at at a reference it looks even less significant out of the typical thousands of auto-named functions:

Now the three plug-ins ran in sequence:
1) Function String associate
2) Mark reference counts
3) WhatAPIs
(If you don't run them in this way the comment order will be messed up)

Now at a glance you see there is extra information about this function's contents:

Here's the break down:
First you see a '5'. This tells you there are 5 references to this function.
The count can give you some hints about the relevance of a function and some idea of it's hierarchy.
If it were just '1' count then you'ed know it's a child of your function; then say if it had 1000 references you could assume
that it might be some kind of common library function.
IDA function reference count to comment plug-in Blog Post

Then you see the tag "STR:" which indicates that what follows are strings found in function.
In this case there is a string contained in it "DEBUG WINDOW". We can use this as a hint as to what the function might
might be about (literally a "debug window").

Then finally you see the tag "<API*>".  This lists API functions (from the import table) that this function is using.
More hints.

From the string above and the fact we see windows UI creation functions, eureka! This function is probably
in fact one that creates a "debug window".   Not even looking at the function we can just glean this from these comments alone..

Then look at a reference (one of the five) to this very same function:

All that information is visible even as a reference!

The reference count comments are also placed for data items.
So now as you are looking through functions and see their data references, and, or, directly at variables in a data segment
you can get some idea of their significance.
If you see some constant or dynamic data element with only one or two references you can infer (a hint) that it's probably not
that significant.  But then on the other hand you see what looks to be a pointer value with 10,000 references then you can make
some assumptions that it's an important data item.

After while this extra info will feel natural, useful, and intuitive.
To me it's a world of difference. If I look at a plain IDB now with out this I feel sort of blind.

[The future]
Hopefully you will find these information comments useful.  However it does have some problems and is not the ideal setup.
For one thing it might be harder to pick out your own comments with these placed.
Then if you accidentally overwrite a comment set with your own you'll loose them. You can't just run the plugins again to replace them (it will cause a mess).

If you use BinDiff or the open source Diaphora to port over your comments from one IDB to the next then that can make a mess of these comments too.
And what if you want to add your own auto-generated comments?
If nothing else they are handy for a debugging or development feature; similar to how people set the background color for the same purposes.
Too many function and data comments will become visual noise.

What would be ideal here to use a custom view!
Then these comments could show up more natively like IDA's own on the fly cross reference (light green colored) comments.
With this type of setup this data can be globally switched on and off, the text could be custom colored, users could add there own per function and data item text (through another plug-in or via Python bindings, etc.) and can optionally be persistently stored inside the IDB.
This view will look pretty much the same as the IDA "Disassembly" view your already familiar with, it'll just show extra information above the function header, below any exiting comment(s).
Finally the data could be ported over from one IDB to another by using names or better, be added to the port tool functionality it's self.

[May 2015] Updated to IDA 6.7 and now there are 64bit versions as well.
Downloads and Source:
>> Sourceforge: Function String Associate
>> Sourceforge: Mark Reference Counts
>> Sourceforge: WhatAPIs

IDA Pro / Re: IDA2PAT Reloaded doesn't seem to log all signatures.
« Last post by Administrator on May 03, 2015, 12:27:19 AM »
From a question PM'ed to me on

Originally Posted by BackDoorMan
Hello sir

I've just downloaded your IDA plugin for generating .pat files however it doesn't export sigs for all of the functions.
What could be the problem?


== IDA2PAT-Reloaded plug-in: v: 1.1 - Mar 28 2011, By Sirmabus ==

Support forum:

Functions to process: 14835

Working, <Press Pause/Break key to abort>...

Patterns created: 79

Process time: 11.41 seconds.


As you can see 79 patterns of 14835 functions.

I also used idb2pat python script which exports fine but it doesn't seem to mask pointers... ipso facto generated .sig file doesn't match all the functions.

IDA2PAT reloaded signature:

IDB2PAT.PY signature:

Thanks in advance!
Best regards.

Re: IDA2PAT Reloaded doesn't seem to log all signatures.

I'll add that to the list of the one I need to update and make a 64bit version of.
I've updated most locally and should have them up on my website soon.
Reminds me too there is an update to FLAIR that should add a little more integrity to sigs now that I could look into.

First one issue:
I made my version to only save user named functions.
To reject all the default ones like "sub_402230", etc.
The original tool tried to use flags to determine if functions were "auto-generated" or not but those flags are unreliable so I use a string filter.
Could be something messing up there.

The whole pattern matching thing is a loaded issue.
First of all IDA's FLAIR system is pretty ambiguous. That's why you'll see IDA placing bad signatures for it's run time set, etc.

I've done research in the area and made my own simple signature tool still in progress I haven't released.
The biggest problem with FLAIR and in general similar simple signature matching is they don't consider things like uniqueness, commonality, etc.

Imagine you are interested in a "std::string" constructor function. The problem is even though you name one of them there could be many of the same exact function.
To make matters worse it could be a small function with very little details (like immediate values, etc.) to discern it form any other number of similar functions.

Then sure your named one should end up in your .PAT file (from a IDA2PAT tool), but will fail in sigmake.exe if there is a conflict (because two or more have the same signature, etc).
If your resolve the conflict (by editing the result file) and the signature makes it to your .SIG file imagine now applying it to a new/updated target.
It's going to apply the name to the first match it finds. It's probably not going to be the one you wanted it to match too.
On top of that it will match a bunch more (all with serialized names).

See the problem?
FAIR is pretty dumb to the whole scene. It doesn't know about the degree of significance, about similarity, relative positions, etc.

Then another issue is knowing properly how to mask out the non-exclusive features in the PAT generation.
So when you have things like "mov dword_1B4B52C,eax" the tool should keep most of the details, maybe only masking out the "dword_1B4B52C" part and keeping the rest.
The address won't (probably not anyhow) translate over when applied as a signature so it needs to get masked.
But actually when you think about it, it is a significant detail. If nothing else there is a relative position hint in it somewhere.
Just that AFAIK no existing tool stores any meaningful context of it.

What is needed is a new type of tool that considers the whole picture.
And some things will just have to go. For functions that can't be tracked reliably it will say so and reject them, etc.

I'll update my variation to a newer IDA SDK as that might help.
But I think any more time spent on FLAIR (a broken system from my perspective) would be kind of a waste.
General Discussion / Re: Bombarded by spam..
« Last post by nocare on May 02, 2015, 11:47:31 PM »
Well not sure when the update was, but I only re-registered a week or so ago.
Surprised to even see the site up and it is cool to see a blog.
IDA Pro / Dump arguments scrip
« Last post by Administrator on January 02, 2015, 03:24:00 PM »
Here is the Python version of a script I first did in IDC some years ago that I use a lot.
I use it to dump function arguments out; most useful for ones that have strings.

The typical case is when you find some sort of dump/log/assert functions that have many interesting strings.
If you see something of interest you click on the address to jump to the function for examination.

Example with this Lua script loader function (I labeled "LoadLuaScripFile_Func00") I can now see where these scripts are being loaded and some of their names/labels:

To use it:
1) Go to the function of interest and click on the name or inside of it so it's selected.
2) Run the script
3) It will ask you for an argument count (three in the example above).
4) It will dump out references to the output window (where you can click on the address to jump)

>Download ShowFuncArgs_IDA_Script.rar <
General Discussion / Bombarded by spam..
« Last post by Administrator on January 01, 2015, 11:50:27 PM »
Not so surprising, my little forum here gets bombarded with spammer bot accounts despite using Google reCAPTCHA, etc.
Getting a half a dozen or so spam accounts every day.

Until I get better anti-spam measures had to set admin account approval for now..

Update: Apologies to those that tried to register in the last month or so.
Forgot to check and out of all that needed approval most were bots anyhow.
Macromonkey Script System / Download latest version
« Last post by Administrator on December 31, 2014, 07:02:19 AM »
Version 2.2

As I'm putting my site back up would like to update it to the latest LuaJit and more, but for now the latest version here: > MacroMonkey 2.2 <
Pages: [1] 2