Known patterns identification

One of Malcat’s main goals is to quickly assess for a given file what it is made of. A way to achieve this goal is to look at known code and/or data patterns inside of files. This can quickly give analysts hints on what the file is capable of doing, or point them to interesting locations. Currently, Malcat features tow know pattern scanners: a Constant scanner to locate well-known data, and a FLIRT signatures scanner to identify known library functions. More will be added in the future.

Constant scanner

Malcat scans for a large variety of know constants during analysis. By constant, we mean any fixed-size byte sequence representing a known data. They can range from known GUIDs, to API hashes, cryptographic numbers, compiler strings, etc. Ide

The constants database is located inside the constants/ subdirectory of both the Data directory structure (Malcat’s default database) and the User data directory (your own database). Malcat’s default database currently contains something around 400 000 constants.

Adding your own constants

Coming soon

FLIRT signatures

FLIRT signatures have been developed by the team behind IDA in order to identify library functions statically linked inside a program. This is kind of a reverse-engineering industry standard nowadays and is very helpful when reverse engineering big applications lacking any kind of symbols.

Adding your own FLIRT signatures

Aadding your own FLIRT signatures is very easy: put any .sig file in the flirt/ subdirectory of your User data directory, hit Ctrl+R and you’re good to go. You will notice that in Malcat there is (currently) no option to manually apply a FLIRT signature to a file. By default, FLIRT signatures are automatically applied to every analyzed program. Why? First, because we want Malcat to be beginner-friendly, and beginners are often overwhelmed when asked to chose the right FLIRT signature to analyse their file.

Second, Malcat has been designed to be fast. Opening a file should be almost immediate. Manually choosing a signature file using a dialog goes somewhat against this philosophy. If you don’t want your FLIRT signature to be applied to every new file, you can specify a precondition for your FLIRT signature instead.

FLIRT signatures precondition

FLIRT scanning comes at a (small) cost: for the big MSVC FLIRT signatures for instance (that is two .sig files of about 5 MB zipped), it takes 500ms to scan a moderate-sized PE program. If Malcat would blindly apply these FLIRT signatures every time to all newly analyzed files, we fear that users would run into two issues:

  • Analysis times would become somewhat noticeable, in particular if you add a lot of FLIRT signatures to Malcat

  • You will see false positives, i.e. wrongly-identified methods, since FLIRT signatures are far from fool-proof

In order to tackle these issues, every FLIRT signature myflirt.sig may be accompanied by a precondition file with the .precond extension, e.g. myflirt.precond. This file should contain a single python lambda expression that will be evaluated by Malcat at runtime. If this expression returns true, then the FLIRT signature will be applied to the file, otherwise the signature files will be ignored.

The python precondition has access to some of the Malcat’s python bindings. Since FLIRT scanning is performed pretty early in the analysis pipeline, the python code will have only access to:

For instance, here is the precondition for the MSVC flirt file:

"RichHeader" in malcat.struct

Any PE file having a Rich header will apply the MSVC flirt signature. But you can have more complicated preconditions. Here is the one for libcurl_x86.sig for instance:

analysis.architecture == malcat.Architecture.X86 and \
    ".rdata" in analysis.map and \
    analysis.file.search("CLIENT libcurl",
        analysis.map[".rdata"].phys,
        min(analysis.map[".rdata"].phys_size, 10000000)
    )[1]

Using python as a language for preconditions should give you, the users, enough control over your FLIRT signatures.