Importance of Compiler Version in generating a signature

Question

I load a reference elf that I cross-compiled for AArch64 into IDA Pro, idb2pat to generate a .pat which I then process through sigmake.

I then use the signature file (in the appropriate IDA Pro directory) to work on a commercial image, however it only identifies perhaps one or two functions (of many hundreds) even though I know the binary I am examining was built off the reference source that I used to build the reference elf that I generated a .pat (and then a signature for).

The commercial elf has all debug/compiler info stripped... pretty ruthlessly so I have to guess what gcc it was compiled with and then cross-compile the reference source using this guessed gcc version.

My question is how important is the compiler version when building an elf to generate signatures from? If I get the version incorrect will all my signatures simply fail to match the target binary I am working with?

Thanks for any help!

Answer 1

Yes, getting the compiler version right is pretty important, as well as the compilation options.

FLIRT relies on fixed byte patterns and does not tolerate even slight differences in the generated code. A different version of compiler may have drastically different register allocator or optimization algorithms, which may result in very different binary for the same source. In addition, idb2pat probably is not tuned for AArch64 and might not mark relocatable bytes properly, leading to overly restrictive patterns. A better option is to generate patterns from the object files (.o) or static libraries (.a) with pelf since it can use relocation information to mark wildcard bytes.

If you have just a single binary, I would suggest to just match it against the source code manually, using straight old human intuition and references between functions/string literals. This will likely be faster than finding the correct compiler version and options.

Another option is to use a more flexible diffing utility like Diaphora which has more algorithms besides fixed byte pattern matching.

If you need this on scale, you'll need to gather many compiler versions and try various options that affect code generation (at least the optimization level, i.e. -O0, -O1, -O2, -O3). You should also try other compilers like llvm/clang (both the public version and ARM's customized one).

For a quick test, you can use Compiler Explorer on some short code snippets to see if you can find a compiler and set of options to match the code you're seeing in the binary.