Izik
2005
This paper talks about glibc initialization framework and how abusive constructors and destructors can be. A quick analysis of how ordinary ELF executable that been compiled using gcc and linked against glibc is been loaded and executed. Also a practical example of abusive constructors, an Anti-Debugging that been implemented within a constructor that puts up a nice fight.
Some knowledge of C, ASSEMBLY and ELF format are required.
The ELF format specifies that each executable should have an entry point as part of the ELF header structure. The entry point is a virtual address that the system first transfers control to once the process started. Depending on the way the program has been compiled and linked the entry point can point straightly to main() or in our case to glibc initialization code. Once glibc been initialized it is invoking the program main() transparently.
To demonstrate this compile the snippet above it in an ordinary way using gcc, like this:
To discover the executable entry point, use the objdump utility like this:
root@magicbox:/tmp# objdump -f ./foobar ./foobar: file format elf32-i386 architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x080482c0
Once we got the executable entry point, we can start examine it. Disassembling it through gdb:
This is a glibc initialization code. It is not fixed and changes based on a different platforms and CPU types but the concept remains the same. This code at some point transfer control to the program main() function.
Quick analysis of this code shows it initialize the stack but also pushes three addresses to the stack as well:
To avoid been dragged into a long-disassemble-session. I would make a few shortcuts and say the following:
So we know for sure that our executable entry point isn't pointing to our main() rather to a glibc initialization code. Which invokes the '__libc_start_main' function that takes '__libc_csu_fini' , '__libc_csu_init' and 'main' addresses as parameters.
Studying the glibc initialization code shows that '__libc_csu_fini' and '__libc_csu_init' functions have a special purpose in the startup flow. The '__libc_csu_init' acts as the constructor function. Is job is to be invoked prior to the real program in our case the main() function. That is an ideal place to put program related initialization code. The '__libc_csu_fini' function acts as the destructor function. Is job is to be invoked as the last function, thus to make sure the program hasn't left anything behind and made a nice clean exit.
In a shared libraries programming, the programmers have two functions '_init' and '_fini' which are the shared library constructer and destructor functions. Our executable has these two functions as well. Only in our case they are been part of an integration mechanism.
Overriding these functions is not possible since they play a role for glibc. However you may create your own constructor and destructor functions and glibc would honor them. It is possible to due gcc attributes extension. gcc supports number of attributes that the programmer may apply to functions. The '((constructor))' attribute and '((destructor))' attribute is what we seek. Let's try to implement it, as follow:
Having these two functions in our code. We expect that 'foobar_init' would be called prior to our main() function. And 'foobar_fini' afterward.
root@magicbox:/tmp# ./foobar2 Good Morning, Foobar! I'm Foobar! Good Night, Foobar!
Understanding exactly what caused these two functions to be integrated with the glibc initialization code. We will once again refer to our favorite debugger to disassemble the glibc initialization code. Earlier I mention that '_init' and '_fini' functions in our case been part of an integration mechanism and there is our key.
We will start by disassembling the '_init' function. This function is been called from '__libc_csu_init', as following:
Now let's disassemble the '_init' function, as following:
Going over these calls. We can see that our last call is the one we interested at, thus the '__do_global_ctors_aux' function.
At first look this function seems to be a little bit abstract. It repeatedly trying to call an address that stored into the eax register. It does that as long as the eax register isn't equals to '0xffffffff'. the eax register is been initialized with the given address '0x80494d8'. Insert a breakpoint at 0x08048493 -- where the CALL been made to see what code resident at the given address?
As you can see our code is been executed. The '__do_global_ctors_aux' function job is to invoke the program specified constructors.
The addresses of the constructors and destructors each stored in a different section in our ELF executable. for the constructors there is a section called '.CTORS' and for the destructors there is the '.DTORS' section. using the objdump utility we can dump the .CTORS section:
root@magicbox:/tmp# objdump -s -j .ctors ./foobar2 ./foobar2: file format elf32-i386 Contents of section .ctors: 8049534 ffffffff 84830408 00000000 ............
The structure of these sections is:
'ffffffff <ANOTHER ADDRESS OF FUNCTION> <ADDRESS OF FUNCTION> 00000000'
And the '__do_global_ctors_aux' function simply performs a walk on the '.CTORS' section, as '__do_global_dtors_aux' does the same job only for the '.DTORS' section which contains the program specified destructors functions.
The constructors and destructors functions resident on the .TEXT section as the rest of our code. they are placed a little bit before the main() function is. but their locating on the .TEXT section is irreverent for the concept.
To conclude our analysis glibc initialization code allows us to specify a functions that would run prior to main() and right after. The initialization code programmed in a way it would go through '.CTORS' and '.DTORS' sections. Looking for an addresses of functions and would invoke it as part of the process.
Constructors and destructors can be abused. I am going to demonstrate how implementation of a simple anti-debugging trick in the constructor. Which can put up a good fight against Reverse Engineering of the executable?
The snippet above would perform a PTRACE on itself. If this action failed means another process already done so and this is usually induces the process been debugged. Since there is no visible modification in our executable initial flow and the glibc initialization code looks the same. The only real difference is that ptrace_trap() function address now stored in the ELF executable '.CTORS' section and would be executed during glibc initialization process.
Constructors and destructors are also ideal place for PACKERS implementation. Encrypting or compressing the actual program code then using the constructor function in order to decompress/decrypt the executable can be a nice trick.
This can be also used as a technique of ELF infecting mechanism. As the parasite resident on the .TEXT section and place is address in the .CTORS and .DTORS make sure that once privileged user such as root would execute the file it would begin to spread and takeover the box.