IDA Pro/Hex-Rays FLIRT Signatures and Standard library function detection

Question

I'm having some problems performing a standard decompilation of a Windows EXE file using IDA Pro/Hex-Rays and its built-in FLIRT signatures.

A lot of standard C++ functions are not being recognized as such, i.e.: rand, memset, etc.. The binary I'm trying to decompile is automatically detected to having being compiled using Visual C++.

I get the following on the output window when trying to open the .EXE:

Plan  FLIRT signature: Microsoft VisualC 2-11/net runtime
autoload.cfg: vc32rtf.sig autoloads mssdk.til

Type library 'mssdk' loaded. Applying types...
Types applied to 302 names.

Type library 'vc6win' loaded. Applying types...
Types applied to 1 names.

Using FLIRT signature: Microsoft VisualC 2-11/net runtime

But then when I go to the List of applied library modules (View > Open subviews > Signatures) I see that the vc32rtf signature had 1061 functions matched, but my it looks like either these were not mapped/renamed appropriately on the disassembled or something else is affecting its ability to identify the functions.

Tried to change signatures and add Type libraries as described here but nothing seems to change.

If it's any useful, the binary I'm looking at is for Reflector 1.5.0 for Windows and a few of the functions I can see unidentified are:

rand:

int sub_64B6F3()
{
  int v0; // eax@1
  unsigned int v1; // ecx@1

  v0 = _getptd();
  v1 = 214013 * *(_DWORD *)(v0 + 20) + 2531011;
  *(_DWORD *)(v0 + 20) = v1;
  return (v1 >> 16) & 0x7FFF;
}

memset:

char *__cdecl sub_5AD770(unsigned __int64 a1, int a2, int a3)
{
  unsigned int v3; // ecx@1
  int v4; // esi@1
  __int64 v5; // rax@2

  v4 = HIDWORD(a1);
  v3 = a1;
  if ( a1 >= 0x311000 )
  {
    *(_BYTE *)a3 = 30;
    if ( v4 || v3 >= 0xCC000000 )
    {
      if ( v4 )
      {
LABEL_10:
        if ( !v4 && v3 < dword_821FBC - 805306368 )
        {
          v5 = (__int64)(__int64 *)((char *)&qword_93C180 + v3 - 3489660928i64);
          return (char *)v5;
        }
LABEL_13:
        sub_64B413("ERROR - address was outside of heap/stack space! (%08lx))\n", v3);
        _mm_storel_pd((double *)&a1, 0i64);
        LODWORD(v5) = a1;
        return (char *)v5;
      }
      if ( v3 < dword_821FC0 - 872415232 )
      {
        v5 = (__int64)(__int128 *)((char *)&xmmword_83C160 + v3 - 3422552064i64);
        return (char *)v5;
      }
    }
    if ( !v4 && v3 < 0xD0000000 )
      goto LABEL_13;
    goto LABEL_10;
  }
  LODWORD(v5) = sub_5ADAA0(a1, HIDWORD(a1));
  *(_BYTE *)a3 = -77;
  return (char *)v5;
}

Answer 1

Read this here: https://www.hex-rays.com/products/ida/tech/flirt/index.shtml

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 a partial signature match from the first so many bytes of a function. Note depending on the build options library functions can be static, using a DLL, or inlined, plus the generated code can depend on optimization settings (thus signitures not matching). There is probably a lot of room for improvement that uses a more exacting system other then FLIRT.

Also related that might be interesting is "GraphSlick" that can find inlined functions:

"This plugin automates detection of inlined functions. It highlights similar groups of nodes and allows you to group them, simplifying complex functions. The authors provide an accompanying presentation which explains the algorithms behind the plugin and shows sample use cases."

https://github.com/nihilus/graphslick