From Collaborative RCE Tool Library

Jump to: navigation, search

IDA Signature Creation Tools

Tool name:

Fast IDB2Sig and LoadMap IDA plugins

Currently4/5
1
2
3
4
5

Rating: 4.0 (1 vote)

Author:

TQN

Website:

N/A

Current version:

1.0

Last updated:

September 14, 2004

Direct D/L link:

Locally archived copy

License type:

Free / Open Source

Description:

It took me two weeks to write two IDA plugins, a renew, fast IDB2Sig plugin and a new, very fast LoadMap plugin.
The IDB2SIG plugin I rewrote base on the orginal source code and idea of:
- Quine (quine@blacksun.res.cmu.edu)
- Darko
- IDB2PAT of J.C. Roberts <mercury@abac.com>
Thanks all of you very much. I think all of you will allow me to public the new source code.
The LoadMap plugin I wrote base on the idea of Toshiyuki Tega. It will supports loading and parsing VC++, Borland (Delphi/BC++/CBuilder) and DeDe map files.
And with two plugins, I need only two days to create two signature file for Delphi 6/7. Very fast and convenience. Hereafter, we can use two above plugins to create signature files, load map symbols...

Source is included, and plugins are precompiled for IDA 4.5 and 5.2.

Also listed in:

(Not listed in any other category)

More details:

Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)

Tool name:

Advanced obj and lib IDA signature ripper

Currently0/5
1
2
3
4
5

Rating: 0.0 (0 votes)

Author:

gerbay

Website:

http://www.woodmann.com/forum/showthread.php?t=9931

Current version:

1.0

Last updated:

May 23, 2007

Direct D/L link:

Locally archived copy

License type:

Free / Open Source

Description:

It loads obj and lib (COFF format) files signature to ida database.

It identifies so many labels more than flair signatures.

FLIRT signature creation not possible for some situation, for example you can try to create flirt signature for flexlm libs, but this plugin will work in such situations too!

Also listed in:

(Not listed in any other category)

More details:

Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)

Tool name:

IDA 2 PAT

Currently0/5
1
2
3
4
5

Rating: 0.0 (0 votes)

Author:

J.C. Roberts

Website:

N/A

Current version:

1.0

Last updated:

Direct D/L link:

Locally archived copy

License type:

Free / Open Source

Description:

For the most part, this plugin is an exercise in futility. There are
very few valid reasons why anyone should ever want to build signatures
of the functions in an existing disassembly. There are better
reasons, methods and tools for creating signatures for use with IDA.
Most importantly, the right way to create signatures is from object
files, object libraries or dynamically linked libraries, so please
realize this plugin is nothing more than a kludge since we are asking
FLAIR to do something it was not designed to do.

**********************************************************************
Option: Create patterns for Non-Auto Named Functions

If you find the rare situation where you want to make patterns
from functions in an existing database, this option is probably your
best bet. It will only create patterns for functions without
auto generated names and it will exclude functions marked as libraries
(e.g. they were already found and named through other FLAIR
signatures). You may want to remove named functions like _main and
WinMain from the resulting pattern file, since these will already
exist in the disassembly where it's applied.

**********************************************************************
Option: Create Patterns for Library Functions Only

I did include the ability to build patterns for functions IDA has
already marked as libraries. This is forpeople doing source code
recovery/recreation since the pattern file can be further parsed to
figure out which header files are needed. There are probably better
ways to go about this as well but until I have time to write specific a
plugin for figuring out which headers are included, this can give you
a step in the right direction.Out side of gathering information on
applied library signatures, this feature is pointless since you're
building patterns for function that were previously found with other
signatures you already have.

**********************************************************************
Option: Create Patterns for Public Functions Only

This could be useful when dealing with a situation where functions
were once stored in a DLL and are now statically linked in an
executable. It's still may a better bet to build a signature from the
DLL and then apply it to the statically linked executable.

**********************************************************************
Option: Create Patterns For Everything

You generally do NOT want to build patterns for every function in
the disassembly. The only place where I can see a legitimate use for
creating signatures of every function in the database is if your goal
is to see how similar two executables are. Instead of using a hex
editor and doing a re-synchronizing binary compare between the two
executables,you could use IDA signatures to get a different/better
way to visualize the similarities.

There are a lot of problems with trying to do this. The first and
most obvious problem is reserved name prefixes (e.g. sub_) on
auto generated function names. Another cascading problem is of course
references to these names withing other functions and whether or not
to keep these references in the patterns in order to cut down the
number of collisions. There are plenty of other problems with this
approach that I won't mention but there are quite a few of them.

I've hacked together a simple work-around. When the user has
selected everything mode, the plugin will prepend the auto generated
function names with FAKE_ and references to these sub routines are
kept to reduce collisions. This should (in theory) work, since every
reference will also have it's own public pattern in the resulting
file. In other words, the named references will resolve to another
(public) function pattern in the file. The problem with this approach
is of course having erroneous address numbers in names of functions
where the signature is applied (e.g. the nameFAKE_sub_DEADBEEF could
be applied to any address where a matching function is found). My
guess why this will work is because a module in a library may have a
by name reference to another object in the library. The pattern file
of a library would keep the references, since the names are defined
in other pattern lines of the file. Of course I could be wrong but
it's worth a shot. If need be comment out the "sub_" tests in
part #7 (references) of make_pattern() to get rid of the refs.

**********************************************************************
Option: Create Pattern For User Selected Function

This allows the user to select a function from the list and
create a pattern for it. It does not work on functions with auto
generated names but probably could with a bit more work.

______________________________________________________________________
**********************************************************************
----------------------------------------------------------------------

LIMITATIONS:

* References and tail bytes are only used by sigmake to resolve
collisions. Auto generated names with reserved prefixes "loc_" "byte_"
"dword_" are not going to be repeatable in the binary where you would
apply the resulting signature. If those references were kept and used
to resolve a collision, you'd end up with a useless signature that
would not be applied because those names do not exist in executable
where the resulting signature is being applied.

* Reference offsets that greater than 0x8000 bytes from the
function start may make this plugin explode or more likely, just make
unusable patterns.

* All references are assumed to be 4 bytes long. This will cause
some problems for situations (e.g. processors) where this is not true.

______________________________________________________________________
**********************************************************************
----------------------------------------------------------------------
TODO:
* Error checking for reference offsets > 0x8000
* Change reference length from being fixed at 4 bytes.
* Create "append" versus "overwrite" dialog.
* Deal with the user choosing a function with an auto
generated name in the "Single Function" mode.

______________________________________________________________________
**********************************************************************
----------------------------------------------------------------------
DEVELOPMENT:

I did this in MSVC++ v6. There are two projects in the workspace. One
is for the plugin and the other for IDAG.EXE so we can debug the
plugin once IDA loads it e.g. start the plugin and at the choose file
dilog break. In the list of modules, you'll find "run()" and other
functions from the plugin.

Depending on where you install IDA, you'll need to adjust where the
plugin is written. I've got output set to "C:\IDA\PLUGINS\IDB2PAT.plw"
The same is true for the location of the SDK and such.

When it's set to build the debug version, there will be a lot of
warnings due to info truncation of debug symbols. It's not a big deal.

Also listed in:

(Not listed in any other category)

More details:

Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)

Tool name:

IDA2PAT Reloaded

Currently0/5
1
2
3
4
5

Rating: 0.0 (0 votes)

Author:

Sirmabus

Website:

http://www.woodmann.com/forum/showthread.php?t=11916

Current version:

1.0B

Last updated:

July 19, 2008

Direct D/L link:

Locally archived copy

License type:

Free / Open Source

Description:

An IDA Pro 5.xx plug-in to generate a pattern file.

You've probably seen or more of the different variants of this plug-in:
"ida2sig", "ida2pat", etc.
We want to create a pattern (".pat") file to assemble a FLIRT signature file (".sig"), using the FLAIR utility "sigmake.exe". This will allow one to apply these sigs to help port updats, etc.

I had preferred TQN's "ida2sig" version since it fastest (see below) I could find. But it had the same problems as the previous version. And I wanted to make a build I could updated with the latest FLAIR lib, etc.

[How to run it]
1. Invoke it using your selected IDA hot-key or from "Edit->Plugins".
2. Select the destination ".pat" file.
3. After it is done, convert your pattern file into a signature file using
"sigmake.exe",.

[Design & Outstanding issues]
There are zero options, the assumption is you want to save only, and all function names that are not autogenerated. That is for the most part, all functions that are not "sub_69B470", and "unknown_libname_228".

There are unfortunately ambiguities, and errors using function name flags like "pFunc->flags & FUNC_LIB", "is_public_name()", "dummy_name_ea()", etc., to determine what is a library, public, etc., function.

Biggest hurdle, consider this.. You go do your RE work, you rename some functions with a name that makes sense to you; or you just rename it specifically so you can come back to it later using a custom sig, etc.
Maybe all is well on the first time because IDA will see it as a user function and thus traditional IDA2PAT will create a pattern for it. But next time after update, etc., you apply the sig. It is no longer a "user function", IDA marks it as a library, or worse as autogenerated. Don't like this. We want to be able to apply a sig, work on the DB rename some functions with better fitting names as my understanding grows, etc., then create a new patterns and not have name collisions, etc.

AFAIK there is no solid way to determine what is "autogenerated", "user-generated" or otherwise, using the stock IDA SDK functions.

What "IDA2PAT Reloaded" does is solely rely on function name patterns instead. It simply rejects functions that start with ""sub_..", "unknown_libname_..", or that start with the characters '$', '@', '?', and '_', etc.

This will be a problem if you intentionally use using something like "sub_MyFunction", or "unknown_libname_MyFunction", etc., as your naming convention. This design assumes IDA is setup to display autogenerated function names as "sub_xxxxxx", etc., in the defaults.

Speed:
TQN's version was definitely faster then others, he replaced the file streaming "qfprintf()" with a very large buffer, then saved the buffer at the end. The real issue was a single "qflush()" call after each pattern create in
Quine's original code. FYI, a file "flush" causes the OS to flush it's write cache causing a file performance hit.

As a baseline, just iterating through around 100k functions (with zero processing) takes ~12seconds on my machine on average. Thus, any processing on top of that is just additive. IDA2PAT-Reloaded only adds ~3 seconds to the base line on a modern machine.

Also listed in:

(Not listed in any other category)

More details:

Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)

Tool name:

SiDAg