----------------------------------------------------------- Abusing .CTORS and .DTORS for fun 'n profit Izik ----------------------------------------------------------- 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. ELF Roadmap ----------- 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: root@magicbox:/tmp# cat foobar.c /* * foobar.c */ #include int main(int argc, char **argv) { printf("Hello World\n"); return 1; } root@magicbox:/tmp# gcc -o foobar foobar.c 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 Surface Examine --------------- Once we got the executable entry point, we can start examine it. Disassembling it through gdb: (gdb) disassemble 0x080482c0 Dump of assembler code for function _start: 0x080482c0 <_start+0>: xor %ebp,%ebp 0x080482c2 <_start+2>: pop %esi 0x080482c3 <_start+3>: mov %esp,%ecx 0x080482c5 <_start+5>: and $0xfffffff0,%esp 0x080482c8 <_start+8>: push %eax 0x080482c9 <_start+9>: push %esp 0x080482ca <_start+10>: push %edx 0x080482cb <_start+11>: push $0x8048410 0x080482d0 <_start+16>: push $0x80483b0 0x080482d5 <_start+21>: push %ecx 0x080482d6 <_start+22>: push %esi 0x080482d7 <_start+23>: push $0x8048384 0x080482dc <_start+28>: call 0x80482a0 <_init+40> 0x080482e1 <_start+33>: hlt 0x080482e2 <_start+34>: nop 0x080482e3 <_start+35>: nop End of assembler dump. (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: * 0x8048410 * 0x80483b0 * 0x8048384 To avoid been dragged into a long-disassemble-session. I would make a few shortcuts and say the following: * 0x8048410 (aka __libc_csu_fini) is glibc _fini() function * 0x80483b0 (aka __libc_csu_init) is glibc _init() function * 0x8048384 (aka main) is our program main() function * Afterward the glibc initialization code invokes '__libc_start_main' function 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. Order in Chaos -------------- 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: root@magicbox:/tmp# cat foobar2.c /* * foobar2.c */ #include void foobar_init(void) __attribute__ ((constructor)); void foobar_fini(void) __attribute__ ((destructor)); void foobar_init(void) { printf("Good Morning, Foobar!\n"); return ; } void foobar_fini(void) { printf("Good Night, Foobar!\n"); return ; } int main() { printf("I'm Foobar!\n"); return 1; } 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! Another Bite ------------ 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: (gdb) disassemble 0x080483e0 Dump of assembler code for function __libc_csu_init: 0x080483e0 <__libc_csu_init+0>: push %ebp 0x080483e1 <__libc_csu_init+1>: mov %esp,%ebp < ... > 0x080483f6 <__libc_csu_init+22>: call 0x8048278 <_init> < ... > 0x08048434 <__libc_csu_init+84>: lea 0x0(%esi),%esi 0x0804843a <__libc_csu_init+90>: lea 0x0(%edi),%edi End of assembler dump. Now let's disassemble the '_init' function, as following: (gdb) disassemble 0x8048278 Dump of assembler code for function _init: 0x08048278 <_init+0>: push %ebp 0x08048279 <_init+1>: mov %esp,%ebp 0x0804827b <_init+3>: sub $0x8,%esp 0x0804827e <_init+6>: call 0x80482e4 0x08048283 <_init+11>: call 0x8048350 0x08048288 <_init+16>: call 0x80484a0 <__do_global_ctors_aux> 0x0804828d <_init+21>: leave 0x0804828e <_init+22>: ret End of assembler dump. Going over these calls. We can see that our last call is the one we interested at, thus the '__do_global_ctors_aux' function. (gdb) disassemble 0x080484a0 Dump of assembler code for function __do_global_ctors_aux: 0x080484a0 <__do_global_ctors_aux+0>: push %ebp 0x080484a1 <__do_global_ctors_aux+1>: mov %esp,%ebp 0x080484a3 <__do_global_ctors_aux+3>: push %ebx 0x080484a4 <__do_global_ctors_aux+4>: push %edx 0x080484a5 <__do_global_ctors_aux+5>: mov 0x8049538,%eax 0x080484aa <__do_global_ctors_aux+10>: cmp $0xffffffff,%eax 0x080484ad <__do_global_ctors_aux+13>: mov $0x8049538,%ebx 0x080484b2 <__do_global_ctors_aux+18>: je 0x80484cc <__do_global_ctors_aux+44> 0x080484b4 <__do_global_ctors_aux+20>: lea 0x0(%esi),%esi 0x080484ba <__do_global_ctors_aux+26>: lea 0x0(%edi),%edi 0x080484c0 <__do_global_ctors_aux+32>: sub $0x4,%ebx 0x080484c3 <__do_global_ctors_aux+35>: call *%eax 0x080484c5 <__do_global_ctors_aux+37>: mov (%ebx),%eax 0x080484c7 <__do_global_ctors_aux+39>: cmp $0xffffffff,%eax 0x080484ca <__do_global_ctors_aux+42>: jne 0x80484c0 <__do_global_ctors_aux+32> 0x080484cc <__do_global_ctors_aux+44>: pop %eax 0x080484cd <__do_global_ctors_aux+45>: pop %ebx 0x080484ce <__do_global_ctors_aux+46>: pop %ebp 0x080484cf <__do_global_ctors_aux+47>: ret End of assembler dump. 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? (gdb) b *0x080484c3 Breakpoint 1 at 0x80484c3 (gdb) r Starting program: /tmp/foobar2 Breakpoint 1, 0x080484c3 in __do_global_ctors_aux () (gdb) disassemble $eax Dump of assembler code for function foobar_init: 0x08048384 : push %ebp 0x08048385 : mov %esp,%ebp 0x08048387 : sub $0x8,%esp 0x0804838a : sub $0xc,%esp 0x0804838d : push $0x80484f4 0x08048392 : call 0x80482b0 <_init+56> 0x08048397 : add $0x10,%esp 0x0804839a : leave 0x0804839b : ret End of assembler dump. 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
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. Evil Grin --------- 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? -- snip snip -- /* * evilgrin.c, tweaking ptrace() to induced whatever we been debugged */ #include #include void ptrace_trap(void) __attribute__ ((constructor)); void ptrace_trap(void) { /* * If ptrace fails here, means someone already ptrace()'ed us. */ if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) { exit(0); } } int main(int argc, char **argv) { printf("Hello World!\n"); return 1; } -- snip snip -- 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. Contact ------- Izik [or] http://www.tty64.org