[------------------------------------------------------------------------] [-- Uninformed Research -- informative information for the uninformed. --] [------------------------------------------------------------------------] [-- Genre : Development --] [-- Name : needle --] [-- Desc : Linux x86 run-time process manipulation --] [-- Url : http://www.uninformed.org/ --] [-- Use : EVILNESS --] [------------------------------------------------------------------------] [-- Author : skape (mmiller@hick.org) --] [-- Date : 01/19/2003 --] [------------------------------------------------------------------------] [-- Table of contents: --] 1) Overview 1.1) Topics 1.2) Techniques 1.3) Execution Diversion 2) Memory Allocation 3) Memory Management 4) Library Injection 5) Code Injection 5.1) Forking 5.2) Threading 5.3) Function Trampolines 6) Conclusion 7) References [-- 1) Overview --] So, you want to be evil and modify the image of an executing process? Well, perhaps you've come to the right place. This document deals strictly with some methodologies used to to alter process images under Linux. If you're curious about how to do something similar to the things listed in this document in Windows, please read the ``References`` section. [-- 1.1) Topics --] The following concepts will be discussed in this document as they relate to run-time process manipulation: * Memory Allocation The use of being able to allocate and deallocate memory in a running process from another process has awesome power for such scenarios as execution diversion (the act of diverting a processes execution to your own code), data hiding (the act of hiding data in a process image), and even, in some cases allocating dynamic structures/strings for use within a process for its normal execution. These aren't the only uses, but they're all I could think of right now :). See the ``Memory Allocation`` section for details. * Memory Management The ability to copy arbitrary memory from one process to another at arbitrary addresses allows for flexible manipulation of a given processes memory image. This can be applied to copy strings, functions, integers, everything. See the ``Memory Management`` section for details. * Library Injection The ability to inject arbitrary shared objects into a process allows for getting at symbols that an executable would not normally have as well as allowing an evil-doer such as yourself to inject arbitrary PIC that can reference symbols in an executable without getting in trouble. This alone is extremely powerful. See the ``Library Injection`` section for details. * Code Injection Well, when you get down to it, you just want to execute code in a given process that you define and you want to control when it gets executed. Lucky for you, this is possible AND just as powerful as you'd hoped. This document will cover three types of code injection: 1) Forking The act of causing a process to create a child image and execute arbitrary code. 2) Threading The act of causing a process to create a thread that executes an arbitrary function. 3) Function Trampolines The act of causing a call to a given function to 'trampoline' to arbitrary code and then 'jump' back to the original function. [-- 1.2) Techniques --] As of this document I'm aware of two plausible techniques for altering the image of an executing process: * ptrace Likely the most obvious technique, the ptrace (process trace) API allows for altering of memory, reading of memory, looking and setting registers, as well as single-stepping through a process. The application for these things as it pertains to this document should be obvious. If not, or if you're curious, read the ``References`` section for more details on ptrace. * /proc/[pid]/mem This technique is more limited in the amount of things it can do but is by no means something that should be cast aside. With the ability to read/write a given process's image, one could easily modify the image to do ``Code Injection``. Doing things like memory allocation, management, and library injection via this method are quote a means harder but *NOT* impossible. They would take a decent amount of hackery though. (Theoretical, not proven yet, by me at least.) [-- 1.3) Execution Diversion --] In order to do most of the techniques in this document we need to divert the execution of a running process to code that we control. This presents a few problems off the bat. Where can we safely put the code that we want executed? How could we possibly change the course of execution? How do we restore execution once our code has finished? Well, thankfully, there are answers to these questions, and they're pretty easy to answer. Let's start with the first one. * Where can we safely put the code that we want executed? Well to answer this question you need to have a slight understanding of how the process is laid out and how the flow of execution goes. The basic tools you need in your knowledge base are that executables have symbols, symbols map to vma's that are used to tell the vm where symbols should be located in memory. This is used not only for functions, but also for global variables. With that said, we can tell where code will be in an executable based off processing the ELF image associated with the process. Example: root@rd-linux:~# objdump --syms ./ownme | grep main 08048450 g F .text 00000082 main This tells us that main will be found at 0x08048450 when the program is executing. But what good does this do us? A lot. Considering the main function is the 'gateway' to normal code execution, it's an excellent place to use as a dumping zone for arbitrary code. There are some restrictions, however. The code has some size restrictions. Here's the preamble and some code from main in ./ownme: root@rd-linux:~# objdump --section=.text / --start-address=0x08048450 --stop-address=0x080484d4 / -d ./ownme ./ownme: file format elf32-i386 Disassembly of section .text: 08048450 <main>: 8048450: 55 push %ebp 8048451: 89 e5 mov %esp,%ebp 8048453: 83 ec 08 sub $0x8,%esp 8048456: 90 nop 8048457: 90 nop 8048458: 90 nop ... 80484d0: c9 leave 80484d1: c3 ret Granted, main isn't always the entry point, but it's easy to find out what is by the e_entry attribute of the elf header. Now, the reason I say main is a great place to use as a dump zone is because it holds code that will _never be accessed again_. This is the key. There are lots of other places you could use as a dumpzone. For instance, if the application contains a large helper banner, you could put code over the help banner considering the banner wont be printed ever again once the program is executing. Use your imagination, you'll think of lots more. 'main' is the most generic method, since it's guaranteed in every application. Well, now we know where we can safely put code to be executed, but how do we actually execute it? * How could we possibly change the course of execution? In order to change the course of execution in a process you need some working knowledge of ptrace and how the vm traverses an executable. Assuming you have both, read on. On x86 there is a vm register used to hold the vma of the NEXT instruction. Once an instruction finishes, the vm processes the instruction at eip (the vm register) and increments eip by the size of the current instruction. There are some instructions, such as jmp and call which are themselves execution diversion functions that cause eip to be changed to the address specified in the operand. We use this same principal when it comes to changing our course of execution to what we want. Now, let's say that we theoretically put some of our own code at 0x08048450 (the address of main above) using the functionality from the ``Memory Management`` section. In order to have our code get executed (since it would normally never get executed) we use ptrace's PTRACE_SETREGS and PTRACE_GETREGS functionality. These two methods allow a third party process to obtain the registers and set the registers of another process. These registers include eip. In order to change the execution we perform the following steps: 1) call PTRACE_GETREGS to obtain the 'current' set of registers. 2) set eip in the returned set of registers to 0x08048450 (the address of our code). 3) call PTRACE_SETREGS with our modified structure. 4) continue the course of execution. We've now successfully caused our code to be executed, but there's a problem. We injected a small chunk of code that we wanted to be run, but then we wanted the process to return to normal execution. That brings us to the next question. * How do we restore execution once our code has finished? Glad you asked, because this is the most important part. In order to restore execution we need a to modify our injected code just a bit in order to make it easy for us to restore execution. We do this by adding an instruction near the end: int $0x3 This is on Linux (and Windows) to signal an exception or breakpoint to the active debugger. In the case of Linux, it sends a SIGTRAP, which, if the process is being traced will be caught by wait(). Okay, so we've modified our code and let's say it looks something like this: nop nop nop nop nop nop mov $0x1, %eax int $0x3 nop The code is setup with a 6 byte nop pad at the top to make our changing of eip more cleaner (and safer) due to the way the vm reacts to our execution diversion. The movement of 1 into eax is just an example of our arbitrary code. The int $0x3 alerts our attached debugger (ptrace) and the nop is for padding so we can see when we hit the end of our code. Okay, that's a lot of stuff. Let's walk through our modified process of execution now. This assumes you've already injected your code at main (0x08048450): 1) call PTRACE_GETREGS to obtain the 'current' set of registers 2) save these registers in another structure. This is used for restoration. 3) set eip in the returned set of registers to 0x08048450 (the address of our code). 4) call PTRACE_SETREGS with the modified structure. 5) continue execution, but watch for signals with the wait() function. If the wait function returns a signal that is a stop signal: a) call PTRACE_GETREGS and get the current set of registers b) if eip is equal to the size of your injected code - 1 (the location of the nop at the end), you know you've reached the end of your code. go to step 6 at this point. c) otherwise, continue executing. 6) at this point your code has finished. call PTRACE_SETREGS with the saved structure from step 2 and you're finished. you've successfully diverted and reverted execution. That was a mouthful, but it's very important that it's understood. All of the topics in this document emplore this underlying logic to perform their actions. Each one has a 'stub' assembly function that gets injected into a process at main to be executed. This code is meant to be small due to the fact that there are potential size issues. Oh, and another thing, you have full control over every register in this scenario because the registers are restored with PTRACE_SETREGS before the 'normal' execution continues. [-- 2) Memory allocation --] Memory allocation is one of the key features in this documented as all of the sub topics in Execution Diversion are dependant on its functionailty. Memory allocation allows for dynamic memory allocation in another process (duh). The most applicable scenario with regards to this document for such a thing are the storage of arbitrary code in memory without size limitations. This allows one to inject a very large function for execution without having fear that they will overrun into another function or harmful spot. Memory allocation is relatively simple, but understanding how to get from a to b requires a bit of explaining. The first thing we need to do is figure out where malloc will be in a given process image so that we may call into it. If we can figure that out we should be home free considering what we know from section 1.3. Realize that all these steps below can and are easily automated, but for sake of knowing, here they are: 1) Where could malloc possibly be? Well, let's see what our choices are: root@rd-linux:~# ldd ./ownme libc.so.6 => /lib/libc.so.6 (0x40016000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) root@rd-linux:~# objdump --dynamic-syms --section=.text / /lib/libc.so.6 | grep malloc 0006df90 w DF .text 00000235 GLIBC_2.0 malloc root@rd-linux:~# objdump --dynamic-syms --section=.text / /lib/ld-linux.so.2 | grep malloc 0000c8f0 w DF .text 000000db GLIBC_2.0 malloc Alright, so we've got malloc in both libc and ld-linux. We could probably use either but what about programs that don't use libc? In order to be the most flexible, we should use ld-linux. This also has a positive side effect which is that every elf binary has an 'interpreter', and, it just so happens to ld-linux is that interpreter. 2) Alright, so we know the vma of malloc is at 0x0000c8f0, but that doesn't exactly look like a valid vma. That's because it's not. It's an offset. The actual vma can be calculated by adding the base address from ldd for ld-linux (0x40000000) to the offset (0x0000c8f0) which, in turn produces the full vma 0x4000c8f0. Now we know exactly where malloc is. 3) Cool, so we know where malloc is, now all we need to do is divert execution to some code that calls it and revert back. We also need the return address from malloc though so we know where our newly allocated buffer is at. Fortunately, this is quite easy with PTRACE_GETREGS. eax will hold the return value (cdecl). The code is pretty simple and, considering we control all the registers, we can use them to pass arguments, such as size, into our code at the time of diversion. Here's some code that will, when diverted to with the correctly initialized registers, call malloc and interrupt into the debugger: nop # nop pads nop nop nop nop nop push %ebx # push the size to allocate onto the stack call *%eax # call malloc add $0x4, %esp # restore the stack int $0x3 # breakpoint nop The above code expects the 'size' parameter in ebx and the address of malloc in eax. 4) Alrighty, so now we've executed our code and we're ready to restore the process to normal execution, but wait, we need the address malloc returned. We simply use PTRACE_GETREGS and save eax and we've successfully allocated memory in another process, and we have the address to prove it. The same steps above can be used for deallocating memory, simply s/malloc/free/g and you're set :). [-- 3) Memory management --] I'm only going to briefly cover the concept of copying memory from one process to another as it's sort of out of the scope of this document. If you're more curious, read about memgrep in the ``References`` section. Copying memory from one process to another simply entails the use of PTRACE_POKEDATA which allows for writing 4 bytes of data to a given address inside a process. Not much more is needed to be known from that point on :). [-- 4) Library Injection --] Library injection is very powerful when it comes to using functionality inside a running process that it wasn't meant to be doing. One of the more obvious applications is that of loading a personally developed shared object into a running executable. This one was fun to figure out, so I'll just kind of walk you through the process I took. First thing's first, we need to figure out how to load a library without the binary being linked to libdl. libdl is what provides functions like dlopen(), dlsym(), and dlclose(). The problem is that executables don't link to this library by default. That means we can't do our magic technique of figuring out where dlopen will be in memory because, well, it isn't guaranteed to be there. There's still hope though. dl* functions are mainly just stubs that make calling the underlying API easier. Kind of like how libc makes calling syscalls easier. Since these are just wrappers, there have to be implementers, and indeed, there are. Check this out: root@rd-linux:~# objdump --dynamic-syms /lib/libc.so.6 | / grep _dl_ | egrep "open|close|sym" 000f7d10 g DF .text 000001ad GLIBC_2.2 _dl_vsym 000f6f10 g DF .text 000006b8 GLIBC_2.0 _dl_close 000f6d80 g DF .text 00000190 GLIBC_2.0 _dl_open 000f7c00 g DF .text 0000010d GLIBC_2.2 _dl_sym Well, isn't it our lucky day? libc.so.6 has _dl_open, _dl_sym, and _dl_close. These look amazingly similar to their dl* wrappers. In fact, they're almost exactly the same. Compare the prototypes: extern void *dlopen (const char *file, int mode); extern void *dlsym (void *handle, const char *name) extern int dlclose (void *handle); To: void *_dl_open (const char *file, int mode, const void *caller); void *_dl_sym (void *handle, const char *name, void *who); void _dl_close (void *_map); Pretty much the same right? Looks very promising. So here's what we know as of now: * We know where the _dl_* symbols will be at in the processes virtual memory. (We can calculate it the same way we did malloc) * We know the prototypes. One thing we don't know is how the functions expect their arguments. One would think they'd be stack based, right? Well, not so. They seem to use a variation of fastcall (like syscalls). Here's a short dump of _dl_open: 000f6d80 <.text+0xdde00> (_dl_open): f6d80: 55 push %ebp f6d81: 89 e5 mov %esp,%ebp f6d83: 83 ec 2c sub $0x2c,%esp f6d86: 57 push %edi f6d87: 56 push %esi f6d88: 53 push %ebx f6d89: e8 00 00 00 00 call 0xf6d8e f6d8e: 5b pop %ebx f6d8f: 81 c3 ba 10 02 00 add $0x210ba,%ebx f6d95: 89 c7 mov %eax,%edi f6d97: 89 d6 mov %edx,%esi f6d99: 89 4d e4 mov %ecx,0xffffffe4(%ebp) f6d9c: f7 c6 03 00 00 00 test $0x3,%esi f6da2: 75 1c jne 0xf6dc0 f6da4: 83 c4 f4 add $0xfffffff4,%esp Looks pretty normal for the most part right? Well, up until 0xf6d95 at least. It's quite odd that it's referencing eax, edx, and ecx which have not been initialized in the context of _dl_open, and then using them and operating on them later in the function. Very strange to say the least. Unless, of course, the arguments are being passed in registers instead of via the stack. Let's look at the source code for _dl_open. void * internal_function _dl_open (const char *file, int mode, const void *caller) { struct dl_open_args args; const char *objname; const char *errstring; int errcode; if ((mode & RTLD_BINDING_MASK) == 0) /* One of the flags must be set. */ _dl_signal_error (EINVAL, file, NULL, N_("invalid mode for dlopen()")); .... } Okay, so we see roughly the first thing it does is do a bitwise and on the mode passed in to make sure it's valid. It does the and with 0x00000003 (RTLD_BINDING_MASK). Do we see any bitwise ands with 0x3 in the disasm? We sure do. At 0xf6d9c a bitwise and is performed between $0x3 and esi. So esi must be where our mode is stored, right? Yes. Let's see where esi is set. Looks like it gets set at 0xf6d97 from edx. Okay, so maybe edx originally contained our mode. Where does edx get set? No where in _dl_open. That means the mode must have been passed in a register, and not on the stack. If you do some more research, you determine that the arguments are passed as such: eax = library name (ex: /lib/libc.so.6) ecx = caller (ex: ./ownme) edx = mode (ex: RTLD_NOW | 0x80000000) Alright, so we know how arguments are passed AND we know the address to call when we want to load a library. From this point things should be pretty obvious. All one need do is allocate space for the library name and the caller in the image using the ``Memory Allocation`` technique. Then copy the library and image using the ``Memory Management`` technique. Then, finally, execute the stub code that loads the library. That code would look something like this: nop # nop pads nop nop nop nop nop call *%edi # call _dl_open int $0x3 # breakpoint nop This code expects the arguments to already be initialized in the proper registers from what we determine above and it expects _dl_open's vma to be in edi. Welp, we've successfully injected a shared object into another processes image. What you do from here is up to the desired outcome. Calling _dl_sym and _dl_close uses the same code as above, but their arguments are as follows: _dl_sym expects: eax = library handle opened by _dl_open edx = symbol name (ex: 'pthread_create') _dl_close expects: eax = library handle opened by _dl_open [-- 5) Code Injection --] I must say we're getting rather hardcore, we can allocate memory, copy memory and load shared objects into arbitrary processes. What more could we possibly want? How about some arbitrary, controlled code execution that isn't limited by size? Sounds spiffy! [-- 5.1) Forking --] Let's say we want to fork a child process inside the context of another process and have it execute an arbitrary function that we've allocated and stored in the processes memory image via the ``Memory Allocation`` and ``Memory Management`` methods. Doing the fork is as simple as writing up some code that will use ``Execution Diversion`` to fork the child and return control to the parent as if nothing happened. An example of forking and executing a supplied function is as follows: nop # nop pads nop nop nop nop nop mov $0x2, %eax # fork syscall int $0x80 # interrupt cmp $0x00, %eax # is the pid stored in eax 0? if so, # we're the child jne fork_finished # since eax wasn't zero, it means we're the # parent. jmp to finished. push %ebx # since we're the child, we push the start # addr call *%edi # then we call the function mov $0x1, %eax # exit the child process int $0x80 # interrupt fork_finished: int $0x3 # we're the parent, we breakpoint. nop This code expects the following registers to be set: ebx = the argument to be passed to the function edi = the vma of the function call in the context of the child. Forking is really as simple as that. Now, one side effect is that if the daemon does not expect fork children (ie, it doesn't call wait()) then your child process will show up as defunct when it exits due to not being cleaned up properly. There are ways around this, though. You could use the ``Execution Diversion`` technique to perform cleanup of exitted children after for the process. [-- 5.2) Threading --] Similar to forking, but different by the fact that a thread runs in the context of the caller and shares memory, threading allows for pretty much the same things that forking does. There are some risks with threading though. For instance, it is _NOT_ safe to create a thread in a process that does not natural thread. This is for multiple reasons -- the most important being that the threading environment is setup at load time (in the case of pthreads). If Linux didn't use some ghetto application-level threading architecture, things wouldn't be so bad. If you really do want to take the risk of creating a thread, the process would be something like this: 1) Inject libpthread.so into the process (``Library Injection``) 2) Find pthread_create's vma in the process (``Library Injection``) 3) Allocate and copy user defined code (``Memory Allocation``) 4) Perform ``Execution Diversion`` on the stub code to create the thread. An example of such code is: nop # nop pads nop nop nop nop nop sub $0x4, %esp # space for the id mov %esp, %ebp # store esp in ebp for pushing push %ebx # push argument push %eax # push function push $0x0 # no attributes push %ebp # push addr to store thread id in call *%edi # call pthread_create add $0x14, %esp # restore stack int $0x3 # breakpoint nop Like I said, threading is dangerous. Know your program before attempting to inject a thread. You will get odd results if you inject a thread into a process that doesn't naturally thread. [-- 5.3) Function Trampolines --] Function trampolines are a great way to transparently hook arbitrary functions in memory. I'll give a brief overview of what a function trampoline is and how it works. The basic jist to how function trampolines work is that they overwrite the first x instructions where the size of the x instructions is at least six bytes. The six bytes come from the fact that on x86 unconditional jumps take up 6 bytes in opcodes. The x instructions are replaced with the jmp instruction that jumps to an address in memory that contains the injected function. This function runs before the actual function runs, and thus, has complete control over whether the actual function even gets called. At the end of the injected function the x instructions are appended as well as a jump back to the original function plus the size of the x instructions. Here's an example: Let's say we want to hook the function 'testFunction' in the executable 'ownme'. root@rd-linux:~# objdump -d ownme --start-addr=0x080484d4 ownme: file format elf32-i386 Disassembly of section .init: Disassembly of section .plt: Disassembly of section .text: 080484d4 <testFunction>: 80484d4: 55 push %ebp 80484d5: 89 e5 mov %esp,%ebp 80484d7: 83 ec 18 sub $0x18,%esp ... 8048500: c9 leave 8048501: c3 ret Well, it looks like the first 3 instructions match our criteria of at least 6 bytes. Let's keep those 6 bytes of opcodes tucked away for now. We need to be smart here. We're going to do a jmp that says jmp to address stored in address x. We're also going to want to restore back to the original place. That means when we allocate our memory we should allocate it in a format like this: [ 4 bytes storing the address of our code ] [ 4 bytes storing the address to jmp back to ] [ X bytes of arbitrary code ] [ X bytes containing the X instructions that we overwrote ] [ 6 bytes for the jump back ] So let's say we want to inject this code and we allocated a buffer in the process of the approriate length which starts at 0x41414140: nop movb $0x1, %al Our actual buffer in memory would look something like this 0x41414140 = 0x41414148 (address of our code) 0x41414144 = 0x080484d8 (address to jmp back to) 0x41414148 = 3 bytes (nop, movb) 0x4141414B = 6 bytes of preamble from testFunction 0x41414152 = jmp *0x41414144 The last step now that we have our code injected is to overwrite the actual preamble (the 6 bytes of testFunction) with the jmp to our code. The assembly would look something like this: jmp *0x41414140 # Jump to the address stored in 0x41414140 Once that's overwritten, we're home free. The flow of execution goes like this: 1) Call to testFunction 2) First instruction of testFunction is: jmp *0x41414140 3) vm jumps to 0x41414148 an executes: nop movb $0x1, %al push %ebp mov %esp, %ebp sub $0x18, %esp jmp *0x41414144 4) vm jumps to 0x080484d8 5) Function executes like normal. That's all there is to it. There are a couple of restrictions when using trampolines: 1) NEVER modify the stack without restoring it before the original functions preamble gets called. Bad things will happen. 2) Becareful what registers you modify. Some functions may use fastcall. For more information on function trampolines, see the ``References`` section. [-- 6) Conclusion --] That about wraps it up. You now have the tools to allocate, copy, inject libraries, create forks, create threads, and install function trampolines. You also have the underlying concept of ``Execution Diversion`` which can be applied across the board to even more things I haven't even thought of yet. [-- 7) References --] * For information about ``Function Trampolines``: http://research.microsoft.com/sn/detours
