Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/alexander-pick/idb2pat

idb2pat plugin, fixed to work with IDA 6.2
https://github.com/alexander-pick/idb2pat

Last synced: 3 months ago
JSON representation

idb2pat plugin, fixed to work with IDA 6.2

Awesome Lists containing this project

README 

        
IDB2PAT



fixed a few things and ingtgrated crc16.cpp into it to work proper with 

IDA 6.2 OSX. Porting it back to Windows should be easy.



Original Plugin by J.C. Roberts 

IDA 6.2 OSX Patch Alexander Pick 



______________________________________________________________________

**********************************************************************

----------------------------------------------------------------------



 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 disassemblly. 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, oject 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

autogenerated 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 togo about this as well but until I have time to write specific a

plugin for figureing 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 patternss 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 functionin the database is if your goal

is to see how similar two executables are. Instead of using a hex

editor and doing aresyncronizing binary compare between the two

executables,you could use IDA signatures to get a different/better

wayto 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

autogenerated 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

numberof collisions. There are plenty of other problems with this

approach that I won't mention but there are quite a few ofthem.



    I've hacked together a simple work-around. When the user has

selected everything mode, the pulgin will prepend the autogenerated

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 anddress 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 referneces 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 refernce 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.



______________________________________________________________________

**********************************************************************

----------------------------------------------------------------------