FLIRT stands for Fast Library Identification and Recognition Technology.
Peter explained the basics, but here's a white paper about how it's implemented:
To address those issues, we created a database of all the functions
from all libraries we wanted to recognize. IDA now checks, at each
A flirt signature is a pattern used to match known function headers. As an example consider the following:
mov ebp, esp
sub esp, 4Ch
mov [ebp+var_4], eax
The compiler is free to change any register to another one or move anything around so it all depends on what the compiler thinks is most optimal. ...
Yes, getting the compiler version right is pretty important, as well as the compilation options.
FLIRT relies on fixed byte patterns and does not tolerate even slight differences in the generated code. A different version of compiler may have drastically different register allocator or optimization algorithms, which may result in very different binary for ...
There is radare2 tool and framework, written in pure C, as an embeddable and a portable library - almost all functionality available via C API and r2pipe API.
There are options to support:
FLIRT itself - r2 supports this format (see 'zF' commands)
Zignatures - internal format of r2 (see 'z?' command for help)
Yara signatures - requires an installed yara ...
Oh, the happyness of near functions vs. far functions, near pointers vs. far pointers, and mixed models (far functions, near pointers)
Back in the 16 bit world, programs could either
use a maximum of 64 KB code, and 64 KB data, have all pointers use 16 bit, and ignore segment registers. This was called the near model, because all offsets were within the ...
If you are talking about IDA FLIRT signatures, unfortunately sooner or later you will probably hit their limitations, and, or, get frustrated with the results if you want high accuracy.
First you can read about IDA's system in detail here:
As you can see it only matches the first 32 bytes of ...
I'm not sure if other tools offer the same functionality, but if you have IDA, you can do File->Produce File->Create MAP File to create a .MAP file with the names that IDA determined (or which were manually created by the user). Many other debugging tools have the ability to load .MAP files, so I have used this trick for example with SoftICE and OllyDbg.
Read this here:
I think they overhauled the FLIRT system in a recent version of IDA.
Overall it works pretty well, but there is a lot of room for improvement.
It's kind of like "finding a needle in a haystack".
It's annoying when the FLIRT names so many false positives.
It assumes a match on just ...
From the Hex-Rays site:
A signature file contains patterns of standard runtime functions.
With their help, IDA is able to recognize the standard functions and names them accordingly.
In an effort of full disclosure, I've not really created any for my own use from scratch. I suppose one instance where creating your own might be helpful is if you have a ...
You may be able to make use of snapshots to make this happen from a plugin. I don't think the database snapshot functions are exposed in IDC or IDAPython.
General algorithm on a freshly opened database would be something along the lines of
libs_before = iterate over all functions to determine initial count of library functions
Using FLIRT for C code requires you to know the exact version of CRT and the exact flags of the compilation so that you could build it yourself and then, having all the binaries and debug symbols, create the signatures from .a or .obj or .lib.
But there are so many variations of CRT built with various versions of the compilers. And there's no way to ...
There is a project called Sibyl based on the symbolic execution framework miasm. They basically call each unknown function with test cases until it passes all test cases for a given hypothesis.
E.g. if the unknown function is "strlen", one test case could be: It should, when you call it with the single parameter "AAAAAAA", not crash and return 7.
You need to build Qt 5.5.1 using MinGw 4.9.2. and guess all the build options that the developer used originally. Then use FLAIR for you IDA version to generate pat files from .a libraries. Then compile pat files into sig files. Put sig files to \IDA\sig and try to apply them.
AFAIK, you can only create the .pat files from statically linked libraries using the method you describe. It appears your file is dynamically linked (that would explain the 'invalid input file' message)
You can give a try to this IDAPython plugin. A good explanation from its author can be found here
IDAPython - you can automate almost everything in IDA with IDAPython or IDC.
The hard part is that it's not very well explained. There are a few things that can help:
All menu actions can be linked to IDC funtion via the IDA configuration files found in the cfg directory inside the IDA installation path (3 files starting with ida)
Read inside the source ...
There is a plugin called BinDiff
If you have renamed Sub_Routines in one IDA DB, you are able to run BinDiff between your current one and a new DB that hasn't been refactored yet. The only down side is it's a little time consuming for binaries that are 30mb+ in size.