Recognize the library functions of statically linked executable file in IDA Pro

Question

Recently I worked on a Linux program which has all of its symbols stripped. Opening it with IDA resulted in none of its functions identified.

Thus I tried to extract any usable information from the executable file with the strings and file commands, but these sadly found nothing.

I know about the FLIRT technology in IDA, but it is based on knowing the version of the static library so it can use the correct signature file. In this case it seems we have no any version information for the used glibc or other libraries, so what should we do now?

$ file stripped
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped

With the outpuf of file as shown above, can I retrieve more details from this? Or is the solution that we can only recognize it via our experience?

Answer 1

Short answer - No, there's no easy way to identity statically linked functions within an executable, other than manually reverse engineering the APIs or finding out which version if glibc exactly was used.

Unfortunately, using FLIRT might not prove useful even after you identify the exact glibc version. This is because actual instructions will be altered in the statically linking process. Some functions might be inlined if used rarely or are relatively short, for example. Advanced optimizations might make matter worse.

However, You could rather easily find SYSENTER (or int 0x80 if using older versions of glibc/linux) instructions and map those to kernel callbacks. Obviously, a lot of API functionality is implemented without ever accessing the kernel, and that you'll need to work harder to recover. It is a possibility (depends on the linker's configuration when compiling the executable) that other glibc functions will be adjacent memory-wise, so finding a few statically linked APIs could help you recover others.

Last point of advice I could give you is to rename all functions you've identified as part of glibc appropriately, even without actually identifying their functionality, glibcsub_* or a similar easily recognizable pattern. I think you'll find this useful.

Answer 2

Yet there is statistics, which can be used to find the basic library functions from which you'll be able to find other functions. E.g. there's almost a zero probability that the code doesn't allocate any memory and doesn't do any string manipulation. So you can count XREFS to all the functions and be sure that those which are called most(and called from all the parts of the binary) are the library functions. After you know where is malloc, you can find free, after you have malloc and free you can find other library functions which use malloc/free. So, if you're ready to spend your time, you can find library functions yourself.