From Collaborative RCE Tool Library

Jump to: navigation, search

IDA 2 PAT

Tool name: IDA 2 PAT
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.
Related URLs: No related URLs have been submitted for this tool yet


RSS feed Feed containing all updates for this tool.

You are welcome to add your own useful notes about this tool, for others to see!



If you find that any information for the tool above is missing, outdated or incorrect, please edit it!
(please also edit it if you think it fits well in some additional category, since this can also be controlled)


Views
Category Navigation Tree
   Code Coverage Tools  (13)
   Code Ripping Tools  (2)
   Helper Tools  (3)
   Hex Editors  (13)
   Memory Patchers  (7)
   Packers  (20)
   Profiler Tools  (11)
   String Finders  (10)
   Tool Hiding Tools  (7)
   Tracers  (22)
   Needs New Category  (3)