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?

  • Is the binary packed with UPX or some variant thereof? How do you know it is malware? What is the SHA1-sum of the binary? Where did you get it from? Is the binary statically linked or dynamically linked? Is there a section header table present? What is the target architecture of the binary? No symbol table means no function names. syssec.mistakenot.net/papers/eurosp-2017.pdf
    – julian
    Apr 26, 2018 at 21:42
  • which disassembler are you using?
    – Igor Skochinsky
    Apr 27, 2018 at 7:06
  • Using radare2, it's a 32 bit elf of mirai from virusshare for arm. Pretty sure it's statically linked
    – bumchux
    Apr 27, 2018 at 19:58

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.