Q:

Stripped elf executable with ~3000 unnamed functions

Reversing a malware sample and have identified the elf as stripped which seems to be why none of the functions are explicitly named. Also, there are no specified imports listed for some reason. Does not appear to be obfuscated though I could be wrong. The strings are not obfuscated so I have been trying to get my hands dirty in basic analysis by looking up where the strings correspond in disassembly. No doubt I will have to find a way to easily identify these thousands of functions which appear just as numerals rather than explicit names. Any suggestions?

A:

Although many ELF files have a symbol table, it is not required for executing a program by the OS. In particular, statically-linked programs embed all necessary library code inside, making the binary completely independent from any external libraries and able to run stand-alone.
So you can start by identifying library functions. There are many ways to do it, here's a few suggestuions:

If you know/can guess the compiler and the version used to compile the binary, you can try to match the libraries shipped with the compiler against the binary. GCC often leaves its version string in the binaries (sometimes even stripped ones), for example:
GCC: (Sourcery G++ Lite 2010.09-58) 4.5.1
GCC: (GNU) 4.8
you can try looking for strings which identify library source files, function names or other messages which are unique enough to identify the function, e.g.:
__get_myaddress: ioctl (get interface configuration)
RPC: (unknown error code)

If all else fails or the binary does not use a standard library, you can always fall back to tracking the use of syscalls.
The binary has to interact with the OS somehow. This is done using so-called syscalls (system calls) - special instructions which invoke OS services. On x86_64, this is done with the syscall instruction, on i386 Linux using int 0x80, while on ARM Linux, the SVC (supervisor call) instruction is used. ARM system calls on EABI systems use numbers starting from 0x900000 which are stored in r7 before invoking the SVC instruction. So, for example, you can search for 0x900004 to find the write syscalls which are likely to be used in output functions.

