I've seen this referenced in a couple of other questions on this site. But what's a FLIRT signature in IDA Pro? And when would I create my own for use?
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 byte of the program being disassembled, whether this byte can mark the start of a standard library function.
The information required by the recognition algorithm is kept in a signature file. Each function is represented by a pattern. Patterns are first 32 bytes of a function where all variant bytes are marked.
It's somewhat old (from IDA 3.6) but the basics still apply.
To create your own signatures, you'll need FLAIR tools, which can be downloaded separately.
(FLAIR means Fast Library Acquisition for Identification and Recognition)
The IDA Pro book has a chapter on FLIRT and using FLAIR tools.
A flirt signature is a pattern used to match known function headers. As an example consider the following:
push ebp mov ebp, esp sub esp, 4Ch mov [ebp+var_4], eax push ebx push edi ...
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. Compiled somewhere else the compiler may choose to use other registers, for instance:
push ebp mov ebp, esp sub esp, 4Ch mov [ebp+var_4], eax push ecx push esi ...
Now you have a couple of options for trying to match this. Either naively create a signature from the sequence of instructions:
push X mov X sub X mov X push X push X ...
Assume stack frames use ebp and esp, which is actually more dangerous than it sounds. It's common for functions to use ebp as a general purpose register:
push ebp mov ebp, esp sub esp, 4Ch mov [ebp+var_4], X push X push X ...
IDA flirt signatures are an attempt to create these sorts of signatures based off of a number of the initial bytes of a function. The problem they are trying to solve is identifying commonly re-used code. These signatures are generated by compiling various commonly used libraries using various compilers. Once the compiler produces a library IDA has tools to extract the signatures from this library while also matching it to its source definition. After a while you can build up quite a lot of signatures for common libraries which will save you quite a lot of time down the road.
For a more complex solution to the related problem of identifying program similarities and differences see BinDiff. It uses much more advanced heuristics.
The signature I used above as an example is fairly worthless since it's way too generic and will create a lot of false positive matches.
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 lot of malware that is of the same family. Typically, they write and use their own library functions and it would make sense for a FLIRT signature to help here.
As an added bonus, here's a public repo of FLIRT signatures.