Chapter 6. ELF Binary Forensics in Linux

The field of computer forensics is widespread and includes many facets of investigation. One such facet is the analysis of executable code. One of the most insidious places for a hacker to install some type of malicious functionality is within an executable file of some kind. In Linux, this is, of course, the ELF file type. We already explored some of the infection techniques that are being used in Chapter 4, ELF Virus Technology – Linux/Unix Viruses, but have spent very little time discussing the analysis phase. How exactly should an investigator go about exploring a binary for anomalies or code infections? That is what this chapter is all about.

The motives for an attacker infecting an executable varies greatly, and it may be for a virus, a botnet, or a backdoor. There are, of course, many cases where an individual wants to patch or modify a binary to achieve totally different ends such as binary protection, code patching, or other experimentation...

The science of detecting entry point modification

When a binary is modified in some way, it is generally for the purpose of adding code to the binary and then redirecting execution flow to that code. The redirection of execution flow can happen in many places within the binary. In this particular case, we are going to examine a very common technique used when patching binaries, especially for viruses. This technique is to simply modify the entry point, which is the e_entry member of the ELF file header.

The goal is here to determine whether or not e_entry is holding an address that points to a location that signifies an abnormal modification to the binary.

Note

Abnormal means any modification that wasn't created by the linker itself /usr/bin/ld whose job it is to link ELF objects together. The linker will create a binary that represents normalcy, whereas an unnatural modification often appears suspicious to the trained eye.

The quickest route to being able to detect anomalies is to first know...

Detecting other forms of control flow hijacking

There are many reasons to modify a binary, and depending on the desired functionality, the binary control flow will be patched in different ways. In the previous example of the Retaliation Virus, the entry point in the ELF file header was modified. There are many other ways to transfer execution to the inserted code, and we will discuss a few of the more common approaches.

Patching the .ctors/.init_array section

In ELF executables and shared libraries, you will notice that there is a section commonly present named .ctors (commonly also named .init_array). This section contains an array of addresses that are function pointers called by the initialization code from the .init section. The function pointers refer to functions created with the constructor attribute, which are executed before main(). This means that the .ctors function pointer table can be patched with an address that points to the code that has been injected into the binary, which...

Identifying parasite code characteristics

We just reviewed some common methods for hijacking execution flow. If you can identify where the execution flow points, you can typically identify some or all of the parasite code. In the section Detecting PLT/GOT hooks, we determined the location of the parasite code for the hijacked puts() function by simply locating the PLT/GOT entry that had been modified and seeing where that address pointed to, which, in that case, was to an appended page containing parasite code.

Parasite code can be qualified as code that is unnaturally inserted into the binary; in other words, it wasn't linked in by the actual ELF object linker. With that said, there are several characteristics that can sometimes be attributed to injected code, depending on the techniques used.

Position independent code (PIC) is often used for parasites so that it can be injected into any point of a binary or memory and still execute properly regardless of its position in memory. PIC parasites...

Checking the dynamic segment for DLL injection traces

Recall from Chapter 2, The ELF Binary Format, that the dynamic segment can be found in the program header table and is of type PT_DYNAMIC. There is also a .dynamic section that also points to the dynamic segment.

The dynamic segment is an array of ElfN_Dyn structs that contains d_tag and a corresponding value that exists in a union:

     typedef struct {
               ElfN_Sxword    d_tag;
               union {
                   ElfN_Xword d_val;
                   ElfN_Addr  d_ptr;
               } d_un;
           } ElfN_Dyn;

Using readelf we can easily view the dynamic segment of a file.

Following is an example of a legitimate dynamic segment:

$ readelf -d ./test

Dynamic section at offset 0xe28 contains 24 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x4004c8
 0x000000000000000d (FINI)               0x400754...

Identifying reverse text padding infections

This is a virus infection technique that we discussed in Chapter 4, ELF Virus Technology – Linux/Unix Viruses. The idea is that a virus or parasite can make room for its code by extending the text segment in reverse. The program header for the text segment will look strange if you know what you're looking for.

Let's take a look at an ELF 64-bit binary that has been infected with a virus that uses this parasite infection method:

readelf -l ./infected_host1

Elf file type is EXEC (Executable file)
Entry point 0x3c9040
There are 9 program headers, starting at offset 225344

Program Headers:
 Type         Offset             VirtAddr           PhysAddr
              FileSiz            MemSiz              Flags  Align
 PHDR         0x0000000000037040 0x0000000000400040 0x0000000000400040
              0x00000000000001f8 0x00000000000001f8  R E    8
 INTERP       0x0000000000037238 0x0000000000400238 0x0000000000400238
              0x000000000000001c 0x000000000000001c...

Identifying text segment padding infections

This type of infection is relatively easy to detect. This type of infection was also discussed in Chapter 4, ELF Virus Technology – Linux/Unix Viruses. This technique relies on the fact that there is always going to be a minimum of 4,096 bytes between the text and the data segment because they are loaded into memory as two separate memory segments, and memory mappings are always page aligned.

On 64-bit systems, there is typically 0x200000 (2MB) free due to PSE (Page size extension) pages. This means that a 64-bit ELF binary can be inserted with a 2MB parasite, which is much larger than what is typically needed for an injection space. With this type of infection, like any other, you can often identify the parasite location by examining the control flow.

With the lpv virus which I wrote in 2008, for instance, the entry point is modified to start execution at the parasite that is inserted using the text segment padding infection. If the executable...

Identifying protected binaries

Identifying a protected binary is the first step in reverse-engineering it. We discussed the common anatomy of protected ELF executables in Chapter 5, Linux Binary Protection. Remember from what we learned that a protected binary is actually two executables that have been merged together: you have the stub executable (the decryptor program) and then the target executable.

One program is responsible for decrypting the other, and it is this program that is going to typically be the wrapper that wraps or contains an encrypted binary within it, as a payload of sorts. Identifying this outer program that we call a stub is typically pretty easy because of the blatant oddities you will see in the program header table.

Let's take a look at a 64-bit ELF binary that is protected using a protector I wrote in 2009 called elfcrypt:

$ readelf -l test.elfcrypt

Elf file type is EXEC (Executable file)
Entry point 0xa01136
There are 2 program headers, starting at offset 64

Program...

IDA Pro

Since this book tries to focus on the anatomy of the ELF format, and the concepts behind analysis and patching techniques, we are less focused on which of the fancy tools to use. The very famous IDA Pro software has a well-deserved reputation. It is hands down the best disassembler and decompiler available to the public. It is expensive though, and unless you can afford a license, you may have settle for something a little less effective, such as Hopper. IDA Pro is quite complicated and requires an entire book unto itself, but in order to properly understand and use IDA Pro for ELF binaries, it is good to first understand the concepts taught in this book, which can then be applied when using IDA pro to reverse-engineer software.

Summary

In this chapter, you learned the fundamentals of ELF binary analysis. You examined the procedures involved in identifying various types of virus infection, function hijacking, and binary protection. This chapter will serve you well in the beginner to intermediate phases of ELF binary analysis: what to look for and how to identify it. In the following chapters, you will cover similar concepts, such as analyzing process memory for identifying anomalies such as backdoors and memory-resident viruses.

For those interested in knowing how the methods described in this chapter could be used in the development of an anti-virus or detection software, there do exist some tools I have designed that use similar heuristics to those described in this chapter for detecting ELF infections. One of these tools is called AVU and was mentioned with a download link in Chapter 4, ELF Virus Technology – Linux/Unix Viruses. Another one is named Arcana and is still private. I have not personally seen any...