Cr1pt0r ransomware: FireEye FLARE idb2pat.py script to build your IDA Pro FLIRT signatures

Hi Everybody,
from my previous post in order to have an human approch to analyze the stripped ELF Cr1pt0r I wrote just a few words about IDA Pro feature to build FLIRT signature.
What is FLIRT?
"The unique F.L.I.R.T. technology allows IDA to recognize standard function calls, and enhance the disassembly output." From Hex-Rays website

The FLIRT Technology is the thing which makes IDA so special during decompiling. Ida knows, by the .sig files thousand standard calls identified by a pattern, renaming the subroutines which matches automatically during the autoanalysis (or by invoking the specific signature later).
Unfortunatly, in this specific condition, where we had a stripped ELF, static compiled, ARM executable, IDA does not have the specific FLIRT signatures and I had to build my owns to make my life better. 💖

The process of creating FLIRT signatures usually requires a number of prerequisite conditions to exist:

• A pattern file must be created via either pelf or similar, followed by use of sigmake
• A compiled, relocatable library containing the functions and associated names, of which signatures are to be generated against, must exist
• The library must be a recognised format and with a supported instruction set

We're not able in this situation to satisfy everything so, Fire Eye’s IDB2PAT tool, created by the FLARE the division of Fire Eye is the tool which makes possible to extract the pattern starting from an IDB:

This script allows you to easily generate function patterns from an existing IDB database that can then be turned into FLIRT signatures to help identify similar functions in new files.
https://www.fireeye.com/blog/threat-research/2015/01/flare_ida_pro_script.html

Source

 
Instead of cross compiling examples to have as much functions in the signature (which has been the better solution in order to maybe avoid many collisions), I thought it was faster to extract the patterns directly from  Debian pre-compiled libraries! 😎
 packages.debian.org  gave me the armel (arm little endian) packages I needed. (libsodium, libc and others)
Once opened the libsodium.so.23.2.so (Shared Object), into IDA , starting the FireEye script, the pat file has been wrote easly on the same directory.

 

  ./sigmake element.pat  element.sig (sigmake is part of FLAIR tools provided by Hex-Rays to produce the .sig file).
And here we go, we got signatures, simply push the files into %IDA_INSTALL_PATH%/sig and let's see if it works!

From the 0 signature we had from the initial load, now we have few hundreds of them recognized!

I am fully informed that starting from the libraries, in addition precompiled, without accurately verifying the collisions, the chances of inaccurate recognition are high. But I don't care! This is not an huge ELF and I'll keep it in mind during the analysis 😂

What is important in this article is the desire to share this technique with you so that it can help you in situations like this or, for example, by decompiling subsequent or previous versions of the same malware, in all those situations where you already have a structured idb, even if I already know that you will quote me bindiff, creating the signatures, will maybe an help to speed-up the analysis.

My heart is branded Hex-Rays. 💘
Cheers,
RE Solver