Identifying library code in statically linked binaries
I recently saw someone asking for a way to apply the .pdb file of a static library to a binary that is using it. Even if that is probably possible with some extra effort, there is a better way to achieve the same advantages without the need to bother with .pdb files: IDA’s FLIRT signature feature (Fast Library Identification and Recognition Technology). While most IDA users are aware of the fact that IDA uses to apply some sort of compiler specific signatures to binaries, a lot of them don’t know that you can generate these signature files from any static library yourself without too much effort.
To get started, you need to acquire the the FLAIR toolkit from Hex-Rays’ download-page. Extract it wherever you want and spawn a CMD in the newly created directory, then CD to bin\win. Let’s assume you found out that your target binary is using MS Detours, however you are unsure of what specific version. That’s no problem, as FLIRT signatures allow you to generate signatures from several libraries and compile them into a single .sig file with ease, which also makes sense in regards of reusability. For the sake of this article, I downloaded version 1.5 and 2.1 of the express edition of MS detours from the Microsoft website. You now go on by generating a .pat (pattern) file from each static library you want to include in the signature file using the pcf tool. Some .lib files (which are effectively just a package of .obj files) that contain empty .objs seem to cause some trouble for the pattern generator, which makes it necessary to provide the -s switch (skip erroneous). After that, you run sigmake to generate a signature file from the pattern files. For a detailed description on the arguments of sigmake, take a look into sigmake.txt in the root of the FLAIR toolkit.
> pcf -s *.libdetours15.lib: skipped 0, total 142detours21.lib: skipped 1, total 145> sigmake -n"Microsoft Detours" *.pat msdetours.sigmsdetours.sig: modules/leaves: 279/259, COLLISIONS: 1See the documentation to learn how to resolve collisions.
When generating the signature file, the toolkit looks out for colliding patterns, which need to be resolved by the user manually by opening the generated .exc in a text editor of your choice. It should look roughly like this:
;--------- (delete these lines to allow sigmake to read this file); add '+' at the start of a line to select a module; add '-' if you are not sure about the selection; do nothing if you want to exclude all modules?[email protected]@@[email protected] 00 0000 83C00783E0F8C3..................................................?PadToDwordPtr@@[email protected] 00 0000 83C00783E0F8C3..................................................
In our example, the list of collisions is short and therefore easy to resolve, but in cases of huge libraries with >1000 colliding patterns, you are good to go by just deleting the first marker line, which will causes the generator to drop all problematic patterns (which usually only makes out a loss of about 1-5% of your patterns in my experience, which is pretty acceptable compared to hours of fixing patterns IMHO). Execute the sigmake command from above again and if everything went right, you should be standing in front of your freshly generated signature file! You now may apply zipsig on your signature file in order to compress it, however that’s optional. Finally, copy your .sig file into sig-directory in the root of IDA’s installation directory. You should now be able to apply your signature in IDA (CTRL + 1 -> Signatures -> INSERT).
Now, let’s see how well it works when applied to a tiny game cheat I found in the web: a topic for another article.
As seen above, generating and using signature files can save you a whole lot of reversing. There are also ways to automatically find library code in projects using self-compiled libraries, however that’s a bit more complicated and a topic for another article.