Best Way to Identify Statically Linked Functions in Firmware

Question

I have a piece of firmware that I pulled off an NXP LPC17XX series chip. Through reviewing the processor manual, I was able to identify the entry point of the code and disassemble the code without any issue in IDA Pro. After a short bit of reversing I found a number of functions that are likely printf, sprintf, and their associated helper functions.

I assume that there are of number of other POSIX functions as well as some core library functions for developing for this chip that are included in the firmware that I am looking at.

What is the best way to go about identifying those functions? I assume that there would be some way to develop a FLIRT signature for this, but I am unsure what would be the best way to approach developing a proper signature for this firmware. Any help or guidance would be really appreciated!

Answer 1

There is a project called Sibyl based on the symbolic execution framework miasm. They basically call each unknown function with test cases until it passes all test cases for a given hypothesis.

E.g. if the unknown function is "strlen", one test case could be: It should, when you call it with the single parameter "AAAAAAA", not crash and return 7.

Sibyl also lets you generate and learn test cases from a known library and try to find matching functions in an unknown binary.

I must admit that I have not really used it, I just stumbled upon it because I created something vaguely similar using angr and had a look at the source code. Sibyl supports ARM, so you might want to give it a try.

Answer 2

Using FLIRT for C code requires you to know the exact version of CRT and the exact flags of the compilation so that you could build it yourself and then, having all the binaries and debug symbols, create the signatures from .a or .obj or .lib. But there are so many variations of CRT built with various versions of the compilers. And there's no way to determine the build flags, so it's very unlikely that you'll be able to use FLIRT in this case. So the best thing you can do is static analysis. In the firmware there's usually enough assert messages and error logging which can help you to determine some basic stuff like alloc, free, fopen, fwrite, fread, fclose. sprintf is also quite easy to find. Also use the fact that CRT functions are grouped together, i.e. if you find one, then the function above it and below it (I'm talking about the addresses) is library function too.