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.
* 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.
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.
